From: <jsi...@li...> - 2000-06-08 13:41:37
|
> Wouldn't be very useful, /dev/mouse is there for backward compatibility > only - as soon as we (or someone else) teach X and SVGAlib and GPM to > use /dev/input/event, even /dev/input/mouse can go away. The same > applies to /dev/input/js, but that'll take much more time - the joystick API > was good and there are many programs using it. Okay. Another question is why do you have more than one /dev/input/event? I pictured it working like /dev/shmiq on IRIX. You open it and read a bunch of events coming in from a bunch of different devices. A unverisal event queue. > > What should be done? Have the system go from console to graphics mode. > > In graphics mode the application access the raw hardware devices via > > /dev/fb and /dev/input or /dev/event. This disables the console system. > > Once the devices are done and they close the console system is restored. > > This is *tough*. Imagine XFree. It does everything itself - switches the > videocard to graphic modes defined in XF8Config, has direct access to > the graphic card's registers, has full control of the keyboard. It will > always need to know the console is being switched. The way it knows if a VT switch was by watching the keys pressed and doing it itself. It will be awhile before all all the cards XFree86 supports is ported over to fbdev. So we will have to keep KDSETMODE. Using this ioctl will prevent VT switching while in graphics mode. This is of course requires us to trust the program :( But with the progress of /dev/input the X servers can support it now! > Btw, I hope you don't mean console switching shouldn't work when in X? > People like to switch to and from X at runtime ... Disabling VT switching while in graphics mode doesn't mean the X server has to give up VT switching. It just has to been done in a different way. For fbdev supported card. X server open /dev/fb and /dev/input. This automatically disables VT switching. Next it mmaps the framebuffer and goes about it business. The user wants to VT switch. The X server sees the event and translates it into meaning I want a VT switch. Next the X server saves the frmaebuffer contents and clears the event queue. Next it cloes both /dev/input and /dev/fb. This restores normal VT switching ablity. > > See above. This means patches will have to be made for XFree86. > > And SVGAlib and all programs using it?. Yeap. The most important being XFree86. I think SVGAlib days are over now that we have /dev/fb. Eventually all the video cards SVGAlib support now will be moved over to fbdev. As for other programs I haven't seen to many programs that cook the keyboard and hit the video hardware directly. |