gmane.linux.ubuntu.devel.x

Fighting renames, day 1

Maarten Lankhorst — 2012-05-24T15:09:18

Hey,

So today I've been trying to get the lts rename scripts to do something
useful and trying to build the results from it, to see if something sane
comes out.

So far I found out this:

The xorg package (x11-common, xserver-xorg, xserver-xorg-video-all, xorg, xorg-dev, xbase-clients, xutils) should if possible be killed, or be altered to not provide x11-common. Userspace libraries can depend on a specific version. I'm leaning towards killing the entire package, since the less packages altered, the easier we can support it. libxres1 will remove x11-common-renamed because it depends on x11-common (>= ...), and it was required on my way to building xserver-xorg-core, oops.

There were a few other things, mostly related to debian/rules and debian/control. I'm trying to use sed for now to automate changes that need to be done. This might break on package updates, but it's easier since we're limited to a few specific files only, so it can be verified.

libdrm is a pain point, plymouth and weston (a wayland compositor universe, so probably not high priority) depend on it, so renaming is a bit harder.

So far my findings have been positive, I haven't encountered evidence yet that it will be impossible to go the renaming route, but I think it is important to limit ourselves to renaming as few packages with other potential users as possible.

~Maarten

Hybrid graphics target of opportunity during the 3.5merge window

Eric Appleman — 2012-05-24T09:21:38

Regarding the following spec work item:

[albertomilone] contact nvidia to see if they're in sync with airlied's
plans/patches, and revisit the patch to expand the use of dma buffers in
the kernel: TODO

The timeline for this one is coming up. Robert Morell's original
patch[1] for the 3.3 kernel was never resubmitted for the 3.4 cycle. It
might be a good idea to contact him or Pierre-Loup Griffais and ask to
resubmit the patch to the LKML and dma-buf-next[2] for the 3.5 cycle.

If we can get this in 3.5 and Dave Airlie can get the rest of his new X
API into 1.13 and stable DDX, Quantal will have a complete PRIME/DrvScrn
environment.

- Eric Appleman

[1] https://lkml.org/lkml/2012/1/17/479

[2]
http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-dma-buf.git;a=shortlog;h=refs/heads/for-next

Testing enablement mechanics (or are there bettersolutions?)

Maarten Lankhorst — 2012-05-16T12:25:13

Hey,

Doing some more testing I haven't found a good way to do this yet. I tried doing things similar to the way the xorg rename script is going to work, and I just can't get a good way of automatically forcing a upgrade. The official way of upgrading to a renamed package is to provide a 'transitional' package that's empty and just depends on the new name, and it would the only way to make this work without breaking everything. However in this case I don't see an advantage to just using exactly the same names.

For example there are some non-trivial depends on x11proto packages:
$ apt-cache rdepends x11proto.*
The most important one being x11proto-core-dev. However in the generic case it will stay backwards compatible, so they will all have to be reviewed to make sure existing code won't break.

Some more digging even finds a versioned depends on xserver-xorg-core, so renaming won't work. virtualbox-guest-x11 depends on Xorg >= 7.

Similarly, some input and video drivers have dependencies:
gpointing-device-settings depends on input-synaptics, open-vm-toolbox on vmmouse, xserver-xorg-input-wacom has ubuntustudio-graphics and kde-config-tablet, bunch of others too.

More fun is that if you try to install the unrenamed package, your package manager will solve the conflict by removing the enablement package and downgrade to it. This seems like a recipe for disaster and not really suitable as a working solution. Also the enablement package won't automatically upgrade to newer versions, so you will stay on lts-q for the rest of the release unless you manually force an upgrade.

ppa would be fine for testing, but I don't think it's set up to have millions of computers pull updates from it, and companies want to have their own mirroring set up to save unnecessary bandwidth. Would it really be impossible to poke the launchpad devs some more for this, since it seems to be the only clean solution to have either only the stable stack in main and an updated stack in backports (which can be held back on a large scale with pinning as needed) or the use of multiple pockets.

I don't believe we should go with the rename route at this point, until we figure out a way to do it cleanly and automatically.

I created 2 test repos, enable the normal one and the lts-q one for testing, lts-r is unused atm:
https://launchpad.net/~mlankhorst

You can force installing dummy-enablement to the original version, and simulate what would happen if you upgrade to the current version, and see it's going to be held back. Furthermore dummy-dev will fail to install after upgrading and won't suggest dummy-dev-lts-q or anything.

