and NOTE_CHANGE to notify the desktop environment to deal with
the change (e.g. after plugging in an HDMI cable)
with this change there is no need to manually do any randr commands
if your desktop environment supports it (gnome, mate, kde, etc.)
ok matthieu@, kettenis@
u_exec, but the introduction of re-exec'ing the previous invocation of cwm if
'exec_wm' failed missed the 'exec' failing path. Will likely split out as a
proper fix.
Odd behaviour reported by Ve Telko.
Corruption has again been reported on Intel hardware running Xorg with
the modesetting driver (which uses OpenGL based acceleration instead of
SNA acceleration the intel driver defaults to).
Reported in various forms on Sandy Bridge (X220), Ivy Bridge (X230) and
Haswell (X240). Confirmed to not occur with the intel driver but the
xserver was changed to default to the modesetting driver on >= gen4
hardware (except Ironlake).
One means of triggering this is to open a large pdf with xpdf on an
idle machine and highlight a section of the document.
There have been reports of gpu hangs on gen4 intel hardware
(T500 with GM45, X61 with 965GM) when starting Xorg as well.
to it is useless, so detach the xserver driver and close it.
Modeled on similar code in xf86-input-{keyboard,mouse}
reminded by Frank Groeneveld (frank (at) frankgroeneveld.nl)
ok matthieu@ kettenis@
which one may configure (wm <name> <path_and_args>) (and choose) specific
window managers to replace the running one. 'wm cwm cwm' is included by
default.
No objections and seems sensible to sthen.
into the keyrelease event, only performing what's actually needed for each;
should result in much fewer events against keyreleases. No intended behaviour
change.
Additionally, like we do for group membership, grab the keyboard only when
required for cycling.
close to cwm's 'ignore'.
Roughly based on an initial diff from Walter Alejandro Iglesias, but with
support for both Atoms and without cwm-based bindings.
