There's little chance that we'll get the input devices at runtime without HAL,
we might as well force the server to add mouse/kbd devices automatically -
just like in the olden days.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Previously each server starting ran xkbcomp with the output set to
<keymapname>.xkm, read it, then deleted it - which led to races if
two servers were starting at the same time with the same keymap.
Sun bug #6773816 Xorg uses the same xkm output file for compiled keymap file
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6773816>
This way we on't need to hold the mutex during the dixSaveScreens() call.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Tiago Vignatti <vignatti@c3sl.ufpr.br>
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
These values need not be constrained to integer values.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Added a configure option called --enable-standalone-xpbproxy which is useful for deveoping xpbproxy.
The 'active' switch in preferences just disables the in-server xpbproxy (not this standalone).
(cherry picked from commit 4294493632)
This prevents visuals with odd sizes. The machine I use didn't have
this problem, but it shows up on some others.
(cherry picked from commit ed181382dd)
Use the settings queried from the system in xprScreen.c, rather than those 2 calls.
The 2 calls increased the total number of visuals a great deal (when using GLXEXT),
and not all of the visuals were usable with GLX. Some of the visuals aren't usable
with GLX still, such as DirectColor, but that seems to be acceptable based on my
understanding of the manual that states "a subset of visuals are made available
for OpenGL rendering."
(cherry picked from commit 373b8a5f32)
It was returning inverted values in comparison to the 1.4 branch. This resulted in
the windows not drawing due to a deep path of: RootlessReorderWindow ->
SCREENREC(pScreen)->imp->DoReorderWindow(winRec) - > xprDoReorderWindow ->
AppleWMDoReorderWindow.
(cherry picked from commit d1d398db76)
We need them for each window, every time a window is allocated. Storing them
in a devPrivate is the wrong thing to do.
This also removes the unused ENTER_LEAVE_SEMAPHORE_ISSET macro.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
grab == devgrab anyway, this is a leftover from the time when we had two
different grabs per device (core and XI grab).
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Copy the EventRec's information into local variables before processing them,
this should make it safer for upcoming threading and also makes it easier to
read.
Simplify the event allocation code from the abyss it was before.
This also fixes a potential bug where a custom handler could scramble the
event before the same -now scrambled- event was then passed through the
master's custom event handler.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
As reported in http://bugs.freedesktop.org/show_bug.cgi?id=18438
the server suggests reconfiguring HAL if AllowEmptyInput is enabled
and no input devices are known.
Instead of that notice, if HAL is disabled at configure time,
AllowEmptyInput is enabled in the config and no input devices are
found report those facts and recommend disabling AllowEmptyInput.
When using any XAAPixmapOps, we call into unknown but freshly
unwrapped callbacks (like fb ones). Unlike the XAA*Fallback calls,
we did so without syncing first, exposing us to all kinds of
synchronisation issues.
I believe that the rendering errors appeared now because *PaintWindow
vanished (e4d11e58), and we just use miPaintWindow instead. This
takes a less direct route to the hw and ends up at
PolyFillRectPixmap, which very often left drawing artifacts.
We now sync accordingly, and no longer get the rendering artifacts i
was methodically reproducing on radeonhd, radeon, unichrome...
Also, in order to allow driver authors to remove extensive syncing
or flushing to hide this issue, create XAA_VERSION_ defines, put
them in xaa.h and bump the patchlevel.
(novell bug #435791)
When setting the depth to 24, leave bpp unset so the logic to pick
a supported value is used instead of ignoring the driver's preference
and forcing 32 bpp.
The swrast DRI provider gets pushed on the glx provider stack at every
server generation, so the stack turns into a circular list on regen.
X.Org bug#18388 <https://bugs.freedesktop.org/show_bug.cgi?id=18388>
GL/capabilities.c: Add handleDepthModes(), and extend
handleRendererDescription() for the various depth and multisampling flags.
Add initialization of the new config options to initConfig().
GL/capabilities.h: Add depth and multisample config members.
GL/visualConfigs.c: Add depth and multisampling support to the visual config
setup.
(cherry picked from commit f527381eea)
GL/capabilities.c: #if 0 (for now) any capabilities above 8 bits per channel,
because they introduce drawing problems.
GL/indirect.c: Comment out some visual setup code that shouldn't be running, and
actually seemed to cause some problems. The current visualConfigs.c code seems
to do a reasonable job of setting up visuals for XQuartz.
GL/visualConfigs.c: Make use of the proper visual .class. Eliminate depth 0.
It seems we really just want 24 for now, and 0 I think was a flaw in the original
code.
(cherry picked from commit 1e5f63f15e)