~Maarten

LTS Xorg backports package set

Christopher James Halse Rogers — 2012-05-16T00:41:26

Hi all!

One of the things which still needs to be decided is the full set of
packages that we'll need to backport in order to take the 12.10 X stack
to 12.04.

Bryce has a prototype backport script in xorg-pkg-tools¹ which gets a
list of package mappings from a lookup table². I think this list is
currently a bit pessimistic, and could be trimmed, but I'd like everyone
to have a look at my reasoning.

Things which are unrelated 3rd party dependencies I think could go:

libdbus-1-dev
libgcrypt-dev
libselinux1-dev
        * Stable upstream. I don't think the X stack is likely to start
        depending on new features
libhal-dev
        * Unmaintained upstream, in Universe.  There won't *be* new
        features for the X stack to depend on.
libudev-dev
        * Not as stable upstream, but I don't think the X stack is
        likely to start requiring new features here. It is closely tied
        to the kernel, though, so the kernel backport might require a
        new udev anyway.


Protocol libraries which I don't think the xfree86 server uses, but are
used by the other weird servers - xdmx, xephyr, etc:

libdmx-dev
libxext-dev
libxfixes-dev
libxi-dev
libxinerama-dev
libxmu-dev
libxmuu-dev
libxpm-dev
libxrender-dev
libxres-dev
libxt-dev
libxtst-dev
libxv-dev
        * Some of these may end up being required for xorg-gtest
        integration tests; those tests are likely to be testing new
        protocol, and hence require the new libs.  We can just turn
        those tests off, though.

Libraries used by the main xfree86 DDX build, but without a versioned
dependency.  I think these also do not need to be backported, as long as
we can add extra packages to the backports set if they end up being
required.

libx11-dev
libxau-dev
libxaw7-dev
libxdmcp-dev
libxfont-dev
libxkbfile-dev


¹: https://code.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/
²:
http://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/view/head:/lts-pkg-mapping.txt

System compositor - start X before login

2012-05-13T12:57:38

Thinking about what the boot process would look like with a wayland system
compositor, it occurred to me X could be started, as the last logged in
user, before the user logs in.  As soon as lighDM finishes loading and
fires the signal to fade from boot splash to lightDM.  Once a user logs in,
if it's the same user, just fade to X once it's loaded.  If a different
user logs in, kill off X, start it with the right user, and fade in when
loaded.

A little more involved, you could kill / restart X as soon as the username
is entered.

If you kill X gracefully, and wait for it to shut down before restarting
it, that could lengthen the effective boot process a significant portion of
the time in cases where different users are often logging in.  Although you
could automatically detect that case on that system and store a flag on the
filesystem to skip this.

Alternately, you could spawn the new instance of X with the correct user
before waiting for X to shut down gracefully, but then you get a different
display number, which I'm sure would annoy some percentage of users.  

Or you could just kill -9 everything.  Might not be horrible.

And I'm sure there are cases where people have browsers automatically
launching which, as a result of automatically launching and killing X
periodically, would result in their browser starting up complaining about
having been shutdown uncleanly no matter which above method was used.
Which somebody might care about.  

But I think it could take a nice chunk out of effective boot time, and
generally be fun.

System compositor

2012-05-10T18:30:45

Is this list the place to discuss this subject?


<Darxus> RAOF: I think you were planning to fork weston to create a
         system compositor.  Why not just add the necessary
         modifications to weston to minimize the work to maintain
         protocol compatibility?
<krh> it should be possible to make a system compositor just another
      shell plugin
<krh> and if we need to add something to make that possible we can do that

He's talking about the type of plugin that currently provides the Weston
UI, shell.c.


<Darxus> One of the things that came up in the uds session was the
         expectation of pressure to do rotating cube transitions, and
         where that should be implemented.  Would that make sense within
         a shell plugin?
<krh> rotating_cube.ko
<krh> then everybody can use it
<Darxus> .ko?
<krh> Darxus: the extension of kernel modules


<Darxus> I think this is probably nuts, but, for the problem of
         proprietary drivers not supporting wayland output... would
         it make sense to run a wayland system compositor on top of X,
         then run X (rooted), login, screensaver, etc., as clients of
         that system compositor?
<Darxus> Oh, I guess that would only work with wlshm output, which
         probably isn't worth doing.
