RRFirstOutput returns the first active output, which won't be set until
after RRScanOldConfig is finished running. Instead, just use the first
output (which is the only output present with an old driver, after all).
I exported the evdev driver to Xephyr server. I'm running it using something
like:
$ ./hw/kdrive/ephyr/Xephyr :1 -mouse evdev,,device=/dev/input/event4 -keybd \
evdev,,device=/dev/input/event1,xkbmodel=abnt2,xkblayout=br
It also closes /#5668.
Don't use our DBusError for property getting, because we simply don't care:
this fixes D-Bus error spew to stderr. Thanks Michel Dänzer for debugging
and testing.
and the Xephyr virtual mouse keeps alive. With this patch the semantic changes
turning '-pointer' && 'Xephyr virtual mouse' always false.
Now we can open a device pointer and pass its options in Xephyr's command line
without having other pointer unused.
Don't call fbFinishWrap until the pixman_image_t that stores the pointer is
actually freed. This prevents corruption or crashes caused by accessing a
wrapped pointer after the wrapping is torn down.
The outport is most likely unnecessary on any currently used hardware,
the byte copy is necessary from what I know on IA64 and friends so leave it.
Add a new API entry point which lets a driver select the old behaviour if
such a needs is ever found.
This gives me ~20% speed up on startup on 945 hardware.
This prevents situations where the server doesn't use the target the
client thinks it does, usually resulting in the texture being sampled as all
white.
I went through the entire xorg-server distribution and aggregated all
the licenses I could find (except the questionable GPL files, see my
last mail).
There are many many permutations on essentially the same license terms,
but I have been pedantic and treated slight differences as separate
licenses.
Here is a description of the process I used:
tar xvjf /usr/portage/distfiles/xorg-server-1.1.1.tar.bz2
cd xorg-server-1.1.1
find -name '*.c' -o -name '*.h' | xargs gvim
egrep -Rli "permission|copyright" * | grep -v "\.[ch]" \
| grep -v "\.in$" | xargs gvim
cd ..
tar xvjf /usr/portage/distfiles/xorg-server-1.3.0.0.tar.bz2
diff -urNp xorg-server-1.1.1 xorg-server-1.3.0.0
git clone git://anongit.freedesktop.org/git/xorg/xserver
cd xserver
git diff xorg-server-1.3.0.0..
For each file, licenses have been aggregated as follows:
If 2 files have identical license text but different copyright notices,
the copyright notices are aggregated and the license text
is included only once.
Note that by identical I mean really identical, i.e.:
'AUTHOR(S)' is not the same as 'AUTHORS'
'KEITH PACKARD DISCLAIMS' is not the same as 'KEITH PACKARD AND COMPAQ
DISCLAIM'
Otherwise, licenses and accompanying copyright notices have been
stacked.
When going through the changes from 1.1.1 to 1.3.0.0 then HEAD, licenses
have been added and removed (so I have reflected this since the original
version of my COPYING file). It's slightly concerning to see that even
between 1.3.0.0 and HEAD, new license permutations are being added. I'd
suggest that a primary license be chosen and this would be indicated at
the top of this COPYING file.
I went through the entire xorg-server distribution and aggregated all
the licenses I could find (except the questionable GPL files, see my
last mail).
There are many many permutations on essentially the same license terms,
but I have been pedantic and treated slight differences as separate
licenses.
Here is a description of the process I used:
tar xvjf /usr/portage/distfiles/xorg-server-1.1.1.tar.bz2
cd xorg-server-1.1.1
find -name '*.c' -o -name '*.h' | xargs gvim
egrep -Rli "permission|copyright" * | grep -v "\.[ch]" \
| grep -v "\.in$" | xargs gvim
cd ..
tar xvjf /usr/portage/distfiles/xorg-server-1.3.0.0.tar.bz2
Disclaimer: It's 6:51am. I'm trying to be as understandable as possible.
What was happening previously was this:
* Press Alt
* Extended event generated and processed: state is now Alt down once
* Core event generated
- keyboard switched: inherited state is Alt down once
- event processed: Alt down twice
* Release Alt
* Extended event generated and processed: state is now null
* Core event generated and processed: Alt down once
If we switch the order:
* Press Alt
* Core event generated:
- keyboard switched: inherited state is null
- event processed: Alt down once
* Extended event generated and processed: state is now Alt down once
* Release Alt
* Core event generated and processed: state is now null
* Extended event generated and processed: state is now null
When we carry over the previous state, it needs to be the _previous_ state
(state and modifiersPerKey), assuming that we're going to catch now-core
events for any of these. For example, if Ctrl is held down as we pivot, we
need to carry Ctrl over with a count of one, for which an extended + core
release will then clear. Carrying over the union of the previous state _and
the state resulting from the immediate action_ was what broke things.
If NoAutoAddDevices is given as a server flag, then no devices will be added
from HAL events at all. If NoAutoEnableDevices is given, then the devices will
be added (and the DevicePresenceNotify sent), but not enabled, thus leaving
policy up to the client.
Add support for HAL-based hotplugging, in which we just get the list of
input devices and properties from HAL. Requires an FDI which is not yet
in mainline HAL.
For some reason, my keyboard has 25 mouse buttons, but zero valuators. This
causes GPE to blow up spectacularly, trying to get (and set) co-ordinates from
devices without valuators. For now, just prevent this from ever happening,
and whack a dirty great FIXME in.
