EMGD PSB backlight driver

[AChea]

Based on the documentation you guys provided here http://edc.intel.com/Link.aspx?id=3930 http://edc.intel.com/Link.aspx?id=3930, and using a reference driver provided by Tista https://launchpad.net/~tista https://launchpad.net/~tista I've implemented a simple little driver that hooks into sysfs, it doesn't seem to be detected by the xbacklight utility, but it does play nice with gnome-power-manager and its brightness control applet.

Wierd thing is, at somepoint during the development of this driver, I lost the ability to use the fn+brightness keys from grub. That used to be how I set my backlight brightness before now, but I've made no updates to my bios or VBIOS. I'm not a hardware engineer, so I was wondering if someone might be able to explain to me how this might have happened? I would think that I would be able to somehow restore the functionality, and maybe extend it so that the keys actually generate xwindows events.

In either case, this driver is dead simple, please feel free to incorporate it into the emgd DRM driver, or keep it as a separate module if required.

2nd question, as a point of optimization. Is it a good practice to memory map pci-config space? The driver I built this one from was doing some wierd memory mapping, but due to the fact that the pci config functions use spin locks, I was worried about race conditions and implemented the driver with pci_read_config_byte and pci_config_write_byte. I don't know if this makes the driver "slow" to respond, or memory mapping is unsafe. Any feedback would be welcome.

Thanks for your time, enjoy the driver.

[AChea]

To answer my own question about the memory mapping thing. It was memory mapping the PWM control registers, which is explicitly discouraged by the LVDS backlight whitepaper, as it might not play nice with the emgd driver. So pci_config_read/write is the way to go.

[Kirk_B_Intel]

Backlight control can be problematic. Many OEMS implement the functionality in their own special ways making a "generic" support nearly impossible, If you had "fn" key control over backlight, then you are using some sort of commercial netbook that uses the US15W (E600 is not in any netbooks that I know of). My guess is you have an Acer One (the US15w one) or Dell Mini.

"FN" key support of devices like that is strictly an OEM thing- sometimes trying to directly manipulate the hardware without the intervention of a driver. I can assure you the driver is NOT providing that capability, although if the hardware register mapping has changed in the driver, then we may have unintentionally moved the control registers for their backlight capability.

It sort of is what it is, and if you have a driver that can manipulate the backlight, then mapping it to respond to keypresses should not be all that difficult.

Sorry I cannot be more help.

Kirk

[AChea]

That's correct, it's the Acer Aspire One 0751h. There's a really brilliant group of folks that have been working to support Ubuntu on US15w chipset netbooks, and after confering with them they do have a driver that allows the backlight keys to work, so I'm currently just trying to understand the process better as an academic exercise. On a subsequent note, the brightness support from BIOS/GRUB returned, so who knows what happened there. I know that Ubuntu isn't one of your support targets, but anything you guys might be able to do to assist their efforts would be really awesome.

https://launchpad.net/~gma500/+archive/emgd https://launchpad.net/~gma500/+archive/emgd

http://ubuntuforums.org/showthread.php?t=1229345&page=400 http://ubuntuforums.org/showthread.php?t=1229345&page=400

On a side note. They're currently using the 1.6 drivers that landed in the Meego tree using a combination of 1.6.0-1922 kernelspace and 1.6.1-1952. Is there a reason why the offical download page is still at 1.5.2-1816?

[Kirk_B_Intel]

It sure is behind!! EMGD 1.6 was just recently released, but the folks that update the EDC pages sometimes get behind. It is available directly to our Premier Support customers on the Quad system and to the MeeGo distribution as you found. We did provide to the EDC maintainers but apparently the updates to the pages are running behind. That will get corrected ASAP.

THX.

[AChea]

It's been updated already, thanks very much for the prompt response. Out of curiosity, what is the typical lag between the Premier customers getting updates and them being published here? If it's more than 10 days, would it be possible to get the Ubuntu GMA500 support team registered as Premier customers? I assume a cost is involved, but are there any other restrections or NDA clauses that would exclude a non-commertial/non-corporate group from joining?