<Darxus> Well, maybe something similar to wlshm could be created to use
         hardware acceleration in X... heh.

wlshm is a hardware independent DDX which does output directly via the
wayland protocol.

remove nvidia-{96,173}-updates?

Timo Aaltonen — 2012-04-29T05:26:22

Hi there!

  I'll just echo here what I wrote on irc, that there's really no point
in nvidia-{96,173}-updates packages.. the major version is never going
to change, and if there's an update to support newer xservers, the main
package can be changed since they're broken now. In fact, it's confusing
to even have them on the archive at their current state :/

or am I missing something obvious?

Please test new X server in precise-proposed

Chase Douglas — 2012-04-20T14:08:07

Hi all,

Yesterday I uploaded a new X server to precise-proposed as a 0-day SRU.
It contains fixes for:

https://launchpad.net/bugs/974887: Various touchscreen issues
https://launchpad.net/bugs/930936: Xorg crashes after connect bluetooth
keyboard

The release team has accepted it into precise-proposed, and said it is a
likely respin candidate. They have asked for extra testing. If you are
able, please enable the precise-proposed repository and upgrade to the
xserver 1.11.4-0ubuntu10.1 to test.

Thanks!

latest xinput/multitouch support?

Aljoša Mohorović — 2012-03-14T14:03:17

i've installed 12.04 beta1 (+dist-upgrade) and i'm looking for the
latest xinput2.2 library/api but it looks like 1.x is available.
any way i can get the latest xinput?
various ppa archives are outdated or provide snapshots of current
development sources, i'm just looking for the latest stable stuff.

if it's not possible to get the latest stable stuff, could somebody
point me to the docs/howto for building xorg stuff on ubuntu?
do i need anything else except build-essentials and how do i create
deb packages from source (how do you do it for official releases)?

Aljosa

X transition time!

Christopher James Halse Rogers — 2012-01-23T23:18:18

Hey all!

It's that time of the cycle again - the time to switch to a new X
server, when the Ubuntu-X team conspires to break everyone's system for
a day or so while the archive settles back into consistent state.

But wait!  This time we're trying out a new method for X transitions
that should entirely remove the breakage. The full X stack has been
staged in a PPA, everything is built against it, and we're preparing to
copy that wholesale to the archive.

There should not be any time when the archive is in an inconsistent
state.  In fact, you shouldn't notice anything much, apart from a large
number of upgrades. This includes users of the proprietary nvidia and
fglrx drivers, with the exception of users of nvidia-96 (for extremely
old cards).

While the Ubuntu-X team has tested the packages and upgrades to the
packages, we obviously can't cover everything.  Please be on the lookout
for X problems in the next couple of days.

Thanks!
Chris

Smoke testing of Precise X server bits

Chase Douglas — 2012-01-20T02:01:40

Hi all,

We have everything ready (almost) for the upload of the X server into
Precise. It includes X server 1.11 plus the input stack from 1.12. It
also includes a bunch of interdependent packages that would break if you
were only to update your X server. Here's the known issues with the PPA:

* No utouch-geis support, which means most of your gestures won't work
  - Will be fixed by feature freeze
* Multitouch in Qt from indirect devices (e.g. trackpads) is broken
  - Will be fixed in next Qt upload *after* we push these packages
* Qt is still building for armel, so don't test this on armel yet
* A security hole will kill your screen saver if you type
  Ctrl+Alt+KP_Multiply
  - Will be fixed in xkeyboard-config upload in the next couple hours

Notably, xserver-xorg-input-synaptics has a large patch added in today
for multitouch support. The X synaptics module is used for all
trackpads. Please test that your trackpad is behaving sanely.

We are mostly looking for blocker bugs right now (random X server
crashes, really obnoxious behavior, etc.). Please reply with any such
bugs you find.

Thanks!

Plans for Precise X upload

Chase Douglas — 2012-01-13T16:03:24

Hi all,

We're now all ready to push the new X server to Precise. This will cause
breakages for many items, so we need to plan this carefully. Chris
Halse-Rogers and I have devised the following plan:

* Push all new packages (Xorg and packages that need changes) to
ppa:canonical-x/x-staging, including:
  - utouch-geis 2.2.3 rebuild for XI API changes
  - qt4-x11 either current package with refreshed XI patch for API
    changes, or 4.8 branch if it's ready. I have patches ready for both.
  - utouch-frame 2.1 for XI API changes
  - utouch-grail rebuild for XI API changes

