Geert Uytterhoeven wrote: > On Wed, 28 May 2008, Denis Oliver Kropp wrote: >> Geert Uytterhoeven wrote: >>> On Wed, 28 May 2008, Denis Oliver Kropp wrote: >>>> One major bug at the moment is mode switching and pitch values being >>>> wrong. It's dumb to >>>> return the pitch of the variable mode settings in the fixed settings >>>> structure anyhow, but >>>> if you like to start with the above mentioned mission, that's where it >>>> could begin. >>> Do you care to tell us why this is dumb? >> Ok, the fixed information should not contain information that changes over >> time, >> otherwise it is not fixed, at least that's my understanding of "fixed". > > It's `fixed' not in the sense that it can never change, but that it > purely depends on the info in struct fb_var_screeninfo.
I'd prefer an ioctl which has input and output fields in the accompanied struct, so that the resulting pitch is returned to the user space with the same system call. >>> The pitch depends on the video mode and the hardware requirements, >>> that's why it's in struct fb_fix_screeninfo. >> It would suffice to encode the pitch requirements independent from the video >> mode, >> i.e. just put the pixel or byte alignment into the fixed structure. > > What if the pitch requirements depend on the video mode? Haven't seen that, usually either pixels or bytes just needs to be a multiple of something. In these cases you could simply forbid/fail to choose the pitch and just return it in the variable structure. > There exists graphics hardware where fb_fix_screeninfo.type depends on > the video mode. Sure, type depends on the pixelformat :) -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
