times you'd end up losing clients (thinking they had gone away).
From the ICCCM (which should not be read without a stiff drink in hand,
I made this mistake so you don't have to): to request a window to be
withdrawn one should send a synthetic UnmapRequest event when iconified.
To request iconification one should just unmap the window. The ICCM
further recommends that the synthetic event should just be taken as a
cue to withdraw, to deal with legacy clients. Taking a hint from this,
rework xev_handle_unmaprequest to correctly detect these situations. A
Withdrawn window may come back anywhere, even as a subwindow of
something else, so the correct way to handle this state is to forget it
ever existed.
While i'm here, kill a dumb attempt to notice this in client_delete, and
nuke the very unnecessary arguments.
Todd confirmed this fixes the `race'.
ok todd@, ok ok okan@
to push attributes around, so things get a lot simplier, while fixing a
few issues in the meantime; original suggestion by Edd Barrett many many
moons ago.
annoying window placement and race, found in c2k8 by todd, fix by oga!
lots of feedback from todd and oga - thanks!
"commit that bad boy" oga@
The behaviour until now was to ask X for the windows name (which is
malloced) then drop that on the floor and do nothing with it. Skip this
foolery and just skip the window. I don't believe I never noticed this before!
"you can has ok" okan@
- properly name, place and static private functions.
- move function which finds the xinerama screen for a coordinate to
a more appropriate place while altering its semantics to match others.
- tiny bit of style.
ok oga@
- merge grab_drag() into mousefunc_window_move().
- properly name, proto and static private functions.
- since we already do XMoveResizeWindow() and XMoveWindow() in (now)
mousefunc_window_resize() and mousefunc_window_move() respectively,
client_resize() and client_move() calls are unnecessary.
ok oga@
correct a cast in input.c, which broke translation of numeric
keypad codes to pageup, pagedown, etc., on 64-bit platform (Debian
#511138, report by Larry Doolittle).
Now that xenocara has been made clean with respect to using kernel headers
instead of those provided with libdrm, remove the copy of the headers included
here. Since it is now very simple, move it over to using standard bsd makefiles
instead of autoconf.
ok matthieu@
thereof provided with libdrm. This has been annoying me forever, and it
a blight caused by developing widely used drivers out of the kernel
tree.
ok matthieu@
it, and we're about to switch to using kernel headers instead of the
ones packaged with libdrm. If the unichrome driver gets rewritten (or I
eventually get time), then it'll come back.
ok matthieu@
light of day and has already been removed in mesa master (ages ago).
As a bonus, removes the annoying "falling back to classic" message on
launching a gl application.
ok matthieu@.
from this was removed from the kernel and is very much deprecated.
Pageflipping is also probably broken and should not be used. Similar
change happened in mesa master a while back.
ok matthieu@
really don't need it. There's one case where it's used, and that is on
``older'' drms, newer ones provide that one value via a parameter.
This is the first stage in my project to stop all cards mapping
registers. This does mean that drivers that depend on this may
eventually die (tdfx, i'm looking at you!).
ok matthieu@
but you disable dri on in the driver build and don't have the via_drm.h
it wants in dri mode. Work around this by changing the #define used to
an openchrome only one, instead of overloading the XF86DRI identifier.
Also disable the DRI build unconditionally.
This is needed here since we don't provide the via DRM module, and i'm
moving libdrm over to using the kernel headers (instead of libdrms own
private copy of same... This is why kernel modules should be developed
in kernel). We won't provide a via drm driver until it is re-written,
since it is full of linuxisms (like futex).
ok matthieu@, discussed with a few. tested by grange@ to prove it was a
no-op functionality wise.
