This reverts commit 43d9edd31e.
This commit was introduced in the 1.2 cycle when hotplugging was less than
ideal (i.e. it didn't exist). From the commit message:
Always add a mouse driver instance configured to send core events, unless
a core pointer already exists using either the mouse or void drivers. This
handles the laptop case where the config file only specifies, say,
synaptics, which causes the touchpad to work but not the pointing stick.
We don't double-instantiate the mouse driver to avoid the mouse moving twice
as fast, and we skip this logic when the user asked for a void core pointer
since that probably means they want to run with no pointer at all.
To get this case above, a user would need to disable hotplugging _and_ have a
xorg.conf that only references one device. This is possible, but not a use-case
we should worry about too much now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Add support for multi-seat-aware input device hotplugging. This
implements the multi-seat scheme explained here:
http://www.freedesktop.org/wiki/Software/systemd/multiseat
This introduces a new X server switch "-seat" which allows configuration
of the seat to enumerate hotplugging devices on. If specified the value
of this parameter will also be exported as root window property
Xorg_Seat.
To properly support input hotplugging devices need to be tagged in udev
according to the seat they are on. Untagged devices are assumed to be on
the default seat "seat0". If no "-seat" parameter is passed only devices
on "seat0" are used. This means that the new scheme is perfectly
compatible with existing setups which have no tagged input devices.
Note that the -seat switch takes a completely generic identifier, and
that it has no effect on non-Linux systems. In fact, on other OSes a
completely different identifier scheme for seats could be used but still
be exposed with the Xorg_Seat and -seat.
I tried to follow the coding style of the surrounding code blocks if
there was any one could follow.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Slowly merging the vastly different code-paths.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
No functional changes, just readability improvements. This also gets rid of
the count variable. Count was just used for resizing the null-terminated
list. Since we're not in a time-critical path here at all we can afford to
loop the list multiple times instead of keeping an extra variable around.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
If we find the core device, move all other device pointers forward right
then and there. The break will jump out of the top loop.
They had a special on braces today, so I added some for readability (and
fixed up tab vs space indentation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
No functional changes.
The options we assign are the ones from the Pointer/Keyboard device so we
might as well use those readable names instead of dev[count-1]->options.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Devices are core pointers/keyboards by default now anyway, but let's set the
option to some value instead of just NULL.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
It doesn't matter. All devices are core pointer devices by default now
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
LogHdrMessageVerb allows passing a parameterized header to insert in a log
message between MessageType and the formatted message body string.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
LogHdrMessageVerb allows passing a parameterized header to insert in a log
message between MessageType and the formatted message body string.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes assertion failure when calling dixSetPrivate
Debian bug#632549 <http://bugs.debian.org/632549>
Reported-and-tested-by: Mohammed Sameer <msameer@foolab.org>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Instead of just closing the log when everything is done, put one more
message in stating that we're actually terminating. Users or scripts that
look at the Xorg.log will then know that a) the server has terminated
properly and b) why the server terminated (to some degree, given that most
real-world errors will be caused by AbortServer()).
Acked-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Tested-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Tested-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For hotplugged devices, xf86AllocateInput does that for us but the xorg.conf
path is different. Since not all drivers reset the fd during PreInit but may
still call close(pInfo->fd) in all cases, this can terminate the logging
early.
Reproducible: add a wacom driver InputDevice section with no Option Device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
xf86ConfigLayout.inputs contains the information from the xorg.conf
file. Passing this into xf86NewInputDevice means the device will get
cleaned up on exit and the pointers in xf86ConfigLayout.inputs are left
dangling. In the second server generation, this results in a server
crash.
Also, rename pDev to pInfo. pDev is pretty much reserved for DeviceIntPtr
types.
Reproducible: AutoAddDevices off and xorg.conf input sections, trigger
server regeneration.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Devices that succeeded during PreInit and DEVICE_INIT but failed in
DEVICE_ON would be deleted through xf86DeleteInput but not removed from the
list of input devices (and not turned off). The result was a double free on
server shutdown.
Fix this by calling RemoveDevice if EnableDevice fails.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
This preference allows users to override the related option in Mac OS X's
Mouse/Trackpad preferences. This effectively lets the user determine
which "context" all of X11 fits into for context-based scrolling until
such API exists within X11 itself to pass along to X11 clients.
This is applicable to Mav OS X 10.7+
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
This occurred to me in hindsight after the last commit. If the
original developer had done this, we would have noticed the
problem sooner.
(cherry picked from commit aa0a57996f)
xp_destroy_surface was called with a surface id of 0, due to some
premature cleanup that set it to 0. This means the surfaces
weren't being destroyed until the window was.
The code that did that was: pDRIDrawablePriv->sid = 0;
In long running applications this leak may or may not have been
harmful. With the old libGL the surfaces weren't destroyed until
the context was destroyed or a new context created. In the new
libGL they are reference counted, and released much sooner, so we
ran into a resource leak more noticeably with some tests.
Make the Apple DRI code dispatch events to the client(s) for
destroyed surfaces, when a resource is destroyed. This seems to
work in my tests, however this clearly wasn't working for a while,
so bugs may result in the future if it enables some new (unexpected)
side effects.
Also add a few helpful comments to aid in understanding the code
in the future.
Tested with the test suite, Pymol, and various Mesa demos.
(cherry picked from commit bede83eb19)
This way we'll print an error and still mostly work rather than crashing if
someone installs XQuartz.app incorrectly or tries running the server within
the build system rather than the installed system.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
The GLXversion member of the __GLXscreen struct
is just cruft since commit ad5c0d9efa,
when we started returning the minimum GLX version supported by all
of the screens on the display, rather than the maximum version supported
by the server.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Document the -[no]wgl options in the XWin manpage
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Report Window XIDs in Window create/destroy/reparent debug messages
It's actually quite useful if you are trying to corrolate those events
with what a client is doing...
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Add a suitable cast to the generated code for glWinSetupDispatchTable()
so it doesn't generate screeds of warnings
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Handle failure to get any useful pixel formats for GLX fbconfigs
more gracefully: If we didn't get any useful pixel formats from
wglGetPixelFormatAttribivARB(), fall back to using DescribePixelFormat().
If that doesn't give us any useful pixel formats, fallback to software
rendering.
This works around a problem with Intel 845G drivers, where
wglGetPixelFormatAttribivARB() doesn't seem to work as we expect it to...
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
... instead just log if an attempt is made to call a wrapper for
a function which didn't resolve
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Propagate and report the failure if SetPixelFormat() fails
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Request the message using languageID 0 (best effort), rather than only using language neutral messages
Always report the numeric error code.
Trim any trailing \r from FormatMessage() output
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Some graphics hardware supports hundreds of pixel formats, so adjust
formatting in fbconfig dumper for 3 digit index numbers
Also report the PFD_SUPPORT_DIRECTDRAW, PFD_DIRECT3D_ACCELERATED and
PFD_SUPPORT_COMPOSITION flags introduced with aero
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
mieqFini() already does the right thing, but it needs to be called by the
various DDXs and the XTest Extension.
X.Org Bug 38634 <http://bugs.freedesktop.org/show_bug.cgi?id=38634>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Acked-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
miPointerUpdateSprite is already called from mieqProcessInputEvents, so
calling it by hand immediately after isn't massively helpful.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
miPointerUpdateSprite is already called from mieqProcessInputEvents, so
calling it by hand immediately after isn't massively helpful.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Headers don't really need to be mode 0755.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add four new private XKB actions for debugging:
* PrGrbs: print active grabs to the log file
* Ungrab: ungrab all currently active grabs
* ClsGrb: kill clients with active grabs
* PrWins: dump the current window tree to the log file
To use these, you need to modify your XKB maps, e.g. the following to
have Ctrl+Alt+(F9-F12) mapped to the above:
- compat/xfree86:
interpret XF86LogGrabInfo {
action = Private(type=0x86, data="PrGrbs");
};
interpret XF86Ungrab {
action = Private(type=0x86, data="Ungrab");
}
interpret XF86ClearGrab {
action = Private(type=0x86, data="ClsGrb");
}
interpret XF86LogWindowTree {
action = Private(type=0x86, data="PrWins");
}
- symbols/pc:
key <FK09> { type="CTRL+ALT", [ Return, XF86LogGrabInfo ] };
key <FK10> { type="CTRL+ALT", [ Return, XF86Ungrab ] };
key <FK11> { type="CTRL+ALT", [ Return, XF86ClearGrab ] };
key <FK12> { type="CTRL+ALT", [ Return, XF86LogWindowTree ] };
At the moment, this only works if the grabbing client continues to call
AllowEvents, as the server does no event processing at all when a device
is frozen.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