* Use the following Breaks: for xorg-server:
  - unity < 5.0.0 (due to crasher if utouch stack is unavailable)
  - utouch-geis < 2.2.3 (due to infinite loop if utouch XCB backend is
                         unavailable)
  - utouch-frame < 2.1.0 (due to XI API change)
  - qt4-x11 < [qt4-x11 ubuntu version to be uploaded] (due to XI API
                                                       change)

* Pocket copy source and binary packages from the PPA into Precise
  - This PPA has been blessed and builds amd64, i386, armel, and
    powerpc. Due to security issues with armel PPAs, Canonical will only
    allow us to bless a PPA that is restricted to Canonical employees.
    Hopefully, the security issues will be resolved soon, but not in the
    next week :).

How does this sound? If it works for everyone, the only remaining
question is which qt4-x11 version to upload.

Thanks!

Heisenbug in xserver-xorg-input-synaptics

Chase Douglas — 2012-01-07T02:05:06

Hi all,

I tried to track down the bug in the X staging ppa
(ppa:ubuntu-x-swat/x-staging) that causes trackpads to flip to the edge
of the screen. This is what I found:

In the X server when there's a relative motion event it computes an
acceleration for it. You can follow the events from QueuePointerEvents()
to BasicComputeAcceleration(). BasicComputeAcceleration() then calls a
function pointer, which by default for the X synaptics driver calls back
into the driver's SynapticsAccelerationProfile() function.

If you set a breakpoint in BasicComputeAcceleration() with the condition
of "result > 10000", you'll get a hit. When you continue, your pointer
will flip to an edge of the screen. Generally, the value of the result
variable is on the order of +<some value>e+304 or inf when this occurs.
The next step is to try setting a breakpoint in
SynapticsAccelerationProfile() with the condition "accelfct > 10000" on
the return statement.

I compiled xserver-xorg-input-synaptics with noopt, but I wasn't able to
trigger the bug. Then, I compiled with the default optimizations, and
the bug reappeared, but the breakpoint with the condition was never hit.
I tried removing the condition, and the breakpoint worked as expected.

I've sent this to both ubuntu-x and ubuntu-devel to ask if anyone has
any ideas on how to debug this without getting to the level of
compiler/assembly/linker debugging :).

Thanks!

Heisenbug in xserver-xorg-input-synaptics

Chase Douglas — 2012-01-07T02:05:06

Hi all,

I tried to track down the bug in the X staging ppa
(ppa:ubuntu-x-swat/x-staging) that causes trackpads to flip to the edge
of the screen. This is what I found:

In the X server when there's a relative motion event it computes an
acceleration for it. You can follow the events from QueuePointerEvents()
to BasicComputeAcceleration(). BasicComputeAcceleration() then calls a
function pointer, which by default for the X synaptics driver calls back
into the driver's SynapticsAccelerationProfile() function.

If you set a breakpoint in BasicComputeAcceleration() with the condition
of "result > 10000", you'll get a hit. When you continue, your pointer
will flip to an edge of the screen. Generally, the value of the result
variable is on the order of +<some value>e+304 or inf when this occurs.
The next step is to try setting a breakpoint in
SynapticsAccelerationProfile() with the condition "accelfct > 10000" on
the return statement.

I compiled xserver-xorg-input-synaptics with noopt, but I wasn't able to
trigger the bug. Then, I compiled with the default optimizations, and
the bug reappeared, but the breakpoint with the condition was never hit.
I tried removing the condition, and the breakpoint worked as expected.

I've sent this to both ubuntu-x and ubuntu-devel to ask if anyone has
any ideas on how to debug this without getting to the level of
compiler/assembly/linker debugging :).

Thanks!

Heisenbug in xserver-xorg-input-synaptics

Chase Douglas — 2012-01-07T02:05:06

Hi all,

I tried to track down the bug in the X staging ppa
(ppa:ubuntu-x-swat/x-staging) that causes trackpads to flip to the edge
of the screen. This is what I found:

In the X server when there's a relative motion event it computes an
acceleration for it. You can follow the events from QueuePointerEvents()
to BasicComputeAcceleration(). BasicComputeAcceleration() then calls a
function pointer, which by default for the X synaptics driver calls back
into the driver's SynapticsAccelerationProfile() function.

