Re: [Xpert]Intercepting keyboard events from within video driver?
Thomas Winischhofer writes: Thanks Mark, Alex, Xavier, Branden. Mark Vojkovich wrote: On Mon, 30 Sep 2002, Thomas Winischhofer wrote: The hardware I am developing for has two CRT controllers (actually it's [...] registers. However, involving the BIOS is definitely not desired.) Those key presses often never get passed the BIOS. They won't even get to the X-server. That's the way they work on the recent laptops that I've had experience with. No software outside of the BIOS knows about it. I know. That's the problem. This key combination causes a *complete* machine lock-up here and on many others. And the idea also was to keep the BIOS from messing around with the registers (eg. while Xv is active, etc). I have seen (literally *seen*, felt like 10 years ago in my assembler era) many SiS BIOSes causing the strangest effects (mouse cursor jumps around wildly in the first left 32 pixels of the screen, xv is totally skrewed up, etc). And the final - and most important - reason is that the BIOS drives the video bridge in slave mode (don't bother...) and this would end up in a catastophe in dual head mode. So, I thought of another qd solution: In the good, old CTRL-ALT-KP_Plus/Minus-manner why not intercept eg. CTRL-ALT-KP_Multiply and cycle through all possible output devices (LCD, TV and - theoretically - secondary VGA, that is)? Can this be done from within a video driver? I looked though the input related code but could not find a solution. I suspect that it's not possible for the video driver to intercept key presses. To hear that from Mark makes it sound quite final.. :( But then, sorry, if I'm annoying: Remember, what I want is not necessarily a secure or standard compliant solution; the target user group is a few people who know what they're doing. What about installing a wakuphandler (or wrapping the old one), wrapping some xkb resource or something like that? No, the Xserver will never see these keys being pressed. Neither does the kernel. Usually these key kombinations involve the Fn-key. Some hardware in the keyboard controller detects this and issues a system management interrupt. Therefore neither X nor the kernel get scheduled before the fatal code has been executed. I have never tried this but it may be possible to tweak the kernel so that you get a chance to intercept the system management interrupt. As far as I know there is support for such things in ACPI. Also there must be a way for the windows driver to deal with these situations. Alex Deucher wrote: you could create a little cli app like s3switch for savage based cards that will switch the output between tv and crt2. then map the keyboard shortcut to run that cli app using your window manager, etc. This would result in writing a server extension. Otherwise an application outside the server won't be able to communicate with the driver, if I'm not mistaken... (And the driver not only NEEDS to know about the change, it is also the driver which is to PERFORM it; setting up LCD or TV on SiS chipsets is ca 500k source code since the driver supports 8 chipsets with each 4 possible video bridges and so far ca. 60 different panel types) - if anybody knows better, feel free to object! I have an extension in mind which can be used to control device specific features. Drivers can register properties that can be set, applications can query the property list, the value type, ranges and current value. I've planned this as an extension to the xf86misc extension which allows to control certain keyboard and mouse features but which isnt extensible. Once you have this extension you can write applications that catch certain key events and use the extension to change device properites. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Intercepting keyboard events from within video driver?
The goal is: A quick hack in order to do a simple task which I am asked for almost every day: The hardware I am developing for has two CRT controllers (actually it's the sis driver for XFree86). One of these CRT controllers is able to control LCD panels and TV encoders, but only one of these two at the same time. The choice between LCD and TV (if both are detected at server start-up) is currently done with an Option in XF86Config-4, but this makes it impossible to change the setting during run-time (which is what users really ask for). (The special key on laptops which should provide this does not work under Linux - don't ask why; even if it did it is not satisfactory as I have no control over what the BIOS does to my registers. However, involving the BIOS is definitely not desired.) So, I thought of another qd solution: In the good, old CTRL-ALT-KP_Plus/Minus-manner why not intercept eg. CTRL-ALT-KP_Multiply and cycle through all possible output devices (LCD, TV and - theoretically - secondary VGA, that is)? Can this be done from within a video driver? I looked though the input related code but could not find a solution. Anybody? Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED]http://www.winischhofer.net/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Intercepting keyboard events from within video driver?
On Mon, 30 Sep 2002, Thomas Winischhofer wrote: The goal is: A quick hack in order to do a simple task which I am asked for almost every day: The hardware I am developing for has two CRT controllers (actually it's the sis driver for XFree86). One of these CRT controllers is able to control LCD panels and TV encoders, but only one of these two at the same time. The choice between LCD and TV (if both are detected at server start-up) is currently done with an Option in XF86Config-4, but this makes it impossible to change the setting during run-time (which is what users really ask for). (The special key on laptops which should provide this does not work under Linux - don't ask why; even if it did it is not satisfactory as I have no control over what the BIOS does to my registers. However, involving the BIOS is definitely not desired.) Those key presses often never get passed the BIOS. They won't even get to the X-server. That's the way they work on the recent laptops that I've had experience with. No software outside of the BIOS knows about it. So, I thought of another qd solution: In the good, old CTRL-ALT-KP_Plus/Minus-manner why not intercept eg. CTRL-ALT-KP_Multiply and cycle through all possible output devices (LCD, TV and - theoretically - secondary VGA, that is)? Can this be done from within a video driver? I looked though the input related code but could not find a solution. I suspect that it's not possible for the video driver to intercept key presses. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Intercepting keyboard events from within video driver?
you could create a little cli app like s3switch for savage based cards that will switch the output between tv and crt2. Alex -- The goal is: A quick hack in order to do a simple task which I am asked for almost every day: The hardware I am developing for has two CRT controllers (actually it's the sis driver for XFree86). One of these CRT controllers is able to control LCD panels and TV encoders, but only one of these two at the same time. The choice between LCD and TV (if both are detected at server start-up) is currently done with an Option in XF86Config-4, but this makes it impossible to change the setting during run-time (which is what users really ask for). (The special key on laptops which should provide this does not work under Linux - don't ask why; even if it did it is not satisfactory as I have no control over what the BIOS does to my registers. However, involving the BIOS is definitely not desired.) So, I thought of another qd solution: In the good, old CTRL-ALT-KP_Plus/Minus-manner why not intercept eg. CTRL-ALT-KP_Multiply and cycle through all possible output devices (LCD, TV and - theoretically - secondary VGA, that is)? Can this be done from within a video driver? I looked though the input related code but could not find a solution. Anybody? Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED]http://www.winischhofer.net/ __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Intercepting keyboard events from within video driver?
then map the keyboard shortcut to run that cli app using your window manager, etc. Alex you could create a little cli app like s3switch for savage based cards that will switch the output between tv and crt2. Alex -- The goal is: A quick hack in order to do a simple task which I am asked for almost every day: The hardware I am developing for has two CRT controllers (actually it's the sis driver for XFree86). One of these CRT controllers is able to control LCD panels and TV encoders, but only one of these two at the same time. The choice between LCD and TV (if both are detected at server start-up) is currently done with an Option in XF86Config-4, but this makes it impossible to change the setting during run-time (which is what users really ask for). (The special key on laptops which should provide this does not work under Linux - don't ask why; even if it did it is not satisfactory as I have no control over what the BIOS does to my registers. However, involving the BIOS is definitely not desired.) So, I thought of another qd solution: In the good, old CTRL-ALT-KP_Plus/Minus-manner why not intercept eg. CTRL-ALT-KP_Multiply and cycle through all possible output devices (LCD, TV and - theoretically - secondary VGA, that is)? Can this be done from within a video driver? I looked though the input related code but could not find a solution. Anybody? Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED]http://www.winischhofer.net/ __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Intercepting keyboard events from within video driver?
Le lun 30/09/2002 à 19:42, Mark Vojkovich a écrit : On Mon, 30 Sep 2002, Thomas Winischhofer wrote: The goal is: A quick hack in order to do a simple task which I am asked for almost every day: The hardware I am developing for has two CRT controllers (actually it's the sis driver for XFree86). One of these CRT controllers is able to control LCD panels and TV encoders, but only one of these two at the same time. The choice between LCD and TV (if both are detected at server start-up) is currently done with an Option in XF86Config-4, but this makes it impossible to change the setting during run-time (which is what users really ask for). (The special key on laptops which should provide this does not work under Linux - don't ask why; even if it did it is not satisfactory as I have no control over what the BIOS does to my registers. However, involving the BIOS is definitely not desired.) Those key presses often never get passed the BIOS. They won't even get to the X-server. That's the way they work on the recent laptops that I've had experience with. No software outside of the BIOS knows about it. I think ACPI (in newer linux kernels) may intercept them. Xav ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Intercepting keyboard events from within video driver?
On Mon, Sep 30, 2002 at 07:34:06PM +0200, Thomas Winischhofer wrote: So, I thought of another qd solution: In the good, old CTRL-ALT-KP_Plus/Minus-manner why not intercept eg. CTRL-ALT-KP_Multiply Apart from what Mark said, that particular key combination is already reserved, though it's not trapped by the server by default. You can be forgiven for not knowing this, though, as it's not documented everywhere it should be. ;-) I either already submitted the following patch to [EMAIL PROTECTED], or will be doing so in my next batch: This patch by Branden Robinson. --- xc/programs/Xserver/hw/xfree86/XFree86.man~ 2002-09-07 00:06:23.0 -0500 +++ xc/programs/Xserver/hw/xfree86/XFree86.man 2002-09-07 00:10:38.0 -0500 @@ -368,6 +368,20 @@ .B DontZoom XF86Config(__filemansuffix__) file option. .TP 8 +.B Ctrl+Alt+Keypad-Multiply +Not treated specially by default. If the +.B AllowClosedownGrabs +XF86Config(__filemansuffix__) file option is specified, this key sequence +kills clients with an active keyboard or mouse grab as well as killing any +application that may have locked the server, normally using the +XGrabServer(__libmansuffix__) Xlib function. +.TP 8 +.B Ctrl+Alt+Keypad-Divide +Not treated specially by default. If the +.B AllowDeactivateGrabs +XF86Config(__filemansuffix__) file option is specified, this key sequence +deactivates any active keyboard and mouse grabs. +.TP 8 .B Ctrl+Alt+F1...F12 For BSD and Linux systems with virtual terminal support, these keystroke combinations are used to switch to Virtual Console 1 through 12. -- G. Branden Robinson| Debian GNU/Linux | Bother, said Pooh, as he was [EMAIL PROTECTED] | assimilated by the Borg. http://people.debian.org/~branden/ | msg09148/pgp0.pgp Description: PGP signature
Re: [Xpert]Intercepting keyboard events from within video driver?
Thanks Mark, Alex, Xavier, Branden. Mark Vojkovich wrote: On Mon, 30 Sep 2002, Thomas Winischhofer wrote: The hardware I am developing for has two CRT controllers (actually it's [...] registers. However, involving the BIOS is definitely not desired.) Those key presses often never get passed the BIOS. They won't even get to the X-server. That's the way they work on the recent laptops that I've had experience with. No software outside of the BIOS knows about it. I know. That's the problem. This key combination causes a *complete* machine lock-up here and on many others. And the idea also was to keep the BIOS from messing around with the registers (eg. while Xv is active, etc). I have seen (literally *seen*, felt like 10 years ago in my assembler era) many SiS BIOSes causing the strangest effects (mouse cursor jumps around wildly in the first left 32 pixels of the screen, xv is totally skrewed up, etc). And the final - and most important - reason is that the BIOS drives the video bridge in slave mode (don't bother...) and this would end up in a catastophe in dual head mode. So, I thought of another qd solution: In the good, old CTRL-ALT-KP_Plus/Minus-manner why not intercept eg. CTRL-ALT-KP_Multiply and cycle through all possible output devices (LCD, TV and - theoretically - secondary VGA, that is)? Can this be done from within a video driver? I looked though the input related code but could not find a solution. I suspect that it's not possible for the video driver to intercept key presses. To hear that from Mark makes it sound quite final.. :( But then, sorry, if I'm annoying: Remember, what I want is not necessarily a secure or standard compliant solution; the target user group is a few people who know what they're doing. What about installing a wakuphandler (or wrapping the old one), wrapping some xkb resource or something like that? Alex Deucher wrote: you could create a little cli app like s3switch for savage based cards that will switch the output between tv and crt2. then map the keyboard shortcut to run that cli app using your window manager, etc. This would result in writing a server extension. Otherwise an application outside the server won't be able to communicate with the driver, if I'm not mistaken... (And the driver not only NEEDS to know about the change, it is also the driver which is to PERFORM it; setting up LCD or TV on SiS chipsets is ca 500k source code since the driver supports 8 chipsets with each 4 possible video bridges and so far ca. 60 different panel types) - if anybody knows better, feel free to object! Branden Robinson wrote: Apart from what Mark said, that particular key combination is already reserved, though it's not trapped by the server by default. You can be forgiven for not knowing this, though, as it's not documented everywhere it should be. ;-) As so many other things as well... :) I saw no code anywhere indicating this. Well then, I don't insist on this very combination anyway. In case I somehow manage to do what I originally intended: What would be a suitable and not-yet reserved combination? Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED] *** http://www.winischhofer.net ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
