Re: Supporting multiple keyboard

[James S. <jsi...@ac...>]

> Are you sure that it is so big security hole? 

Yes :( Remeber the video memeory is shared with all VCs allocated to it.
Each VC has it own text buffer which make sit safe to have different apps
writing on different VCs at the same time. Any changes the frmaebuffer
mapping makes effects all the VCs attached to it. A good example is I use
Mesa-GGI and when I VT switch it works right. By if I VT switch back and
forth very rapily it locks my machine. The text buffer and framebuffer 
contents get scrambled. 

> You started processes on
> both VT's, if you were allowed to switch them... 

This is no problem if both process are text console programs since they
have seperate text buffers. 

> Oops, there is special
> case when you have syslog printing output to screen... 

While in graphics mode printk or syslog could still write to the text
buffers instead of directly to the video memory. You also have the power
of redirect. You can even send it to your printer.

> But oops again,
> there is only one difference - without mmapping /dev/fb YOU have to
> read screen and write it down, with /dev/fb software can do it for you...

I though /dev/vcsa was for that. 

> I think that it is not so big problem. Only missing part is add `hangup'
> to all these input/output devices, so that logout can cause disconnects
> for running mmap /dev/fb (or /dev/dsp...), like it disconnects backgrounded 
> processes from /dev/tty...

Yes this does need to be added.

> XF68_FBDev worked only with raw->mediumraw patch in XFree 3.3.x...

Its going to have to be patched anyways to use /dev/input/*