106 replies to this topic

[irako]

Wow... thanx for the long explanation, it seems that there is a huge progress about it, i will try the Chiken fix, and the kext from g62, i hope to get same results as you, (better would be awesome), and then wait to G62 to his miracle kext or fix!!!.../

Thanx again to all of you for all your effort!!!

[giofrida]

Guys, i need your input!

I'm trying to get Intel HD Graphics to work with a DSDT injection.
I tried to inject it and now with original kexts i got a KP, so it does not hang on boot.

I need someone with a MBP6,1 or MBP6,2 to get this infos: (about HD Graphics)

• Device ID
  
• Vendor ID
  
• Subsystem Vendor ID
  
• Subsystem Device ID
  
• Revision

Thanks to all in advance!

[iWin32]

giofrida, on 04 August 2012 - 12:11 PM, said:

Guys, i need your input!

I'm trying to get Intel HD Graphics to work with a DSDT injection.
I tried to inject it and now with original kexts i got a KP, so it does not hang on boot.

I need someone with a MBP6,1 or MBP6,2 to get this infos: (about HD Graphics)

• Device ID
  
• Vendor ID
  
• Subsystem Vendor ID
  
• Subsystem Device ID
  
• Revision

Thanks to all in advance!

Whoa!!  Slow down.  First, how are you trying to get DSDT injection to enable the Intel HD Graphics?  What is your reasoning, and what are you changing?  Second, is the KP early in the boot stage like "Could not find driver for this platform: ACPI" or is it something else?  Because in my earlier attempts to use a DSDT, I got that kernel panic.  I eventually gave up using it because I found out I was only using a version that would be read from my computer directly, anyway, and unless I had something to change for something to work (which I didn't), there was no need for a DSDT.aml file.

[giofrida]

I tried to inject the GFX0 Device with _DSM Method (changing infos of GFX). I can boot with original kexts with "GE=Yes -v" but the screen is:

Strange . I need more info about injecting the display into DSDT.

These values are picked up from IORegistryExplorer (on SL 10.6.7 w/ Partial QE/CI)


Other useful Info:

Chipset Model: Intel HD Graphics
Type: GPU
Bus: Built-In
VRAM (Total): 288 MB
Vendor: Intel (0x8086)
Device ID: 0x0046
Revision ID: 0x0012
gMux Version: 1.9.21
Displays:
Display Connector:
Status: No Display Connected

So, the new DSDT Code will be like: (add in Device (GFX0))

				Method (_DSM, 4, NotSerialized)
				{
					Store (Package (0x12)
						{
							"model",
							Buffer (0x11)
							{
								"Intel HD Graphics"
							},
							"built-in",
							Buffer (One)
							{
								0x01
							},
							"device-type",
							Buffer (0x08)
							{
								"display"
							},
							"device-id",
							Unicode ("F"),
							"vendor-id",
							Buffer (0x04)
							{
								 0x86, 0x80, 0x00, 0x00
							},
							"subsystem-vendor-id",
							Buffer (0x04)
							{
								 0x6B, 0x10, 0x00, 0x00
							},
							"subsystem-id",
							Buffer (0x04)
							{
								 0x3A, 0x14, 0x00, 0x00 <--- THIS IS WRONG!
							},
							"revision-id",
							Buffer (0x04)
							{
								 0x12, 0x00, 0x00, 0x00
							},
							"VRAM,totalsize",
							Buffer (0x04)
							{
								0x00, 0x00, 0x00, 0x12
							}
						}, Local0)
					DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					Return (Local0)
				}

I think if we can grab the right values, we can have fully QE/CI.

[ebmesnow]

I have been trying to get the 10.7.4 lion kexts to work for a while now. From what I can see the frame buffer is needed as it looks like this does the VRAM allocation and many other things. On mine with only the AppleIntelHDGraphics kext loaded I get the screen scrambled, via screen sharing there are ways I can get it to show the correct Graphics type but I think these are only cosmetic. I can get the Lion frame buffer to load on mine but have to add the following to the graphics card section of the DSDT using the above method in giofrida's post.

"AAPL,os-info",
Buffer (0x14)
{
/* 0000 */   0x30, 0x49, 0x01, 0x11, 0x01, 0x10, 0x08, 0x00,
/* 0008 */   0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
/* 0010 */   0xFF, 0xFF, 0xFF, 0xFF
},

I can see a section in the kext which looks for this value, without the os-info addition and the frame buffer I get the spinning thingy continually at startup, with the os-info addition I get a grey screen eventually, and a lot more promising entries in the registry when viewed via screen sharing and it shows 768Mb of video memory. When I tried injecting the VRAM size as above this caused me problems, one of the kexts would not load, can't remember which, but with the frame buffer loaded it shows this value anyway.

I think the problem I have is it is now not detecting the screen at all to get the size and timing information, display information is blank which without the intel frame buffer shows at least some information even if wrong. I tried many ways to try and inject display EDID information without success. What I did wonder is if the default NDRIV framebuffer on a real Mac gets this information, on our systems with a single graphics card because the Intel frame buffer has grabbed the card, the NDriv framebuffer can't get any information out of the display. I know without the Intel FB the Ndriv FB loads and shows in ioregistryexplorer against the Intel graphics. If this is the case perhaps someone could write a fake ndriv frame buffer that just reads the information, I believe the source code is available for this frame buffer?

Hope this helps someone get a little further, unfortunately I have made many changes to my DSDT to get it nearer to a real MacBookPro 6.2 so not sure if there are any other changes that have helped my intel framebuffer kext to load.

[iWin32]

ebmesnow, on 06 August 2012 - 03:22 PM, said:

I have been trying to get the 10.7.4 lion kexts to work for a while now.

Just a quick question.  Did you try this with Snow Leopard?  I would try Lion, but until I get graphics working, I only have an old version of iMovie that requires Rosetta to run.

[ebmesnow]

iWin32, on 06 August 2012 - 03:49 PM, said:

Just a quick question.  Did you try this with Snow Leopard?  I would try Lion, but until I get graphics working, I only have an old version of iMovie that requires Rosetta to run.

No unfortunately only have Lion around these days, bit of a pain to install on my laptop and get running.

[iWin32]

I decided to cave in and give Lion a shot, but:

ebmesnow, on 06 August 2012 - 03:22 PM, said:

I can get the Lion frame buffer to load on mine but have to add the following to the graphics card section of the DSDT using the above method in giofrida's post.

"AAPL,os-info",
Buffer (0x14)
{
/* 0000 */   0x30, 0x49, 0x01, 0x11, 0x01, 0x10, 0x08, 0x00,
/* 0008 */   0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
/* 0010 */   0xFF, 0xFF, 0xFF, 0xFF
},

I'm confused as to WHERE in the DSDT this should go.  You mention giofordia's post, but can't find exactly where to put it.  Googling around didn't help at all.  Can you help me?

[ebmesnow]

You need to find the Graphics section of your DSDT, probably called GFX0 or IGPU then add this code under it

Method (_DSM, 4, NotSerialized)
				{
							Store (Package (0x0A)
								{
									"hda-gfx",
									Buffer (0x0A)
									{
										"onboard-1"
									},
									"device_type",
									Buffer (0x08)
									{
										"display"
									},
									"model",
									Buffer (0x12)
									{
										"Intel HD Graphics"
									},
									"built-in",
									Buffer (One)
									{
										 0x01
									},
									"AAPL,os-info",
									Buffer (0x14)
									{
										/* 0000 */   0x30, 0x49, 0x01, 0x11, 0x01, 0x10, 0x08, 0x00,
										/* 0008 */   0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
										/* 0010 */   0xFF, 0xFF, 0xFF, 0xFF
									}
								}, Local0)
							DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
							Return (Local0)
	}

You will also need to add the DTGP method in not already included in your DSDT, this is a fairly common method of injecting stuff, used to trick kexts into think the hardware is something other than it is and used a lot in fixes, if you look at some of the standard hacks in DSDTSE you will see it frequently used.

[iWin32]

Thanks for the help, ebmesnow, and now I'm getting these errors in compiling the DSDT.aml.

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20100331 [Mar 31 2010]
Copyright (c) 2000 - 2010 Intel Corporation
Supports ACPI Specification Revision 4.0
dsdt.dsl  5284:					 Name (NBTT, Package (0x08)
Remark   5048 -											 ^ Initializer list shorter than declared package length
dsdt.dsl  6327:					 Method (BINI, 0, NotSerialized)
Warning  1088 -								^ Not all control paths return a value (BINI)
dsdt.dsl  7056:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  7060:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  7119:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  7123:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  7188:							 Name (_PLD, Buffer (0x10)
Error	4080 -			  Invalid object type for reserved name ^  (found BUFFER, requires Package)
dsdt.dsl  7205:							 Name (_PLD, Buffer (0x10)
Error	4080 -			  Invalid object type for reserved name ^  (found BUFFER, requires Package)
dsdt.dsl  7275:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  7279:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  7338:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  7342:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  7453:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  7457:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  7516:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  7520:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  7631:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  7635:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  7694:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  7698:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  7809:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  7813:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  7872:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  7876:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  7987:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  7991:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  8050:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  8054:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  8165:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  8169:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  8228:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  8232:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  8343:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  8347:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  8406:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  8410:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  8521:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  8525:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  8584:								 Name (_T_0, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_0)
dsdt.dsl  8588:									 Name (_T_1, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_1)
dsdt.dsl  9671:				 Method (_WED, 1, NotSerialized)
Warning  1099 -	  Unknown reserved name ^  (_WED)
dsdt.dsl  9671:				 Method (_WED, 1, NotSerialized)
Warning  1099 -	  Unknown reserved name ^  (_WED)
dsdt.dsl  9671:				 Method (_WED, 1, NotSerialized)
Warning  1099 -	  Unknown reserved name ^  (_WED)
dsdt.dsl  9671:				 Method (_WED, 1, NotSerialized)
Warning  1099 -	  Unknown reserved name ^  (_WED)
dsdt.dsl  9671:				 Method (_WED, 1, NotSerialized)
Warning  1099 -	  Unknown reserved name ^  (_WED)
dsdt.dsl  9731:					 Name (_T_0, Zero)
Remark   5111 -							  ^ Use of compiler reserved name (_T_0)
dsdt.dsl  9944:					 Name (_T_0, Zero)
Remark   5111 -							  ^ Use of compiler reserved name (_T_0)
dsdt.dsl 10505:							 Name (_T_0, Zero)
Remark   5111 -		Use of compiler reserved name ^  (_T_0)
dsdt.dsl 10601:					 Name (_T_0, Zero)
Remark   5111 -							  ^ Use of compiler reserved name (_T_0)
dsdt.dsl 10669:					 Name (_T_0, Zero)
Remark   5111 -							  ^ Use of compiler reserved name (_T_0)
dsdt.dsl 10728:					 Name (_T_0, Zero)
Remark   5111 -							  ^ Use of compiler reserved name (_T_0)
dsdt.dsl 11192:						 Name (_T_0, Zero)
Remark   5111 -	Use of compiler reserved name ^  (_T_0)
dsdt.dsl 11196:							 Name (_T_1, Zero)
Remark   5111 -		Use of compiler reserved name ^  (_T_1)
dsdt.dsl 11220:								 Name (_T_2, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_2)
dsdt.dsl 11242:									 Name (_T_3, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_3)
dsdt.dsl 11267:										 Name (_T_4, Zero)
Remark   5111 -					Use of compiler reserved name ^  (_T_4)
dsdt.dsl 11306:											 Name (_T_5, Zero)
Remark   5111 -						Use of compiler reserved name ^  (_T_5)
dsdt.dsl 11348:						 Name (_T_6, Zero)
Remark   5111 -	Use of compiler reserved name ^  (_T_6)
dsdt.dsl 11352:							 Name (_T_7, Zero)
Remark   5111 -		Use of compiler reserved name ^  (_T_7)
dsdt.dsl 11372:								 Name (_T_8, Zero)
Remark   5111 -			Use of compiler reserved name ^  (_T_8)
dsdt.dsl 11394:									 Name (_T_9, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_9)
dsdt.dsl 11419:										 Name (_T_A, Zero)
Remark   5111 -					Use of compiler reserved name ^  (_T_A)
dsdt.dsl 11454:											 Name (_T_B, Zero)
Remark   5111 -						Use of compiler reserved name ^  (_T_B)
dsdt.dsl 11503:					 Name (_T_0, Zero)
Remark   5111 -							  ^ Use of compiler reserved name (_T_0)
dsdt.dsl 11508:						 Name (_T_1, Zero)
Remark   5111 -	Use of compiler reserved name ^  (_T_1)
dsdt.dsl 11562:					 Name (_T_0, Zero)
Remark   5111 -							  ^ Use of compiler reserved name (_T_0)
dsdt.dsl 11618:						 Name (_T_1, Zero)
Remark   5111 -	Use of compiler reserved name ^  (_T_1)
dsdt.dsl 11658:									 Name (_T_2, Zero)
Remark   5111 -				Use of compiler reserved name ^  (_T_2)
dsdt.dsl 11720:				 Name (_WDG, Buffer (0xF0)
Warning  1099 -	Unknown reserved name ^  (_WDG)
dsdt.dsl 13491:						 Subtract (Local0, 0x03)
Warning  1106 -										^ Result is not used, operator has no effect
ASL Input:  dsdt.dsl - 14562 lines, 538932 bytes, 6032 keywords
Compilation complete. 2 Errors, 8 Warnings, 60 Remarks, 8 Optimizations
[Completed]

Can you help me, please?  Thanks in advanced!

[ebmesnow]

Quote

Thanks for the help, ebmesnow, and now I'm getting these errors in compiling the DSDT.aml.

Can you attach your DSDT and I will have a look, have you done this before? Some of the DSDT compilations are known to be full of errors before, does not look like anything we have introduced.

[Duncan Leo]

I have a question...

What is AAPL,os-info? What does it do?

Also the FB detects my screen properly just that the screen would have a backlight with no image...

I also get a screwed up graphics if I boot with the display on VGA. My laptop is Lenovo T410. The DSDT I can try to edit... Any way for DSDT to get the image displayed?

My screen is 1280x800 btw

[iWin32]

ebmesnow, on 09 August 2012 - 09:11 PM, said:

Can you attach your DSDT and I will have a look, have you done this before? Some of the DSDT compilations are known to be full of errors before, does not look like anything we have introduced.

Sorry I didn't reply sooner, but I managed to use a different DSDT editor and compiler to compile the source code created by DSDTDE.  I managed to install Lion with it just fine, but I get this kernel panic when trying to boot the installation:
 P1070478.JPG   1.1MB   37 downloads

I also have attached my compiled DSDT.aml as well as my error-filled DSDT source code.  Please take a look at it.  And yes, this is the first time I am using DSDT fixes.
 my-dsdt.zip   82.15K   10 downloads

[Duncan Leo]

Guys.. I don't think this works...

I did everything, os-info and all, the FB detected my screen fine, but still black screen

[iWin32]

I recently found a link to this useful open source tool on Apple's User forums (of all places), where a user of a real Macbook Pro (I think with the same Graphics card as us) wanted to use the integrated Graphics.  Here is what one user said to use:
http://codykrieger.com/gfxCardStatus

If we use this tool (starting it by screen sharing), we may be able to use Vanilla Kexts (with or without DSDT?) to switch to the Intel HD Graphics card without kext modding, etc.

[fmac]

iWin32, on 23 August 2012 - 11:04 PM, said:

I recently found a link to this useful open source tool on Apple's User forums (of all places), where a user of a real Macbook Pro (I think with the same Graphics card as us) wanted to use the integrated Graphics.  Here is what one user said to use:
http://codykrieger.com/gfxCardStatus

If we use this tool (starting it by screen sharing), we may be able to use Vanilla Kexts (with or without DSDT?) to switch to the Intel HD Graphics card without kext modding, etc.

dont waste Time on this application its a nogo
tryed this 2 years ago

Sorry for the bad news

read the original thread of GMA 5700


kind regards
fmac

[iWin32]

fmac, on 24 August 2012 - 06:05 PM, said:

dont waste Time on this application its a nogo
tryed this 2 years ago

Sorry for the bad news

read the original thread of GMA 5700


kind regards
fmac

I read the original thread, and the reason it DIDN'T Work was because of 4 screens without being able to see the menu bar.  I suggested trying to enable screen sharing, but I can't test this out (as of now) because of network issues.  Specifically, my built in wi-fi is unsupported, my built in ethernet is supported, but I can't get the kexts to enable it for the life of me.  And I have the infamous Netgear WG111v3, and as many of you know, it doesn't save profiles (where WiFi default network configuration is stored) in lion, so I'll go start a thread to see if I can get Ethernet to work.  I will say, though, for those that CAN get networking to work, try enabling the vanilla HD Graphics kexts, and start the program through screen sharing.  We'll see what we can do if this program works.

P.S. If you are so convinced that it won't work, than why not modify the code to help us?  After all, it's open source!!

[Duncan Leo]

I used Snow Leopard...
Lion better? I will try it

[sockerkid]

iWin32, on 24 August 2012 - 06:25 PM, said:

I read the original thread, and the reason it DIDN'T Work was because of 4 screens without being able to see the menu bar.  I suggested trying to enable screen sharing, but I can't test this out (as of now) because of network issues.  Specifically, my built in wi-fi is unsupported, my built in ethernet is supported, but I can't get the kexts to enable it for the life of me.  And I have the infamous Netgear WG111v3, and as many of you know, it doesn't save profiles (where WiFi default network configuration is stored) in lion, so I'll go start a thread to see if I can get Ethernet to work.  I will say, though, for those that CAN get networking to work, try enabling the vanilla HD Graphics kexts, and start the program through screen sharing.  We'll see what we can do if this program works.

P.S. If you are so convinced that it won't work, than why not modify the code to help us?  After all, it's open source!!

I had email the owner of the gfxcardstatus and the owner himself does not even know how the mechanism works. it is a work from another people.

[iWin32]

I have a developer-based idea on how to fix resolution on Intel HD Graphics.  The problem: I'm only a beginner in developing.  So, here is my idea:

If I understand G62's kext correctly, it is enabling the graphics card and extending the display to our EDID's resolution.  However, OS X is still outputing 1024x768 because it doesn't have a framebuffer.  However, if my idea is right, a framebuffer won't be needed.

I tried to use the VBIOS dump earlier in this post, but I couldn't get it to work.  According to Slice (the developer of Clover on Project OS X forums), the reason is Chameleon has poor support of Intel VBIOS ROM files.  Clover has better support for the use of Intel ROMs with its GraphicsInjector.  However, the problem is that Clover is based off of UEFI firmware, so without a graphics driver for the firmware, it can only output three resolutions: 640x480, 800x600, and 1024x768.  This is true for those who are even lucky that their VBIOS has their custom resolution and Chameleon picks it up: if those lucky people boot with Clover, OS X will only output 1024x768; switch back to Chameleon, and their custom resolution can be used.

I have two ideas: one Chameleon-based (which may or may not work), and one for Clover.  First, the Clover one (because it needs to be based heavily off of G62's AppleSamplePCI.kext).  Before Clover loads the boot menu, it loads EFI drivers.  My idea is to port G62's kext to an EFI driver.  Any driver, in theory, can be ported to EFI, but without knowing a good deal on how the driver works, it can be difficult.  That's where G62's kext comes in.  He knows how to code the driver.  I think that if the kext is used before the OS is loaded, OS X may load our correct resolution (especially since the driver would enable the Graphics Card and have it output our correct resolution in EFI).

And as for a Chameleon fix, I'm not sure how we would start this one (other than looking at how 915resolution loads VBIOS info).  We would need to have an external tool (perhaps a Grub2 module?) copy a patched VBIOS (or the VBIOS in the forum) into memory, and then chainload Chameleon from there.  The idea here is to override the VBIOS by loading a different one into memory before Chameleon loads.  This would enable Mac OS X to load a different resolution.

Anyways, those are my ideas.  Like I said up above, I'm not a skilled developer, so if those are concepts that you think you can use, than feel free to try them out.  I'd also like feedback: would these ideas even work at a first glance?