Quoting Mark Adams: > There are various framebuffer drivers for the cle266: there's a version of > viafb in the DirectFB CVS, there's a version of the code released by VIA > patched for 2.6 kernels, and there's the latest 2.6 release of the driver > from VIA. > > Most people who have done any work in this area have been using the second > of those as the starting point as other mailing list articles suggest that > the most recent code from VIA does not work out of the box with DirectFB. > The version you need is the one from [1]http://patcher2k.012webpages.com/.
I'm installing the patcher2k version now. Then I apply your patch. If everything works I'll create a working version with all benefits based on the latest VIA release and push it back to them :) > I implemented this by using the integer argument to the FBIO_WAITFORVSYNC > ioctl. However, other drivers use this argument to determine which screen > to wait for. I have not found any definition of the correct usage of this > ioctl: ideally, it should have some flag bits to change the mode as well > as the screen number. Does anyone know who originally specified this > ioctl and what the constraints are on the usage of its parameter? I introduced this ioctl once as a patch for matroxfb. It had no parameters. Ville Syrjala added the parameter for syncing to a specific head and the ioctl got accepted by a wider community and seems to be a standard now :) In my opinion the ioctl argument should be redefined as a structure containing flags and arguments or similar. > So in summary, it is possible to get an excellent quality interlaced TV > picture using DirectFB with the CLE266/VT1622A but at the moment it > requires a number of patches to the kernel and to DirectFB. Didn't check yet which chip is used in the CN400. Do you think that your patches will work on CLE266, too? > What should ideally happen is that the version of viafb in the DirectFB > CVS should be updated using the patcher2k version along with the no-scale > mode and the field parity patch. The DirectFB unichrome driver should > then be updated to support these. As written above I'd like to do that based on the official driver, otherwise it might be hard to make the patched driver official again :) I just need to grab all bits for this: patcher2k viafb, no scale patch and field parity patch. Am I missing something? > I could help with this but I do not have the time to do it all (and I do > not have access to the DirectFB CVS in any case). Not yet :) > Finally, there are some further changes I have had to make to the code > that checks the version of the CLE266 chip: I do not know what the correct > long term solution is because I do not have the datasheets that describe > the differences. All I know is that my chip needs the opposite code to > what the original DirectFB thought it did. Hmm, sounds like I should test on CLE266 first? > On hardware MPEG decoding, there was some talk of a new video provider > that would use this but I've not seen anything yet. On the EPIA MII you > should be able get good results without hardware decoding provided you use > the most efficient pixel formats (YV12 for the video plane). If you need > to blit YV12 surfaces, I've got a patch for that too but it's not entirely > clean. But CLE266 has hw mpeg acceleration though? -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