[Kirk_B_Intel]

Cool, that JUST happened as when I posted earlier today it was still 1.5- I guess asking about it was the right thing to do!

Normally there should only be a day or two delay, but the EDC development team is doing some deep rework of the site which caused the longer delay. Getting a non-commercial group into Quad is theoretically possible but you would need an Intel field rep sponser to do the legwork. I would make sure your team has "privledged" accounts and that way we can release files that way...

Hope this helps, Kirk

[AChea]

Personally I would think that a 1 to 2 day lag is more than acceptable, so there's probably no need to bother trying to get a privilaged account just for drivers. If I ever reach the point where one of those locked files looks like it might be helpful I'll re-evaluate the situation, but otherwise I'll just keep my ear to the ground and come knocking if the drivers slip in the future.

Please pass my thanks along to the driver team, when I bought my 0751h a year and a half ago, I knew nothing about driver issues, just that intel GMA's, while not powerful, were a safe bet for 3D on Linux. Shortly afterwards I was being told that I'd bought a lemon, but at GDC 2010 I talked to folks from both Img Tec and Intel about the situation, the floor staff were surpirsingly knowledgable about the situation, and said in a nutshell, "We're sorry, we know it sucks. It's complicated and we can't go into detail, but we're working on it". Less than a year later and I start seeing that promise honoured. It's a quirky device, but with the current level of support it sure doesn't feel like a lemon, at least not to someone looking for an excuse to get into kernel hacking. It's a refurbed device, so neither Acer nor the reseller have been any help. It's refreshing to deal with a vendor who cares, especially since neither the CED, the documentation, nor these forums are really meant for the end user. So thanks to you too Kirk, you've been a big help navigating this stuff.

[PMoor1]

At the risk of resurrecting a long dead post (which is a crime on some forums), I was wondering if you guys might be able to help. EMGD is now the future of the Intel's Windows 7 driver for Poulsbo and I have built the last several releases for the Sony VAIO P (which has an unusual 1600x768 panel). Someone in the Vaio P community a while back converted the X11 modeline info into a DTD so the display is ok, but the backlight is more of a mystery. Using the EMGD driver the backlight hotkeys work, but the at brightness levels 1-3 on the scale of 8 the light is completely off. Below are the default settings in the EMGD configuration editor, but I cannot find a datasheet for the specific panel - a Toshiba LT080EE04000. Would changing these values affect that scale calibration, or not? Or is it more likely due to the EMGD expecting a different vBIOS, or the calibration of the Sony Shared Library which controls the hotkeys/onscreen display of the level?

[Kirk_B_Intel]

Those parameters only affect the power sequency, not the levels. You need to look in the Attribute page on the LVDS configuration. See the User's Guide for minimal details. This is really an attribute of the backlight control of the board so the driver is pretty general about how these are used as the developer of the board normally needs to determine how these are set:

[PMoor1]

Thanks for that pointer Kirk - I experimented with a few values without the desired efffect. Then I searched high and low but could only find mention of this reference value for the Inverter Frequency of 20300 from the EMGD docs. However, I had read that someone had got it working for a different range of Sony Vaios so I got that driver and discovered that a value of 300 was used. Once I put that it in it worked perfectly! I wrote it up here:

http://pcloadletter.co.uk/2012/07/06/iemgd-for-vaio-p/ http://pcloadletter.co.uk/2012/07/06/iemgd-for-vaio-p/

[Kirk_B_Intel]

Excellent find! That is the sort of platform specific information we just do not have especially for a non-POR use case such as this. It is really cool that the driver is working for you on your netbook, however, it is not something we intended for the driver (netbooks are not "embedded") and not something we normally are not able to support from the embedded team other than a "best effort" approach. It worked out in this case so all is good!!

Kirk