[fpc-devel] Linux kernel behaviour change regarding keyboard

[Michael Van Canneyt]

On Wed, 18 Jul 2007, Daniël Mantione wrote:

> 
> 
> Op Wed, 18 Jul 2007, schreef Michael Van Canneyt:
> 
> > 
> > 
> > On Wed, 18 Jul 2007, Daniël Mantione wrote:
> > 
> > > 
> > > 
> > > Op Wed, 18 Jul 2007, schreef Michael Van Canneyt:
> > > 
> > > > > > well then that's it... If you want to use these keys, you'll have to run your
> > > > > > programs as root...
> > > > > > 
> > > > > > Or use a GUI IDE like Lazarus...
> > > > > 
> > > > > You just proposed this yourself, but before executing the IDE?
> > > > 
> > > > ? I proposed to use a small wrapper program, which does an Exec() after setting
> > > > the proper TTY properties. Not set up a communication channel with a setuid root
> > > > program. The solution is worse than the problem then...
> > > 
> > > What is bad about such a solution?
> > 
> > It's not KIS. If you can't have certain keys without being root, well then
> > you'll have to learn to live with it. This is no longer the MS-DOS age when
> > everything was possible. It's a shortcoming of the platform, and for me
> > this is the end of the story. The keyboard unit should in no way set up
> > such a communication channel; if you absolutely want that, you can set 
> > it up for the IDE (I don't use it anyway), but not for the standard keyboard 
> > driver unit. Develop a driver that handles this, and use that in the IDE.
> 
> The "scary" thing is the setuid root. The communication channel can be 
> standard i/o and there is nothing scary about that.

There is: a user using the keyboard unit should then distribute the
(setuid) program too, and that is not acceptable. (not for me as an FPC
developer, and most likely also not fot the user) So if you want to go 
through with this, develop a separate keyboard driver for linux console
that can catch all keys. But not the standard driver.

> 
> > I can agree that some of the Linux kernel developers are braindead - seeing 
> > what they have done - but I don't think we should go out of our way to fix 
> > that. Rather, we should request that they implement a decent keyboard 
> > interface which allows you to detect properly the state of all keys on 
> > the terminal which you are currently using.
> 
> Yes, I agree all kinds of hacks suck. However, the situation with Unix 
> keyboard is not "if" there should be hacks, but to what extend you go. 
> I.e. you can enable xterm "meta sends escape" with an escape sequence to 
> allow detecting alt-key combinations. However some xterms already do this 
> by default and start sending double escapes. We detect this with an ugly 
> hack. 
> 
> Some people go much further I.e. you can bypass xterm limitations by 
> opening a stealth connection to the X server and many people are doing it. 
> However, this went too far for me for now. 
> 
> Unfortunately Unix and keyboards is one hell, like it or not. There is no 
> proper "API" and you have to work around things to get work done.

I understand. But spawning an external setuid process and talking to that 
just to get a text mode thing working in some weird cases is not one, 
but two bridges too far for me...

I mean, seriously, how many people develop on the Linux console ?
You can't even open a browser then ! I expect most people do
their work in an X-Term if they use the fp ide...

> 
> By the way, I have started to talk to Andrew Morton and his reply was 
> constructive. Perhaps a proper solution is possible after all.

Great, that is the way to go !! 

Please, keep us updated on any progress you make on this :-)

Michael.