From: Gerd K. <kr...@by...> - 2001-07-12 07:15:27
|
> > IMHO it is important to let the driver pick the buffer size to avoid > > trouble due to hardware limitations / alignment issues / ... > > which the application doesn't know about. > > My current idea was the app was told about alignement issue > in _CAP, and could require the size it needs by computing > (pixelsize*paddedX*paddedY), and require that size or more. I'd still think it is better to leave that completely up to the driver because it's more flexible and gives the driver full control. paddedX/paddedY will take care about any alignments / paddings and will probably catch most cases, but there might be other constrains ... > > Hmm, is this _really_ a problem? Do you want to mix that with > > console? I'd expect graphic applications whould use that only, > > like fbtv, dvd players (there is a fb-based one IIRC), ... > > Yes, if you want to be able to use the text console while > displaying stuff like video or a still image. One could > use `fbi' (:-) to display a background picture or `fbtv' > for background movie/video stream. It's an overlay, > it should behave nicely toward the foreground app, > even fbcon. IMHO :-) Don't know anything about the ruby design, but with the current console it simply doesn't work. fbi and fbtv switch the console into graphics mode (ioctl(tty,KDSETMODE, KD_GRAPHICS)). And they _have_ to do that for several reasons: - clean console switching, the apps must not write to the framebuffer if they are not running on the foreground console. fbtv also needs to turn off video DMA before it can allow switching away to another console. - full control over panning. fbcon changing the panning to scroll the text would scroll the fbi image / fbtv video too. fbtv has a switch to keep video dma enabled when switching consoles, this can lead to some funny effects ... Gerd -- Damn lot people confuse usability and eye-candy. |