Re: [Linux-fbdev-devel] re: James's new API post

[Petr V. <van...@vc...>]

On Sat, Nov 24, 2001 at 10:29:36PM -0800, James Simmons wrote:
> > As far as virtual xres and yres.. keep in mind this is a virtual filesystem..
> > if your driver or subsystem has additional needs, you can simply register a
> > new entry to deal with virtual resolution.. If you want a place for virtual
> > resolution.. something like:
> > 
> > 	/dev/gfx/card0/frame0/resolution_virt
> > 
> > should suffice just fine. (Name pending).
> 
> Okay I see people got confussed over the ASCII thing. Yes Linus wants
> ioctls to go away. There have been huge ioctl clashes in the past. Plus
> Linus dreams of a network transparentancy. I also like that idea. So the
> two things he wants to see go away are mmap and ioctl functionality. In
> its place you create a file to represent the functionality of the device
> and that you can read and write data to so its behavior changes. This data
> can be binary or ASCII. It just has to be passed in via read and write.

Do not forget that current API is atomic, with doing it in multiple
steps you can get nasty surprises (as resolution and resolution_virt
depends one on another, either changing one changes also another one,
or some modes are not accessible without first modifying resolution_virt),
besides not being atomic...

And AFAIK Al Viro (main ioctl killer) does not require that every current
fb_*_info field should have its own file. From his posts I understand
that he is completely satisfied with just some text-based extensible API,
so 
(
echo "mode=1024x768-16@60,outputfmt=NTSC,vxres=2048,xoffset=141" >&0
read a
echo $a
) <> /dev/fb0/control'
would be enough for him... As there is already couple of comma separated
list parsers in the kernel (mount options, kernel cmdline), I think that
it is preferred format - in simplest form you write one line in, and
get one line back...
						Best regards,
							Petr Vandrovec
							van...@vc...