The new gma500 driver

[prj]

With 3.0 you get none of the SDVO fixes made for the Fit-PC2. Don't remember what state the driver was in back then, but have you tried just setting the mode on the grub command line (e.g. video=1920x1200@60).

Otherwise I guess you could roll an out-of-tree backported version of just the driver from a later kernel (with some hacking of course) and include that as a package.

I guess it depends on how badly you need it.

[opencompany]

@prj - thank you for your quick reply.

We actually need it quite bad so I will definitely try all options to get the best video performance out of the fit-PC2 with the 3.0.X kernel. Others using SUSE Linux Enterprise 11 SP2 on fit-PC2 like we do here or just another 3.0 based system, might be interested in this as well I think.

Could you lead me in the right direction how to backport the newest / best driver for the GMA500 chipset? Maybe a link to a how-to if you know any?

[prj]

I'm afraid it's not a trivial task. You need to know your way around the Linux kernel. I think the best way of putting something useful together is to:

1. Take the gma500 driver from 3.3 (gma500_gfx).
2. Fix up the GTT allocation code to allow non stolen memory.
3. Find any other Fit-PC2 related fixes introduced in later versions.
4. Backport everything
5. Compile and smile

Look for patches that I've submitted (Patrik Jakobsson). Most of them are Fit-PC2 related.

[EDIT: gma500_gfx is only in 3.3 and not in 3.1 as I previously wrote]

[prj]

I took a stab at doing this but it seems the DRM FB glue and GEM has changed quite a bit in 3.3. It makes things a bit tricky. I'll try taking psb_gfx from 3.0 and apply the SDVO code and some bug fixes instead. Might be easier... or not

[opencompany]

Thank you so much for looking into this!
I won't mind try to solve this my self, but if its tricky for you it will be a lot more tricky (or impossible) for me. So I will wait and see how it goes for you for now and then be more than happy to test etc. afterwards.

[monnier]

Have anyone successfully setup the new driver on a 3.0 kernel system?

I've used the kernel (3.0) driver without problems, yes.
All I needed was to specify the right "video=" argument on the kernel command line.
In my case I use: video=1600x1200MR-16@55
The "-16" is because I prefer 16bit depth (tho it apparently triggers a bug in Cairo when printing PDFs from Firefox), the "MR@55" changes the refresh rate and signal timing a bit (M means something like "use standard timing", R means reduce-blanking which is appropriate for non-CRT panels, and @55 is the refresh rate) which convinces my screen not to complain about "suboptimal mode". The problem being that the binary driver doesn't read the EDID info sent from the monitor, so it doesn't know what is the non-suboptimal mode to use.

IIRC for 3.0 I needed to use "RM" instead of "MR". If you add "drm.debug=6" you can then (via "dmesg") get extra info about what mode was used and how the "video=" arg was parsed.

Note also that I'm using stock Debian kernels. For other kernels, your mileage may vary.

[prj]

Linuxshoppen: Is Monniers solution good enough? I'd rather not do a backport unless necessary.

Also note that the performance may not be sufficient. This driver is unaccelerated. It's a pure framebuffer, nothing more. I found it ok for basic 2D but depending on your application it might not be enough.

Just want to make sure a backport is really what you need.

[opencompany]

I will test the solution asap. and get back to you.

[Dominik]

I tested the psb_gfx driver from new kernel. It works fine, but I absolutly cannot see any difference to uvesafb I'm using for years.

[prj]

I tested the psb_gfx driver from new kernel. It works fine, but I absolutly cannot see any difference to uvesafb I'm using for years.

The difference is you can set non-vesa modes and faster performance because you don't need to do the bank switching (though I haven't tried uvesafb). It sounds like you aren't using the fbdev driver in xorg. Or you don't tax the system enough to see any difference.