Re: [ubuntu-x] xorg package set update for lts
On Mon, 2012-11-12 at 11:50 +0100, Maarten Lankhorst wrote: Hey, Could the xorg package set be updated to include the following packages, for the lts point release? libdrm-lts-quantal mesa-lts-quantal xorg-server-lts-quantal xorg-lts-quantal and a wildcard xf86-*-lts-quantal xserver-xorg-*-lts-quantal same with s/quantal/raring/ would be nice too, but probably overboard at this point. :-) Lets get more into details now, since I think most technical issues have been worked out now, so I think this can be uploaded soon after verifying it works locally. Needs to be updated in precise, for building: apt, for switching stacks https://launchpad.net/bugs/1062503 x11proto-gl, from quantal for xserver x11proto-dri2, from quantal for xserver x11proto-randr, from quantal for xserver wayland, from quantal for mesa 9. New unrenamed packages for precise: llvm-3.1, from version from quantal, used by mesa 9. - All the -lts-quantal packages are autogenerated, by running the lts-stack script from: https://code.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools Currently I use 'lts-stack' on quantal to download all packages, and rerun it again on precise from same directory to generate the binaries. Special cases: libdrm - weird case to rename, really special case, see lts-libdrm-rename all sonames have been renamed to start with libkms_ltsq or libdrm_ltsq, for example libdrm_ltsq_radeon.so.1 and libdrm_ltsq.so.2. libdrm_nouveau1a has been killed by the rename script. Hm. I obviously wasn't clear about what I was thinking here. I was expecting libdrm.so.2 → libdrm.so.2ltsq. That (should be) just a matter of changing the version passed through to libtool, and shouldn't require futzing with anything else - things linking with -ldrm will pick up the right library. mesa - slightly easier, can no longer directly link with -ldrm* so scripts are used to fix those makefiles up. libosmesa6 and libgl1-mesa-dri-experimental are not rebuilt by the rename script. ...which might make this easier. Since it seems you've already sorted out the libdrm_lts* problems its probably not worth the effort to re-do this. Sorry about that! -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
[ubuntu-x] 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: 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 signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
Re: [ubuntu-x] latest xinput/multitouch support?
On Wed, 2012-03-14 at 15:03 +0100, Aljoša Mohorović wrote: 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? libxi is what you're after. It's (roughly) the latest version; it supports Xi 2.2. That is the latest API. signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
Re: [ubuntu-x] gallium version of i915_dri.so
On Fri, 2012-02-10 at 09:11 -0800, Bryce Harrington wrote: On Fri, Feb 10, 2012 at 04:13:50PM +0100, erwin wrote: On Fri, 10 Feb 2012 16:31:57 +0200, Timo Aaltonen tjaal...@ubuntu.com wrote: (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. Any chance of getting it back in? I'd be happy to help with any issues, could you point me in the right direction? I understood that this was no longer being maintained upstream, thus the frequent build issues. I'm pretty sure i915g is being actively maintained and developed; IIRC the ChromeBooks use i915g. It is, as Erwin says, more featureful than i915. i965g is indeed unmaintained and (as far as I'm aware) never did anything much more than lock up the GPU. Chris signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
Re: [ubuntu-x] Smoke testing of Precise X server bits
On Fri, 2012-01-20 at 03:01 +0100, Chase Douglas wrote: 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 This is now fixed. signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
[ubuntu-x] [Fwd: Handling server / drivers dependencies]
Hey, all! For those of you not subscribed to the Debian X list, Cyril Brulebois has just written a little documentation about where the Debian dependency information between the Xserver and driver packages is going. Forwarding the initial mail, containing a link to the alioth documentation. ---BeginMessage--- Cyril Brulebois k...@alioth.debian.org (01/02/2011): index.mdwn |4 + reference/dependencies.mdwn | 131 xsf.css |5 + 3 files changed, 140 insertions(+) New commits: commit dfb93d750512f99ecbbe8e7d97db97acb6641505 Author: Cyril Brulebois k...@debian.org Date: Tue Feb 1 13:34:52 2011 +0100 dependencies: New reference document. I tried to summarize both upstream and debian aspects of server / drivers dependencies. It's currently just a draft which aims at summarizing where we want to go (rather than where we came from) and how to do so; also the current state should be pretty obvious to anyone having an apt cache handy, so I skipped talking about that. :) Tweaks to xorg-server + sample driver updates will be pushed to repositories under users/kibi/pkg-xorg probably, for discussion / review before pushing to the main repositories. The draft document is available online: http://pkg-xorg.alioth.debian.org/reference/dependencies.html KiBi. signature.asc Description: Digital signature ---End Message--- signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
Re: [ubuntu-x] [Retitled] i830 support
On Sat, 2010-10-02 at 08:29 -0600, Gordon Schumacher wrote: On 09/22/2010 06:55 PM, Christopher James Halse Rogers wrote: On Wed, 2010-09-22 at 10:27 -0600, Gordon Schumacher wrote: On 09/20/2010 05:07 PM, Bryce Harrington wrote: Aha, gotcha. I *suspect* the calls are already coded up in the 8xx driver code. If there's anything missing, then it should be possible to cargo-cult from the 9xx code. On the plus side, if you get stuck with any API stuff, the Intel developers are friendly and can be reached on irc or mail pretty readily. I also have some contacts at Intel now, albeit in entirely the wrong group; they might be able to pass me along to someone though. Also, I think I know in broad strokes what it is that broke video for me. I seem to remember that once upon a time, there were two drivers one could load for the i830 - the current driver, or the old i810 driver (which is still there). The current driver never worked for me, but the i810 driver did. That doesn't work anymore, but I might be able to cargo-cult the older i810 driver code that supported the i830 into the new driver. Hm. That reminds me of bug a freedesktop.org bug¹ that I thought applied to i810, but seems to actually apply to (some) i830s. If that turns out to be your bug then there's a lot of information on that bug, including prospective patches. Um. So... the release candidate works *perfectly* for me, with respect to video: no freaky text mode flicker, no X-shift in the installer... it all just works. That will make it a little hard to debug :) What changed from Lucid? We stopped trying to load the Intel X driver and just use fbdev instead on your hardware. :) You should be able to degrade your experience (in some ways, gaining features in others) back to Lucid by manually selecting the Intel driver in xorg.conf (see https://wiki.ubuntu.com/X/Bugs/Mavericki8xxStatus for instructions). If that still doesn't get you back to Lucid's behaviour, yay! Magical kernel fairies have come in and fixed everything! signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
Re: [ubuntu-x] gnome-settings-daemon: the new Xserver?
On Thu, 2010-09-30 at 23:41 +0200, Tormod Volden wrote: Hi, Over the last years the autodetection abilities of the Xserver has been improved to the point that in most cases X detects all screen connected and chooses the best resolution available, with no configuration needed. However, on the Ubuntu desktop another friend increasingly wants to have a say: The gnome-settings-daemon and its magic use of xrandr. g-s-d has been useful to let the user choose his own screen settings and let them be remembered over sessions. But now it wants to overrule the Xserver even in the default configuration, before the user even gets a chance to configure anything. One of the latest changes (gnome_settings_daemon 2.31.91-0ubuntu3) introduced more xrandr manipulation (turn on external screens by default) and caused a family of regressions like 643118 and 640807. I have a couple of issues with this change: 1) It was pushed into Maverick just before Final Freeze, without explanation, without reference to any bug it may fix. I know that gnome packages are exempted from upload freeze rules, but I think that is to allow upstream bug fixes to flow in, and not to lightly add Ubuntu changes. 2) If external screens need to be enabled for some reason, why shouldn't the Xserver do it instead? This smells of plastering and workarounds to me. And do for example Xubuntu and Kubuntu users not want the same display modes by default? I was under the impression that this is actually the logical conclusion of the drive to strip required configuration from X, and the “mechanism, not policy” philosophy. Determining what to do on monitor hotplug, now that clients actually *get* hotplug events, seems like it should be done in the desktop environment. It's a policy decision that's probably user-specific. Note that although (2) reveals my personal opinion, it is not meant rhetorically, I have not been following closely lately and have missed out on much information. A changelog bug reference would probably have helped :) What is exactly the way we want this to work, both as in user experience and in the strategics of distributing logic between Xserver and g-s-d? Also, is this well coordinated and communicated between X team and gnome/desktop team? g-s-d should probably be smarter about not needlessly changing settings, but I think that g-s-d *should* be in charge of resolution policy. I think we might want to have a multi-head discussion at UDS with the design team and the various desktop teams to work out the user experience we want. I am sure some of the reported bugs boil down to bugs in the graphic drivers and that the above g-s-d changes would otherwise have been fine, but this is a minefield to be treaded carefully, especially in these days of KMS migration. Tormod signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
Re: [ubuntu-x] i8xx, again!
On Wed, 2010-09-08 at 09:42 -0400, Eric Appleman wrote: On 09/06/2010 05:34 AM, Christopher James Halse Rogers wrote: On Mon, 2010-09-06 at 04:52 -0400, Eric Appleman wrote: Is Option 2 the shadow framebuffer approach that Chris suggested? - Eric No. As I mentioned in the preamble, that branch still has some problems. We also can't reasonably ship a branch of the intel X driver. Option 2 is basically “let KMS bring up a bare framebuffer, and use the dumb X framebuffer driver to draw to it”. fbdev has even fewer features than vesa - it doesn't do modesetting *at all*. It'll just use the resolution that the kernel picked on boot. Oh wow. This is going to be more troublesome than I thought. Is there really no courage in the ubuntu-x team to harass the Release Drivers for special freeze exemptions to get the proper fixes in? We have a month and yet we're already admitting defeat. This would be easier if there *were* proper fixes. There's a very large kernel patch that touches infrastructure shared by all Intel drivers that (mostly) fixes one of the big problems on the i855 chipset, and does nothing for i845 users or i830 users. There are a couple of -intel X driver branches seeking to address this, the most recent of which (Chris Wilson's shadow branch) is not a lot more than fbdev + modesetting support. There's no 3D, and no 2D acceleration there as far as I understand it. For the past few years, most notably with the KMS/GEM/UXA/DRI2 transition and the move from -i810 to -intel, whenever a serious regression is discovered you guys have a tendency to throw up your arms and say it, we'll handle it in the next dev cycle and bodge together a rather unsavory workaround. Yeah. It's a balancing act. We want to provide the best experience for the most users, which means we want the new shiny, but without regressing support for older hardware. It's been hard. User experience is everything. I have a fond memory of how miserably Hardy and Jaunty ran on my Intel graphics. My $0.02. - Eric signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
Re: [ubuntu-x] i8xx, again!
On Mon, 2010-09-06 at 04:52 -0400, Eric Appleman wrote: Is Option 2 the shadow framebuffer approach that Chris suggested? - Eric No. As I mentioned in the preamble, that branch still has some problems. We also can't reasonably ship a branch of the intel X driver. Option 2 is basically “let KMS bring up a bare framebuffer, and use the dumb X framebuffer driver to draw to it”. fbdev has even fewer features than vesa - it doesn't do modesetting *at all*. It'll just use the resolution that the kernel picked on boot. signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
[ubuntu-x] Xserver 1.9 transition
Summary for the impatient: A new X server is soon to be uploaded which requires all the drivers to be rebuilt. Be careful when upgrading in the next few days. As promised earlier in the cycle, we've got the second X server transition coming up. This will take us to X server 1.9, which features improvements to startup time, some memory usage improvements, and many DRI2 fixes. The 1.9 server has a new input and video ABI which means existing driver packages will break. The server needs to be uploaded first so the new drivers build against the correct ABI, which means that there will be a period where safe upgrades will have held-back packages. The dependencies should ensure that you won't accidentally get a non-working combination of X server and drivers, but be careful if an upgrade wants to remove X packages. Happy testing! signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
[ubuntu-x] Common bug tags between the X and kernel teams
A fairly large percentage of bugs that get reported against X now end up being kernel bugs thanks to KMS. As users cotton on to this shift there will likely be more bugs reported against the kernel which are actually an X bug, too. In X land we've got a rich set of tags¹ set up for describing the various forms of common brokenness. Some of these obviously don't apply to the kernel side of things, some obviously do. On the kernel side we have a much smaller set of tags² mainly organised around subsystems. There's also a single lonely “xorg-needs-kernel-fix” tag which looks like it could painlessly be folded into the kernel-graphics tag. In the X team we've found the wider set of tags quite useful, as we're generally pretty reluctant to merge bugs by duplicating them unless exactly the same hardware is involved. These bugs often get fixed as group, however - particularly bugs tagged edid and backlight, but also others - and having the richer tags makes it easier to find bugs to ask for re-testing. As we'll be exchanging bugs with more regularity I thought it would be useful to check that we're on the same page, and to work out a common set of tags if the kernel team feel they'd be valuable. [1]: https://wiki.ubuntu.com/X/Tagging [2]: https://wiki.ubuntu.com/Kernel/Tagging signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
[ubuntu-x] Call for Testing: Nouveau
Hi all, The drive towards stabilising Nouveau for a rocking Lucid LTS release has resulted in large changes to the packaging stack. Nouveau's kernel module is now in the main kernel package, which fixes most of the problems people have previously reported. If you have previously tested nouveau and found your VTs didn't work, or that plymouth splash didn't work, or that you just got no display at all please test again with the 2.6.32-16 kernel. If you've updated in the last day, you should already have this kernel installed. You can check which kernel you are running by running “uname -r” from a terminal - it should print something like “2.6.32-16-generic”. The important bit is 2.6.32-16. This work means that nouveau now has a lack of good bugs reported against it. I'm hoping that the fine testers of Ubuntu can rectify this! If you've got an nvidia graphics card, please try disabling the restricted drivers and testing nouveau for a day. Just using your computer with the nouveau drivers and reporting any problems you encounter will be useful, but if you want to test more systematically, there's a list[1] of things to check on the wiki. Filing a good bug is as simple as running “ubuntu-bug xorg” and describing the problem you see, and how you can trigger it, in the report. The apport hooks will magically attach all the relevant logs for you. If you run into a bug and want to invest some extra effort to help get it fixed, after reporting the bug you can test with a newer version of Nouveau. These packages are available in the xorg-edgers/nouveau PPA. Further instructions are on the wiki[2]. Your feedback is greatly appreciated. Let's go find some bugs! [1]: https://wiki.ubuntu.com/X/Testing/NouveauEvaluation [2]: https://wiki.ubuntu.com/X/Testing/NouveauEvaluation#upstreamtesting signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
Re: [ubuntu-x] Kernel v2.6.33 drm update
On Sat, 2010-03-06 at 12:47 +, Andy Whitcroft wrote: On Fri, Mar 05, 2010 at 03:32:05PM -0800, Luis R. Rodriguez wrote: On Fri, Mar 5, 2010 at 2:54 PM, Timo Aaltonen tjaal...@cc.hut.fi wrote: On Fri, 5 Mar 2010, Bryce Harrington wrote: On Fri, Mar 05, 2010 at 06:56:11PM +, Andy Whitcroft wrote: We are therefore planning to upload a hybrid 2.6.32 kernel containing the 2.6.33 drm backported. Btw, for bug report fiddling purposes, is there a reliable way to detect the drm version installed? The drm version does not show up in uname -a of course, and `dmesg|grep drm|grep 2\.6\.33` returns nothing (at least, on nouveau). (Basically I want a way to automatically distinguish between bug reports that were tested with the new 2.6.33 drm vs those that won't, so we can prioritize our attentions accordingly.) Isn't the kernel abi enough for that? -16 has the backport, anything before that doesn't. Right but its still good to know a backport from which 2.6.33.y Fair point. Right now we have v2.6.33 straight. But I do see how we might want some finer grain record of the version. I will look at where we can expose that. For prior art, Nouveau's upstream build captures the output of git-describe and displays it on module load. Feeding the git information into the kernel build getting the other drm drivers to display the same information shouldn't be too hard. signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
Re: [ubuntu-x] Lost monitor at boot (was Re: Nouveau - remaining tasks.)
On Tue, 2010-02-23 at 10:39 -0800, Bryce Harrington wrote: On Mon, Feb 22, 2010 at 01:38:37PM +1100, Christopher James Halse Rogers wrote: Finally, I'm still seeing some reports on IRC of nouveau turning off the monitor on boot, leaving the system unusable. I've done some investigation, and I've got a hypothesis: if vga16fb gets loaded first, it claims fb0 and everything dies a fiery death. Are you able to reproduce this issue? Is there a bug# for tracking? If not, let's get a bug report in about it filed against linux-backports-modules. On further investigation, I'm not able to reproduce this, and I haven't heard any further complaints. If this was a bug, I think it's been fixed. signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
Re: [ubuntu-x] Status of kernel X drivers
On Thu, 2010-02-18 at 10:29 -0800, Bryce Harrington wrote: On Thu, Feb 18, 2010 at 02:57:18PM +0200, Timo Aaltonen wrote: On Thu, 18 Feb 2010, Christopher James Halse Rogers wrote: I'd suggest that we stick with our current libdrm 2.4.18, lbm-nouveau, and xserver-xorg-video-nouveau stack, and cherry pick backport whatever fixes we want to grab. In which case, as long as there's a 2.6.33 drm in lbm, the nouveau stack is happy. 2.4.18 has other fixes in it, so better to just revert the offending commit with a patch, and then decide if the ABI bump is worth it. Less work than pulling a number of patches on top of 2.4.17. I'd agree. Plus it'll be easier to explain we're carrying 2.4.18 minus patch foo. Which is the commit(s) that needs reverted? libdrm would need b496c63143e9a4ca02011582329bce2df99d9b7c and I think also 88e8a8bbaf026aa10225880001ab7ca1c392168a reverted. If we're comfortable with pulling from the nouveau kernel tree[1] for linux-backports-modules-nouveau, then going over the API bump would indeed make cherry-picking and backporting fixes easier. The API bump hasn't made it out of that tree yet, as far as I'm aware. If we're additionally going to have lbm packages for intel and radeon built from 2.6.34, I think it makes sense to pull from the nouveau tree now, and later switch to the .34 tree when we pull the rest of the drm drivers for lbm. [1] http://cgit.freedesktop.org/nouveau/linux-2.6/ signature.asc Description: This is a digitally signed message part -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
[ubuntu-x] Call for testing: nouveau open-source nvidia driver
We're aiming to ship Nouveau as the default driver for nVidia cards in Lucid as a better nv. Towards this end there are now packages ready for wider testing in the xorg-edgers/nouveau PPA[1]. To test the nouveau drivers you just need to add the PPA with “add-apt-repository ppa:xorg-edgers/nouveau”, update your package lists, upgrade your packages and then install the “xserver-xorg-video-nouveau” package from the PPA. This should install the needed packages: linux-backport-modules-nouveau for the kernel module, nouveau-firmware, and xserver-xorg-video-nouveau for the X driver. The upgraded xserver-xorg-core should automatically use the nouveau drivers without an xorg.conf, and the newer libdrm is also needed. All Lucid users can help with testing - if you don't have nvidia hardware please test that it doesn't break your existing drivers. Users with nvidia hardware should test that they get: 1) Kernel modesetting from early boot including a nice native-resolution console. 2) The nouveau driver is automatically loaded by X without needing an xorg.conf - this can be checked in /var/log/Xorg.0.log, as usual. 3) The nouveau driver generally works as well as nv - nouveau should pick the correct resolution, dual-head should work, video should play nicely, etc. You should not expect to work: * The nvidia binary drivers. The nouveau kernel module will bind to the hardware and there is no mechanism for handing off to nvidia kernel module. * 3D acceleration. Brave souls can build mesa from source (and may well find that they can run compiz), but we will not be shipping the 3D component in Lucid. For the moment problems can be reported as replies to this mail - I'm particularly interested in any situation where this breaks non-nvidia hardware. [1]: https://edge.launchpad.net/~xorg-edgers/+archive/nouveau -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
[ubuntu-x] Nouveau: what's happening upstream, what it means for Lucid
I've been following what's happening upstream with respect to nouveau, and there have been a couple of interesting events. Firstly, nouveau is now in staging in Linus' tree[1]. Commit id is 9764757932ce26f139332f89d1d3b815e4cc56ab. So, for Lucid+1 it looks like we won't have to do anything special to get nouveau. For Lucid, we can do a number of things: 1) A nouveau module slightly older than the one pushed to Linus can happily build run against an almost-unmodified Lucid drm.ko. This option looks pretty safe, at least as far as breaking unrelated drm drivers. There's a proof-of-concept “nouveau-scratchpad branch of Lucid's 2.6.32-7 kernel with the nouveau bits dropped in at cooperteam.net/kernel-lucid-nouveau.git. This will make it more difficult to pull upstream bugfixes, but is the safest way to get an in-kernel nouveau.ko. 2) We can try and pull nouveau from Linus' tree. This is more difficult, as it requires some changes in drm ttm; specifically the factoring out of displayport support into drm_kms_helper, and changes in the ttm_placement APIs, which will affect i915 and radeon, respectively. 3) Do something different; either an out of tree backports module, or keep updating the nouveau-kernel-source dkms package. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9764757932ce26f139332f89d1d3b815e4cc56ab -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
