Debugging NULL pointers is significantly easier than random memory.
Plus, if new fields (such as pointer barriers) are added they may just be
properly initialised.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
We really need symbols, compat, keynames, vmods and types for a sensible keymap.
Try this in your xorg.conf.d snippets for all keyboards:
Option "XkbLayout" "us"
Option "XkbVariant" "nodeadkeys"
us(nodeadkeys) doesn't exist so xkbcomp provides everything but the symbols
map. We say we want everything but don't _need_ anything, the server happily
gives us a keymap with every key mapped to NoSymbol. This in turn isn't what
we want after all.
So instead, require symbols, compat, keynames, vmods and types from the
keymap and if that fails, load the default keymap instead. If that fails
too, all bets are off.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Refactoring for simpler double-use in the next patch. No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
The previous XKB info was being returned instead of the current
one, producing inconsistent results between the latest events
and the modifiers/group returned by this call.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-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>
==9999== Syscall param writev(vector[...]) points to uninitialised byte(s)
==9999== at 0x4AB5154: writev (writev.c:51)
==9999== by 0x7C7C3: _XSERVTransWritev (Xtrans.c:912)
==9999== by 0x61C8B: FlushClient (io.c:924)
==9999== by 0x62423: WriteToClient (io.c:846)
==9999== by 0xCE39B: XkbSendMap (xkb.c:1408)
==9999== by 0xD247B: ProcXkbGetKbdByName (xkb.c:5814)
==9999== by 0x4AB53: Dispatch (dispatch.c:432)
==9999== by 0x205BF: main (main.c:291)
==9999== Address 0x557eb68 is 40 bytes inside a block of size 4,096 alloc'd
==9999== at 0x48334A4: calloc (vg_replace_malloc.c:467)
==9999== by 0x62567: WriteToClient (io.c:1065)
==9999== by 0x452EB: ProcEstablishConnection (dispatch.c:3685)
==9999== by 0x4AB53: Dispatch (dispatch.c:432)
==9999== by 0x205BF: main (main.c:291)
==9999== Uninitialised value was created by a stack allocation
==9999== at 0xD1910: ProcXkbGetKbdByName (xkb.c:5559)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
==537== Syscall param writev(vector[...]) points to uninitialised byte(s)
==537== at 0x4AB7154: writev (writev.c:51)
==537== by 0x8935B: _XSERVTransWritev (Xtrans.c:912)
==537== by 0x6C55F: FlushClient (io.c:924)
==537== by 0x6CCF3: WriteToClient (io.c:846)
==537== by 0xD51D3: XkbSendNames (xkb.c:3765)
==537== by 0xD8183: ProcXkbGetKbdByName (xkb.c:5825)
==537== by 0x27B7B: Dispatch (dispatch.c:432)
==537== by 0x205B7: main (main.c:291)
==537== Address 0x55899f2 is 154 bytes inside a block of size 1,896 alloc'd
==537== at 0x4834C48: malloc (vg_replace_malloc.c:236)
==537== by 0xD47AF: XkbSendNames (xkb.c:3642)
==537== by 0xD8183: ProcXkbGetKbdByName (xkb.c:5825)
==537== by 0x27B7B: Dispatch (dispatch.c:432)
==537== by 0x205B7: main (main.c:291)
==537== Uninitialised value was created by a heap allocation
==537== at 0x4834C48: malloc (vg_replace_malloc.c:236)
==537== by 0xD47AF: XkbSendNames (xkb.c:3642)
==537== by 0xD8183: ProcXkbGetKbdByName (xkb.c:5825)
==537== by 0x27B7B: Dispatch (dispatch.c:432)
==537== by 0x205B7: main (main.c:291)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
==543== Syscall param writev(vector[...]) points to uninitialised byte(s)
==543== at 0x4AB7154: writev (writev.c:51)
==543== by 0x8935B: _XSERVTransWritev (Xtrans.c:912)
==543== by 0x6C55F: FlushClient (io.c:924)
==543== by 0x6D013: FlushAllOutput (io.c:668)
==543== by 0x27A83: Dispatch (dispatch.c:453)
==543== by 0x205B7: main (main.c:291)
==543== Address 0x556dc8c is 12 bytes inside a block of size 4,096 alloc'd
==543== at 0x48334A4: calloc (vg_replace_malloc.c:467)
==543== by 0x6CE37: WriteToClient (io.c:1065)
==543== by 0x223A7: ProcEstablishConnection (dispatch.c:3685)
==543== by 0x27B7B: Dispatch (dispatch.c:432)
==543== by 0x205B7: main (main.c:291)
==543== Uninitialised value was created by a stack allocation
==543== at 0xA3350: ProcRRCreateMode (rrmode.c:289)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
==9999== Syscall param writev(vector[...]) points to uninitialised byte(s)
==9999== at 0x4AB5154: writev (writev.c:51)
==9999== by 0x7C7C3: _XSERVTransWritev (Xtrans.c:912)
==9999== by 0x61C8B: FlushClient (io.c:924)
==9999== by 0x62743: FlushAllOutput (io.c:668)
==9999== by 0x4AA5B: Dispatch (dispatch.c:453)
==9999== by 0x205BF: main (main.c:291)
==9999== Address 0x55711b9 is 1 bytes inside a block of size 4,096 alloc'd
==9999== at 0x48334A4: calloc (vg_replace_malloc.c:467)
==9999== by 0x62567: WriteToClient (io.c:1065)
==9999== by 0x452EB: ProcEstablishConnection (dispatch.c:3685)
==9999== by 0x4AB53: Dispatch (dispatch.c:432)
==9999== by 0x205BF: main (main.c:291)
==9999== Uninitialised value was created by a stack allocation
==9999== at 0x160E78: ProcRRQueryVersion (rrdispatch.c:37)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
We don't modify "value", make it official.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
The EDID processing regards physical dimensions of 0mm x 0mm as
invalid. Previously the old values for height and width would be
preserved if none of the physical dimension specifications in the new
EDID were considered valid.
This will come up in particular if first a monitor is connected to an
output, and then a projector is connected. Since projectors generally
report physical dimensions of 0mm x 0mm, this would result in the
projector claiming to have the physical dimensions of the monitor.
Signed-off-by: Evan Broder <ebroder@mokafive.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This aligns the xorg server build with the mesa build, which is needed on
systems where aiglx with dri support is not enabled. Else the following error is
obtained when trying to load the software raster:
(EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: undefined symbol: _glapi_tls_Context)
(EE) GLX: could not load software renderer
(II) GLX: no usable GL providers found for screen 0
because mesa always enables TLS use in GLX, even if dri is not available.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
- Apps like xterm can trigger a lot of fallback rendering.
- This can lead to (annoyingly) high latencies, because you
have to wait for the block handler.
- You need a driver that doesn't directly access the front
buffer to trigger this (NV50+ nouveau for example).
- Repeatingly doing dmesg on an xterm with a bitmap font
will reveal that you never see part of the text.
- I have recieved at least one complaint in the past of slow
terminal performance, which was related to core font
rendering.
- This does sacrifice some throughput, roughly 33% slower.
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
- Not sure if it was causing problems, but you never know.
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
M_DRAWABLE_PIXMAP is the lookup mask to dixLookupDrawable, and _not_ the
type value in the drawable itself.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Signed-off-by: Keith Packard <keithp@keithp.com>
DGAIsDgaEvent() is not used anymore.
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Move some variables to the scope where they are used.
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously some sort of absolute coordinates were sent out in
the padding of the DGA2 Motion and Button events. DGAMouseX
and DGAMouseY were used to keep track of said coordinates.
libXxf86dga doesn't use that data for anything, and at least
git history didn't show any past usage either. So let's just
remove the last remnants of of this mess.
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Copy dx/dy from the internal event to the DGA2 Motion/Button events.
Do the same for Key events for the sake of keeping the code consistent.
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
mieq_installed is used as a boolean, so why not make it such. Also
it's a static variable, so the the explicit zero initialization can
be removed.
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Remove the handler only if it was installed. Also mark it as
uninstalled, otherwise it wouldn't get reinstalled after a
server reset.
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The ET_DGAEvent handler is only installed when a client
requests relative events via DGA1. Do it also when a client
requests DGA2 events.
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
DGA key event support was lost in commit
8da0ff2d51. Bring it back.
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When XkbChangeEnabledControls is called to disable key repetition of a
certain key (or keys), currently ongoing repetition of that key was
not cancelled. It was cancelled if ChangeKeyboardControl was used to
disable key repetition globally.
Reviewed-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Reviewed-by: Dirk Wallenstein <halsmit@t-online.de>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
xf86bigfont.c: In function 'XFree86BigfontExtensionInit':
xf86bigfont.c:146: error: 'ProcXF86BigfontDispatch' undeclared (first use in this function)
xf86bigfont.c:147: error: 'SProcXF86BigfontDispatch' undeclared (first use in this function)
It seems this has been broken since commit cbd4d5dbb7
"delete pervasively use of DISPATCH_PROC" (2010-09-28), which is a bit worrying as
that presumably indicates that no tinderbox is configuring with --enable-xf86bigfont.
In a similar fashion to that commit, fix by moving XFree86BigfontExtensionInit()
below the definitions of the static dispatch functions it references.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Julien Cristau <jcristau@debian.org>
We get an XP_EVENT_DISPLAY_CHANGED event when our display configuration is
changed. If this change was caused by hotplugging a monitor or Mac Display
Preferences changes by the user, we need to call RRScreenSizeNotify in order
to ensure new connections get the correct screen size.
http://xquartz.macosforge.org/trac/ticket/460
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This is clearly meant to short-circuit the (modestly) expensive resource
lookup in LegalNewID. The problem is that long-lived clients will
eventually run completely through their XID space and start asking
XC-MISC for IDs to reuse. Once that happens, the comparison against
expectID will always be true, and we'll no longer catch XID collisions
at all.
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We can return from WaitForSomething with no clients ready for any number
of reasons. There's no reason to set up the scheduler timer when this
happens.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
xdmxconfig.c: In function ‘dmxConfigCanvasDraw’:
xdmxconfig.c:299:23: warning: ‘maxHeight’ may be used uninitialized in this function
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
dmxinputinit.c: In function ‘dmxBlockHandler’:
dmxinputinit.c:610:44: warning: cast from pointer to integer of different size
dmxinputinit.c: In function ‘dmxWakeupHandler’:
dmxinputinit.c:637:41: warning: cast from pointer to integer of different size
dmxinputinit.c: In function ‘dmxInputInit’:
dmxinputinit.c:1041:36: warning: cast to pointer from integer of different size
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
dmxinputinit.c: At top level:
dmxinputinit.c:135:29: warning: ‘DMXCommonOth’ defined but not used
DMXCommonOth is actually mentioned in a #if 0 block, so delete it and
the block that references it. If anyone needs it, git remembers.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
dmxgc.c: In function ‘dmxChangeClip’:
dmxgc.c:386:5: warning: case label value exceeds maximum value for type
dmxgc.c:387:5: warning: case label value exceeds maximum value for type
dmxgc.c:388:5: warning: case label value exceeds maximum value for type
dmxgc.c:389:5: warning: case label value exceeds maximum value for type
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
