Division between CED and config file options?

[AChea]

Hi there,

I'm trying to improve my install and better understand how it all works now that I've got a funtional baseline running under Ubuntu 10.10. My main questions are as follows:

Are there any configuration options in the CED that result in changes to the binaries packaged by the utility? Or are all the options ultimately mutable through xorg.conf or powervr.ini? That'll simplify things if I don't have to go back to CED every time I want to experement with getting somthing new working.

Are there any configuration options which are inherently dangerious to misconfigure. I've been very conservative about changes I've made for fear of damaging my display or other parts of the controller hub. Especially with respect to the backlight and SVDO options.

Do any functions of the new drivers require a video BIOS update in order to fully work? Is it "safe"-ish to flash the video BIOS independantly of the main BIOS? I'm obviously not going to hold anyone accountable for what happens to my netbook, but I don't have information to make a risk decision, and I really don't want to brick my machine.

If I'm having trouble getting a feature to work, may I post my CED configuration to get feedback, or is that really beyond the level of free support I should expect here? It's my hope that Intel is at least partially interested in getting these drivers to work on as many distros as possible, provided that it's just a matter of tweaking one of the supported profiles. That's work I'm prepared to do for the benifit of myself and the community at large.

Thanks for your time...

[Kirk_B_Intel · Accepted solution]

The Linux driver is completely and independently configured via the xorg.conf file. Changes ARE made to the VBIOS that CED can build, but no binary changes are made to the OS drivers. Tweaking XORG.COF is exactly what we do- just remember to shutdown X and restart it to try your cahnges- only the GUI will do real time changes.

The DTD or power sequence timing (T1-T5) potentially could damage a badly designed LVDS panel or really old VGA displays (there was an IBM CRT that could be burned out with bad video timing), but that is rare.

I have never managed to blow up any hardware because of the settings. The only related item I can think of is be careful switching between LED and CCF backlight panels as the hardware can be badly affected but that is not a sw config thing.

VBIOS and driver are totally independent of each other except that CED does coordinate them for you. I almost never change the VBIOS when working in an OS (unless it is DOS!).

We can try to help and are happy to review configs (usually an xorg.conf or the CED generated ???.x file is enough for us to see what is happening). It is a "best effort" kind of thing. Things have been busier here on the EDC than we had planned which is, in a weird way, a good thing.

Other distros may need script changes which we are happy to see get propagated but our ability to support issues on non-POR distros so we need to keep that in mind.

Hope this helps.

[AChea]

Thanks Kirk,

When I got home form work last night I proceeded to start trying to answer my own questions, and discovered much of what you just said. However, the engagement with the community has been very helpful in getting me to that point, so I really appreciate the assistance you guys have provided.

I'm going to experement a little more so that I can upload a "clean" solution for the community, but as I mentioned in another post, I got back light controls working via the setpci command last night, and just now got my xorg configuration supporting DIH.

So that's all major video issues solved. My Acer Aspire 0751h netbook does everything I need it to do using the MeeGo 1.1 profile under Ubuntu 10.10, out of the box. There's room for improvement still, by way of XRandR and sleep/hibernate support, but I'm confident it's something that can be fixed on the open side, since the video drivers themsevles seem to shutdown/restore just fine.

I'm hoping I can take what I've learned back to the ubuntu community and see if my solution works for other configurations.

But again, many thanks to you guys for getting some modern linux drivers out there so quickly. While Ubuntu may not ever be a POR system, I'm hoping that the ubuntu community can maybe maintain their own solution piggybacked off the MeeGo drivers.

[Kirk_B_Intel]

Sounds good.

Keep in mind that we do support rudimentary (read that older) XRandR features but not all the new bells and whistles (yet). We have plans but those are being worked. Fortunately I believe we do have all the needed capabilites, just not the "easy" all in one place XRandR solution.

Kirk

[AChea]

A quick gander at the Ubuntu page for the Acer 0751h suggest that the gnome backlight controls fail because there is no /proc/acpi/video structure. Would that be emgd.ko's responsiblity to create? If so, I'm willing to sink some time into patching the drivers if you guys don't already have that on your radar.

[Kirk_B_Intel]

That Acer Netbook although a great piece of hardware, is not used in embedded applications all the frequently other than as a development platform for the special purpose built embedded hardware. As such we are not working on it as that particular platform is not in our target markets thus is not POR (chipset Z500 and US15w YES, Acer implimentation of it as a netbook- no). We eill not "step on your toes" if you pursue that avenue.

I am not aware of that particular structure being handled by the driver- however I will need to check with our developers. It could be an "Ubuntu thing" that we will need to support when Ubuntu is on our POR again...

Kirk

[Kirk_B_Intel]

So my research indicates that the stuff in /proc/acpi would need to be done by the ACPI driver, not the graphics. Also, it appears that all of that structure may be deprecated in current releases. Now those type of operations get handled by sysfs.

Take a look here for good details on current backlight control:

https://wiki.kubuntu.org/Kernel/Debugging/Backlight https://wiki.kubuntu.org/Kernel/Debugging/Backlight

Hope this helps!!

[AChea]

Sorry for the late reply, just wanted to say thanks for the info. My issue does seem to be that nothing is hooking into either the /proc or /sys file systems with hooks into the backlight. Right now it seems to be loading the default video.ko module, though booting with acpi_backlight=vendor didn't seem to change anything, though perhaps I did it wrong.

For this issue I'm going to see if I can find a kernel hacker to educate me on the process, and I'll let you guys know if I make any progress. In theory I suppose the acpi code could be added to the emgd.ko driver, but that'd probably the wrong way to do it, and an asus_emgd.ko or some such type driver needs to be written or found.

Anyway, it's been an enlightening weekend. Looking forward to the next release of the drivers.