After following /message/5445# 5445 this thread, I was able to install the IEMGD drivers for Ubuntu 10.10. However, my xorg.conf file does not seem to be working properly. The screen brightness seems to be very high, and I cannot tell what is causing the problem. I suspect there is a setting in xorg.conf that needs to be modified. Any help is welcome.
I can adjust the brightness using the keyboard brightness controls during boot up, but once linux starts booting I lose control over the brightness. My work around is to play with the brightness in the GRUB menu before committing. I too am unable to adjust backlight settings once in Linux. I've tried all the configurations I can think of outlined in this document (http://download.intel.com/embedded/processors/Whitepaper/324567.pdf http://download.intel.com/embedded/processors/Whitepaper/324567.pdf) But I've had no luck. I don't know if I'm doing something wrong in the xorg.conf or if the emgd xorg driver or the emgd.ko layer that would handle this but doesn't.
How are you trying to set the brightness? Are you trying to use the GUI (EMGDGUI that should be with the release)?
Are you aware of the various backlight control methods used? Legacy vs PWM vs hybrid? Are you setting that properly for your hardware (only the hardware manufacturer will know how they wired it up)? Is it possible that your hardware developer has wired it in some proprietary fashion that we cannot control?
Backlight control is one of those things that is very difficult for us to handle because of the wide variety of implementations. If the backlight control is implemented like we have on the Intel Crownbeach CRB, then you should be able to control it. I just verified that gamma, backlight and contrast are definitely working on an E600 CRB with EMGD (on MeeGo).
Getting the brightness up down from the keyboard is also a proprietary feature. If you want that to work, you will need to create a special keyboard driver that watches for the special keypresses and then calls the EMGD interface to adjust the appropriate control. THe EMGDGUI source is included with the release as a guide to show how to call our functions. That assumes that the hardware does use something we are able to control.
If you hardware manufacturer has gone "off menu" for some of the control, then there will be no way for us to handle that feature.
Hope this helps.
This was very informative. I was unaware that emgdgui even existed. I've ran it and attempted to configure the brightness and gamma controls, but the screen still looks washed out, no matter what the controls are set to. I cannot determine if this is caused by the way that the display is wired, but I know the display works fine when X is not loaded or xorg.conf is not present. Thanks again for your help.
Using the EMGDGUI utility to control the framebuffer options works fine, but the way it changes the display it doesn't look like it's actually affecting the duty cycle of the backlight, just messing with the colour space. So it "looks" darker, but doesn't actually consume less power. And while I'm not really concerned about the keyboard support, I used to be able to use the xbacklight command (and/or the Gnome brightness applet) to adjust the backlight under the old psb drivers.
xbacklight seems to use XRandR to issue those commands, and now reports "No outputs have backlight property".
So it worked once, and in theory should work again. Does EMGD support XRandR? I've been trying to find a mix of settings in my xorg.conf that do the trick, but they don't seem to do anything that I can decern. The "options" in the device section, do they go to the kernel module (emgd.ko) or are they only intercepted by the xorg emgd driver?
Would any of this functionality be dependant upon the video BIOS, or does the kernel assume full control of all hardware once the system has booted? I would assume that the bios drops out of the picture after boot, since my brightness is controllable via the keyboard buttons during boot, and all of it stops working after boot. If the vBIOS is a key component, how risky is it to reflash it with the vBIOS generated by the CED? Are the system BIOS and video BIOS tightly integrated? Or is it not unusual to get the lastest and greatest vBIOS from the actual vendor?
The only thing I haven't tried yet is writing my own user level program using the Windows backlight example in that whitepaper. Perhaps even if XRandR isn't supported, it's still possible to control the backlight properly through the defined register interface?
Is there any documentation that spells out the relationship between the hardware, the kernel, the emgd.ko driver, X windows and the emgd x drivers, and what kind of functionality they should govern? I'll keep digging, but I don't want to invest the effort trying to solve this if the problem exists in the closed binaries, so I'm hoping you guys can help me out. I want to fix this if I can, and I don't want to be a pest, but being pointed in the right direction would help.
I'd take this issue to Acer if I actually though I could get anyone to listen, maybe someone at Intel could help me get in touch with an engineer who worked on the 0751h netbook? I figure if I attack this from as many different angles as possible I'll hit a breakthrough at some point.
TL;DR version: The old psb drivers supported backlight via XRandR, while the EMGD drivers do not. Where might the problem be? If it's a xorg.conf or a kernel driver issue, then I'll get to the bottom of it. If it's a xorg driver issue, is there something you guys are willing to do about it?
I have noticed that I am unable to properly set the bit depth using the emgdgui. The GUI tells me the bit depth is set to 32, but I have specifically set it to 24 (the proper bit depth for my setup) in the xorg.conf.
Which is correct? The xorg.conf or what emgdgui is showing?
Can I somehow change the bitdepth using the emgdgui?
32 and 24 bitdepths should be equivilant. 24 bit colour is usually 8 bits of RGB, 32 bit colour is 8 bits of RGBA (A is the alpha channel, for storing transparency data in the framebuffer). But since you can't actually "see" alpha (It's only used to blend the current frame buffer RGB data against new RGB data), 32 bit framebuffers still only have 24 bits of colour.
The "Should I write my own brightness application" per the mechanism outlined in this document http://edc.intel.com/Link.aspx?id=3930 http://edc.intel.com/Link.aspx?id=3930 worked. Except that I didn't have to write anything.
the linux setpci command pretty much does it all, but some initial testing suggests that the
Option "ALL/1/Port/4/Attr/72" "0"
Option "ALL/1/Port/4/Attr/72" "1"
Made no difference, in spite of the CED documentation specifying that "0" is PWM and "1" is LBB + PWM control mode.
At any rate, try the following command to adjust your backlight
setpci -s0:2.0 F4.B=#
where # is a hex value between 00 (off) and FF (max brightness). If you want to see what the current brightness is before you go messing around, then try
lspci -s 0:2.0 -xxx
This wil dump the whole register block, you'll want to find address F4, so that'll be the 5th value in from the f0: line... ie
f0: 06 00 ff 01 20 00 00 00 86 0f 07 00 4d cb 6b 7f
In this case my brightness is set to 0x20
Hope this works for you.
Unfortunately this doesn't seem to work for me. I'm taking a wild guess that you are using SDVO on a PCI bus, whereas I'm using LVDS. Is there an equivalent command for my setup?
No, this is with my LVDS panel. I haven't had any luck getting the SVDO output to work once in X.
According to the docs that backlight control attribute should be set to 1 by the server options. But if it still doesn't work for you, then it probably just means your vendor doesn't support the legacy backlight register. Maybe someone from Intel can weigh in, but you might have to go back to bugging your vendor.
I suppose you are correct, the monitor likely does not support this feature. I am still not 100% convinced that the issue is with the monitor brightness anyway. I can adjust the monitor brighness manually and the screen still looks "washed out," like there is too high of a contrast in the color scheme being used. I've surpassed my allotted time on debugging this issue unfortunately. Hopefully someone will respond to this thread with an answer or new drivers will come out soon. For now it looks like we may have to look into using an ARM processor and chipset that fully support Linux instead
I have treid every setting possible. Even with brightness, gamma, and contrast turned down to their lowest, the screen color still appears "washed out," almost as if the color pallette has too much white in it.
I am sorry you are getting frustrated, but most of the frustration may be your selection of the development platform. When an OEM creates a netbook with our products, they do not always impliment them the way we would like. Have you considered getting a different box? We use the Portwell 8044/8045 board here for many development, supprt and valaidation tasks. It is implimented closely following our CRB guidelines.
I wonder if there is confusion over the frame buffer bit depth (the one you can change in the GUI vs the actual LVDS interface bit depth. When you start talking about washed out colors, it sounds like you may have a mismatch on the LVDS interface.
Have you tried flipping attribute 26 between 18 and 24 bit? It would look something like this for 24bit:
Option "ALL/1/Port/4/Attr/26" "24"
It defaults to 18 bit and if your panel is 24bit it might cause your description.
Hope this helps
Just looked at your xorg.conf again and it is missing this attribute thus it is defaulting to 18bit LVDS interface. Try adding the line I provided previously. At a minimum you will need to restart your X session (it is an init option), a reboot may be better.
Hope this helps.
Congratulations Kirk! You've solved my problem!!! It was indeed the bit-depth being set incorrectly. I'm attaching my xorg.conf for reference.
Adrian thanks for all your help as well. I have learned a lot from you!
Excellent. If you had just said "washed out" instead of "trouble with brightness control" sooner, we would have figured this out sooner.
Glad we could help.