Display output "hot Key" switch is on hight demand. Here is a discussion on adding the feature on server side, with a default "hot key" that is independent of the system. We may need a default "hot key" because a lot of laptops currently in market do not have ACPI support for such a "hot key".
Here a proposal of using a "hot key" to dynamically reconfigure output devices, and with consecutive key presses, rotate output status. Below is a brief description of the prototyping. (1) The basic switch code, do_mon_switch(), is a state machine added to X server that uses RandR1.2 functions RRGetInfo(), RRScreenSizeSet() and RRCrtcSet() to probe, detect and set monitor outputs. do_mon_switch() is triggered by a predefined "hot key" stroke. If such a key is pressed 8 seconds or longer after the previous press, the monitor output configuration is re-probed so that any output configuration changes, such as adding or removing monitors, can be detected and adapted to. When 2 monitors are turned on, the largest common resolution for both monitors will be automatically used. The proposal allows switch among up to 3 video outputs. For example, in a system with LCD, VGA and DVI outputs and 2 crtcs, 6 different states (excluding states of all on and all off) of them will be cycled through with consecutive "hot key" presses. (2) Two interfaces are provided. * ACPI defined "hot key", a function key defined by a laptop ACPI layer. A kernel driver is required to detect the key stroke, and send a corresponding event to X server. * Default "hot key", A predefined key stoke independent of system. Default "hot key" is useful when a system does not provide ACPI defined "hot key" support. (3) Implementation of default "hot key" * A new keysym XORG_Switch_MON is added to keysym database XKeysymDB, and a predefined keycode mapping is created to map certain keycode to XORG_Switch_MON with a predefined modifier. * A new xkb action, XkbSA_SwitchMonitor is added that triggers a monitor switch (a call to do_mon_switch()) whenever XORG_Switch_MON is activated. * Command "xmodmap -e ..." may be used to undefine the predefined keycode mapping, or to redefine a new keycode mapping. Examples: (suppose F5 is the keycode for F5 key) xmodmap -e "keycode 71 = F5 XF86_Switch_VT_5 XORG_Switch_MON" to define hot key to be "Mode_switch + F5" xmodmap -e "keycode 71 = F5 XF86_Switch_VT_5" to undefine the previous definition.
On Mon, Jun 02, 2008 at 05:05:54PM -0700, bugzilla-daemon@freedesktop.org wrote: > (1) The basic switch code, do_mon_switch(), is a state machine added to X > server Why would you not do this on the client side?
(In reply to comment #2) > On Mon, Jun 02, 2008 at 05:05:54PM -0700, bugzilla-daemon@freedesktop.org > wrote: > > (1) The basic switch code, do_mon_switch(), is a state machine added to X > > server > > Why would you not do this on the client side? > If doing it on client side, the client must be able to grab key strokes, and must run constantly. Some window managers may qualify. But X applications may run without window manager.
On Wed, Jun 04, 2008 at 11:50:55AM -0700, bugzilla-daemon@freedesktop.org wrote: > --- Comment #3 from henry.zhao@sun.com 2008-06-04 11:50:53 PST --- > (In reply to comment #2) > > On Mon, Jun 02, 2008 at 05:05:54PM -0700, bugzilla-daemon@freedesktop.org > > wrote: > > > (1) The basic switch code, do_mon_switch(), is a state machine added to X > > > server > > > > Why would you not do this on the client side? > > If doing it on client side, the client must be able to grab key strokes, Sure. One specific key. > and must run constantly. Some window managers may qualify. But X applications > may run without window manager. So, have a dedicated client. This is an insane amount of logic to add to the server, especially given that people often want to be prompted by the keystroke, instead of having it blindly guess.
(In reply to comment #4) > On Wed, Jun 04, 2008 at 11:50:55AM -0700, bugzilla-daemon@freedesktop.org > wrote: > > --- Comment #3 from henry.zhao@sun.com 2008-06-04 11:50:53 PST --- > > (In reply to comment #2) > > > On Mon, Jun 02, 2008 at 05:05:54PM -0700, bugzilla-daemon@freedesktop.org > > > wrote: > > > > (1) The basic switch code, do_mon_switch(), is a state machine added to X > > > > server > > > > > > Why would you not do this on the client side? > > > > If doing it on client side, the client must be able to grab key strokes, > > Sure. One specific key. > > > and must run constantly. Some window managers may qualify. But X applications > > may run without window manager. > > So, have a dedicated client. This is an insane amount of logic to add > to the server, especially given that people often want to be prompted by > the keystroke, instead of having it blindly guess. > Unfortunately "dedicated client" would not always work. A client implementation may work if we assume display switch is triggered ONLY by ACPI defined "hot key" stroke. In that case, we may have the client subscribe to receiving such "hot key" event, and when kernel detects such "hot key" stroke it notifies the client. We have a prototyping for doing the above. However, as I mentioned before, a lot of laptops in market do not have ACPI support for display switch "hot key", i.e. an ACPI event is NOT generated on a "hot key" stoke, even though there is a display switch mark printed on the "hot" function key. This leads to the idea of defining a "default hot key" (redefinable by users) independent of system. If a client is used for that purpose, the client has to be able to grab key inputs. Implementing it as a regular one, you have to first launch (or activate) the client before making a key storke, that would be inconvenient. Implementing it as a window manager could avoid such problem, but not all applications run under window manager. It may look like the stuff is too "application specific" to add to the server. But I really don't have a better way of doing it. Due to the wider use of laptops the topic of display switch becomes hot. Intel has a proposal of doing it with a co-ordination of VBIOS, server and driver, plus a new feature of "driver ready" (basically it prohibits switching during initialization, suspend resume etc). However it works only on platforms shipped with intel-opregion-ready vbios. It does not address the problem that currently many laptops systems do not have ACPI support of display swith "hot key".
On Mon, Jun 09, 2008 at 07:13:08PM -0700, bugzilla-daemon@freedesktop.org wrote: > Unfortunately "dedicated client" would not always work. A client implementation > may work if we assume display switch is triggered ONLY by ACPI defined > "hot key" stroke. What? You were talking about adding a new XKB server action, triggered by a new keysym. Why could the new keysym just be added (or one of the existing ones used), and the client run XGrabKey to make sure it receives events from that key? If it's possible to run a server action whenever this hotkey is pressed (be it ACPI or not), then it's possible to have a client do something. > If a client is used for that purpose, the client has to > be able to grab key inputs. Yes. > Implementing it as a regular one, you have to first > launch (or activate) the client before making a key storke, that would be > inconvenient. Well, right now we already force people to launch a special client before they can change focus, or move a window around. Why is this hard? We don't special-case the Print Screen key in the server, but instead the desktop environment grabs it and makes sure the screenshot app is launched. I'm sure desktop environments can take care of it. > Implementing it as a window manager could avoid such problem, but > not all applications run under window manager. So? > It may look like the stuff is too "application specific" to add to the server. Yes. > But I really don't have a better way of doing it. Due to the wider use of > laptops the topic of display switch becomes hot. Of course, and I sympathise with that, but adding insane display reconfiguration logic to the server is _not_ the answer. As I said before, some people will want to be prompted (look at what happens on ThinkPads under Windows when you press the display hotkey). How do you handle that within the server? Remember: mechanism, not policy. And we already have all the mechanism in place. > Intel has a proposal of doing > it with a co-ordination of VBIOS, server and driver, plus a new feature of > "driver ready" (basically it prohibits switching during initialization, suspend > resume etc). However it works only on platforms shipped with > intel-opregion-ready vbios. It does not address the problem that currently > many laptops systems do not have ACPI support of display swith "hot key". You're conflating about 17 problems here. Your proposal is to have a specific new keysym trigger a specific new XKB SA. I'm pointing out that if you can get that KeySym into XkbProcess*(), then you can get that keysym to the client with zero extra effort. The client can than grab on that key and DTRT. If it's not running, well, tough: nothing happens. We don't have window management logic in the server. We don't have print screen logic in the server (despite it being an important 'hot key'). I don't see the unprecedented importance of the display switch hot key (how it's wired up, be it ACPI, opregion, actual key event, really doesn't interest me in the slightest, as long as a KeyPress is generated in the end) that would force us to buck with 21 years of actual good sense and shove all this in the server.
Created attachment 17941 [details] [review] Client implementation of video display device switch The binary will be built in the same module where xrandr
Description of the attachment (17941): 1) Usage: dispswtch [options] where options are: -display <display> or -d <display> -key <keysym> or -k <keysym> -mod <modifier> or -m <modifier> —help —notwin —verbose —testrun The default hotkey (without -key and -mod options) is 'Shift + F5'. -key <keysym> -mod <modifier> will let you define your hotkey: <keysym> is any keysym defined in /usr/X11/include/keysymdef.h, with prefix XK_ removed, such as F5, F8, Escape. <modifier> is any or combination of modifiers on your system. You can run /usr/X11/bin/xmodmap to find all available modifiers on your system. They can be shift, control, mod1, mod3, mod4, etc. Examples: o -key Escape -mod shift defines the hotkey to be 'shift + Esc' o -key F2 -mod "shift+control" defines the hotkey to be 'shift + control + F2' * —notwin option skips twinview states in two devices rotating. * —testrun option lets you switch repeatedly without hotkey strokes * —verbose option prints debug messages (2) Features The tool lets you rotate on/off of display devices for up to 3 devices. Twin view is included when two devices are connected. When only one device is turned on, either the resolution before switching or the highest resolution of the monitor will be used for display. When 2 devices are turned on, the largest common resolution is used. If a key stroke is hit 5 seconds or longer after the previous hit, display devices are re-probed so that any changes such as adding or removing devices, can be detected and adapted to. (3) Notes It works with all drivers that support RandR1.2. If you add a new display device whose resolution is larger that the one you started X server, or you get into a twin view state that needs a higher resolution to cover both screens, you need to allocate a larger virtual screen size during X server startup with a config file.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.