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 q&d 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
