<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.ubuntu.devel.x">
    <title>gmane.linux.ubuntu.devel.x</title>
    <link>http://blog.gmane.org/gmane.linux.ubuntu.devel.x</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/791"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/789"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/787"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/784"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/783"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/778"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/774"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/770"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/764"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/751"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/746"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/742"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/738"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/738"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/738"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/737"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/736"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/732"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/727"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/719"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/791">
    <title>Fighting renames, day 1</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/791</link>
    <description>&lt;pre&gt;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 (&amp;gt;= ...), 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 comp&lt;/pre&gt;</description>
    <dc:creator>Maarten Lankhorst</dc:creator>
    <dc:date>2012-05-24T15:09:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/789">
    <title>Hybrid graphics target of opportunity during the 3.5merge window</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/789</link>
    <description>&lt;pre&gt;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

&lt;/pre&gt;</description>
    <dc:creator>Eric Appleman</dc:creator>
    <dc:date>2012-05-24T09:21:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/787">
    <title>Testing enablement mechanics (or are there bettersolutions?)</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/787</link>
    <description>&lt;pre&gt;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 &amp;gt;= 7.

Similarly, some input and video drivers have dependencies:
gpointing-device-s&lt;/pre&gt;</description>
    <dc:creator>Maarten Lankhorst</dc:creator>
    <dc:date>2012-05-16T12:25:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/784">
    <title>LTS Xorg backports package set</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/784</link>
    <description>&lt;pre&gt;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 whic&lt;/pre&gt;</description>
    <dc:creator>Christopher James Halse Rogers</dc:creator>
    <dc:date>2012-05-16T00:41:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/783">
    <title>System compositor - start X before login</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/783</link>
    <description>&lt;pre&gt;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 numb&lt;/pre&gt;</description>
    <dc:creator>darxus-gf8W+JFHfRr/2OF+hy8yCA&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-05-13T12:57:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/778">
    <title>System compositor</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/778</link>
    <description>&lt;pre&gt;Is this list the place to discuss this subject?


&amp;lt;Darxus&amp;gt; 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?
&amp;lt;krh&amp;gt; it should be possible to make a system compositor just another
      shell plugin
&amp;lt;krh&amp;gt; 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.


&amp;lt;Darxus&amp;gt; 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?
&amp;lt;krh&amp;gt; rotating_cube.ko
&amp;lt;krh&amp;gt; then everybody can use it
&amp;lt;Darxus&amp;gt; .ko?
&amp;lt;krh&amp;gt; Darxus: the extension of kernel modules


&amp;lt;Darxus&amp;gt; I think this is probably nuts, but, for the problem of
         proprietary drivers not supporting wayland output... would
         i&lt;/pre&gt;</description>
    <dc:creator>darxus-gf8W+JFHfRr/2OF+hy8yCA&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-05-10T18:30:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/774">
    <title>remove nvidia-{96,173}-updates?</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/774</link>
    <description>&lt;pre&gt;
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?

&lt;/pre&gt;</description>
    <dc:creator>Timo Aaltonen</dc:creator>
    <dc:date>2012-04-29T05:26:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/770">
    <title>Please test new X server in precise-proposed</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/770</link>
    <description>&lt;pre&gt;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!

&lt;/pre&gt;</description>
    <dc:creator>Chase Douglas</dc:creator>
    <dc:date>2012-04-20T14:08:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/764">
    <title>latest xinput/multitouch support?</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/764</link>
    <description>&lt;pre&gt;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

&lt;/pre&gt;</description>
    <dc:creator>Aljoša Mohorović</dc:creator>
    <dc:date>2012-03-14T14:03:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/751">
    <title>X transition time!</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/751</link>
    <description>&lt;pre&gt;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
&lt;/pre&gt;</description>
    <dc:creator>Christopher James Halse Rogers</dc:creator>
    <dc:date>2012-01-23T23:18:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/746">
    <title>Smoke testing of Precise X server bits</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/746</link>
    <description>&lt;pre&gt;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
