Quoting Ville Syrj?l? ([EMAIL PROTECTED]): > Well actually no patch because I managed to mess up my original changes. > But here are the changed files in all their glory... > > Changes: > - I swapped the field address registers around because the image on my TV > was a bit jumpy and AFAIK matroxfb uses them this way. The jumping might > have been caused by something else though. They are write-only so I can't > check how they are programmed in Windows. > - hsync, vsync, and preload registers don't effect the output but I've > programmed them to 0 just in case. Oh and I got rid of programming the > fieldline registers since they don't seem to make any difference and > they aren't programmed in Windows either. fieldpol and fieldlength seem to > belong to this category as well. > - Most importantly I tried to clean up the maven code and hopefully I got > rid of the problem where maven would get somehow confused and drop part of > the input data. Also I was able to find the correct sequence to > programming the registers. Now all the registers match that in Windows and > maven doesn't get turned off in the process :) > > Todo: > - hue, saturation etc. > - deflicker mode > - vsync support > - maybe something else? > > Comments? Test reports? Somebody say something... :)
This sounds really cool, but I don't know if it works with my G550, too. One question: Does it override the secondary framebuffer device? Having single head support in matroxfb only with full access to both heads and memory in DirectFB seems to be an acceptable solution. We just have to add support for layers on another screen (output)... -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