If you set a breakpoint in BasicComputeAcceleration() with the condition
of "result > 10000", you'll get a hit. When you continue, your pointer
will flip to an edge of the screen. Generally, the value of the result
variable is on the order of +<some value>e+304 or inf when this occurs.
The next step is to try setting a breakpoint in
SynapticsAccelerationProfile() with the condition "accelfct > 10000" on
the return statement.

I compiled xserver-xorg-input-synaptics with noopt, but I wasn't able to
trigger the bug. Then, I compiled with the default optimizations, and
the bug reappeared, but the breakpoint with the condition was never hit.
I tried removing the condition, and the breakpoint worked as expected.

I've sent this to both ubuntu-x and ubuntu-devel to ask if anyone has
any ideas on how to debug this without getting to the level of
compiler/assembly/linker debugging :).

Thanks!

Precise X staging

Chase Douglas — 2011-12-24T22:26:08

Hi all,

At UDS we decided to use the X.org 1.11 server with the input subsystem
backported from 1.12 for multitouch. The upstream 1.12 server
development branch just landed the multitouch support, so I packaged it
up for Precise.

Ubuntu has had multitouch support in our X server since 11.04, but it
was a prototype implementation. The protocol specification and
implementation merged upstream is very similar, but includes a few key
modifications.

Over the past week, Chris Halse-Rogers and I have created a staging PPA
(ppa:ubuntu-x-swat/x-testing) for all the X packages and any packages
that need fixes due to the input protocol changes. This PPA is as much
for our own development benefit as it as a chance for others to test it
out. We would gladly appreciate feedback on ubuntu-x-nLRlyDuq1AZFpShjVBNYruG/Ez6ZCGd0< at >public.gmane.org
However, note that the code is still rather unstable.

We need to determine what to do about the qt4-x11 package in particular.
The Ubuntu package includes a patch that enables multitouch using the
prototype implementation. I have reworked the patch for the upstream
implementation (it was far easier than I thought it would be :), and it
is available in the ppa as well. For the transition, we could do one of
the following:

1. Drop the patch from qt4-x11 now, and add it back in after the X
packages land in precise.

2. Synchronize the X package and Qt package uploads and use "Breaks"
debian control clauses to hold back packages during the transition period.

I proposed option #1 to Scott on irc this past week. I think it's the
least hassle because it does not require significant synchronization
between the kubuntu packagers and the ubuntu-x teams. There are no
API/ABI changes from the patch, it merely hooks up the plumbing in the
qt x11 implementation. I am also unaware of any applications in the
archive using the qt multitouch capability yet. However, I have no
issues with either approach. Any thoughts?

Thanks!

Bug #806546 in xserver-xorg-input-evdev (Ubuntu): “Modifier keys (Shift, Alt, Super) stick_cling at the mere_simple push of a button.”

Dmitriy Perlow — 2011-12-20T19:12:45

Hello, all. I made a bug-report about a half of an year ago, but it hasn't
got any answer from maintainers yet. Could anybody help me please?
Link:  
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/806546

Intel driver SNA PPA

Peter Clifton — 2011-11-12T17:15:46

Hi guys,

I'm aware of (and using) the PPA with the SNA enabled version of the
Intel 2D driver, in conjunction with Xorg Edgers.

When I last checked, SNA also requires a series of patches to the xorg
server which are in Chris Wilson's xorg-server repository. I checked
today, and found that these weren't applied to the xorg-edgers version
of the xorg server, so it would not be likley that the SNA enabled
driver will work properly.

Since I'm a little out of touch on the graphics drivers stuff nowadays,
I might be wrong about what patches are required, and I'd be interested
to hear if anyone has more up to date information.

Best regards,

Peter Clifton

evdev and absolute axes help

Jean-François Dagenais — 2011-11-09T22:49:46

Hi,

I am using maverick,
I have tried for the last two days to do something which some X developers would find quite trivial I imagine. We have a capacitive wheel using the ad714x.c driver in the kernel. In my latest desperations, I have changed the events sent by ad714x.c so they are BTN_LEFT and ABS_Y so that it better matches what a mouse does. I am trying to make this wheel do what a regular mouse wheel does. OR even better, send a keyboard keycode (one for up, one for down), which I may do later by hacking the evdev code. But first things first, why I am not able to get this to work...