cras&lt;/pre&gt;</description>
    <dc:creator>Chase Douglas</dc:creator>
    <dc:date>2012-01-20T02:01:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/742">
    <title>Plans for Precise X upload</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/742</link>
    <description>&lt;pre&gt;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 &amp;lt; 5.0.0 (due to crasher if utouch stack is unavailable)
  - utouch-geis &amp;lt; 2.2.3 (due to infinite loop if utouch XCB backend is
                         unavailable)
  - utouch-frame &amp;lt; 2.1.0 (due to XI API change)
  - qt4-x11 &amp;lt; [qt4-x11 ubuntu version to be uploaded] (due to XI API
                                                       change)

* Pocket copy source and binary packages fr&lt;/pre&gt;</description>
    <dc:creator>Chase Douglas</dc:creator>
    <dc:date>2012-01-13T16:03:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/738">
    <title>Heisenbug in xserver-xorg-input-synaptics</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/738</link>
    <description>&lt;pre&gt;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 &amp;gt; 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 +&amp;lt;some value&amp;gt;e+304 or inf when this occurs.
The next step is to try setting a breakpoint in
SynapticsAccelerationProfile() with the condition "accelfct &amp;gt; 10000" on
the return statement.

I compiled xserver-xorg-input-synaptics with noopt, but I wasn't able to
trigg&lt;/pre&gt;</description>
    <dc:creator>Chase Douglas</dc:creator>
    <dc:date>2012-01-07T02:05:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/738">
    <title>Heisenbug in xserver-xorg-input-synaptics</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/738</link>
    <description>&lt;pre&gt;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 &amp;gt; 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 +&amp;lt;some value&amp;gt;e+304 or inf when this occurs.
The next step is to try setting a breakpoint in
SynapticsAccelerationProfile() with the condition "accelfct &amp;gt; 10000" on
the return statement.

I compiled xserver-xorg-input-synaptics with noopt, but I wasn't able to
trigg&lt;/pre&gt;</description>
    <dc:creator>Chase Douglas</dc:creator>
    <dc:date>2012-01-07T02:05:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/738">
    <title>Heisenbug in xserver-xorg-input-synaptics</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/738</link>
    <description>&lt;pre&gt;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 &amp;gt; 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 +&amp;lt;some value&amp;gt;e+304 or inf when this occurs.
The next step is to try setting a breakpoint in
SynapticsAccelerationProfile() with the condition "accelfct &amp;gt; 10000" on
the return statement.

I compiled xserver-xorg-input-synaptics with noopt, but I wasn't able to
trigg&lt;/pre&gt;</description>
    <dc:creator>Chase Douglas</dc:creator>
    <dc:date>2012-01-07T02:05:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/737">
    <title>Precise X staging</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/737</link>
    <description>&lt;pre&gt;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&amp;lt; at &amp;gt;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 multit&lt;/pre&gt;</description>
    <dc:creator>Chase Douglas</dc:creator>
    <dc:date>2011-12-24T22:26:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/736">
    <title>Bug #806546 in xserver-xorg-input-evdev (Ubuntu): “Modifier keys (Shift, Alt, Super) stick_cling at the mere_simple push of a button.”</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/736</link>
    <description>&lt;pre&gt;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

&lt;/pre&gt;</description>
    <dc:creator>Dmitriy Perlow</dc:creator>
    <dc:date>2011-12-20T19:12:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/732">
    <title>Intel driver SNA PPA</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/732</link>
    <description>&lt;pre&gt;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

&lt;/pre&gt;</description>
    <dc:creator>Peter Clifton</dc:creator>
    <dc:date>2011-11-12T17:15:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/727">
    <title>evdev and absolute axes help</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/727</link>
    <description>&lt;pre&gt;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&amp;lt; at &amp;gt;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    &lt;/pre&gt;</description>
    <dc:creator>Jean-François Dagenais</dc:creator>
    <dc:date>2011-11-09T22:49:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/719">
    <title>[Fwd: Re:  Hybrid graphics detection]</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/719</link>
    <description>&lt;pre&gt;
&lt;/pre&gt;</description>
    <dc:creator>Christopher James Halse Rogers</dc:creator>
    <dc:date>2011-11-03T13:12:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.x/712">
    <title>Hybrid graphics detection</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.x/712</link>
    <description>&lt;pre&gt;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
&lt;/pre&gt;</description>
    <dc:creator>Evan Broder</dc:creator>
    <dc:date>2011-10-31T18:36:39</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.ubuntu.devel.x">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.ubuntu.devel.x</link>
  </textinput>
</rdf:RDF>

