Hi! Forgive me if I am asking a stupid question, but is the idea of the keyboard input driver not that it is necessary because not all DirectFB applications actually run within a terminal? As I understand it stdin only makes sense if you're running within a shell / login process, ie your app is attached to a terminal in text mode. It seems to me that this is not always the case with DirectFB -> some apps might be started without being attached to a terminal, and then they would receive NO keyboard input at all.
Also, having to SSH into a box to kill a process can just as easily happen if you are using stdin -> it is quite possible for your X-Windows, Text Terminal, your shell, or even the Keyboard driver to crash in some way, meaning you need another channel in if you want to interact with the still-working parts of the system. Finally I don't think the security argument holds either -> a text terminal is switchable into 'raw' mode, meaning most keyboard input will get through. And an app using stdin can just as easily 'pretend' to exit as an app using the keyboard driver. I don't quite see the extra danger resulting from the use of the kernel level keyboard driver rather than the character stream level input driver. As for your question of how to implement a stdin driver, I'm afraid someone more knowledgeable will have to answer that one. One suggestion I do have is to use 2 Screens/GFX Cards for DirectFB development. Run X-Windows, your favourite development environment, emacs and whatever else you need on the main screen. Run your framebuffer driver and the DirectFB apps on the secondary GFX card and screen. That way you should never need to SSH again, AND can keep all your Xwindows open while testing! Richie -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von user3545 . Gesendet: Mittwoch, 09. November 2005 15:27 An: [email protected] Betreff: [directfb-dev] stdin input driver I have found the keyboard input driver completley unacceptable due to the way it hooks ALL keyboard input. There is a reason stdin is used as apposed to full keyboard access, this is incredibly apparent when the application crashes and the only thing you can do to rectify this is ssh into the box. This method of input also allows various attacks by allowing the application to appear exactly as if it had closed, when infact it has not - all input and output to/from the machine is still under the control of that application. The application I am using needs a stream of characters - stdin is just that, however as it is using the DirectFB keyboard interface, things suddenly stop being simple. Is it possible somebody could either write such an input driver or at least provide me with an outline of the functions that it would consist of... oh, on another note: keyboard.c: /* fill driver info structure */ snprintf( info->name, DFB_INPUT_DRIVER_INFO_NAME_LENGTH, "Keyboard Driver" ); That is functionally equivilent to strncpy, only it will be considerabley slower due to it having to compare each character with '%'. // fill driver info structure strncpy( info->name, "Keyboard Driver", DFB_INPUT_DRIVER_INFO_NAME_LENGTH ); - a vexed DirectFB user ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