The resulting input device looks like this (including a sweep of the finger on it):
jfdagenais< at >jfdg3:~$ sudo evtest /dev/input/event7
Input driver version is 1.0.1
Input device ID: bus 0x18 vendor 0x0 product 0x7147 version 0x1
Input device name: "ad714x_captouch_wheel"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 272 (LeftBtn)
  Event type 3 (Absolute)
    Event code 1 (Y)
      Value    244
      Min        0
      Max     1024
Testing ... (interrupt to exit)
Event: time 1320870200.685118, type 1 (Key), code 272 (LeftBtn), value 1
Event: time 1320870200.685122, type 3 (Absolute), code 1 (Y), value 294
Event: time 1320870200.685124, -------------- Report Sync ------------
Event: time 1320870200.720007, type 3 (Absolute), code 1 (Y), value 295
Event: time 1320870200.720009, -------------- Report Sync ------------
Event: time 1320870200.820458, type 3 (Absolute), code 1 (Y), value 296
Event: time 1320870200.820460, -------------- Report Sync ------------
Event: time 1320870200.853917, type 3 (Absolute), code 1 (Y), value 299
Event: time 1320870200.853919, -------------- Report Sync ------------
Event: time 1320870200.887364, type 3 (Absolute), code 1 (Y), value 300
Event: time 1320870200.887366, -------------- Report Sync ------------
Event: time 1320870200.920873, type 3 (Absolute), code 1 (Y), value 303
Event: time 1320870200.920875, -------------- Report Sync ------------
Event: time 1320870200.954413, type 3 (Absolute), code 1 (Y), value 298
Event: time 1320870200.954415, -------------- Report Sync ------------
Event: time 1320870200.968208, type 1 (Key), code 272 (LeftBtn), value 0
Event: time 1320870200.968210, -------------- Report Sync ------------

I have added this to my xorg configs (in /usr/share/X11/xorg.conf.d) so that it can attach evdev to my device
Section "InputClass"
Identifier "AD7147 Wheel"
MatchProduct "ad714x_captouch_wheel"
Driver "evdev"
Option "Mode" "Relative" #this seems to have no effect
Option "Emulate3Button" "false"
Option "XAxisMapping" "4 5"
Option "EmulateWheel" "true"
Option "EmulateWheelTimeout" "0"
Option "EmulateWheelButton" "1"
EndSection

my efforts to do this through udev were less successful because I had trouble matching the correct attribute, any hints what udev rule I should use to do what "MatchProduct "ad714x_captouch_wheel"" does? Will using udev make any difference?

this out of my Xorg.0.log
[  1559.326] 
X.Org X Server 1.9.0
Release Date: 2010-08-20
[  1559.327] X Protocol Version 11, Revision 0
[  1559.327] Build Operating System: Linux 2.6.24-28-server x86_64 Ubuntu
[  1559.327] Current Operating System: Linux jfdg3 3.1.0-jfdebug-dbg+ #24 SMP Tue Nov 8 10:53:32 EST 2011 x86_64
[  1559.327] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.1.0-jfdebug-dbg+ root=UUID=d599661e-3435-408f-a5fb-61112f92a97a ro intel_iommu=igfx_off
[  1559.327] Build Date: 09 January 2011  12:14:27PM
[  1559.327] xorg-server 2:1.9.0-0ubuntu7.3 (For technical support please see http://www.ubuntu.com/support) 
[  1559.327] Current version of pixman: 0.18.4
...
[  5540.100] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Nov  9 17:16:17 2011
[  5540.100] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  5540.101] (==) No Layout section.  Using the first Screen section.
...
[  4603.813] (II) config/udev: Adding input device ad714x_captouch_wheel (/dev/input/event7)
[  4603.813] (**) ad714x_captouch_wheel: Applying InputClass "AD7147 Wheel"
[  4603.813] (**) ad714x_captouch_wheel: always reports core events
[  4603.813] (**) ad714x_captouch_wheel: Device: "/dev/input/event7"
[  4603.813] (II) ad714x_captouch_wheel: Found 1 mouse buttons
[  4603.813] (II) ad714x_captouch_wheel: Found absolute axes
[  4603.813] (II) evdev-grail: failed to open grail, no gesture support
[  4603.813] (II) ad714x_captouch_wheel: Configuring as mouse
[  4603.813] (**) Option "EmulateWheel" "true"
[  4603.813] (**) Option "EmulateWheelButton" "1"
[  4603.813] (**) Option "EmulateWheelTimeout" "0"
[  4603.813] (**) ad714x_captouch_wheel: YAxisMapping: buttons 4 and 5
[  4603.813] (**) Option "XAxisMapping" "4 5"
[  4603.813] (**) ad714x_captouch_wheel: XAxisMapping: buttons 4 and 5
[  4603.813] (**) ad714x_captouch_wheel: EmulateWheelButton: 1, EmulateWheelInertia: 10, EmulateWheelTimeout: 0
[  4603.813] (II) XINPUT: Adding extended input device "ad714x_captouch_wheel" (type: MOUSE)
[  4603.813] (II) ad714x_captouch_wheel: initialized for absolute axes.


