Edge Computing Division Users Forum

I did some digging and realized I've been working on this before. The thing is, we still don't support console framebuffers larger than 8mb. To work around this on high resolution displays we fall back to 16bpp. This works fine for me but obviously not for everyone. The modesetting driver in X can h...

I don't know what kernel versions you've tried but a while back we didn't support 1920x1200 framebuffers in gma500_gfx since they didn't fit in the memory reserved by BIOS at boot (usually 8MB). If you know how to compile a kernel you can try my gma500-next branch at: git://www.github.com/patjak/drm...

You can also compile your own kernel (at your own risk). There are some required packages that you need before you can do this, but a simple google search should be able to answer that. On Ubuntu (and likely any other distribution) you can do: # Download and unpack whatever kernel version you prefer...

Here is a status update of what's going on in drm-next: - Console framebuffer defaults to 16bpp which resulted in the resolution limit to be lifted. - The modesetting driver has matured so running 1920x1080 at 32bpp works fine - Hardware cursor support is on it's way (I have it working on my end) bu...

I'm only using fbdev in xorg! I tried out proprietary drivers a couple of time ago (e.g. emgd), but all of them weren't stable enough and scrolling in x-terminals was horrible slow! But with uvesafb and the new psb_gfx (which I had to blacklist if I want to use uvesafb anymore), I cannot see any di...

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 ...

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 enoug...

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

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 fix...

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...