headers
Maarten Lankhorst | 24 May 17:09
Favicon

Fighting renames, day 1

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
Permalink | Reply | 2 comments |
headers
Eric Appleman | 24 May 11:21
Picon
Gravatar

Hybrid graphics target of opportunity during the 3.5 merge window

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
Permalink | Reply | 3 comments |
headers
Maarten Lankhorst | 16 May 14:25
Favicon

Testing enablement mechanics (or are there better solutions?)

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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christopher James Halse Rogers | 16 May 02:41
Favicon
Gravatar

LTS Xorg backports package set

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:
(Continue reading)

Permalink | Reply | 2 comments |
headers
darxus | 13 May 14:57
Favicon

System compositor - start X before login

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
darxus | 10 May 20:30
Favicon

System compositor

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Timo Aaltonen | 9 May 21:35
Favicon

Re: xorg-server 1.12 on X Updates PPA

08.05.2012 15:48, Pedro Pedruzzi kirjoitti:
> Hello!
> 
> xorg-server versions 1.12.0 and 1.12.1 have been released upstream [1]
> [2].
> 
> The current Ubuntu release (12.04) is still using 1.11 (package xserver-
> xorg-core).
> 
> Do you plan to publish any of those in the X Updates PPA [3]?
> 
> I could get it from gir or from xorg-edgers but I would prefer the
> upstream stable, if available.
>
> Thank you.
>
> Regards,
> --
> Pedro Pedruzzi
>
> [1] http://lists.x.org/archives/xorg-announce/2012-March/001846.html
> [2] http://lists.x.org/archives/xorg-announce/2012-April/001930.html
> [3] https://launchpad.net/~ubuntu-x-swat/+archive/x-updates

Any particular reason for the update? There has been no discussions
about providing it..

ps. please use the ubuntu-x mailinglist for such questions in the future :)

t
(Continue reading)

Permalink | Reply | 5 comments |
headers
Timo Aaltonen | 29 Apr 07:26
Favicon

remove nvidia-{96,173}-updates?


	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?

--

-- 
t
Permalink | Reply | 1 comment |
headers
Chase Douglas | 20 Apr 16:08
Favicon

Please test new X server in precise-proposed

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!

-- Chase
Permalink | Reply | 3 comments |
headers
Aljoša Mohorović | 14 Mar 15:03
Picon
Gravatar

latest xinput/multitouch support?

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
Permalink | Reply | 4 comments |
headers
Timo Aaltonen | 10 Feb 15:31
Favicon

Re: gallium version of i915_dri.so


(please use the mailing list mentioned on the maintainer field of the
package)

On 10.02.2012 15:51, erwin wrote:
> 
> Hi Timo,
> 
> I noticed the following line in the changelog for
> libgl1-mesa-dri-experimental in the xorg edgers ppa:
> 
> Drop the dri-alternates driver search path, and don't ship
>     gallium version of i915_dri.so for now
> 
> Could you tell me why you stopped shipping the gallium version of
> i915_dri.so? I used this to get OpenGL2 support on my netbook (some games
> require it). Is there anything I can do to get it back in?

Nope, don't remember why I dropped it. Maybe just that the package had
enough issues to get it built, and it was getting on the way.

--

-- 
t
Permalink | Reply | 6 comments |

Gmane