here's what I get from xinput list-props:
jfdagenais< at >jfdg3:~$ xinput list-props ad714x_captouch_wheel
Device 'ad714x_captouch_wheel':
Device Enabled (129):1
Coordinate Transformation Matrix (131):1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Device Accel Profile (252):0
Device Accel Constant Deceleration (253):1.000000
Device Accel Adaptive Deceleration (254):1.000000
Device Accel Velocity Scaling (255):10.000000
Evdev Reopen Attempts (249):10
Evdev Axis Inversion (256):0, 0
Evdev Axis Calibration (257):<no items>
Evdev Axes Swap (258):0
Axis Labels (259):"Abs Y" (251)
Button Labels (260):"Button Left" (132), "Button Unknown" (250), "Button Unknown" (250), "Button Wheel Up" (135), "Button Wheel Down" (136)
Evdev Middle Button Emulation (261):2
Evdev Middle Button Timeout (262):50
Evdev Wheel Emulation (263):1
Evdev Wheel Emulation Axes (264):4, 5, 4, 5
Evdev Wheel Emulation Inertia (265):10
Evdev Wheel Emulation Timeout (266):0
Evdev Wheel Emulation Button (267):0
Evdev Drag Lock Buttons (268):0

Even if I have set ABS_Y (labeled Abs Y), when I sweep my finger on the wheel, the mouse cursor moves left and right, in absolute position. With the "Emulation Button" set to "0", it is as if I click down, drag left/right, then release the button. (xev confirms this). When I then set the Emulation button to "1" (using xinput), then I no longer get clicks while the cursor moves right or left, nor do I get buttons 4 and 5 for wheel up/down. If I manage to tap the wheel without moving, I get button down/up events.

So it's kinda like the emulation algo is doing something, but fails to report the button (4, 5). I have successfully configured the emulation on a real mouse.

Any help or pointers are welcome!

/jfd

Jean-Francois Dagenais 
Software Architect - B.Sc.A


Experience the new veo phased array flaw detector at www.sonatestveo.com.


Sonatest AP
2900 chemin des Quatre-Bourgeois
Bureau 305
Quebec City Quebec G1V 1Y4

T| +1 (418) 683 6222 x106   F| +1 (418) 683 7032   M|    W| www.sonatest.com



This message (and any associated files) is intended only for the use of Ubuntu-x-nLRlyDuq1AZFpShjVBNYrg< at >public.gmane.org, xorg-devel-go0+a7rfsptAfugRpC6u6w< at >public.gmane.org and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the above recipient(s) you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.

Think green - help the environment by not printing this email.

[Fwd: Re: Hybrid graphics detection]

Christopher James Halse Rogers — 2011-11-03T13:12:03

Hybrid graphics detection

Evan Broder — 2011-10-31T18:36:39

At the hybrid graphics session today, we discussed how we could detect
which GPU was actively being used in a hybrid graphics configuration.
I have some code that I've been using to do this, using libpciaccess.

It's based on the code that X itself uses to pick which drivers to
load at startup, so it likely suffers from some of the issues we
discussed in the session. But it does seem to work for nVidia Optimus,
which is the only hybrid graphics system I have access to.

I'm currently using the following Upstart job when either
nvidia-current or fglrx are installed:

 start on starting gdm

 task
 script
     if [ "$(hybrid-detect)" = "integrated" ]; then
         update-alternatives --set gl_conf /usr/lib/mesa/ld.so.conf
         ldconfig
     fi
 end script

Both of these are a bit rough around the edges, and would definitely
need some tuning before being adapted by Ubuntu in general.

- Evan