#ubuntu-x 2006-08-15
<rodarvus> just in case there is anyone listening to this channel :)
<rodarvus> "Ave,
<rodarvus> just introducing simple sugar in the form of a new acceleration architecture.
<rodarvus> In the spirit of being short and sweet, that fits very well with the concepts
<rodarvus> of Glucose:
<rodarvus> - it's an OpenGL based acceleration architecture,
<rodarvus> - all driver code is limited to just initialising it (a call to
<rodarvus> glucoseDriverInit), which really could be eliminated as well, by cleverly
<rodarvus> hooking it up in the server... we might want to do that soon.
<rodarvus> - it uses XGL code, so it accelerates everything using exactly the same paths
<rodarvus> as XGL does. So there's no duplicate code/work here."
<crimsun> sounds interesting
<ajmitch> nice, a middle ground between AIGLX & Xgl magic
#ubuntu-x 2006-08-16
<shining> hi
<shining> rodarvus: hi
<rodarvus> hi shining
<shining> you just missed my question on debian-x :) but it's more on topic here :
<shining> http://pastebin.ca/134377
<rodarvus> shining, thanks, I'm working on this fix as we speak :)
<rodarvus> (been doing since yesterday afternoon, actually)
<shining> ha, so there is really something to be fixed, I thought I messed up something during the huge update :)
<shining> ha ok
<rodarvus> actually mesa already has the right dri directory builtin
<shining> though, I think I first saw this problem quite a while ago
<shining> ha
<rodarvus> but it seems that for some users upgrading from dapper, this is not working
<rodarvus> I'm chasing the root of this problem
<shining> ha, well that was my case, but I'll maybe reinstall anyway
<shining> ho right
<shining> just booted on edgy desktop cd, and it looks in the correct place
<shining> but r300 is not there :d
<shining> btw, it's not possible to get the stupid eye candy effect with edgy?
<shining> aiglx+compiz worked fine on dapper, after adding an unofficial repo. but the edgy branch of this repo seems broken
<rodarvus> no need to add extra repositories for aiglx on edgy (it is part of official xorg-server)
<rodarvus> compiz is a different subject, obviously
<shining> what about xserver-xorg-air or something?
<shining> it seems to be available, but Xorg-air didn't start
<ajmitch> compiz will be updated soon, I promise :)
<ajmitch> shining: just use the regular x server
* rodarvus has no idea of what xserver-xorg-air is - "accelerated indirect rendering"?
<ajmitch> yes, obsolete, should be removed from edgy
<rodarvus> but anyhow, as ajmitch says, no need to run a different xorg-server
<rodarvus> you'll just need compiz, quite probably
<rodarvus> (and it is/should be on universe)
<ajmitch> should be, the one in universe is broken, I've got packages locally that are missing a patch or two
<ajmitch> ah, bug 55997
<shining> ha ok
<shining> well anyway, I don't really care, as long as 3d accel is working :) I just wanted to play a bit more with it till I'm bored
<rodarvus> ajmitch, to remove this package from edgy you'll have to subscribe ubuntu-archive to this bug
<rodarvus> (and probably make it have a more formal wording)
<ajmitch> yes, I didn't file it, I just remembered seeing it :)
<rodarvus> "please remove xorg-air from edgy, as upstream xorg-server implements aiglx natively" or something like this
<ajmitch> at least malone has a nice clear link to editing the description now
<shining> ho
<shining> actually, it's looking in /usr/lib/dri/ when libgl1-mesa-glx and libgl1-mesa-dri are not installed
<shining> so it doesnt find anything, because the dri package containing the driver is not there
<shining> but after installing these packages, now that the drivers are in /usr/lib/dri/, it looks in /usr/X11R6/ again :d
<shining> it's funny
#ubuntu-x 2006-08-18
<shining> hi
<shining> any success fixing the "path bug" ? :)
<rodarvus> a new mesa package was uploaded to the archive earlier today
<rodarvus> https://launchpad.net/distros/ubuntu/edgy/+source/mesa/6.5.1~20060817-0ubuntu1
<crimsun> (and is available in the archive now)
<shining> is it supposed to fix it?
<shining> it seems it's the same as before
<shining> after unsetting LIBGL_DRIVERS_PATH, it tryes again to open /usr/X11R6/lib/modules/dri/i915_dri.so
#ubuntu-x 2007-08-13
<ubotu> New bug: #132082 in xserver-xorg-video-i810 (main) "man page wrong/ driver options confusing" [Undecided,New]  https://launchpad.net/bugs/132082
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #3598 in usplash (main) "mtrr allocation failed" [Medium,Fix released]  https://launchpad.net/bugs/3598
<ubotu> New bug: #112310 in xorg (main) "Setting Wacom pen button to double click doesn't work" [Undecided,New]  https://launchpad.net/bugs/112310
<ubotu> New bug: #132192 in xorg (main) "ubuntu installation on VAIO VGN-A617M -- Screen Blank" [Undecided,Incomplete]  https://launchpad.net/bugs/132192
<tepsipakki> bryce: I'm off to London for a couple of days, and thus offline until Friday :) (just in case there was something urgent)
<bryce> heya tepsipakki
<bryce> tepsipakki: thanks for getting -ati up :-)
<tepsipakki> yeah, so far so good.. or no-one using it/gutsy :)
<bryce> tepsipakki: I think most everything's under control now, the one question is whether we want to shoot for xserver 1.4 for gutsy, or leave it for gutsy+1
<bryce> anyway, have a good trip to London, I'll cya Friday
<tepsipakki> thanks, I need to pack and sleep a few hours :)
<tepsipakki> as ig
<tepsipakki> er, if
<ubotu> New bug: #132268 in xorg-server (main) "Xorg with composite enabled causes abnormally high cpu usage" [Undecided,New]  https://launchpad.net/bugs/132268
#ubuntu-x 2007-08-14
<ubotu> New bug: #131872 in xorg (main) "[Gutsy]  running glxgears crashes xorg" [Undecided,Incomplete]  https://launchpad.net/bugs/131872
<ubotu> New bug: #132360 in xserver-xorg-video-ati (main) "[gutsy]  vlc doesn't render properly with compiz 'normal desktop effects'" [Undecided,Incomplete]  https://launchpad.net/bugs/132360
<kylem> bryce, around?
<bryce> yep
<kylem> bryce, nm. it can wait until tomorrow.
<bryce> ok cool
<ubotu> New bug: #132377 in xserver-xorg-input-mouse (main) "USB Mouse not work after some time" [Undecided,Incomplete]  https://launchpad.net/bugs/132377
<ubotu> New bug: #132400 in linux-restricted-modules-2.6.15 (restricted) "6.06LTS: Computer locks up with nvidia proprietary driver on SMP system" [Undecided,New]  https://launchpad.net/bugs/132400
<ubotu> New bug: #132405 in xterm (main) "Please sync xterm (229-1) from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/132405
<mvo> bryce: I would like to do some testing/patching for -video-i810 and -video-intel to use xf86XVFillKeyHelperDrawable instead of xf86XVFillKeyHelper in those drivers for better support of composited video
<mvo> bryce: -video-ati should be done with the debian/experimental version that we will soon get (as I understand it)
<ubotu> New bug: #132432 in mesa (main) "glxinfo crashed with SIGSEGV" [Undecided,New]  https://launchpad.net/bugs/132432
<jcristau> #132432 is using the nvidia libGL...
<bryce> mvo, ok
<mvo> bryce: basicly I would like to get this http://people.ubuntu.com/~mvo/tmp/xserver-xorg-video-i810_1.7.4-0ubuntu5.debdiff one here in to make basic video play under composite work. I have no i810 based laptop yet (I got one now that is currently updating). are you happy with this? should I use a patchsystem?
<mvo> bryce: and don't tell me that patch system is quilt ;) 
<bryce> heh
<bryce> can you add a description at the start of the patch for what the patch does (i.e., why switching from xf86XVFillKeyHelper to *Drawable is needed), and specify where the patch comes from (e.g., link to the mailing list discussion or bug url)
<mvo> bryce: right, this is more a draft so that you can have a look :) the patch was done my me based on the -video-ati driver, I will certainly improve the description
<mvo> bryce: is there a patchsystem I should use or edit it inline?
<bryce> debian-x usually uses quilt
<bryce> (I know I'm not supposed to tell you that)
<mvo> haha
<mvo> I was afraid of this answer
<bryce> editing inline is fine (I don't use quilt either)
<mvo> cool
<bryce> as long as it builds and everything stays inside debian/, I'm not fussy :-)
<mvo> ok, I will test it on my new-old i810 laptop that I got for testing and if it is ok I will upload. the same dance will have to be done with -intel and maybe -ati (if we do not merge the experimental version there)
<mvo> that should fix the video playback problem under compiz
<bryce> excellent :-)
<jcristau> mvo: what's the problem with quilt?
<jcristau> also, is there any plan to use some sort of version control for the ubuntu x packages?
<mvo> jcristau: there is no real problem apart from that I forget all the time to run quilt add before editing a file
<jcristau> ok
<mvo> jcristau: and that I have not found a way yet to create autoreconf patches with it
<mvo> without quilt add loads of files beforehand and forgetting half of them
<jcristau> yeah, we apply autoreconf stuff directly in the diff
<bryce> we'd decided since bzr does not have a git import mechanism currently (or at least when we last discussed it), to use git
<mvo> I feel that its not ideal to not have a reference tree to diff against
<bryce> however really we only have a couple packages where ubuntu has a significant amount of stuff differing from debian, so it has not been a very high priority for me
<jcristau> mvo: sometimes i just create the diff with git, and then put it in debian/patches/
* mvo grumbles about xserver-xorg-video-i810 creating a broken .pc and patches smylink
<mvo> bryce: I'm going to upload -video-i810 now, what is the status of -video-ati (sorry for naging, its just that I want to plan what servers needs to be checked for Xv working with compiz)
<mvo> bryce: will it be merged? or will we stay with the current version for feature freeze?
<jcristau> i think tepsipakki merged it with the experimental version a few days ago
<bryce> correct
<bryce> we have also been discussing about potentially going with the randr 1.2 branch of -ati, at alex's recommendation, however we're not yet certain about the stability of it compared with main.
<ubotu> New bug: #132523 in xserver-xorg-driver-neomagic (main) "[feisty]  xserver crashes running xzgv over ssh" [Undecided,New]  https://launchpad.net/bugs/132523
<mvo> bryce: is that something that we can decide after feature-freeze? or will it have to be done by then?
<bryce> well, I'd want it done before feature freeze.  I'm not sure there's sufficient time though.
<bryce> however having xrandr functionality in -ati would be _way cool_ esp. for projector users
<bryce> but for -ati I think stability would trump way-cool arguments
<jcristau> i expect it'll have a bunch of regressions, as it hasn't been tested very extensively yet
<bryce> yes, as well if there are fixes in the main branch, it could involve a lot of backporting work
<mvo> hm, I'm inclined to backport the make-compiz-happy-with-xv patch to -ati then if you are unsure if we get the new one or not
<bryce> yes do
<bryce> I'm fairly sure we won't be switching to the xrandr branch.  I might post a deb of it to my web space for people to play with.
<mvo> ok, thanks
<ubotu> New bug: #109357 in xorg (main) "gnome crashes upon relogin" [Medium,Confirmed]  https://launchpad.net/bugs/109357
#ubuntu-x 2007-08-15
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #132622 in xserver-xorg-video-ati (main) "Color palette corruption on Radeon 7200 "All-In-Wonder"" [Undecided,New]  https://launchpad.net/bugs/132622
<ubotu> New bug: #132633 in xserver-xorg-video-intel (main) "Video playback is horizontally stretched for GMA965 (X3100)" [Undecided,New]  https://launchpad.net/bugs/132633
<ubotu> New bug: #132635 in xorg (main) "delete from font path not working" [Undecided,New]  https://launchpad.net/bugs/132635
<jcristau> bryce: no debian versions again on http://people.ubuntu.com/~bryce/Xorg/versions_current.html :)
<ubotu> New bug: #132700 in xserver-xorg-video-ati (main) "r300: poor 2D performance in some apps" [Undecided,New]  https://launchpad.net/bugs/132700
<ubotu> New bug: #132707 in xserver-xorg-video-ati (main) "r300: poor compiz performance" [Undecided,New]  https://launchpad.net/bugs/132707
<ubotu> New bug: #132716 in xserver-xorg-video-ati (main) "ATI Driver Gets Black Screen on Radeon 7500 Mobile (Regression)" [Undecided,New]  https://launchpad.net/bugs/132716
<bryce> jcristau: fixed
<jcristau> thanks
* Starting logfile irclogs/ubuntu-x.log
#ubuntu-x 2007-08-16
<bryce> jcristau, I notice in mesa-7.0.1 that debian has some changes to parameter ordering for some macros in r300_texstate.c and I'm curious about them?
<bryce> e.g. line 75:         _ASSIGN(RGBA8888, R300_EASY_TX_FORMAT(Z, Y, X, W, W8Z8Y8X8)),
<bryce> vs
<bryce>        _ASSIGN(RGBA8888, R300_EASY_TX_FORMAT(Y, Z, W, X, W8Z8Y8X8)),
<ubotu> New bug: #132807 in xorg (main) "cant change screen resolution." [Undecided,New]  https://launchpad.net/bugs/132807
<bryce> jcristau: nevermind, I figured it out.
<jcristau> yeah, i don't think we have any changes there
<ubotu> New bug: #131821 in xorg-server "Random Dell D600 Keyboard Freeze" [Undecided,New]  https://launchpad.net/bugs/131821
<ubotu> New bug: #132838 in xorg (main) "periodic screen flashes after unplugging an external monitor, ATI card" [Undecided,New]  https://launchpad.net/bugs/132838
<seb128> the new ati driver seems to freeze my computer when using a web browser, is that a known issue?
<jcristau> seb128: not sure, but you can file a bug on fd.o and make it a blocker for #11749 (xf86-video-ati 6.7 release)
<seb128> jcristau: is there any debug informations that would be nice to attach to the bug?
<seb128> I can ssh to the box still
<seb128> Xorg is eating all the CPU when that happens
<jcristau> maybe try to attach to it with gdb to see what it's doing?
<seb128> and restarting gdm or Xorg doesn't make any difference on the buggy box, the screen is still frozen, I can only move the mouse pointer on it
<seb128> I tried but I've only "??", not sure of what dbg packages I need, I'll try again later
<jcristau> xserver-xorg-core-dbg and xserver-xorg-video-ati-dbg probably
<ubotu> New bug: #132903 in linux-restricted-modules-2.6.20 (restricted) "no vmware-player kernel modules for linux-image-2.6.20-16-server" [Undecided,New]  https://launchpad.net/bugs/132903
<ubotu> New bug: #131428 in xorg (main) "Matrox G400 graphical errors with AIGLX enabled" [Undecided,New]  https://launchpad.net/bugs/131428
<ubotu> New bug: #132930 in xserver-xorg-video-nv (main) "nv driver misdetects panel size of dell 2007fp monitor" [Undecided,New]  https://launchpad.net/bugs/132930
<ubotu> New bug: #70539 in xorg-driver-synaptics (main) "Erratic touch pad cursor movement (dup-of: 12124)" [Undecided,New]  https://launchpad.net/bugs/70539
<ubotu> New bug: #119537 in xserver-xorg-input-mouse (main) "usb mouse stops" [Undecided,Incomplete]  https://launchpad.net/bugs/119537
<ubotu> New bug: #133002 in xorg (main) "[gutsy]  The resolution is fine but only 20% aprear in the screen" [Undecided,New]  https://launchpad.net/bugs/133002
<ubotu> New bug: #124610 in xserver-xorg-driver-i810 (main) "Totem Movie Player crashes when opening movie file" [Low,Confirmed]  https://launchpad.net/bugs/124610
<ubotu> New bug: #132966 in xserver-xorg-input-keyboard (main) "Keyboard stops working after any wireless device is removed" [Undecided,Incomplete]  https://launchpad.net/bugs/132966
<bryce> jcristau, how has your xserver 1.3.99 packaging gone?  I notice it's not up on experimental - were there too many issues, or are you just waiting on 1.4?
<jcristau> bryce: waiting for pixman to clear NEW...
<bryce> ok thanks, yeah I am looking at that too
<jcristau> other than that, the server packaging is basically ready
<bryce> there is a (now obsolete) libpixman package that is a distant ancestor of pixman - are you planning to drop or replace that one with this?
<jcristau> the other libpixman package isn't used by anything and hasn't been updated in ages, i don't know why it's there :)
<bryce> jcristau: have you heard word about the release date for 1.4?  (Since today is ubuntu FF I'm trying to decide whether to bite the bullet and go for 1.4, or stick with 1.3 and avoid risk)
<bryce> yeah I talked to cworth about it and he was perplexed why we'd still have it ;-)  I think we should drop it
<bryce> might be confusing for people if we have libpixman and pixman packages
<jcristau> i'll need to talk to our cairo maintainer, but last time i emailed it about pixman i never got any answer
<jcristau> s/it/him/
<bryce> I could forward along cworth's answer if you'd like?
<jcristau> anholt's release schedule said 2007-08-29 for 1.4, but i guess it'll slip :)
<jcristau> yes please
<bryce> sent
<jcristau> thanks
<seb128> bryce: I've uploaded mesa, xhost, xlsfonts, the xmodmap version is already in gutsy
<ubotu> New bug: #133032 in xserver-xorg-video-nv (main) "Please sync xserver-xorg-video-nv (main) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/133032
<bryce> seb128: excellent, thanks!
<seb128> bryce: you're welcome
<seb128> bryce: xserver-xorg-video-nv synced
<bryce> excellent
<bryce> also I have a question
<bryce> I want 'pixman' synced from debian, but requestsync doesn't accept it since it's not yet in
<bryce> ...not yet in ubuntu
<jcristau> bribe some debian ftp-master to accept it :)
<bryce> heh, well after that ;-)
<seb128> bryce: wait for the package to be available in Debian and then open the bug ;)
<jcristau> the other option is to take our package from git and upload it as -0ubuntu1, afaics
<seb128> or get it from whoever uploaded to Debian
<jcristau> or that
<seb128> the only issue with using git or whatever other csv is to have the same orig tarball
<seb128> or we can't sync later
<jcristau> the tarball is http://xorg.freedesktop.org/releases/individual/lib/pixman-0.9.4.tar.gz
#ubuntu-x 2007-08-17
<ubotu> New bug: #133060 in xserver-xorg-input-synaptics (main) "Synaptic touchpad fails to register some of the taps for tap-to-click" [Undecided,New]  https://launchpad.net/bugs/133060
<ubotu> New bug: #133049 in xorg (main) "Caps Lock & Num Lock don't work" [Undecided,New]  https://launchpad.net/bugs/133049
<ubotu> New bug: #132847 in xorg (main) "downloaded updates, now X11 does not load" [Undecided,New]  https://launchpad.net/bugs/132847
<ubotu> New bug: #132593 in xorg (main) "Gutsy Thinkpad R31 Xwindows Failure" [Undecided,New]  https://launchpad.net/bugs/132593
<ubotu> New bug: #133109 in linux-restricted-modules-2.6.20 (restricted) "wrong nvidia-glx driver loads (1.0-9755 vs. 1.0-9631) when nvidia-glx is installed and enabled" [Undecided,New]  https://launchpad.net/bugs/133109
<ubotu> New bug: #133116 in xorg (main) "Implement a way to minimize full screen windows like games" [Undecided,New]  https://launchpad.net/bugs/133116
<ubotu> New bug: #133119 in xserver-xorg-driver-ati (main) "no dri or xgl on imac g3" [Undecided,New]  https://launchpad.net/bugs/133119
<bryce> seb128: did you want to talk more about  118745?
<seb128> bug #118745
<ubotu> Launchpad bug 118745 in libgnome "Font sizes in Gutsy are vulnerable to bad X.org DPI detection" [Medium,In progress]  https://launchpad.net/bugs/118745
<seb128> not really
<seb128> I don't have a real opinion on this guidance thing
<seb128> do you know about it? what is it doing? if that's working, shouldn't that be done by xorg rather?
<bryce> well, what I gather is that it's not exactly xorg's fault, but rather I believe it's our postinstall scripts
<bryce> I don't understand how the gnome code is determining dpi from xorg settings, but it sounds like it's taking it from the refresh rates
<bryce> however the way our xorg postinst scripts are designed, much of the time those are just educated guesses
<bryce> so relying on those guesses for determining dpi is bound to be problematic and result in lots of incorrectness
<bryce> it would be nice to have someone experiencing the issue test it with and without an xorg.conf.  If my hypothesis is correct, in the latter case the font dpis should work out correctly
<bryce> I noticed one person in the bug commentary mentioned doing essentially this, but I'd like to see a confirmation on it
<bryce> I wasn't able to find any bug reports upstream regarding DPI issues, which also makes me think it's our(+debian) issue, not xorg's
<bryce> so the true fix for this would be to massively fix up / rearchitect the postinst for xorg, and replace a lot of the monitor resolution guesswork logic with something more reliable - or make it better at letting xorg take over when it doesn't know
<seb128> bryce: I don't think GNOME is calculating the number of dpi
<bryce> but I think that's like a 1+ month job, not something we could safely do for gutsy
<seb128> xpdyinfo shows the same numbers
<seb128> like
<seb128>   resolution:    85x86 dots per inch
<seb128> hum, k
<seb128> so do you have an opinion on whether we should use the guidance script or go back to use a fixed 96dpi version?
<bryce> which guidance script?
<seb128> <Riddell> seb128: are you planning to do anything about bug 118745?  we have a script in guidance that runs on login for kubuntu that sets the DPI which you could use
<ubotu> Launchpad bug 118745 in libgnome "Font sizes in Gutsy are vulnerable to bad X.org DPI detection" [Medium,In progress]  https://launchpad.net/bugs/118745
<jcristau> fwiw, there's some discussion of that issue in bugs.debian.org/237877
<bryce> jcristau: cool, thanks
<jcristau> the "DPI, font size, and Debian" thread at http://lists.debian.org/debian-x/2004/12/threads.html might be relevant too
<jcristau> don't know if things changed much since then
<bryce> ok
<bryce> seb128: interesting, the guidance script basically also hardcodes to 96 when xorg think's its dpi is less than 140
<jcristau> bryce: pixman is in incoming right now, on the mirrors in a few hours
<bryce> great
<seb128> bryce: weird
<bryce> but yeah reading the comments on this function it seems to be compensating for inaccurately detected monitor sizes
<bryce> so yeah my opinion is that we should hardcode the dpi's, either directly, or using this displayconfig-restore.py script
<seb128> I'll use the 96dpi as it used to be
<seb128> I don't see the need to add an extra package and script to do basically what we were doing
* bryce nods
<bryce> I think that should solve the issue suitably for now.  The higher dpi's would provide for higher resolution fonts for users with large monitors, but it won't be a regression to not have that
<seb128> right
<bryce> I'm planning on doing some plumbing work on the postinst scripts for the next release, that will hopefully make workarounds like these needed less often.
<seb128> ok
<seb128> I've to go
<bryce> cya
<seb128> we can talk about that later again
<seb128> thanks
<seb128> see you
<jcristau> anything that kills stuff from xserver-xorg.postinst can only be good :)
<bryce> agreed :-)
<ubotu> New bug: #133192 in xserver-xorg-video-ati (main) "Screen displays garbage" [Undecided,New]  https://launchpad.net/bugs/133192
<ubotu> New bug: #133200 in mesa (main) "[gutsy]  libGL.a missing - linking fails" [Undecided,New]  https://launchpad.net/bugs/133200
#ubuntu-x 2007-08-18
<ubotu> New bug: #133250 in xorg (main) "Xorg 7.3 autodetection does not use "nvidia" driver when appropiate" [Undecided,New]  https://launchpad.net/bugs/133250
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #132760 in xserver-xorg-input-synaptics (main) "Touchpad doesn`t work on Switch user (dup-of: 68370)" [Undecided,Confirmed]  https://launchpad.net/bugs/132760
<ubotu> New bug: #133379 in xserver-xorg-driver-i810 (main) "Turning mouse cursor invisible causes screen to go blank" [Undecided,New]  https://launchpad.net/bugs/133379
<ubotu> New bug: #133383 in xserver-xorg-video-ati (main) "desktop effekts does not work on  ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] " [Undecided,New]  https://launchpad.net/bugs/133383
<ubotu> New bug: #133385 in xserver-xorg-driver-nv (main) "[gutsy]  "nv" is not new enough to support my chipset (Quadro FX 570M), but is detected as the most appropriate display driver during installation" [Undecided,New]  https://launchpad.net/bugs/133385
<ubotu> New bug: #133394 in xserver-xorg-video-ati (main) "[kubuntu gutsy]  dpi resolution for screen is no longer recognised" [Undecided,New]  https://launchpad.net/bugs/133394
#ubuntu-x 2007-08-19
<ubotu> New bug: #21552 in xfonts-core (main) "core fonts aren't registered with defoma" [Wishlist,Fix released]  https://launchpad.net/bugs/21552
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #133481 in compiz (main) "Videoclips don't play with the Desktop Effects enabled (dup-of: 111257)" [Undecided,New]  https://launchpad.net/bugs/133481
<ubotu> New bug: #133503 in xorg (main) "[Gutsy]  Screens And Graphics on ATI" [Undecided,New]  https://launchpad.net/bugs/133503
#ubuntu-x 2008-08-11
<tjaalton> bryce: btw, I've prepared a couple of copypaste responses for nvidia/fglrx bugs, but can't get to them right now (they're on my home desktop)
<bryce> ok
<bryce> tjaalton: I trust you to make good responses :-)
<bryce> I've got a crapload of tasks I promised people to do, so think I'm going to be swamped taking care of them for a while:
<tjaalton> bryce: heh, well they need to be proofread first :)
<bryce> - GEM-enabled packages for BenC
<bryce>   (half-done)
<tjaalton> and we probably need to tell people about the bug policy regarding fglrx/nvidia
<bryce> - input hotplug testing (mostly done, need to test a game controller and futz with some wacom tablets)
<tjaalton> cool
<bryce> - failsafe-x stuff.  mdz is adamant about keeping it.  not sure what to do, but have some solid ideas.
<bryce> - review/upload tseliot's x-kit stuff
<bryce> - ati bug triage
<bryce> - inkscape stuff
<tjaalton> should keep you busy for some time :)
<bryce> - dholbach's sponsoring todo's 
<bryce> - goddamn spam
<tseliot> bryce: thanks to your xorg.conf files x-kit is a lot more robust now. I'm about to upload some new improvements (in addition to what I committed yesterday). Just FYI
<bryce> tseliot: yay!!
<tseliot> :-)
<tjaalton> tseliot: I guess you don't mind if we'll close nvidia bugs (those that are nvidia's fault) as wontfix in the future?-)
<tseliot> tjaalton: of course I don't mind ;)
<tjaalton> and ask them to use nvidia-bug-report.sh instead
<bryce> tjaalton: yeah.  I wish I could just focus 100%, but I do kind of like that my tasks enable other people to move forward with their own stuff
<bryce> oh, forgot
<bryce> - test the new apport features
<bryce> - experiment with new the LP 2.0 API
<tjaalton> bryce: btw, wouldn't NoTrapSignals do the same as your patch?
<bryce> would it?  I've not looked at NoTrapSignals
<tjaalton> MrCooper asked me about it, and I couldn't answer :)
<tjaalton> man xorg.conf would suggest that it should work
<bryce> I didn't see any #ifdefs in the code or whatnot that would make me think NoTrapSignals would do it
<bryce> but I could be wrong
<jcristau> tjaalton: notrapsignals means the server doesn't get a chance to clean up
<jcristau> (possibly your patch does, too, but i haven't checked)
<bryce> night
<tseliot> bryce: xkit committed
 * tseliot > lunch
<tjaalton> woohoo, so GEM will be in 2.6.27 :)
<jcristau> probably not?
<tjaalton> ah sorry, jumped the gun
<tjaalton> just a list of commits to merge on top of -rc1 to get GEM working, bah
<pwnguin> so what is the bug policy regarding nvidia?
<pwnguin> (and fglrx)
<bryce> pwnguin: how do you mean?
<tormod> gmail is broken, I can't read my bug mail. opportunity to sleep?
<bryce> tormod: yep
<bryce> tormod: sorry got distracted...  need to finish one email then I'm on it
#ubuntu-x 2008-08-12
<bryce> tormod: uploaded
<tormod> bryce: \o/
<tormod> bryce: do you have an interest in laptop's acpi and friends?
<bryce> not too much, but if you're looking for sponsoring I'm game
<tormod> there's a related debdiff in 250938
<tormod> not by me, but I can endorse it
<tormod> there used to be mjg59 that maintained these things, and had his opinions, but he jumped ship I think
<tormod> and things are poorly coordinated between pm-utils, acpi-support, laptop-mode-tools you name it
<bryce> mm
<bryce> maybe you'll become the new mjg59 ;-)
<bryce> ok, so the debdiff in comment #1?
<tormod> yes, there's only one :)
<tormod> lately Alexey, ceg and some other guys started to look at this
<bryce> tormod: uploaded
<tormod> I think they will help testing out things thoroughly
<tormod> great
<bryce> cool
<bryce> well I'll be happy to do review/upload support
<tormod> maybe Intrepid will be _the_ laptop release :)
<bryce> awesome :-)
<bryce> btw, brian's switched from fglrx to -ati (maybe to help testing/verification?)
<bryce> <brian> bryyce: can you help me set the ati driver and glx or point me to documentation?
<bryce> <bryyce> sure, what do you need to set?
<bryce>  https://help.ubuntu.com/community/RadeonDriver seems reasonably accurate, starting from 'Ubuntu installation with AIGLX'
<bryce> <brian> bryyce: I'm having some issues with libGL
<bryce> <brian> Removing xorg-driver-fglrx ...
<bryce>  dpkg-divert: rename involves overwriting `/usr/lib32/libGL.so.1' with different file `/usr/lib32/fglrx/libGL.so.1.xlibmesa', not allowed
<bryce> <bryyce> maybe  $ sudo apt-get install --reinstall libgl1-mesa-glx libgl1-mesa-dri
<bryce> <brian> same issue
<bryce> <brian> bryyce: I seem all squared away now
<tormod> I say, never install fglrx in the first place :)
<tormod> it's like syphilis
<tormod> bryce, what about the radeon release with that M6 cherrypick?
<bryce> which?
<tormod> oh, I have this debdiff for SRU in bug #204483, can you review/triage/upload if you can
<ubottu> Launchpad bug 204483 in xserver-xorg-video-ati "[Hardy] Closing Laptop lid corrupts screen and beeps" [Undecided,Fix released] https://launchpad.net/bugs/204483
<tormod> the M6 lockup is bug #148408
<ubottu> Launchpad bug 148408 in xserver-xorg-video-ati "[M6 LY] System lockup when switching VT's or Resume from Suspend" [High,Fix committed] https://launchpad.net/bugs/148408
<bryce> sure I'll take a look at it later.  Since alpha-4 soft-freeze is tomorrow I'm just focusing on intrepid uploads today
<tormod> makes sense
<tormod> bryce, I saw your acpi-support upload, but the laptop-mode-tools doesn't show up?
<bryce> hmm, changes rejected
<bryce> Unable to find laptop-mode-tools_1.45.orig.tar.gz in upload or distribution.
<bryce> Files specified in DSC are broken or missing, skipping package unpack verification.
<bdmurray> bryce: I've an xserver lockup now, I was trying to check out openarena
<tormod> bdmurray: what card do you have?
<bdmurray> tormod: rv370 / x300se
<bdmurray> I can't kill Xorg now either
<tjaalton> pwnguin: it's a mere proposal right now
<mvo> tjaalton: just to clarify, the new xorg stuff gets its keymap now from /etc/default/console-setup ?
<tjaalton> mvo: yes
<mvo> tjaalton: execellent, so a global change of the keybinding can be done via "debconf console-setup" and x will pick it up on the next start?
<tjaalton> mvo: yup
<mvo> excellent, thanks tjaalton!
<tjaalton> well, hal needs a restart :)
<tjaalton> and then X
 * mvo nods
<Q-FUNK> does Bug #255991 look like a suitable candidate for an SRU?
<ubottu> Launchpad bug 255991 in xserver-xorg-video-geode "xf86-video-geode:  DDC probing broken on GX2/CS5535 since 2.9.0 (patch)" [Undecided,New] https://launchpad.net/bugs/255991
<mvo_> hey tjaalton! after upgrading (from hardy) to the interpid xserver I lost the ""EmulateWheel"  "true"" and  "EmulateWheelButton"    "2" options it seem (they work no more)  - have you heard about this problem? 
<tjaalton> mvo_: they are ignored :)
<tjaalton> because it uses evdev
<mvo_> tjaalton: is there a way to bring this feature back? 
<tjaalton> other than going back to mouse, I don't know
<jcristau> the emulatewheel stuff was recently added to the evdev driver upstream i think
<tjaalton> oh
<tjaalton> so it seems
<Q-FUNK> hm. interesting.
<jcristau> you should be able to set that with hal. or device properties in 1.6
<tjaalton> hopefully whot will backport input properties for F10 ;)
<Q-FUNK> Live GIT/Linux user spotted.
<mvo> tjaalton: sory, dropped offline (compiz got a bit unhappy on me :)
<mvo> tjaalton: did you say aynthing in the meantime?
<tjaalton> mvo: upstream evdev has support for those options, it seems
<tjaalton> in master
<mvo> tjaalton: sweet, thanks. so I just need to wait until that is released at some point? or do you think it might be worthwhile to backport the patch?
<tjaalton> mvo: it could be backported, no idea when a new release is due
<mvo> ok, thanks
<mvo> I'm keen on this feature, I may have a look myself 
<tjaalton> mvo: you can configure evdev via hal, since xorg.conf is ignored for it
<bdmurray> bryce: yesterday I was rambling aboug unable to allocate texture - I've submitted bug 257419 about it
<ubottu> Launchpad bug 257419 in xserver-xorg-video-ati "unable to allocate texture" [Undecided,New] https://launchpad.net/bugs/257419
<bryce> bdmurray: ok looking
<Ampelbein> Hi! Could some experienced user check on Bug 255826 and tell me if I done the examination in the correct way? Thank you.
<ubottu> Launchpad bug 255826 in xserver-xorg-video-savage "scrolling in Firefox causes Xorg-process to lag (S3 Savage driver)" [Undecided,Confirmed] https://launchpad.net/bugs/255826
<bryce> Ampelbein: certainly, looking...
<bryce> Ampelbein == Jordi Puigsegur I assume?
<Ampelbein> No, I'm Andreas Moog.
<bryce> ah got it
<bryce> yes looks like you've done it all correctly! Good work
 * bryce sets to triaged
<Ampelbein> ok, thanks for the feedback.
#ubuntu-x 2008-08-13
<crevette> hello
<tjaalton> so, do we want input-properties in 1.5? :)
<tjaalton> *iput-device-
<tjaalton> uh, _input_
<crevette> what is evdev ? I see this used for keyboard layout in gnome-keyboard-properties
<tjaalton> a driver
<tjaalton> generic driver for simple input devices
<tjaalton> man evdev
<crevette> ah okay thanks
<crevette> so no need to set a specific keyboard layout now
<tjaalton> you must use that model or else things will break
<tjaalton> layout != model
<crevette> ah sorry, my X knowledge is zip
<tjaalton> you can change the layout
<tjaalton> the model should probably be forced, but that would break non-evdev setups
<crevette> the driver is not listed in xorg.conf, this is not a problem?
<tjaalton> no
<tjaalton> I probably should upload the xorg changes
<crevette> (I regenerated the xorg conf with dpkg-reconfigure recetnly for intrepid)
<tjaalton> after the upload you'd have no input devices in xorg.conf
<tjaalton> since they are ignored anyway
<crevette> I had a strange problem few days back, where I had no input in gdm after an update
<tjaalton> mouse worked?
<crevette> so I wasn't able to logon :)
<crevette> no
<crevette> but the problem vanished
<tjaalton> so you didn't have all the updates
<tjaalton> we use input-hotplug now, and that requires the latest hal
<crevette> so blame update-manager :)
<crevette> ah, xorg as the hal module now
<crevette> great
<tjaalton> "few days back" <- what does that mean?
<crevette> so we take advantage of hotplug 
<crevette> tjaalton: hmmm, less than a week
<tjaalton> which mirror?
<tjaalton> the hal version was uploaded tuesday last week
<crevette> http://archive.ubuntu.com/ubuntu/ 
<crevette> perhaps One week, I don't remamber
<crevette> remember
<crevette> but it disappeared now
<tjaalton> ok, you have the old xorg.conf somewhere?
<tjaalton> or maybe you didn't have evdev installed
<crevette> let's see
<crevette> the dpk-reconfigure remove a InputDevice stanza for synaptic
<crevette> removed
<crevette> and added XkbOptions"	"lv3:ralt_switch
<tjaalton> those should not matter
<bryce> tjaalton: btw I got all the Gem packages built
<bryce> installed and tested them on my laptop too.
<tjaalton> bryce: whee, works too?
<bryce> well, it isn't broken!
<tjaalton> bryce: btw, what do you think about input-device properties? whot would like to see it in 1.5 and I'm pushing for it. It would also need a patch for inputproto and libXi, but would allow changing settings runtime for those devices that support it
<bryce> (I don't see any difference... but I assume the kernel side stuff has to be there)
<bryce> yes I definitely think that's worth including
<tjaalton> bryce: heh, yeah it falls back to the old stuff
<tjaalton> cool, I'll prepare stuff for post-alpha4
<bryce> great
<tjaalton> synaptics support (think SHMConfig madness..) is not there yet, but I believe it's just a matter of time if 1.5 supports IDP
<bryce> btw, all the gem stuff has been merged to master upstream 
<tjaalton> yep, that's great news
<tjaalton> I also looked at plymouth (a kernel-modesetting -aware bootsplash thingie), but that's probably intrepid+1 material by now :)
<bryce> what's its dependencies?
<tjaalton> it has fallbacks for non-km setups, so it just needs integration
<tjaalton> basically would replace usplash once it's mature
<crevette> GEM is planned for intrepid or later?
<tjaalton> crevette: I guess it depends on how stable it is
<tjaalton> or will be
<bryce> heya tseliot
<bryce> crevette: we're just beginning to test it; hard to say when it'll be ready.  I've got packages if you want to play with it; I'll post to ubuntu-x@ in a bit
<tseliot> hi bryce
<crevette> bryce: cool
<tjaalton> bryce: btw, do you have the source for the versions_current.html script somewhere? I could reuse it for vdr packages
<bryce> tjaalton: hmm I take back my "I don't see any difference".  It's quite buggy actually
<tjaalton> hehe :)
<bryce> had it flashing red screens at me.  quite alarming
<bryce> tjaalton: http://bryceharrington.org/files/xorg_pkg_list, http://bryceharrington.org/files/xorg_pkg_list.cron
<tjaalton> bryce: cool, thanks!
<bryce> wow, I've totally thrashed this laptop
<bryce> I think it's because I did an apt-get upgrade after installing the test packages
<bryce> silly man I am
<tjaalton> :)
<tjaalton> things to do when feeling tired :)
<bryce> network-manager broke 
<bryce> but it's working now
<tjaalton> works fine here too, 3G and all
<tjaalton> I've got IDP ready, now all I need is drivers that support it :)
<tjaalton> evdev checks for input API 3, so it needs patching to work
<tjaalton> whot said that synaptics is almost ready
<bryce> tjaalton: any ideas on 255008?
<tjaalton> bryce: yeah, mdz should change the model in the kbd capplet
<tjaalton> bag
<tjaalton> uh
<tjaalton> *bah
<bryce> sounds like he's not satisfied with that
<tjaalton> if we decide not to support non-evdev setups, it could be forced in gnome
<tjaalton> evdev forces the model initially, but it can be changed AIUI
<tjaalton> so the driver could force evdev once and for all
<bryce> hm, that doesn't sound like a great solution, since conceivably evdev might not work for some folks
<tjaalton> so if you use evdev, the driver forces the model to be evdev?
<bryce> hrm, with the gem mesa + libdrm, the gem -intel refuses to build.  hrmph.
<bryce> "Unmet build dependencies: libgl1-mesa-dev | libgl-dev"
<bryce> ah, need to throw more .deb's at it.  of course.
<bryce> sweet it's building
<tjaalton> you've got them on ppa?
<bryce> no
<bryce> hrm, fails to build due to missing uxa.h
<jcristau> there's a patch for that on the list
<bryce> jcristau: ah, it's not in git?
<jcristau> think not
<bryce> screen flickers a lot too
<bryce> alright, Gem-enabled buggy crap posted to list.  time for bed.  cya.
<tjaalton> night :)
<soren> "GEM"? Wow, that takes me back.
 * soren wonders if even Wikipedia remembers
<soren> Oh, it does: http://en.wikipedia.org/wiki/Graphical_Environment_Manager
<soren> Oh, it's GPL now!
<tjaalton> workbench ftw!
<tjaalton> :)
<soren> :)
<tjaalton> pwnguin: turns out my tablet is a rebranded waltop media tablet
<tjaalton> and not really aiptek
<tjaalton> http://www.waltop.com/p_mediate_tablet.htm
<tjaalton> identical
<pwnguin> heh
<pwnguin> isn't hardware rebranding fun?
<tjaalton> sure is
<tjaalton> apparently wacom should work
<pwnguin> orly?
<tjaalton> at least for the other walto models
<tjaalton> waltop
<pwnguin> i almost wonder if
<pwnguin> walto rebrands other people's stuff
<tjaalton> like aiptek 600U and 14000U
<tjaalton> could be, but lsusb shows this as waltop
<pwnguin> who owns the vendor id?
<tjaalton> WALTOP International Corp.
<pwnguin> crazy
<pwnguin> when i picked up mine, i made sure it was a wacom
<pwnguin> specifically to avoid that crap
<tjaalton> yeah, talk about luck :)
<tjaalton> I only need to verify it works
<pwnguin> id be surprised if wacom actually works with it
<tjaalton> I knew it was el cheapo model, and if it didn't work I could always sell it without losing that much
<pwnguin> linuxwacom is actually run by wacom
<tjaalton> maybe it's just rebranded wacom :)
<tjaalton> yep, works
<pwnguin> crazy
<pwnguin> perhaps waltop licensed wacom technology, and aiptek rebranded that
<tjaalton> I need to fix the settings, but at least it doesn't jump like with aiptek
<tjaalton> even pressure works, yay
<soren> Ok, someone please enlighten me:
<soren> What are the benefits we get from evdev that justifies making my life miserable?
<tjaalton> :/ I guess you mean kvm?
<soren> And anything else that cares about extended keycodes, but yes, specifically kvm.
<tjaalton> tbh I haven't tried a virtual setup with input-hotplug.. what issues does it have?
<soren> The issue is not in the guest. It's the host.
<soren> Oh, perhaps that's what you meant.
<soren> Anyhow, the problem is..
<soren> ..that someone's at the door.
<soren> brb
<tjaalton> :)
<tjaalton> hmm, can't create the kvm img
<tjaalton> "next" does nothing
<soren> Er... No, it's a bit... no.
<soren> tjaalton: Well, to get back to the core issue. What are the benefits we get from evdev?
<tjaalton> soren: input-hotplug
<tjaalton> and out-of-the-box support for mice with N buttons (N>>3)
<tjaalton> etc
<soren> Ah, so it's a prerequisite for input-hotplug? that's what I thought.
<tjaalton> hal can be taught to load other drivers, too
<tjaalton> so if you're thinking of virtual machines, they could load vmmouse AIUI
<tjaalton> there just needs to be a way to identify one (from hal)
<soren> The problem is with evdev on the host.
<tjaalton> if your keys are behaving strangely, make sure to set the keyboard model as evdev
<soren> If the host uses evdev, any kind of extended key presses are lost.
<bryce> morning
<tjaalton> soren: does xev show them?
<tjaalton> morning bryce
<soren> Like, say, up arrow and down arrow.
<tjaalton> soren: as I said, make sure that the model is evdev :)
<tjaalton> bug 255008
<ubottu> Launchpad bug 255008 in xorg-server "Up arrow key mapped to Print [screen]" [High,Triaged] https://launchpad.net/bugs/255008
<bryce> tjaalton: maybe we should revert back to non input-hotplug for keyboards?
<tjaalton> the real solution would be to make sure that libxklavier uses evdev model when evdev is used
<soren> I don't know why, but my laptop screen is *very* dark suddenly, and it doesn't let me increase the brightness, so I'm rebootting. bbiab
<tjaalton> bryce: I don't think that's necessary
<tjaalton> bryce: see the last message on that bug
<tjaalton> by me
<tjaalton> to further quote daniels, "gnome stupidity is 99% of the problem."
<tjaalton> "makes a pleasant change from us just being too shit."
<bryce> hmm.  doesn't sound certain that this would work
<tjaalton> why?
<bryce> well, first we'd need to backport device properties, then patch libxklavier, etc.  Hopefully/maybe that'd work, but it doesn't sound like a certain solution
<bryce> + what other issues might it bring?
<tjaalton> less than what forcing it in gconf would
<tjaalton> which is the only other way
<tjaalton> (aiui)
<tjaalton> bryce: svu should be persuaded to fix libxklavier ;)
<bryce> tjaalton: I guess I should see if I can reproduce the issue
<bryce> but breakfast first... bbiab
<pwnguin> is there a doc on the keymap problems i should read?
<tjaalton> pwnguin: what do you mean?
<pwnguin> my laptop keyboard sucks in intrepid
<pwnguin> page down triggers right click
<pwnguin> arrow keys dont work
<tjaalton> start from that bug
<tjaalton> just reset the kb model from the gnome keyboard capplet
<tjaalton> it's documented on the alpha4 release notes btw
<pwnguin> well, heh
<pwnguin> ive been using intrepid since before alpha1
<tjaalton> yes, relnotes are not for you ;)
<tjaalton> the wacom.fdi doesn't seem to work right, evdev grabs the device
<pwnguin> tjaalton: is it too late to pull in a new release from upstream?
<pwnguin> oh right, i forgot it might not build
<tjaalton> pwnguin: don't think so
<pwnguin> our fearless hero danny may have broken linuxwacom on debian in the process of fixing openSuse
<tjaalton> heh
<pwnguin> of course, it takes a committer to make it official
<tjaalton> what good is the kernel module for?
<pwnguin> i have no clue
<tjaalton> doesn't look like it's using it for me
<tjaalton> but it seems to work fine
<pwnguin> i dont see it either
<tjaalton> the modules is loaded, just that lsmod shows that nothing is using it
<pwnguin> its not even loaded in mine
<tjaalton> I should probably wash my bike while I have time.. bbl->
<pwnguin> tjaalton: thanks for the keyboard tip
<pwnguin> oh thats not good
<pwnguin> dmesg | grep wacom
<pwnguin> [   50.383182] Xorg[7733]: segfault at ff36 ip b68a97cc sp bfc034d0 error 4 in wacom_drv.so[b68a6000+13000
<bryce> tjaalton: what are the issues from forcing it in gconf?  that sounds more feasible to do for alpha-4 - what if we deployed that for alpha-4 and switched back once the libxklavier fixes are available?
<bryce> tjaalton: what are the issues from forcing it in gconf?  that sounds more feasible to do for alpha-4 - what if we deployed that for alpha-4 and switched back once the libxklavier fixes are available?
<bryce> oops mispaste
<tjaalton> bryce: AIUI it would break those setups that don't want to run with evdev
<tjaalton> I didn't think that this should be fixed for alpha4
<bryce> tjaalton: why not?
<tjaalton> lack of time? :)
<tjaalton> hmm, actually, forcing the key /desktop/gnome/peripherals/keyboard/kbd/model as empty would use whatever the system has as default
<tjaalton> so there's no need to force it as evdev
<tjaalton> I'll test this sucker on my laptop..
<seb128> tjaalton: the default is empty already
<tjaalton> seb128: yes, but not mandatory
<seb128> tjaalton: it's set according to the xorg value during the first login most likely
<seb128> tjaalton: we don't force configs this way over users
<tjaalton> seb128: btw, you like hacking libxklavier? :)
<seb128> no
<tjaalton> heh
<seb128> I've no clue about keyboards
<tjaalton> are there any packages that set mandatory gconf keys?
<tjaalton> seb128: the problem is that there's no other way, at least for alpha4
<seb128> tjaalton: no, setting mandatory gconf keys is wrong
<seb128> that's a sysadmin thing
<seb128> the package should not touch this database
<seb128> that's likely changing users value
<seb128> you might think it's a good idea in some case but that's wrong and you will get some angry users
<tjaalton> how so? it's not copied to the user settings
<tjaalton> we'll get angry users who have broken keyboard
<seb128> no, but mandatory is something sysadmin set usually
<seb128> so if you overwrite their changes that's not good
<seb128> that's something the distro should not touch
<seb128> well, overwritting sysadmin configs is not the way to do that
<tjaalton> ok
<seb128> if you want to force a value change the code which reads the key, don't do system changes
<tjaalton> hmm
<tjaalton> what might that be
<seb128> tjaalton: gnome-settings-daemon
<tjaalton> seb128: btw, the multimedia-keybindings are still wrong ;)
<seb128> tjaalton: http://cvs.fedoraproject.org/viewcvs/rpms/gnome-settings-daemon/devel/gnome-settings-daemon-2.21.91-ignore-model-if-evdev.patch
<tjaalton> seb128: cool!
<seb128> tjaalton: I'll update the package to change those and apply this patch too
<seb128> doing that in a few minutes
 * tjaalton hugs seb128 <3
 * seb128 hugs tjaalton
<tjaalton> much easier than doing it in libxklavier
<seb128> tjaalton: do you have a bug number about the issue?
<tjaalton> bug 255008
<ubottu> Launchpad bug 255008 in xorg-server "Up arrow key mapped to Print [screen]" [High,Triaged] https://launchpad.net/bugs/255008
<tjaalton> I'll reassign against g-s-d
<tjaalton> (the libxklavier part)
<seb128> ok, thanks
<seb128> I'll will close it in the changelog ;-)
<tjaalton> eeexcellent..</burns>
<tjaalton> fedora has had this patch for nearly three months.. shame on them. it should be upstream
<bryce> cool, thanks seb128
<tjaalton> hmm, the patch is over five months old
<seb128> tjaalton: right, I'll upstream it now
<tjaalton> seb128: great, thanks
<seb128> I mean send it to bugzilla.gnome.org
<tjaalton> yep
<seb128> tjaalton: bug open upstream and change uploaded to intrepid
<tjaalton> seb128: rrrock
<tjaalton> trying to figure out what's wrong with 10-wacom.fdi
<superm1> bryce, on one of our platforms with cantiga graphics we were seeing this odd situation where it looks like too many displays are enabled at one time.  kinda like the panels are restricted to the maximum output of the second display (which isn't physically plugged in).  Jose said there was a patch at some point in 8.04 to work around this behavior.  is it possible that such patch didn't make it into intrepid?
<bryce> hi superm1
<superm1> hi :)
<bryce> ah sounds like our old pipe-a quirk issue
<superm1> was the quirk hardware specific?
<superm1> or generic to the whole intel driver
<bryce> er, I mean the ignore_tv quirk
<superm1> well this must be an evolution of it then..
<bryce> yeah that's the problem - they're tied to specific hardware pci id's
<superm1> no svid on these, hdmi probably would be the culprit to be causing it
<bryce> a lot of the dell systems have the issue, and we just quirk each of them as we identify it.  So probably we just need to do the same.
<superm1> i'll be getting later engineering builds very soon for  these too, so i'll check with those first
<bryce> put in a bug with the lspci -nnvv output and I'll take care of it.  I can usually backport the quirks easy if you want it fixed in hardy too
<superm1> do you know if this sort of thing is caused by a vbios bug then?  we can get ahead of the curve if so and report these types of issues
<bryce> I don't know the specifics... keithp or jesse would be the ones to ask.  I understood the problem was that they can't detect loads on tv_out
<superm1> to bios teams etc
<bryce> I need to doublecheck some of the rework they've done to the quirks.  I know they've changed some to affect whole classes, so that might take care of it.  Not sure.
<superm1> that seems odd that a load is not detectable on tv out.  how else would it dynamically determine in the bios what displays to turn on
<superm1> okay well i'll sync back up with you once the later build gets here
<bryce> ok cool
<superm1> would you like one of these to play with too?
<bryce> sure
<superm1> i'm not sure if you have anything with cantiga thus far
<superm1> okay i'll check with the quantities that we have and see what i can do :)
<bryce> I did have one briefly a month or so ago, and sorted out a kernel issue they were having
<bryce> but I only had it for about a week and didn't get into much depth in the testing beyond that, and a totem issue
<superm1> okay we've got plenty of these with more builds coming in soon.  you can hang on to this one for a  bit then at least 
<bryce> excellent
<superm1> re that radeonhd thing i was talking about the other day, it shows up on the new engineering builds too.  vesa is okay with it, so i'm leaning towards buggy radeon driver
<superm1> so i'll get both these out in the mail tomorrow or so
<bryce> btw, if you're interested I've put up some GEM-enabled packages of -intel, mesa, and libdrm at http://people.ubuntu.com/~bryce/Testing/Gem/
<superm1> what's GEM?
<bryce> it's the new graphics memory manager (to replace TTM)
<bryce> that in theory makes X all manner of happy
<superm1> ah
<superm1> sure i'll add a note to take a look
<superm1> should be valid on all variants of -intel?
<bryce> it just got merged into master upstream, so figured we ought to have packages for anyone wishing to start playing with it
<superm1> ah so sorta like an intel-next type of thing to play with then
<bryce> I believe so.  Or at least all 9xx chips
<bryce> yeah, I stuck it on my 965 and found it to be quite buggy (bad flickering).  So definitely still a WIP
#ubuntu-x 2008-08-14
<soren> tjaalton: Ok, I've read up on the subject of the kvm brokenness due to evdev, and it almost makes me cry.
<tjaalton> soren: ok, so the guest is broken?
<soren> No.
<soren> It's... well..
<soren> Let me explain the issue:
<soren> kvm does full virtualisation, so it emulates a keyboard of some flavour.
<soren> This means that it has a virtual keyboard that sends scan codes to the guest os like a regular keyboard would do.
<soren> This is key.
<soren> it doesn't send "f", if you press the f button. It sends keycode 41.
<soren> Let's rewind about a year..
<soren> Back then, the way this was accomplished in kvm (and qemu), you had to pass "-k fi" to kvm if you had a Finnish keymapping.
<soren> That way, kvm could look at the keysym(!) look it up in the finnish keymap it had, figure out to which keycode that corresponded, and sent that to the guest.
<soren> This was annoying for many reasons.
<soren> First of all, it was a bit flaky from time to time.
<soren> E.g. azerty keyboards need you to hold down shift to type numbers, so kvm couldn't send the shift key to the guest until it knew what you had pressed.
<soren> Also, you set this in kvm, so when you're using vnc, you have to be using the same mapping as the one you told kvm you'd be using.
<soren> this sucks big time if you want to give different users access to kvm instances and they don't share a keymap.
<soren> ...or if you simply don't know ahead of time which keymap the client will be using (in hosted environments for instance).
<soren> Fast forward to... hmm.. February this year.
<soren> I got fed up with this and started looking for a way to properly fix this.. Anthony Liguori (vnc and kvm hacker (very, very convenient combination)) extended the VNC protocol to be able to send keycodes instead of keysyms.
<soren> Er... I should have said scancodes almost every time I said keycodes, I think.
<soren> Anyhow..
<soren> It turned out that the key code X reported corresponded exactly to the scan code from the keyboard. Great success. So we took those, sent them untranslated over the wire to kvm, and kvm passed them directly, untranslated to the guest.
<soren> This was fantastic. 
<soren> No more passing "-k <lang code>" to kvm to make things work (somewhat). The world was a better place.
<soren> Fast forward a few months..
<soren> Now, evdev comes along.
<soren> evdev is not doing anything wrong per se.. There's nothing in the X protocol that dictates that keycodes should correspond to the hardware scan codes from the keyboard.
<soren> and it just so happens, that with evdev, they don't.
<tjaalton> Ok, I see your point
<soren> ...so we no longer have the raw scan codes.
<soren> There are a few different solutions..
<soren> We could ditch evdev.
<soren> We could tell the evdev developers to "fix" it. (as I said, they're not doing anything wrong per se, but it's annoying to us)
<tjaalton> that's possible
<tjaalton> since fedora should be seeing the same bug by now
<soren> We could come up with a way of a) detecting the use of evdev, and b) if detected, translate evdev keycodes to scancodes again.
<soren> According to my sources, Fedora are not switching to evdev.
<soren> Because of this very bug.
<soren> s/bug/issue/
<tjaalton> anyway, maybe it would be best if you could mail xorg@lists.freedesktop.org about this problem
<tjaalton> fedora rawhide is already using it
<soren> I think someone already did. I'll need to check up on it.
<tjaalton> they didn't switch to it for F9
<soren> Oh.
<soren> Er..
<tjaalton> but there were other bugs too
<soren> Right, that might be true.
<soren> What they're *not* doing is shipping the patch to kvm that enables the raw keycode thing to happen.
<tjaalton> ah
<tjaalton> so they like old bugs
<soren> We're the only ones who ship it, and it really makes a massive difference.
<tjaalton> ok..
<tjaalton> in that case the third solution sounds cleaner
<soren> Detect evdev and try to do the mapping?
<tjaalton> right..
<tjaalton> we can't avoid evdev forever, so better fix/work around any issues that come up :)
<soren> Do you know how to detect evdev?
<tjaalton> how low level should it be?
<tjaalton> the detection
<tjaalton> setxkbmap -print is one way if it's just a script that configures kvm runtime
<tjaalton> there should be better ways to get that
<soren> ah, yes. I could look at setxkbmap and see what it does.
<bdmurray> bryce: since alpha4 is out did you want to do something with the -ati bugs?
<bryce> yep
<bdmurray> was tormod doing some of it manually though?
<tseliot> bdmurray: can you renew my membership in the Ubuntu Bug Control (ubuntu-bugcontrol) Launchpad team, please?
<superm1> tseliot, can't you do that yourself?
<tseliot> superm1: if I could I would do it myself ;)
<tseliot> "To prevent this membership from expiring, you should get in touch with one of the team's administrators:  etc."
<superm1> oh
<bdmurray> tseliot: what is your launchpad username?
<tseliot> bdmurray: albertomilone
<bdmurray> tseliot: Oh sure, done!
<tseliot> bdmurray: thanks a lot :-)
<bdmurray> no problem
<tjaalton> bryce: btw, got input-device properties working with evdev today. peter said he'd apply the backported patches to xserver 1.5 etc
<bryce> tjaalton: excellent
<bryce> bdmurray: he might have, but it doesn't hurt to repeat.
<bdmurray> heh
<bdmurray> bryce: How does http://pastebin.osuosl.org/21740 look for a comment?
<LaserJock> anybody here know how to set up a touchpad in Intrepid?
<bryce> bdmurray: sounds good
<LaserJock> there used to be a tab in the Mouse settings but I don't see it anymore
<bryce> LaserJock: I've not tested any touchpads, but I saw three user contributed docs which I've linked to from https://wiki.ubuntu.com/X/Config
<LaserJock> bryce: you don't have any laptops? :-)
<bryce> er, /not tested any touchpads that required manual configuration/
<LaserJock> ah
<LaserJock> well, mine works, just too well ;-)
<LaserJock> I gotta turn of the tap-to-click or I start typing everywhere
<LaserJock> *off
<bdmurray> bryce: hmm, I just realized I should subscribe to all of these
<pwnguin> anyone wanna take a look at https://bugs.launchpad.net/bugs/234466 ?
<ubottu> Launchpad bug 234466 in wacom-tools "[hardy] Pen crazy in tablet PC" [Undecided,Confirmed] 
<pwnguin> there's a debdiff
<pwnguin> or not
 * pwnguin reads harder
<tjaalton> I can update wacom tomorrow
<pwnguin> cool
<pwnguin> i just got a new job yesterday
<tjaalton> besides, I'll try to make it support input-properties..
<tjaalton> pwnguin: congrats!
<pwnguin> its a nice, easy part time job
<tjaalton> serving fast-food?-
<tjaalton> :)
<bdmurray> I'm not sure that qualifies as easy
<tjaalton> hehe
<pwnguin> lab assistant for a graphic design program
<pwnguin> its all osx, which is good... and bad
<tjaalton> (there's an old joke in finland; what an arts grad asked the tech student at McDonald's? "want fries with that?")
<tjaalton> pwnguin: sounds good
<pwnguin> well, there's actually a lot of help wanted posters
<pwnguin> presumably because they're a community college rather than a university, and are cheaper
<bryce> congrats pwnguin
<bryce> pwnguin: make sure to pimp inkscape ;-)
<pwnguin> heh
<pwnguin> illustrator isn't very popular
#ubuntu-x 2008-08-15
<bdmurray> "I can't help you anymore because my other laptop burned down"
<bdmurray> bryce: https://launchpad.net/~brian-murray/+karma
<bdmurray> look at the closeness of actions :)
<bryce> bdmurray: heh, mega karma coming soon
<bdmurray> nah, not for that
<bdmurray> So I've New, Incomplete and Confirmed just Triaged left
<bdmurray>     ^ done
<bryce> cool
<pwnguin> well triaged is the hard one, no?
<bryce> lol  http://img182.imageshack.us/img182/9371/georgiale1.jpg
<tjaalton> hah :)
<tjaalton> hmm, fedora has added EXA changes from master to 1.5
<tjaalton> includes the glyph cache stuff
<tjaalton> heck, I'll try it out
<mvo> tjaalton: so, I have a input driver with emulate-wheel support now, how can I make sure it is enabled? I added it to xorg.conf but it seems to get ignored (or worse, configured after the initial configuration and then it can not get the device grab anymore)
<tjaalton> mvo: evdev upstream has support for it, I can backport that
<mvo> tjaalton: I did a backport (well a git snapshot) already
<mvo> tjaalton: I'm just wondering how to activate it now :)
<mvo> tjaalton: oh, I think I have it, so I need to figure out which /dev/input/eventX is my trackpoint and just use that?
<mvo> yeah, that worked 
 * mvo dances with joy
<tjaalton> you could make an fdi file for it and drop it in /etc/hal/fdi/policy
<mvo> now I just wonder if the inputX number is stable accross reboots
<mvo> oh, that sounds even better
<mvo> were can I find a example?
<tjaalton> you can for instance match info.product of the device, and <merge key="input.x11_driver.OptionName" type="string">foo</merge>
<tjaalton> then that should add that option for the driver
 * mvo nods
<mvo> I will try that
<mvo> uploading a git snapshot of the evdev driver is probably too risky, right? so I should do a proper backport of the mousewheel stuff
<tjaalton> mvo: yes, there was a commit that made ctrl-c close the server, but it's reverted now :)
<tjaalton> mvo: also, I should backport the properties stuff, so I can do both
<mvo> tjaalton: will it be possible with the properties stuff to set the mouse-wheel emulation at runtime? or what is it good for?
<tjaalton> mvo: exactly
<tjaalton> and synaptics support is on the way too
<mvo> is there something that already uses it?
<tjaalton> no, it's pretty fresh stuff
 * mvo nods
<tjaalton> evdev master supports it for the wheel and middlebutton emulation
<tjaalton> also, you can disable devices with it
<mvo> cool
<mvo> I will play with it after lunch
<tjaalton> heh, it needs support in the server, libXi and xinput
<tjaalton> I've got it running, but it needs cleanup
<Q-FUNK> bug #255991 is pending sponsoring to debian/unstable.  once that's done, a sync to intrepid should do it.
<ubottu> Launchpad bug 255991 in xserver-xorg-video-geode "xf86-video-geode:  DDC probing broken on GX2/CS5535 since 2.9.0 (patch)" [Undecided,New] https://launchpad.net/bugs/255991
<Q-FUNK> hardy-proposed might require some hand-picking to apply the same fix.
<mvo> tjaalton: is it <merge key="input.x11_driver.EmulateWheel" type="bool">true</merge> that then will get picked up?
<tjaalton> mvo: might be.. does it work?
<mvo> tjaalton: no :) this is why I was asking
<tjaalton> mvo: try "string"
<mvo> shows up just fine in lshal
<tjaalton> oh
 * mvo nods
<tjaalton> hmm
<tjaalton> well, try anyway:)
<jcristau> all properties need to be strings in hal
<mvo> aha, thanks jcristau
<Q-FUNK> jcristau: could you please sponsor the upload to unstable?
<mvo> hm, no luck with the fdi file
<tjaalton> mvo: does the logfile reveal anything?
<mvo> tjaalton: no, unfortunately not, I suspect I set the wrong values, input.x11_driver.OptionName does not match what the keyboard uses (input.xkb.OptionName), but I couldn't find out about it from just peeking over the source
<jcristau> input.x11_options.<stuff>
<jcristau> see config/hal.c in the server
<tjaalton> oh right :)
<mvo> jcristau: oh, that sounds like the right one
<tjaalton> my bad
 * mvo restarts X to test the changes
<mvo> I'm a happy man again, thanks jcristau and tjaalton for your help, mouse wheel emulation is working again for me :) I can't life without that :)
<tjaalton> mvo: heh, good to hear
<tjaalton> yeah, wacom hotplug works.. input.x11_options.Type has to be set in the fdi file or the driver wont initialize
<tjaalton> now my cheap aiptek works OOTB
<tjaalton> updated wacom-tools uploaded
<tjaalton> also a new version
<tjaalton> hmm, unplugging the tablet crashes the server :)
<jcristau> tjaalton: heh
<tjaalton> so wacom still isn't hotplug-friendly
<jcristau> shouldn't be too hard though?
<tjaalton> probably not, I could get a proper backtrace
<bdmurray> bryce: what should happen with bug 188792 now?  Set it back to triaged and leave the back the same?
<ubottu> Launchpad bug 188792 in xserver-xorg-video-ati "Incorrect default resolution with Radeon9200SE and CRT over VGA" [Undecided,Incomplete] https://launchpad.net/bugs/188792
<bryce> looking
<bryce> bdmurray: yes, but we also will need an Xorg.0.log on that one
<bryce> I've updated
<bdmurray> bryce: bug 210414 has only commenter and they've replaced their video card should so can't test is it safe to close?
<ubottu> Launchpad bug 210414 in xserver-xorg-video-ati "Extremely slow graphics at rotated 1400x1050 without EXA" [Undecided,Incomplete] https://launchpad.net/bugs/210414
<bryce> bdmurray: yup
<jcristau> that title sounds like an 'it hurts when i put a knife in my arm' kind of bug
<bryce> tjaalton: any problem if I merge debian's current xorg?  I've got that apport stuff to deploy
<bryce> (still doesn't work right, but seems to be an issue in xserver, not xorg)
<tjaalton> bryce: there's 7.4~1ubuntu1 waiting to be uploaded?
<bryce> yep
<bryce> committed to git too
<tjaalton> I've somehow missed the memo ;)
<tjaalton> not even in the spam folder
<tjaalton> but yes, looks good
<bryce> ok, uploading
<bryce> so this change will let people report bugs via 'apport-cli -f -p xorg'
<bryce> and 'apport-cli -f -p xserver-xorg-video-intel' et al
<bryce> which will nicely attach all the files we like to get, easy peasy
<tjaalton> I actually thought about a similar approach yesterday, since I was asked to attach all kinds of things to debug an acpi issue
<bryce> also >in theory< it should also collect these files on X crashes, but this part doesn't work yet - the xserver seems to be trapping SEGV signals pretty thoroughly.  So I still need to sort that out.
<bryce> there's also a gui tool for the bug reporting, though I don't remember the command
<tjaalton> that the triager should only ask to run one command which then would attach the needed files in the bug. and this is basically it
<bryce> yep
<bryce> lp #258375 is an example of what we get
<ubottu> Launchpad bug 258375 in xorg "testing xorg apport - this bug can be closed" [Undecided,New] https://launchpad.net/bugs/258375
<tjaalton> yeah I saw, neat
<bryce> it's pretty easy to add/change what's included.  let me know
<bryce> also, we can have different things attached for different packages, but for now for simplicity I've just make them all identical
<bryce> I like that it does all the attachments in one comment, rather than each one an individual comment.
<tjaalton> indeed
<tjaalton> log.old maybe
<bryce> ok
<tjaalton> for xkeyboard-config bugs 
<tjaalton> uh
<jcristau> bryce: if you start X with -core, it'll abort() instead of exit() in AbortServer(), so maybe that would do what you want?
<tjaalton> .. setxkbmap -print and xkbcomp :0 -
<bryce> added
<tjaalton> thanks
<bryce> committed but not uploaded; will go in next time xorg is uploaded
<tjaalton> yep, that's fine
<tjaalton> sigh, xkb-data is a mess
<bryce> jcristau: thanks I'll give that a try directly
<jcristau> tjaalton: i touched it for the first time a few days ago, and... yeah, it is
<jcristau> tjaalton: unfortunately not the right time to clean it up here, with the freeze and all
<tjaalton> jcristau: just trying to find out why evdev breaks ABNT (missing keys) :/
<tjaalton> packaging aside ;)
<jcristau> ah. yeah. it's a mess in more than one way
<jcristau> :)
<tjaalton> hum, I think we can close all the "error activating XKB configuration" bugs now
<tjaalton> heh, right
<bryce> jcristau: nope
<jcristau> ok :/ dunno how apport's supposed to work, so..
<tjaalton> forwarded 255372 upstream
<tjaalton> bug 255372
<ubottu> Launchpad bug 255372 in xkeyboard-config "[evdev] ABNT2 missing keys" [High,Triaged] https://launchpad.net/bugs/255372
#ubuntu-x 2008-08-16
<bryce> signal handler and my patch.  http://pastebin.ubuntu.com/37830/
<jcristau> tjaalton: hrm. symbols/inet(evdev) redefines AB11 as XF86Launch4. symbols/br(abnt2) defines it as [     slash,   question,       degree, questiondown ]
<jcristau> tjaalton: i guess that's the point where you lose.
<tjaalton> jcristau: hmm interesting
<jcristau> tjaalton: setxkbmap br -print | xkbcomp -xkb - -
<jcristau> and then enjoy :)
<jcristau> (it worries me that i can sort of make sense of what xkbcomp spits out)
<tjaalton> don't tell svu :)
<jcristau> anyway it's pretty clear that's what happens here. we get [ XF86Launch4, question, degree, questiondown ].
<tjaalton> not only that, but the keycode for that is 211, and not 97 (which has Romaji)
<jcristau> oh. hum.
<tjaalton> hmm.. addint -model abnt2 to that command shows that 97 should have Home, and AB11 has 211
<tjaalton> *adding
<tjaalton> heh, fjp asking for 10-synaptics.fdi :)
<jcristau> that might just be evdev keycodes being different
<jcristau> tjaalton: have a link to your synaptics.fdi somewhere?
<tjaalton> jcristau: it's currently identical to the one in fedora: http://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/xorg-x11-drv-synaptics/devel/10-synaptics.fdi?rev=1.1
<tjaalton> it lacks support for mac trackpads
<jcristau> ok
<tjaalton> would be enough to have someone with a macbook run 'lshal'
<tjaalton> alex-weej: hey, you asked for some synaptics options to be turned on by default? please reply to the bug, we need you :)
<alex-weej> tjaalton: er
<alex-weej> i did!
<alex-weej> at least, i did via email
<alex-weej> maybe it didn't get through
 * alex-weej checks
<tjaalton> alex-weej: yep, it's there.. didn't get the mail :)
<tjaalton> damn mimetypes
<alex-weej> hm lol yeah
<alex-weej> mimetype fail
<alex-weej> fixed :)
<tjaalton> info.product = 'appletouch'
<tjaalton> that should do it
<alex-weej> ah, it's not actually synaptics...
<alex-weej> just speaks the same protocol to the X11 driver
<tjaalton> right
<alex-weej> learn something new every day
<tjaalton> a sec
<tjaalton> what is the option name?
<tjaalton> VertTwoFingerScroll & HorizTwoFingerScroll?
<alex-weej> um, will check
<alex-weej> i think the *default* configuration (i.e. nothing in Xorg config) reserves a huge chunk of the right and bottom edges for scrolling
<alex-weej> that should really be disabled for this
<alex-weej> let me read my config
<alex-weej>     Option         "HorizEdgeScroll" "0"
<alex-weej>     Option         "VertEdgeScroll" "0"
<alex-weej>     Option         "VertTwoFingerScroll" "1"
<alex-weej>     Option         "HorizTwoFingerScroll" "1"
<tjaalton> k, try this out: http://users.tkk.fi/~tjaalton/dpkg/10-synaptics.fdi
<tjaalton> put it in /etc/hal/fdi/policy
<tjaalton> restart hal & X
<tjaalton> and comment out the stuff from xorg.conf
<alex-weej> oh yay
<alex-weej> i didn't realise you could already specify X options with HAL
<tjaalton> neither did I, before last week
<alex-weej> BRB then
<alex-weej> tjaalton: fail :<
<alex-weej> i don't see the keys via HAL Device Manager
<tjaalton> yes, one </match> missing :)
<alex-weej> xml fail
<tjaalton> try now
<jcristau> xml is fail in itself, don't try to add more to it
<alex-weej> lol
<alex-weej> shhh
<alex-weej> ok it's merged in now
<alex-weej> let's see if X picks it up
<alex-weej> tjaalton: nope :<
<alex-weej> X doesn't seem to want to pick it up
<tjaalton> you are on intrepid?
<tjaalton> logfile or didn't happen
<alex-weej> hehe
<alex-weej> yes i am
<alex-weej> let's see
<alex-weej> tjaalton: ok i see a problem
<alex-weej> during X startup it claims to detect my touch pad like 3 times... (checks)
<alex-weej> first of all it sets up based on my xorg.conf
<alex-weej> (II) config/hal: Adding input device appletouch
<tjaalton> comment those out
<alex-weej> then it has the right things like (**) Option "VertTwoFingerScroll" "1"
<alex-weej> but then it says (WW) appletouch can't grab event device, errno=16
<tjaalton> because it's already taken
<alex-weej> tjaalton: nuke my xorg.conf ?
<tjaalton> full log please, after you've cleaned up your xorg.conf :)
<tjaalton> move it aside
<alex-weej> tjaalton: it's clear that these HAL settings only apply to devices that have been added as part of the HAL sniffing
<tjaalton> right
<alex-weej> which i guess is fine, as long as people stop using xorg.conf to configure stuff
<tjaalton> sun is rising.. ;)
<alex-weej> i'm gonna try it and see what the default settings are like these days
<alex-weej> ok cya :P
<tjaalton> not really rising yet, but got some action by saying that
<tjaalton> harhar
<tjaalton> sure takes a long time to run 'mv xorg.conf xorg.conf.old; gdm restart'
<jcristau> hrm svu closed the bug
<tjaalton> sigh
<tjaalton> I'll reopen
<tjaalton> seems like alex broke his X, but I can't stay up a minute longer.. night!
<bryce> night timo
#ubuntu-x 2009-08-10
<AnAnt> Hello, is Intel X45000HD graphics  chip supported by Ubuntu (wether jaunty or karmic) ?
<diverse_izzue> hey guys. i'm testing the radeon KMS code. other than resuming from standby being broken, the biggest issue for me is performance. DRI performance is 2-4-fold reduced for me, depending on the situation, compiz feels sluggish at times. what does upstream say about that - do they think they will be able to speed that up somewhat in time for release?
<diverse_izzue> also, scrolling in GTK apps for example is much slower than with the non-KMS code.
<jcristau> they'll probably have things working in f12
<diverse_izzue> that's sort of the same timeframe as karmic, right?
<tjaalton> a bit later
<tjaalton> and they'll likely use a newer kernel
<tjaalton> tseliot: I haven't, no hw for that
<tseliot> tjaalton: ok, no problem. I was wondering if we could use nouveau to replace nvidia-glx-71 (which should be removed from karmic)
<tjaalton> tseliot: ok, why should it be removed?
<tseliot> tjaalton: because Nvidia didn't (and won't) add the support for xserver 1.6.x to that driver
<tjaalton> ah, so it still hasn't.. ok
<tjaalton> supporting nouveau like that would imo mean shipping the drm driver with the kernel
<tseliot> ah so we don't do that
<tjaalton> which should be doable, just a bit of work to make sure there are no collisions
<tjaalton> nope
<RAOF> Although we'd need to pull in a newer drm.ko & ttm.ko.
<tseliot> can't that be done with dkms instead?
<tjaalton> there's nouveau-kernel-source for that
<RAOF> That's what's currently done.
<tseliot> and what's the problem with using the current approach then?
<tjaalton> it should be moved to main
 * tseliot is just trying to understand
<tjaalton> I guess
<tseliot> ok, do we still default to "nv" for nvidia?
<tjaalton> yes
<tseliot> and does nouveau have 3D acceleration? (the version in Karmic)
<tjaalton> no
<tjaalton> needs some crackhead branch for mesa
<tseliot> ok, then we should keep using "nv". Update manager will switch to "nv" with nvidia-common
<tjaalton> yes
<tseliot> good
<RAOF> Upstream would be extremely unhappy with us if we shipped nouveau's 3D component.
<tjaalton> yes, it's totally unsupported
<RAOF> But we might want to use nouveau over nv, given that it's got 2d acceleration (and kms).
<RAOF> Problem is, I've got no hardware that's only supported by -71, so I don't know nouveau's status on that hardware.
<RAOF> Nouveau will be a bit more fragile than nv, too, since it recently regained a hard-dependency on the kernel module.
<tjaalton> I should probably try nouveau again
<RAOF> The edgers ppa version supports kms on everything I've got access to (and works nicely).
<Ng> --help
<EagleScreen> can i disable UXA in karmic?
<hyperair> no, i don't think you can
<hyperair> why would you want to anyway?
<EagleScreen> because UXA kill/hangs kdm on logout
<jcristau> you can configure kdm to not do that
<EagleScreen> what? configure kdm to not crash X server?
<jcristau> yes
<EagleScreen> what are you talking about?
<jcristau> specifically, to terminate the server and using a new one, instead of reusing the same
<EagleScreen> i think it is done by default now..
<jcristau> therefore avoiding the intel bug where it crashes when you init a second session
<EagleScreen> any tip to do that configuration?
<jcristau> there was something on the fdo bug
<EagleScreen> fdo bug?
<EagleScreen> which bug?
<EagleScreen> i only know Bug #371500
<ubottu> Launchpad bug 371500 in xserver-xorg-video-intel "[i965gm] X server crash at closing session if kdm is in use. [UXA bug]" [Medium,Confirmed] https://launchpad.net/bugs/371500
<jcristau> 20516 iirc
<jcristau> shouldn't be too hard to find..
<EagleScreen> sorry by my ingnorance, but, what does "20516 iirc" mean?
<EagleScreen> i cannot find that option in kdmrc
<micahg> is anyone here using the xorg crack on Jaunty?
<Duke`> xorg crack?
<micahg> https://edge.launchpad.net/~xorg-edgers/+archive/ppa
<micahg> would the xorg crack drivers fix this problem: http://pastebin.ubuntu.com/250969/
<micahg> I'm running the ubuntu-x-swat intel 2.7 driver
<micahg> ping bryce ^^^^
<tjaalton> maybe, if you get a new kernel too
<micahg> yeah, well that ppa comes with 
<micahg> 2.6.30
<bryce> micahg, dunno not an error I've seen before
<micahg> ah, ok
<micahg> well, has anyone actually used the xorg-edgers stuff for a while?
<micahg> xorg-video-intel 2.7 got my dual screens working, but it started crashing
<tjaalton> karmic is more sensible :)
<micahg> I'm wondering if 2.8 wiil fix it
<micahg> I can't go to karmic as this is my prod laptop
<tjaalton> well the errors are from the kernel
<micahg> ah
<micahg> I thought they were from the graphics driver module though
<tjaalton> just try getting the kernel and nothing else
<jcristau> tjaalton: do you guys have 865 issues in karmic?  bgoglin says X hangs on startup..
<micahg> tjaalton: kernel from where?
<micahg> xorg-edgers?
<tjaalton> micahg: yes
<micahg> ok
<tjaalton> jcristau: I haven't triaged -intel for a while, but I remember someone on the forums saying that 8xx have issues with kms and disabling it worked around the problem
<jcristau> k
<tjaalton> s/for/in/
<micahg> tjaalton: it seems to have worked
<micahg> xscreensaver no longer crashes my box
<micahg> the kernel worked
<bryce> jcristau, yes I sent a slew of 8xx bugs upstream over the past few weeks
<bryce> jcristau, I speculate some quirks didn't get copied into the kernel, but most of the issues I sent were existing issues from pre-KMS
#ubuntu-x 2009-08-11
<diverse_izzue> hello. i disabled desktop effects under karmic, and now i cannot re-enable them, even though they worked properly before. is there a way of doing it manually?
<seb128> compiz --replace
<diverse_izzue> seb128, thanks. but that will probably not change the setting in the appearance capplet and thus have to be done every time i log in?
<seb128> you can change /desktop/gnome/session/required_components in gconf-editor
<diverse_izzue> windowmanager->compiz?
<seb128> yes
<diverse_izzue> thanks
<tseliot> bryce: did you receive my email?
<bryce> tseliot, yes
<bryce> tseliot, sorry, yesterday was busy being first day back
<tseliot> bryce: np, I just wanted to be sure
<maco> im using an intel 965 on kubuntu karmic. up until my wireless driver decided that *it* wanted 101% CPU (grrr), Xorg was using 98% CPU, though now its using 58% CPU (wireless driver + kmail wanting 40% CPU whittled it down)
<maco> i do NOT have any compositing stuff turned on
<maco> like, im not using compiz or kwin+composite.... just xmonad.  have any of you heard of X going bonkers on CPU without compositing?
#ubuntu-x 2009-08-12
<hyperair> maco: i don't think that the wireless driver is related to the gpu driver.
<hyperair> maco: rather, i've noticed your issue on the .31 kernels, specifically whenever the system begins running out of memory, or during periods of very high I/O activity
<maco> oh i dont think the drivers are touching each other, just that X was going nuts until the wireless wanted so much CPU that they couldnt both have what they wanted
<hyperair> O_o?
<maco> well they both wanted to use 100% of CPU and kmail wanted 40%
<maco> with a dual core, they can only get 200%
<hyperair> kmail is an x client.
<hyperair> but seriously, this isn't within ubuntu-x's field
<hyperair> you should be complaining to the kde people
<hyperair> ubuntu-x only handles X itself, and its drivers.
<maco> *sigh* but the Xorg process was using 100% and then 58% later
<maco> i already talked to rtg about the wireless thing, im just concerned about why Xorg is using my entire CPU when there's not even compositing happening
<hyperair> O_o sounds like you seriously got your system screwed up
<maco> i just installed it like 3 weeks ago
<hyperair> but there are X clients that can cause Xorg's CPU usage to rise dramatically
<maco> but kmail and Xorg are listed separately in top
<hyperair> yes they are
<hyperair> they are different processes
<maco> and Xorg was using quite a lot more than kmail was
<hyperair> but kmail is an X client
 * hyperair facepalm
<hyperair> will you listen?
<hyperair> quit kmail and see
<maco> but kmail doesnt count into it!
<hyperair> for all you know, kmail's causing X's CPU usage to rise
<maco> it is not
<hyperair> X clients *communicate* with the X server.
<maco> xorg's usage has gone down since then
<maco> Xorg process is down to 4% now (yay)  and kmail is still 31%
<hyperair> well next time identify the faulty X client
<maco> so Xorg's CPU usage in top isnt just adding up all the X clients' usage %s 
<maco> im running all the same things i was runnign before
<hyperair> ...you seriously aren't listening.
<hyperair> Xorg is a *server*. Kmail and other applications are X *clients*
<hyperair> when a client bombards a server with requests, what happens?
<hyperair> the server takes more CPU.
<hyperair> it's as simple as that.
<hyperair> they are separate processes!
<hyperair> hell they could even be on different computers!
<maco> so how do i find out which client is sending all those requests?
<maco> the same apps have been running the entire time.
<hyperair> dunno. quit the highest cpu using client and see
<hyperair> could be a buggy client that suddenly screwed up
<maco> if an application is on a different workspace, does it still talk to X? it doesnt need to be drawn...
<hyperair> yes, it does.
<maco> so if a terminal has an ssh session and that session is compiling stuff, X still would be requested to render all that compiler-spew?
<maco> oh and the terminal is on a different workspace
<maco> a not-visible one
<hyperair> it would probably be telling X that there are updates
<hyperair> but i don't think it would be rendered until it's unobscured
<maco> hmm so could that be why my cpu usage goes up when im remote compiling?
<hyperair> well it might rise a little, but very little.
<hyperair> you should probably just test quitting the clients one by one the next time it happens
<maco> ok
<bryce_> hyperair is right
<maco> im sorry i got confused before. the server & client separation didnt occur to me. i thought it was a parent/child process thing he was talking aout
<bryce_> maco, xrestop can also give some clues about what apps might be using X, but it looks only at resource memory usage so isn't a perfect indicator
<maco> how many *top apps are there?
<maco> [h]top, powertop, and iotop were the ones i knew
<bryce_> there's like a dozen
<bryce_> htop, vtop, ptop, itop, atop, mtop, ntop, top, xrestop... probably lots more.  'stop' ;-)
<bryce_> maco, anyway, it's a common point of confusion, and I've documented it at http://wiki.ubuntu.com/X/Troubleshooting/
<maco> ok
<maco> thanksguys
<bryce_> Sarvatt, if you're interested in scoring some merges for your motu app, I've marked some packages currently needing merged:  http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html
<ScottK> bryce_: Give away the hard ones....
<bryce_> ScottK, I don't want to scare him off!  ;-)
<Starks> bryce, what do you think of this? http://ubuntuforums.org/showpost.php?p=7773647&postcount=13
<Starks> would the license allow this?
<tseliot> Starks: the patch acts upon the open part of the driver therefore I don't that patch is a problem
<Starks> can karmic ship with it?
<tseliot> poulsbo was only made available in a PPA
<tseliot> Ubuntu doesn't have poulsbo in its repositories
<tseliot> as poulsbo uses an old version of libdrm
<tseliot> a PPA would be the right place for that
<ScottK> tseliot: PPA is only allowed for free software.
<Starks> ppa doesn't allow binary blobs?
<Starks> since when?
<tseliot> ScottK: I know that nvidia is also made available in PPAs and there's this PPA with psb too: https://launchpad.net/~ubuntu-mobile/+archive/ppa
<ScottK> tseliot: Read the PPA terms of service.
<jcristau> maybe canonical gets an exception
<ScottK> It probably does as there are commercial exceptions to the TOS.
<tseliot> it could be
<Starks> does a driver have to be sanctioned in order to be included?
<Starks> also, even if intel and powervr had up to date psb drivers, would they be included by default?
<Starks> or would it be restricted?
<tseliot> restricted
<tseliot> not that it's so simple
<Starks> poulsbo's successor is likely to be another powervr-created monster.
<jcristau> sigh.  they didn't learn anything from the psb fiasco?
<Starks> dunno.
<Starks> it was a decent chip spec-wise
<Starks> drivers were shit though.
<Starks> windows was no exception.
#ubuntu-x 2009-08-13
<ScottK> tseliot: Any thoughts about making the height of the dead zone at the bottom of the mini 10v touchpad configurable?  I either need it taller or to get smaller fingers.
<tseliot> ScottK: you can set set the bottom to a lower value
<tseliot> ScottK: xinput set-int-prop "SynPS/2 Synaptics TouchPad" "Synaptics Area" 32 0 0 0 4000 and replace 4000 with a lower value
<ScottK> tseliot: Thanks.
<tseliot> np
<superm1> ScottK, once you find a good default value, maybe it would be good to submit a quirk to set it as the default when that model touchpad is detected?
<ScottK> superm1: I think it's per user in terms of what works best.  Different sizes of fingers, touchpad styles, etc.
<ScottK> What we have now is not a bad default.
<superm1> i haven't done a fresh install on a 10v with karmic in a few weeks so i've not seen lately
<xerosis> I'm experiencing corrupted VTs in Karmic on Intel, I presume this has already been reported but I can't seem to find a bug report, does anyone know if it had been reported?
#ubuntu-x 2009-08-14
<bryce> xerosis, even if it has been reported, it's usually better that you file another report
<bryce> xerosis, anyway it doesn't strike a bell with me; so it probably hasn't been reported
<bryce> xerosis, 'ubuntu-bug xorg' and attach a photo of the screen
<bryce> actually it's probably a linux bug, not xorg.
<xerosis> bryce: thanks, I'll do that
<pwnguin> should i be surprised that uinput can be used to crash X?
<pwnguin> a friend is reporting wminput can crash X reliably
<pwnguin> not sure whether to blame wminput for acting funny, or X for crashing because of it
<pwnguin> crazy thing is, i cant duplicate i
<pwnguin> t
<bryce> pwnguin, collect a full backtrace, file a bug.  X should not be crashable by any client app
<Ng> [09:30] < hughsie> if anyone was wondering about how to fix gnome-power-manager blanking the screen when  the session is not idle, then I've posted a fix here:  http://blogs.gnome.org/hughsie/2009/08/14/blanking-in-gnome-power-manager-fixed/
<Ng> I believe karmic people are seeing this. I certainly am ;)
<diverse_izzue> Ng, awesome, many people on Karmic see this!
<tseliot> it's definitely worth backporting
<bryce> yeah on my todo list
<bryce> would have done it yesterday but we were frozen; didn't do it today just because I got distracted by other matters.
<seb128> so it was an xorg bug ;-)
<Ng> \o/
<tjaalton> the random blanking didn't matter too much, but if it allows the display to sleep when it should, then I'm happy :)
<seb128> right, it's rather disturbing that a real issue
<seb128> at least it doesn't break anything
<tjaalton> sounds like it's not the same issu
<tjaalton> +e
<tjaalton> in karmic my display(s) never blank or go to sleep when they should
<bryce> seb128, shut it
<tjaalton> :)
<seb128> what?
<bryce> actually, the patch Ng points to is different from the one I was looking at that someone else pointed to
<seb128> was that I request for me to stop writing there?
<bryce> seb128, ah, yeah that'd do ;-) ;-)
<Ng> tjaalton: random blanking seems to also include random suspending, which is really quite annoying :)
 * seb128 confused
<bryce> actually I never was sure whether this was an xorg bug or not; I'd upstreamed it to -ati but they claimed it was a ubuntu problem, so they were wrong
<bryce> Ng, wonder how many bugs this'll close
<Ng> yeah, could be interesting
<hyperair> random suspending?
<tjaalton> seb left :P
<hyperair> i haven't noticed that one. though random blanking does happen
<Ng> hyperair: I would assume that if idle timeouts are confused all kinds of random idle-related power events could happen
<hyperair> Ng: i suppose. that would suck, though
<Ng> hyperair: I get quite angry when it happens ;)
<Ng> then I remind myself that I'm running a development release, and look at something shiny that I didn't have in jaunty, and smile again ;)
<hyperair> Ng: haha. i don't get angry if errors are easily recoverable.
<hyperair> Ng: like i don't get annoyed over compiz refusing to redraw when i return from hibernation/suspension
<Ng> hyperair: I'm usually working when it happens, and all my work is over ssh ;)
<hyperair> Ng: what i do get annoyed about is stuff like the GEM memory leak. but that's in the past
<Ng> hyperair: (but I know I can't blame anyone for a development distro breaking my work, and I have no desire to)
<hyperair> hahah
 * hyperair began running karmic because jaunty was very annoying with the whole intel mess
 * hyperair brb new kernel
<tjaalton> I don't understand why icons were removed from gtk menus
<tjaalton> quite useful for the firefox bookmark-menu for instance..
<tjaalton> _that_ makes me upset, not some random crash :)
<seb128> tjaalton, the bookmarks not having icons is a firefox bug
<tjaalton> seb128: ok, good to hear :)
<seb128> they is a property to set to always have an icon
<seb128> objects should set this one
<seb128> ie drives, bookmarks, files, directories, etc
<tjaalton> hmm, I see icons on my laptop again
<seb128> you can also turn icons back using a gconf key
<tjaalton> maybe it's ff 3.5
<seb128> the rational was that icons were overused
<tjaalton> sure
<tjaalton> there are places where I got so used to them that they help me navigate to the correct entry
<tjaalton> it's faster to recognize the icon than to read the text :)
<seb128> right same here
<seb128> bug #407621
<tjaalton> but I'll wait and see what comes next
<ubottu> Launchpad bug 407621 in libgnome "(design decision) Icons missing from context menu , dialogue buttons , firefox bookmark favicons" [Wishlist,New] https://launchpad.net/bugs/407621
<seb128> comment there
<tjaalton> thanks, I'll subscribe for now
<Ng> I hope the always_show icon property will lead to smarter use of icons, and not just flood them back by people setting it everywhere ;)
<Ng> I always thought the stock icons were a good idea though
<Ng> it strongly hints that something is going to do what you expect
<seb128> right, it reboot in fusa is clear
<seb128> the no icon force you to read text
#ubuntu-x 2009-08-16
<ziroday> Hi, I seem to have an odd bug upon when starting X the system freezes with a distorted image of either the BIOS or Usplash screen. The card is an Radeon 3410 and this happened after install fglrx through jockey. How would I go about diagnosing it?
<ziroday> hmm removing xorg-driver-fglrx fixes the issue, but I still have no accelerated 3D.
<hyperair> well hello there ziroday =D
<bryce_> ziroday, see http://wiki.ubuntu.com/X/Troubleshooting
#ubuntu-x 2010-08-16
<Sarvatt> knittl: probaby fallout from nvidia-96,173 and fglrx having been forcibly removed from jockey for now because they dont work
<RAOF> Good morning.
<RAOF> asac: Good gallium for 965, for Maverick?  No.
<RAOF> Even though you're not here.
<Sarvatt> probably not maverick+1 either
<RAOF> Not unless someone wants to devote some resources to it.
<RAOF> Gah.  Stupid UTC+10
<RAOF> You wake up just as the people looking into the bug you're after go to sleep
<ajmitch> RAOF: yay for mondays? :)
<RAOF> Eh.
 * RAOF is disappointed that Adobe's DNG converter doesn't process the lens distortion data into it's nice, documented format.
<knittl> morning. how do i find out which graphics driver is currently in use?
<RAOF>  /var/log/Xorg.0.log will tell you what drivers have loaded, and which one(s) are in use
<knittl> thanks RAOF 
<knittl> in maverick i get an error/warning message on boot
<knittl> conflicting fb hw, disabling generic driver
<knittl> something like that. is that ok?
<RAOF> That's not a warning, and it's expected.
<knittl> Aug 16 09:52:18 kbook kernel: [   16.914621] fb: conflicting fb hw usage nouveaufb vs VESA VGA - removing generic driver
<knittl> ok :)
<RAOF> C'mon.  Fix the server crash, fix the server crash!
<knittl> does standby work for you?
<RAOF> Yes.
<RAOF> Even on my nouveau laptop.
<RAOF> Urgh.  It won't fix the server crash until it compiles!
<czajkowski> RAOF: are you about ?
<czajkowski> RAOF: just wondering if you could possibly look into/comment on https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/605041
<ubot4`> Launchpad bug 605041 in xorg-server (Ubuntu) "High usage of the cpu - up to 100% (affects: 1) (heat: 8)" [Undecided,Confirmed]
<gord> these nvidia 2d performance regressions on anyones radar? was only happening to me a few weeks ago but noticed a few others coming forward too. i know its kinda hard with binary drivers =\
<tseliot> gord: ??
<tseliot> gord: if you file a bug report about it, I'll tell Nvidia about it
<gord> tseliot, ever since around the end of last month, nvidia binary drivers have been suffering some huge 2d performance issues. 3d works fine, but just drawing a gtk window or switching tabs or anything is painful. makes xorg cpu usage go crazy. its hard to define though and doesn't seem to affect everyone
<gord> tseliot, will do
<tseliot> ok, thanks
<RAOF> gord: I thought that was fixed with the new cairo upload?
<RAOF> It certainly fixed it for the nouveau drivers :)
 * RAOF goes back to sleep
<czajkowski> :(
<Sarvatt> http://www.nvnews.net/vbulletin/forumdisplay.php?f=14 is the support forum for nvidia where the people who can actually fix the blob post in case it helps
<Sarvatt> just looking through the first few pages it seems like 2D has regressed a ton on the GPU's that can't do trapezoid acceleration on 256.xx
<Sarvatt> aka i dont see anyone on a gt200 or newer (or ion) complaining about 2D performance. the new cairo disabled server side gradients unconditionally and that was something the blob accelerated, I wouldn't be surprised if that caused even more of a performance hit and that was uploaded aug. 4th
<tseliot> aah, so it's the issue with cairo. Now it makes sense
<gord> Sarvatt, my desktop at home has a gtx260 that has 2d performance issues
<Milos_SD> Hi
<Milos_SD> Sarvatt, 
<gord> its just that it has a quad core i7, so you don't notice it. its only when looking at top and seeing xorg go crazy you notice. i would assume a lot of other people on gt200's have good cpu's like that taking the brunt of the performance problems
<Sarvatt> gord: does nvidia-settings -a PixmapCacheRoundSizeKB=16000 help any?
<seb128> ideally the cairo changes would be on some drivers only
<seb128> if somebody want to work on that ;-)
<Milos_SD> I think there is a but with new libpixman package that was sent today
<seb128> if filter on known buggy drivers
<Milos_SD> notify-osd bubble is not showed as it should
<gord> Sarvatt, not on this machine (9600gtm), can't say about my desktop until i am home 
<Milos_SD> here is the screenshot: http://www.glowfoto.com/viewimage.php?img=16-060157L&rand=5836&t=jpg&m=08&y=2010&srv=img5
<Sarvatt> its really a problem with the blob hitting software fallbacks way too often not really cairo
<Milos_SD> is there a way to downgrade that package to previuse one?
<Sarvatt> Milos_SD: do you have it in /var/cache/apt/archives/ still?
<Milos_SD> no I don't :(
<Sarvatt> Milos_SD: amd64 or i386?
<Milos_SD> amd64
<Sarvatt> https://edge.launchpad.net/ubuntu/+source/pixman/0.18.2-1/+build/1741447
<Sarvatt> https://edge.launchpad.net/ubuntu/+source/pixman/0.18.2-1/+build/1741447/+files/libpixman-1-0_0.18.2-1_amd64.deb
<Sarvatt> Milos_SD: let me know if it works correctly again when you downgrade please
<Milos_SD> ok, but it was this version: libpixman-1-0 (0.19.1+git20100722.bf125fbb-0ubuntu0sarvatt~lucid) to 0.19.1+git20100815.8a5d1be1-0ubuntu0sarvatt~lucid
<Milos_SD> :D
<Sarvatt> oh you mean in xorg-edgers!
<Sarvatt> i just updated it in maverick too and thought you meant that :D
<Milos_SD> in xorg-edgers for lucid
<Milos_SD> :)
<Sarvatt> Milos_SD: http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/pool/main/p/pixman/
<Sarvatt> grab it quick because it only stores the latest 2 versions and i'm about to update it again so the 0722 will go away :)
<Milos_SD> Sarvatt, thanks
<Milos_SD> I'll try if it works
<Milos_SD> maybe the new version will work after you update it :)
<Milos_SD> Sarvatt, it works now
<Milos_SD> thanks :D
<Sarvatt> possibly, they stopped supporting alpha maps with alpha maps completely and then added some handling to it if it happens just after i updated it yesterday
<Sarvatt> its uploading now
<Milos_SD> yes, it happened after that update
<Milos_SD> :)
<Sarvatt> Milos_SD: what GPU do you have and what driver are you using btw? I can't reproduce it on intel
<Milos_SD> Sarvatt, Nvidia 7600 GT PCIe and 256.44 drivers
<Milos_SD> in that screenshot compiz is on
<Milos_SD> but if I use only metacity, that part of notify-osd is darker then other part of it
<Sarvatt> yay so more 2D brokenness with the blob? :)
<bjsnider> the 7k cards have significantly older hardware than 8k and newer
<Milos_SD> Sarvatt, but it worked ok before that update today/yesterday :)
<bjsnider> the blob is basically optimized for 8k and newer
<Sarvatt> yeah but it's not broken on nouveau or intel for me so it might have broken something they didn't expect that the blob uses I'm thinking
<czajkowski> RAOF: are you up ?
<jono> hi all
<jono> my X is seg-faulting - http://pastebin.com/gUmYb3Xv - I just wanted to check if this was a known issue
<jono> (in Maverick)
<jcristau> that's out of date maverick
<jcristau> is it reproducible with the latest version?
<jcristau> could be fixed by the patch in <yunk4nrtdoi.fsf@aiko.keithp.com> if so
<czajkowski> Just wondering if anyone could comment on bug https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/605041  someone was talking about it yesterday on identi.ca and looking for help 
<ubot4`> Launchpad bug 605041 in xorg-server (Ubuntu) "High usage of the cpu - up to 100% (affects: 1) (heat: 8)" [Undecided,Confirmed]
<jono> jcristau, I just did  dist-upgrade
<jcristau> your log says xorg-server 2:1.8.1.902-0ubuntu2
<jcristau> but, xorg-server | 2:1.8.99.905-1ubuntu2 |      maverick | source
<jono> jcristau, hmmm
<jono> how do I upgrade it?
<jono> jcristau, when was that published?
<jcristau> i have no idea
<jono> it is weird that I have an old package
<jono> jcristau, ok I managed to install it
<jono> it was in my apt cache but not installed
<jono> so I installed it and it still segfaults
<jcristau> time to try that patch then
#ubuntu-x 2010-08-17
<RAOF> czajkowski: Could you please run âapport-collect 605041â?  That bug doesn't have much information on it (such as your Xorg.0.log, your video hardware, etc).
<RAOF> czajkowski: Also, as X is a server, 100% cpu bugs are often misbehaving clients.
<RAOF> GAH!
<RAOF> Too clever for my own good.
 * RAOF loves it when my debugging printfs introduce segfaults.
<soreau> s/my/his
 * soreau hates it when people jump from third to first using /me
<RAOF> Eh.  Subject consistency is for the weak.
<RAOF> Woot!  Only one segfault to go.
 * Milos_SD-aWay is Away, Reason: ( Spavam ... ) | Since: ( Monday August 16 2010. 22:13:47 ) Xlack v2.1
 * Milos_SD-aWay is back ( Away 1 min 52 secs )
<era> bryceh, what is gevdev in relation to evdev?
<RAOF> era: It's evdev + a gesture-creation patch.
<era> oooh
<era> utouch?
<RAOF> It's basically a temporary, fairly small fork of evdev.
<RAOF> Yeah.  utouch.
<era> on a somewhat related matter, how do i install synaptic gestures?
<RAOF> I'm not sure what you mean - do you mean the two-finger scroll, three finger middle-click type things?
<RAOF> That should Just Workâ¢, although there seems to have been some problems with devices getting mis-identified.
<Sarvatt> darn, got my hopes up synaptics actually released the linux gesture suite to the public but nope!
<Sarvatt> maybe if i dig through the dell support site i can find it
<Sarvatt> darn, HP is the only OEM I can find shipping synaptics drivers with SGS enabled, no chance at getting a linux driver out of them :D
<tjaalton> RAOF: I already asked to run 'ubuntu-bug' (the same thing, right?) but it didn't collect anything, which is weird
<tjaalton> he's also using some custom kernel
<RAOF> tjaalton: Aah.  It might be due to the lack of a source package hook for xorg-server, referenced in xorg (1:7.5+6ubuntu3)'s changelog.
<knittl> hi. is nvidia-current currently abi-incompatible with xserver? :(
<knittl> Xorg.0.log tells me something about -ignoreabi to override, how can i do that? as of now, boot hangs after splash and my pc does nothing
<gord> knittl, add a section in your xorg.conf called "ServerFlags" then put Option "IgnoreABI" "true" inside that section
<knittl> gord: ok, i'll try. thanks
<knittl> gord: thanks a lot, it's booting again
<gord> knittl, np
<knittl> uh oh. i shouldn't use 3d applications though
<knittl> totally crashes xserver
<era> raof, why is two-finger scrolling blanked out? i have to use gconf to enable that setting.
<knittl> if i use nouveau, shouldn't that use software rendering?
<RAOF> It will, unless you've installed the experimental dri modules.
<knittl> i don't think so
<knittl> blender crashes xserver with nvidia driver
<knittl> i'll try recompiling blender
<RAOF> But that's not nouveau; that's the binary nvidia driver.
<knittl> RAOF: yes, i asked about nouveau, because i need a working blender :D
<knittl> and with nouveau it always told me that it cannot create glx-something
<RAOF> Well, you could either try nouveau software rendering again, or you could try nouveau with the dri modules, or you could pastebin a backtrace of your X crash.
<RAOF> era: That's a good question.
<knittl> where would that backtrace be? i started blender in a screen session, but there was no output
<RAOF> The backtrace would be in /var/log/Xorg.0.log.old, since it's the X server that's crashing, not blender.
<era> i ask because it works perfectly and was disabled either during the karmic cycle i thing
<era> *think
<tjaalton> RAOF: duh, would've thought that was already there..
<tjaalton> maybe even SRU'able to add it to lucid
<knittl> RAOF: http://paste2.org/p/953368 does that help?
<knittl> it's quite a short backtrace
<RAOF> era: I'd guess it's a bug in gnome-control-centre, which provides that capplet.  It looks to me like the X side is doing its thing.
<era> i'll give pics in a sec
<RAOF> No need; I can reproduce locally.
<era> ah
<era> gconftool-2 --set /desktop/gnome/peripherals/touchpad/scroll_method --type int "2"
<era> enables
<RAOF> And since that works, and it looks like the correct driver is being loaded, I'm calling it Not An X Bugâ¢.
<era> doesn't work anymore
<era> D:
<RAOF> Ah.
<era> worked a few weeks ago
<era> now the touchpad option is disabled, yet filled
<era> but now 2-finger scrolling
<era> *but no
 * RAOF wonders idly where his mouse pointer sprite has gone.
<RAOF> era: Could you please kindly pastebin your /var/log/Xorg.0.log?
<era> one sec
<era> http://pastebin.ubuntu.com/479264/
<RAOF> Hm.  Ok.
<RAOF> A couple of weeks ago, you say?
<RAOF> Could you check in Software CentreâHistory what got upgraded around then?
<knittl> RAOF: how can i try the experimental dri drivers?
<RAOF> knittl: Install the libgl1-mesa-dri-experimental package.
<knittl> RAOF: and purge nvdia* und rm xorg.conf?
<RAOF> Use the Hardware Drivers capplet; it'll do the required voodoo.
<era> raof, this is a rather new install. wouldn't be reflected in the history and driver bisecting will be a pain in the ass.
<era> it's either xinput or synaptic
<RAOF> Depending on how long ago it was it'll either be synaptic or Xserver 1.9
<RAOF> It's probably synaptic, indeed.
<knittl> RAOF: no, jockey does not work at all for me
<era> what's the best way to test aside from a daily?
<knittl> use on a productive system, era ;)
<era> i do. this is my primary laptop.
<era> :)
<knittl> haha, mine too
<RAOF> knittl: Right.  That's a particularly unuseful backtrace.  You might get better luck attaching gdb (requires a second system to work reasonably).
<RAOF> knittl: Jockey doesn't work at all?
<knittl> RAOF: maybe related to my problems: is nvidia-kernel-common required?
<knittl> RAOF: no, it installs the driver and then fails with Â»driver could not be installed, see logÂ«
<knittl> status of driver then switches from not installed to installed, but not in use
<knittl> i also don't mind fixing jockey :D
<knittl> sudo apt-get purge nvidia* jockey*
<knittl> let's reinstall all that stuff
<RAOF> Eh, give it a whirl.
<knittl> so, what do i need to install, which pulls all the dependencies? only jockey-gtk?
<LLStarks> raof, should i apport against synaptic?
<RAOF> LLStarks: Go for it.
<RAOF> knittl: jockey-gtk should do it, I think.
<knittl> RAOF: should i restart first? because right now nvidia is in use
<knittl> could cause conflicts?
<knittl> so. purge â reboot â install jockey-gtk â reboot â install nvidia via jockey
<RAOF> Yeah, give that a whirlygig
<knittl> hell yeah! brb :)
<LLStarks> raof, it was definitely working on june 24th.
<RAOF> That's rather a long time ago :)
<LLStarks> well, that's when i did this: http://ubuntuforums.org/showthread.php?p=9505892
<knittl> hehe, nouveau feels snappier than nvidia with ignoreabi=true
<knittl> now, install jockey and reboot again
<LLStarks> raof, this works though: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/476866/comments/5
<ubot4`> Launchpad bug 476866 in xserver-xorg-input-synaptics (Ubuntu) "two-finger scrolling does not work on Dell Studio 15 (1555) via gui config (affects: 12) (heat: 62)" [Undecided,New]
<knittl> but blender works with nouveau again. i can tell from the slowness it's using software rendering
<LLStarks> are you using gallium?
<knittl> me? i'm using nouveau
<LLStarks> or rather is it installed with nouveau
<RAOF> Ah.  gnome-control-center bug, probably.  The synaptics driver is clearly exposing the required interfaces, gnome-control-centre doesn't seem to be using them properly though.
<knittl> never heard of gallium
<knittl> The following NEW packages will be installed: jockey-common jockey-gtk nvidia-173-modaliases nvidia-96-modaliases nvidia-common nvidia-current-modaliases
<LLStarks> it's the 3d driver for nouveau
<LLStarks> libgl1-mesa-dri-experimental
<RAOF> knittl: Looks right.
<knittl> no, i don't use the experimental dri thingy
<knittl> $ apt-cache policy libgl1-mesa-dri-experimental
<knittl> libgl1-mesa-dri-experimental: Installed: (none)
<knittl> RAOF: ok, installing â rebooting :)
<knittl> LLStarks: RAOF: i'll try dri-experimental later
<knittl> how âexperimentalâ is it? :D
<LLStarks> enough on intel graphics hardware from my experience
<LLStarks> very stable with nouveau though
<RAOF> LLStarks: Except that we don't ship intel gallium (or, in fact, anything but nouveau) due to it being horribly unready.
<LLStarks> i know, i was making a point.
<LLStarks> i915 gallium is terrible
<RAOF> Not as bad as i965 gallium :)
<RAOF> knittl: It's unlikely to eat your dog, and it pretty much works in my testing.  It's called âexperimentalâ mainly because I want to aggressively ignore any bugs filed about it.
<RAOF> LLStarks: If you felt like a fun deep coding challenge, I understand that asac would quite like i965g to work :)
<LLStarks> will gallium be ready for default inclusion in narwhal?
<RAOF> Nouveau: ...unlikely, I think.  Radeon: yeah.
<LLStarks> i suck at c. wish i could help.
<knittl> RAOF: ok, that sounds good. i'm allergic to dogs though ;)
<knittl> restricted drivers available {popup}
<RAOF> Nothing says âyou'll get better at Câ like diving into mesa :)
<knittl> i'll clear the log before
<knittl> RAOF: 2010-08-17 09:14:52,995 DEBUG: handler xorg:nvidia_current previously unseen
<knittl> is that normal, good or bad?
<jcristau> RAOF: i thought it was "you'll get better at drinking"
<jcristau> RAOF: my bad
<jcristau> ;)
<RAOF> :)
<knittl> hehe
<knittl>   File "/usr/share/jockey/handlers/nvidia.py", line 178, in __init__
<knittl>     raise SystemError, 'does not currently work with xserver 1.9'
<LLStarks> when i say i'm bad at c, i mean it. i couldn't even figure out how to do game of life.
<RAOF> Hasn't Alberto uploaded the new nvidia yet?
<knittl> don't know. where to get it? apt-get upgrade has no new packages
<RAOF> knittl: Make sure you've got nvidia-current (256.44-0ubuntu1) available.
<knittl> read: my system is up to date
<RAOF> Hm.  I was sure that got fixed in the new nvidia-current.
<knittl> gimme a sec, updating right now some other components
<knittl> nvidia-current: Installed: (none) Candidate: 256.44-0ubuntu1
<knittl> i'm on i386 if that matters
<RAOF> jcristau: Incidentally, does Debian's -ati want the patch I've just added to Ubuntu's git branch?
<knittl> 2010-08-17 09:14:50,771 WARNING: modinfo for module nvidia_current failed: ERROR: modinfo: could not find module nvidia_current
<knittl> hrmmm, i think i'll try dri-experimental :>
<knittl> hihi, quadrapassel works again
<czajkowski> RAOF: that's not my bug, just a guy who was aking for help thanks though
<apw> Sarvatt, RAOF, am wondering if either if you had looked at the ATI GPU hangs when booted with grub in graphics mode:  bug #605614
<jono> hey folks
<jono> now when I start X I get:
<jono> Fatal server error:
<jono> [    18.307] no screens found
<jono> how do I fix this?
<jono> log file is at http://www.jonobacon.org/files/Xorg.0.log
<jono> it seems the intel driver is not loading
<jono> ahhh somehow the package wasnt installed
#ubuntu-x 2010-08-18
<vbrummond> hi I have a question about the stable updates X.org ppa, it seems that the xorg version is higher in Ubuntu Lucid than in the PPA I wondered why
<RAOF> I havn't checked, but I'd guess it's because the stable updates PPA grabs the drivers.
<vbrummond> I see
<vbrummond> no wait, its higher.. ;/ odd I cant seem to update to it, ill figure it out
<RAOF> apw: I haven't looked at that bug since I saw it, saw that Colin and you appeared to be on it, and that it looked decidedly kernel-ish.
<vbrummond> i think I see I am a bit confused because of metapackages, xserver-xorg-core says a newer version than the ppa is installed, but its essentially the same version
<Sarvatt> whoa, 2.6.36-rc1 is an insane amount more responsive than .35
<Sarvatt> apw: thanks for patching out comedi so it built!
<Sarvatt> thats crazy, updating 31 packages extracting 600mb of lzma archives and the gnome-do dock is still instant
<Sarvatt> well my mind is blown, nothing I do with 2.6.36-rc1 slows down the desktop. it hasn't responded anywhere remotely this good since 6.06
<Sarvatt> hmm, jockey could probably use an update to offer libgl1-mesa-dri-experimental, trying to activate effects says its not possible unless the nvidia drivers are installed still but works when you cancel it
<warewolf> Sarvatt: poke
<RAOF> Sarvatt: I don't think we particularly want to offer libgl1-mesa-experimental; does that occur when libgl1-mesa-experimental is installed already?
<bjsnider> Sarvatt, why is it more responsive, is it because of those disk activity patches?
<bjsnider> is it the scheduler?
<knittl> hi guys. my display stays blank after standby. if rhythmbox was playing it plays, but stops after the current song
<Sarvatt> darn, 12 hours later i'm getting some heavy swapping going on and it killed the performance, knew it was too good to be true :)
<barry> hi folks.  what's the current best recommendation for ati support on maverick?  i have a radeon hd 4670 and cannot install fglrx (bug 573748) from main archive, or the swat or edgers ppa.  the free driver gives me a usable dual-headed desktop, but no gl.
<jcristau> "no gl"?
<barry> glxgears says: "extension GLX missing on display :0.0"  also no "visual effects" i.e. no compiz
<jcristau> i suspect something in your install is broken then
<barry> jcristau: i'm sure it is, but i can't suss it out ;).  i was working with #ubuntu+1 yesterday to try many different combinations, without luck.  otoh, it seems like bug 573748 is affecting many other people
<barry> but i guess my first question is: should i be using edgers and/or swat ppa or just the main archive?  i think i ran lucid entirely off of edgers, but i'd like to avoid that for maverick if possible
<Sarvatt> barry: fglrx doesn't work with maverick and probably wont until the very last minute before release, you need to purge the fglrx package you probably have lying around
<barry> Sarvatt: cool, will do.  does it help at all to use the ppas?  i don't mind helping to test things as long as i can get some help when the desktop breaks horribly :)
<minimec> barry: the x-edgers ppa has a package called purge-ppa. Be sure to install that one ;)
<Sarvatt> nope, but the r600 mesa driver is much better in xorg-edgers than whats in maverick if you find it too slow. ati is notoriously bad about supporting new stuff in fglrx, from what I've read 10.10 will be the first release with any chance of supporting xserver 1.9 and 10.8-10.9 are just supposed to be minor bugfix releases
<barry> minimec: oh yes, purge-ppa is my favorite :)
<Sarvatt> ppa-purge is in maverick and lucid-backports as well now :)
<Sarvatt> (thanks BlackZ!)
<barry> Sarvatt: cool thanks.  i think i'll stick with the main archives then and just wait.  thanks for the info!
<Sarvatt> heads up to anyone using edgers on intel, if you have a ~/.drirc you need to delete it or manually enable ARB_fragment_shader support in it
<Sarvatt> well the people using i915_dri.so that is
<Sarvatt> uhoh, nouveau getting ready for a new api? hopefully just declaring 0.0.16 as stable 1.0.0 :) http://cgit.freedesktop.org/mesa/drm/commit/?id=b61e81a191d3a5c269c5f7c40199aebc9ebc034c
<penguin42> Have people run the X test suite (xts) recently - and is it normal for it give a load of fails?
<penguin42> (I've never run it before so I don't know if it's actually trustworthy)
<jcristau> yes
<jcristau> and yes
<penguin42> hmm thanks for the reply; is there any trustworthy test then that actually checks rendering?
<jcristau> what are you trying to do?
<penguin42> jcristau: I've got a reliable bug where any 3d rendering on the cirrus card emulated inside kvm is gently screwed up in an odd way - it looks like it's wrongly addressing or something; given that it won't actually be trying to do hardware 3d (because the card doesn't have any) I wondered if there was a way to narrow it down to maybe which operation was broken
<jcristau> see, that's a more useful question.
<penguin42> jcristau: Well true; but it would be nice if xts worked and passed!
<jcristau> for gl, i'd try piglit
<penguin42> any 2d ones? I could swear there used to be a 2d x render test many years ago
<jcristau> you said the problem occurred with 3d rendering..
<penguin42> jcristau: Yes, but since the card doesn't have any 3d support I'm assuming it's one of the 2d opps that the 3d emulation is using
<penguin42> 2d seems fine - the odd pixel dropping here or there, but it seemed sensible to try a 2d test if there was one
<jcristau> without a 3d driver stuff gets rendered in software by swrast
<penguin42> and swrast would just use all the normal 2d back end routines I assume?
<jcristau> no
<jcristau> well.  not really.
<jcristau> swx11 does that.
<jcristau> swrast does the rendering itself, and then uses PutImage to display it.
<penguin42> ok, so in principal if PutImage is working swrast should be pretty much independent
<penguin42> hmm a PutImage screw up would potentially fit the symptoms - it does look like a misrendered image
<jcristau> putimage just copies bits around
<jcristau> there's no magic there
<penguin42> ok, it just looks almost like an image with the wrong depth/width 
<penguin42> jcristau: http://launchpadlibrarian.net/50279619/Screenshot.png
<penguin42> hmm cmake, not used that before, still it's pretty
<penguin42> jcristau: Ah that's interesting, piglit's sanity check passes even though from the display it's obviously wrong
<penguin42> Piglit's sanity test fails on his Hosts Radeon (open source driver/maverick)
#ubuntu-x 2010-08-19
<Sarvatt> I think this is what you were looking for for 2D but glxgears having that problem has nothing to do with it - https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+sourcepub/1154014/+listing-archive-extra
<Sarvatt> have you tried using --vga vmware instead of cirrus?
<Sarvatt> or --vga std
<Sarvatt> (kvm args, instead of the default --vga cirrus)
<penguin42> Sarvatt: Isn't that just the X Render extension that is testing?
<Sarvatt> yup
<penguin42> And I thought I'd tried VMWare but I'll check again once piglit finishes
<penguin42> Sarvatt: It's one of those things that while really running 3d on a VM will obviously need something special doing, being able to run apps that use GL for little things at an almost useable pace means that at least you get a chance to turn things off
<Sarvatt> it'd be nice if the qemu-kvm git tree was actually readable
<penguin42> Sarvatt: git clone git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git  that one?
<Sarvatt> is that just a stock lucid vm?
<Sarvatt> i can't reproduce it
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/marcelo/qemu-kvm.git;a=shortlog
<Sarvatt> yeah
<penguin42> Sarvatt: Maverick currently on maverick
<penguin42> but I did that when it was lucid on lucid
<penguin42> Sarvatt: In what way not readable? Just hard to understand?
<Sarvatt> ah i just tried lucid on lucid and lucid on maverick
<penguin42> I was fairly sure lucid on lucid was what broke for me - you have glxgears working?
<Sarvatt> oh they merged branches up to certain commits, i thought they squashed chunks of the real qemu trees into single commits
<Sarvatt> yeah glxgears was working fine
<penguin42> Sarvatt: Hmm - that's with Cirrus?
<penguin42> I just tried vmvga and it worked
<penguin42> and back to cirrus and it fails again
<penguin42> bizarre, rendercheck seems faster in my vm than native on the Radeon
<Sarvatt> penguin42: nothing strange about that :D
<chrismsnz> hi guys, do the owners of the xorg edgers ppa hang out here?
<chrismsnz> just trying to update my lucid install to the latest nouveau - it seems that the nouveau module backport package in the ppa doesn't support the current ubuntu kernel
<soreau> so upgrade your kernel?
<chrismsnz> soreau, thanks, the kernel I'm running (from stable lucid) is of a higher version than the backported modules
<chrismsnz> 2.6.32-24 (stable lucid) vs. 2.6.32-20 (xorg-edgers nouveau backport module)
<soreau> It doesn't make much sense to run latest userspace with older kernel bits IMHO
<chrismsnz> right
<chrismsnz> but what use is a backport that doesn't support the current kernel being pushed by ubuntu's updates?
<soreau> None. Which is why you should use and complain only about latest bits ;)
<chrismsnz> i'm having trouble with nouveau and my card with a fresh install - i tried the edgers ppa to either solve or allow me to file a bug
<chrismsnz> so i'm ppa-purging right now as i can't run the latest module anyway. might upgrade to 10.10 alpha and see how it goes
<soreau> cheers
<chrismsnz> will the edgers ppa work against maverick?
<soreau> yea
<chrismsnz> sweet
<soreau> it keeps repos for most recent versions of ubuntu (especially testing)
<chrismsnz> right...
<chrismsnz> maybe i'm getting this wrong
<chrismsnz> i installed and updated lucid, ran all available updates and my computer would hang when it got to X (using nouveau)
<chrismsnz> setting nouveau.modeset=0 gets it to boot as VESA
<chrismsnz> I added the edgers ppa and installed all the latest bits, but the kernel seems to still pick up the old module - should there have been a backported kern module for nouveau? Or did I do something incorrectly?
<chrismsnz> everything seemed to indicate that the plain 0.15 version was loading, instead of the 0.16+change version from edgers
<chrismsnz> that version was showing in the xorg log and dmesg
<soreau> Did you try a latest kernel?
<chrismsnz> ah, no - just the 2.6.32-24 from lucid - i should have used one from the kernel team ppa
<chrismsnz> righto, my bad then - maverick upgrade underway so hopefully that fixes it
<ginggs> Hi, I've tested and uploaded a patch for http://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/553415 - can anyone assist with creating a lucid task?
<ubot4> Launchpad bug 553415 in xorg-server (Ubuntu) (and 2 other projects) "mouse trapped in box for Open Motif (affects: 26) (dups: 3) (heat: 111)" [Undecided,Fix released]
<tjaalton> ginggs: done, I could even sponsor the fix but would like to talk to the release manager about pulling whole 1.7.7
<ginggs> thanks!
<Sarvatt> whoa, thats where all my memory went!
<Sarvatt> 7504 objects
<Sarvatt> -1318584320 object bytes
<penguin42> -ve memory - always bad
#ubuntu-x 2010-08-20
<RAOF> Woo!  Gem!
<soreau> about ppa-purge, is it a tool to purge any repo for ubuntu? but ppa-purge itself is provided by xorg-edgers?
<RAOF> It'll purge any PPA; it's also in Universe as of Maverick.
<soreau> oh cool, thanks
<virtuald> i tried running x as user and it put my password on irc
<virtuald> everything i typed at tty1 got onto irc somehow
<gord> FYI guys, all the sluggish nvidia 2d performance is solved if you turn off subpixel font rendering in gnome-appearance-properties 
<Sarvatt> well ditching compiz slowed down the memory leak on intel at least, 370MB after 24 hours instead of 2gb+ and it was 300MB or so when I disabled compiz. haven't figured out whats causing the leak yet :(
<bryceh> heya Sarvatt
<Sarvatt> heyo bryce!
<cnd> bryceh, do you have a moment to chat about ABI dependencies between evdev and xserver-xorg-core?
<cnd> I'd like to figure out what the best way to handle it is
<bryceh> cnd, sure
<bryceh> cnd, tjaalton or jcristau probably are the best people to give advice here
<cnd> ok
<bryceh> cnd, the xorg package has files in debian/scripts/vars.* which set up dependencies on the drivers
<bryceh> e.g.
<bryceh> XSERVER_XORG_INPUT_DEPENDS="xserver-xorg-input-evdev, \
<bryceh> 	xserver-xorg-input-synaptics, \
<bryceh> ...
<jg> bryceh: I'm finally back to trying to get this HP 2540p going (eDP display); I have a maverick install running; but screen is flashing at a couple hertz; any prayer of xorg-edgers working this instant?
<bryceh> so that's sort of where my concern about a circular dependency is
<cnd> bryceh, would it be better to just assume that things will work?
<bryceh> jg, no idea I haven't been keeping up on it; Sarvatt would be better to ask
<cnd> there's api/abi changes that x goes through all the time
<bryceh> cnd, probably... could you explain particularly what motivated it?
<jg> bryceh: I would have asked him, but he wasn't around....
<cnd> bryceh: the new evdev module will require the server to have gesture support, and that support landed in the *-1ubuntu2 version of the server
<cnd> that version has been there for a week now
<jcristau> cnd: the server installs files in /usr/share/xserver-xorg/ that driver packaging uses to set up dependencies.
<cnd> jcristau, thanks, I'll take a look
<jcristau> cnd: so if you bump that in the server, drivers built against it will get the bumped dependency
<jcristau> or should, anyway
<bryceh> jcristau, thanks
<cnd> jcristau, bryceh, so the input abi/api hasn't changed, but I see that the file also has xserver-xorg-core (>= 2:1.8.99.904)
<cnd> should I bump that to xserver-xorg-core (>= 2:1.8.99.904-1ubuntu2)?
<cnd> it's not really an issue for anything other than evdev
<jcristau> cnd: debian/serverminver in the server package
<nigelb> Anyone heard of an issue where the screen's flickr after about 30 minutes of switching on?
<nigelb> they just flickr like a barcode :(
<cnd> jcristau, ok, so you would recommend bumping that up to *-1ubuntu2?
<jcristau> cnd: yep
<cnd> jcristau, ok, thanks!
<jcristau> np
<cnd> jcristau, should I add a build-deps in evdev against the new version of xorg-server?
<jcristau> probably, yes
<cnd> so that we're sure the right serverminveris picked up
<cnd> ok
<cnd> bryceh, if I upload a new server package with just the bump in debian/serverminver to people.canonical.com, can you upload that to the archive for me?
<cnd> it's the only change I'll make
<bryceh> cnd, certainly
<cnd> k, thanks
<fester> hi, i'm trying to get kernel 2.6.35 to work with fglrx 
<fester> i run aticonfig --initial=dual-head and it writes a new xorg conf, but it always errors out on a rebot
<fester> reboot
<fester> anyone have any experience with this?
<fester> am i in the wrong place?
<cnd> bryceh, I've got a new source package pushed to http://people.canonical.com/~cndougla/x/
<cnd> that's for xorg-server
<cnd> bryceh, actually, I should do a quick build test with that just to be sure
<cnd> I'd feel bad if I somehow screwed up something so small :)
<bryceh> heh, ok
<bryceh> and one day we'll have a test suite to run too ;-)
<bryceh> cnd, I've gone ahead and committed this change to our git tree
<bryceh> (and pushed)
<cnd> bryceh, to the git tree but not the archive, right?
<bryceh> correct
<cnd> k
<cnd> bryceh, looks good for me
<cnd> please upload to the archive
<cnd> I'll send out a new email with my updates to evdev
<bryceh> cnd, done, uploaded to maverick
<cnd> thanks!
<cnd> bryceh, I just updated the evdev git repo and sent a reply to your review
<bryceh> ok
#ubuntu-x 2010-08-21
<eagles0513875> hey guys im trying out the nvidia-current from yalls ppa
<eagles0513875> it works fine yet i still am getting the occasional driver crash. 
<trinikrono> hey guys are they different xserver -xorg-video-intel drivers between xubuntu and ubuntu
<trinikrono> on bug 601441 the reporter says he changed to xubuntu and it works fine now
<ubot4> Launchpad bug 601441 in xserver-xorg-video-intel (Ubuntu) "[i845G] Running Firefox crashes X (affects: 1) (heat: 89)" [Undecided,Incomplete] https://launchpad.net/bugs/601441
#ubuntu-x 2010-08-22
<warewolf> Sarvatt congrats on your job :)
<bryceh> Sarvatt, welcome aboard :-)
<penguin42> Does anyone know where the ioctls for radeon dri are defined for user space?
<penguin42> oh maybe in an X server file rather than normal /usr/include/linux ?
 * penguin42 finds libdrm
<jg> ping Sarvatt 
<penguin42> anyone understand drm_buffer_pointer_to_dword and friends?
<X3> hi guys
<X3> need help form someone experienced who can backport nvidia drivers and vdpau etc from 185 to 256 on karmic and lucid need to have a ppa which offers all those choices on one ppa
<X3> its for this project https://sourceforge.net/projects/xci/
<tjaalton> X3: https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates for lucid
<tjaalton> maybe the same works for karmic
<X3> er thats only offering 256 in lucid
<X3> i need to offer choice from 185 up to 256
<tjaalton> heh, good luck then
<X3> oh thx for your help... not
<tjaalton> 256 supports the same devices, so I don't understand what you're aiming for
<X3> if you read about XCI you would know
<X3> its a post installer script for xbmc some devices etc
<X3> users not all want just one driver version
<tjaalton> still doesn't answer the question
<X3> diferent machines, setups, needs etc
<tjaalton> yes, and if 185 works then 256 will
<X3> really
<tjaalton> well, it's nvidia...
<tjaalton> so maybe not
<X3> i must have droped IQ
<tjaalton> but in theory it would
<X3> in theory
<X3> you would nderstand I need to offer a chice for my script users
<X3> *choice
<tjaalton> so to answer your question; no there is no place with every nvidia driver available since 185
<X3> I know
<X3> this is what Im trying to create
<X3> nvidia ppa offers this for karmic
<X3> but not for lucid
<X3> and x swat only offers one dribver version
<tjaalton> then ask whoever is providing that
<X3> oh lord
<tjaalton> oh sunday
<X3> man why you making a easy requet into a nightmare
<tjaalton> are you asking for someone to create a ppa for you?
<X3> most importantly why am I listening to someone ewho clearly not helpfull
<X3> ya I need someone whos experienced with drivers
<tjaalton> trying to save you some time. it's rather pointless to provide that sort of choice to the users..
<X3> oh right
<tjaalton> hey, I maintained nvidia/fglrx for 8.04
<X3> why they ask for it
<X3> i have 6k users and they wanted choices
<tjaalton> it's trivial to rebuild the package for a given distro
<X3> trivial for u perhaps
<tjaalton> dunno about forward-porting to a newer kernel, but shouldn't be too hard
<X3> ah
<tjaalton> dch, bump the version & change the release, debuild -S, dput
<X3> your assuming that im experienced packager, in that case I wouldnt be asking for help
<X3> its not that simple
<X3> in order to have one ppa with several difernt versions of same the packages need renaming
<X3> e.g. nvidia-drivers to nvidia-drivers-185
<X3> otherwise the newer drivers just erase oldr ones on ppa
<X3> also many of the packages have problems that require some attention
<tjaalton> no it doesn't
<tjaalton> oh
<tjaalton> it does
<X3> :/
<tjaalton> well, see, it's pointless :)
<X3> whats pointless is this discussion
<tjaalton> indeed
<penguin42> X3: Why don't you try cribbing from some other packages that do similar things?
<X3> ?
<penguin42> X3: Find another package which has 2 or 3 versions available and borrow the way they do it
<X3> its any compile issues that need fixing as well as other things
<X3> its not as simple as that
<penguin42> X3: Yeh well I'm not sure where you're going to find someone to fix compile issues on so many versions - I guess it's hard enough just keep one or two versions built and working
<X3> for choice and availability for all?
<X3> nm
<penguin42> X3: But it's a lot of work I guess; so I guess the people who know try and pick one or two versions which work for most
<X3> LOL
<X3> never mind Ill just do it myself
<penguin42> well if you disagree find someone who wants to do it, but please don't laugh at us
<X3> im not laughing at you
<X3> ust at the defeatist attitudes
<penguin42> X3: It really shouldn't need every version; it should just work with one or two
<penguin42> X3: It's defeatist to build every damn version for every kernel
<X3> im trying to help people with their projects andn i get the destinct message that says its hard work forget about it
<tjaalton> X3: that's what happens after you've dealt with the blobs for some time
<penguin42> X3: I'm not saying some hard work is a bad thing; but I'm saying its probably not the most useful thing
<X3> Clearly you guys know nothing about XCI or xbmc users so nm
<tjaalton> heh, do they differ from ubuntu users?-)
 * penguin42 checks the channel title
<X3> nm you guys have a dandy sunday I just found a useless channel
<X3> ill do it all myself
<penguin42> enjoy
<tjaalton> penguin42: btw, did you try #dri-devel, or #radeon?
<penguin42> tjaalton: Not yet, I've not get much time left today so I'll probably pick it up again next weekend
<tjaalton> penguin42: okay
<penguin42> tjaalton: But thanks for the reply
<tjaalton> np
<tjaalton> my better contribution for the day ;)
 * penguin42 is working through the kernel with sparse and trying to understand some of the warnings; I've found some nice obvious bugs that I've reported - nice simple ones; but there are a few I want to think more about
<Sarvatt> penguin42: /usr/include/libdrm/radeon_drm.h and drm_buffer_pointer_to_dword was added here - http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg46896.html
<Sarvatt> jg: what's up?
<Sarvatt> and ...wow... at the scrollback :D
<penguin42> Sarvatt: Thanks
<tjaalton> yeah, sorry about that
<Sarvatt> why are YOU sorry? :D 
<tjaalton> for feeding the troll?-)
<jg> Sarvatt: I finally had a chance to get back to installing on my HP 2540p; Maverick installs, but the screen flashes at 1-2hz randomly.  So there is still some problem....
<Sarvatt> whoa, really? with the massive amount of eDP fixes queued up for the kernel I'm surprised it's working
<penguin42> jg: Weird bug!
<jg> penguin42: almost certainly not quite driving the panel correctly...
<jg> Sarvatt: so is there some version of bits I should try out, better than Alpha 3?
<penguin42> jg: I've seen something similar on a Radeon with an old Dell 20" but it only happens sometimes
<jg> penguin42: yeah, it's more than a bit distracting; I did find a previous kernel that behaves better.
<penguin42> and it was much less specific, it tended to blink off just when you looked at it 
<penguin42> but maybe that was the --spiteful option
<Sarvatt> jg: not yet, the mainline kernels stopped building because one of the staging drivers is broken, hopefully intel gets the fixes into 2.6.36-rc2 that should be coming out soon and that'll be in here - http://kernel.ubuntu.com/~kernel-ppa/mainline/
<Sarvatt> have you tried http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc1-maverick/ by any chance?
<jg> Sarvatt: yes; was unstable and oopsed with dismaying frequency; I think it also flashed the screen at me, IIRC.
<Sarvatt> how do you like that 2540p by the way? laptop shopping for something broken on linux :)
<jg> Sarvatt: I like the machine a lot, except for the problem's I've been having under Linux.  It has a full sized keyboard; it's clearly very ruggedly built, and has a DP connector on it, which means I can drive just about any external display (at least when the bugs get shaken out...)
<jg> It's relatively small, but bigger than this VAIO I hate intensely.
<bjsnider> what's the chipset?
<jg> Sarvatt: I haven't poked at all of the devices yet; dunno about the finger print reader, nor the support for SD, etc.
<jg> bjsnider: http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/321957-321957-64295-3740645-3955549-4138624.html
<Sarvatt> its just a normal qs57, i'm looking at the 14" version since its hard to justify paying that much for a 1280x800 screen
<bjsnider> that should work perfectly fine with linux -- it's all intel
<Sarvatt> eDP is all kinds of messed up on intel
<Sarvatt> and the screen is connected over that internally so theres a bunch of problems
<jg> Sarvatt: IntelÂ® Coreâ¢ i7-640LM Processor (2.13 GHz, 4 MB L3 cache)
<jg> Sarvatt: there is also a tablet version available (multitouch screen).
<Sarvatt> it's a shame sony vaio z is the only decent 13" laptop with a non 1280x800/1366x768 screen :( i may just get a precision M6500 from the dell outlet for half price and stick to this netbook for traveling since it gets about 18 hours total battery life
<jg> Sarvatt: I've liked my VAIO for traveling, but it has sucked for everything else; the HP is slightly bigger and heavier, but I get a full sized keyboard, and it's clearly much better made.
<jg> will still be fine for traveling, and I can finally drive my big flat panel properly; the VAIO i have was very marginal on the video at that size.
<Sarvatt> the $249 batteries on the vaio are putting me off on that with how much I go through them
<Sarvatt> jg: when you say flashes, do you mean like it blanks and comes back? or things shift for a split second?
<jg> no, the screen blanks out pretty completely.
<Sarvatt> you could try booting with i915.powersave=0 added to the kernel command line, possibly i915.lvds_downclock=0 as well
<jg> so flashes isn't really the right term; it's as if it turns off and on.
 * penguin42 what's eDP?
<Sarvatt> jg: how often does it happen? does it have any correlation to activity on the desktop at all?
<Sarvatt> penguin42: embedded displayport
<jg> Sarvatt: all the time; no correlation with what I'm doing otherwise.
<penguin42> Sarvatt: Ah right
<Sarvatt> its a standardized plug for lcd's internally on laptops
<Sarvatt> jg: like every 10 seconds, every minute...? or just completely random?
<jg> the command line options had no effect, on 2.6.36-17-generic.
<jg> Sarvatt: like all the time, once or twice per second.
<jg> Really bad....
<Sarvatt> oh nasty :(
<Sarvatt> probably not powersave related then but still worth a shot
<jg> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc6-maverick/ is what I'm running, on which the video does not screw up.
<jg> all in the launchpad bug reports....
<Sarvatt> hmm, thats older than the maverick kernel, the maverick kernel doesn't work?
<Sarvatt> i'll check the report
<jg> the  2.6.35 14, 16, and 17 kernels all screw up on the screen.
<Sarvatt> hmm last response is saying the maverick kernel works fine for someone else with your same laptop, thats odd
<penguin42> Sarvatt: And same panel? I think the panels vary on the same models
<jg> Sarvatt: there are two slightly different chips under the same model, much less what panel it mayhave.
<micahg> any chance of getting the intel 2.12 driver in the x-updates PPA?
<micahg> for Lucid that is
<jg> Sarvatt: actually, four flavors depending on what configuration: ntelÂ® Coreâ¢ i7-620M Processor (2.66 GHz, 4 MB L3 cache)
<jg> IntelÂ® Coreâ¢ i5-540M Processor (2.53 GHz, 3 MB L3 cache)
<jg> IntelÂ® Coreâ¢ i5-520M Processor (2.40 GHz, 3 MB L3 cache)
<jg> IntelÂ® Coreâ¢ i7-640LM Processor (2.13 GHz, 4 MB L3 cache)
<Sarvatt> micahg: I haven't put it in yet because it requires libdrm 2.4.21 which will break nouveau but will eventually
<Sarvatt> LM does have a different GPU than the M models
<micahg> Sarvatt: k, thanks, will wait in anticipation :)
<penguin42> and all of those are the in-socket gpu aren't they?
<Sarvatt> yeah gpu is on the same package as the cpu
<Sarvatt> the LM models have a lower clocked gpu that turbo boosts higher and are about half the speed since turbo boost is pretty useless on the gpu :D
<penguin42> oh what a weird way of doing it
<Sarvatt> support for turbo boost didnt go in until 2.6.36 but its backported into 2.6.35-17 in maverick
<penguin42> I think Turbo boost on the CPU worked on Lucid didn't it?
 * penguin42 has i7-860
<jg> I gotta run....
<Sarvatt> jg: sorry again I don't have any more info for ya, will ask jbarnes if any of this eDP stuff queued in drm-intel-next might fix it
<Sarvatt> penguin42: I dunno, maybe the cpu turbo boost can happen automatically but the GPU definitely can't, there's an intel_ips module controlling it now
<penguin42> ok
<Sarvatt> theres a description of it here - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=aa7ffc01d254c91a36bf854d57a14049c6134c72
<penguin42> ah yeh, gpu is separate
<penguin42> getting the CPU/GPU trade off is probably a non-trivial (non-soluble?) problem
<penguin42> anyway, time to disappear until next weekend
<Sarvatt> it only clocks up the gpu when theres enough power headroom for it to do so which is pretty much only when the cpu isn't getting used, and how often do you really need gpu power without a big cpu load going on at the same time? :D so those LM/UM core 2010's are massively crippled since they run at 1/2-1/4 the speed without turboboost
<Sarvatt> linux-headers-generic-lts-backport needs to somehow get pulled in for people using linux-image-foo-lts-backport metapackages..
<Sarvatt> for nvidia/fglrx sorry
<tjaalton> isn't linux-foo-lts-backport for that?
<Sarvatt> it only grabs the kernel, blobs just silently fail because theres no headers
<Sarvatt> then again maybe neither work with it anyway, I didn't check :)
<tjaalton> right, only depends on the image, meh
<Sarvatt> oh hp, your crappy windows specific bioses never cease to amaze me
<Sarvatt> i have to boot this pavilion with a geforce 6150 IGP on battery for powermizer to work
<tjaalton> heh
<Sarvatt> great, it never goes up from the lowest speed if i do that too. so boot with battery to make it too slow to do anything but saves power or boot off ac and have it suck down 8 watts more idle
<Sarvatt> never goes up rather
<jg> Sarvatt: it is actually quite easy to issue commands to a GPU that might keep it very busy, without taking much CPU....
<jg> Sarvatt: it's very application dependent as to whether it will take much CPU to keep the GPU busy.
<Sarvatt> I was looking at it from the perspective of playing a game where there's almost never a low cpu load going on, but even say dragging a window around with compiz enabled pushes the cpu enough where it wouldn't use the turbo boost speed from what I can see
<jg> Sarvatt: I gathered from keithp that airlied may have gotten one of these eDP laptops, FWIW.
<Sarvatt> looks like he got a 2740p from the commit message on one of his recent patches
<jg> I've been too busy with vacation, a workshop, and chasing a problem in the internet to have had time to follow up;
<jg> on the other hand, Yellowstone was very pretty indeed, and the internet bug definitely important; maybe I'll have a bit of time now to act as a decent tester....
#ubuntu-x 2011-08-15
<Sarvatt> hrm looks like gbm now requires libgbm-dev to build after http://cgit.freedesktop.org/mesa/mesa/commit/?id=85fe9484945cb57ffd49df248b0e5057eba6af04
<techmik> is this channel more for development, or support? or both?
<bjsnider> Sarvatt, is siretart in any channel you're in?
<ricotz> bjsnider, #ubuntu-motu #ubuntu-devel
<techmik> i need some help with setting up my multihead/multiseat setup..... its really an issue of the custom files in xorg.conf.d/ and the display manager's conf file.... i have different issues depending on which dm i have tried to use between kdm gdm and lightdm
<techmik> is this the right channel?
#ubuntu-x 2011-08-16
<mvo> bryceh: do you mind if I upload http://paste.ubuntu.com/667262/ ? the upgrade tester is currently unhappy because of this
<bryceh> mvo, yes please go ahead
<Sarvatt> goodbye SNA in edgers! :(
<bryceh> Sarvatt, problems?
<Sarvatt> yeah too many reports of problems that only happen under unity
<bryceh> mm
<bryceh> Sarvatt, might be worth mentioning to Intel at tomorrow's meeting; I got your invite, are you planning to attend it?
<jcristau> i've seen ickle mention sna not liking unity a few times
<Sarvatt> yeah they know, there was a bug where ickle said he wasn't even going to look at it until unity is valgrind clean thats been sitting for 2 months :P we wont be turning it on until 12.10 at the earliest anyway and I'm getting tons of complaints (well ~15 emails a week) about it, oddly i dont have any problems on any of my machines
<Sarvatt> yeah i'll be on the call tomorrow, shared the calendar entry vanhoof made about it because you werent on it for some reason
<ricotz> Sarvatt, did you get the ubuntu-p kernel to compile? i was getting a message like "unsupported kernel version" from the buildscripts yesterday
<Sarvatt> yep, one sec
<Sarvatt> DEB_BUILD_OPTIONS=parallel=64 AUTOBUILD=1 NOEXTRAS=1 skipabi=true fakeroot debian/rules no_dumpfile=1 binary-headers binary-generic
<Sarvatt> need the no_dumpfile=1
<ricotz> ah, thanks!
<ricotz> parallel 64 sounds nice :P
<Sarvatt> yeah kernel team quad xeon X7550, 9 minutes or so :P
<ricotz> Sarvatt, hehe
<ricotz> i hope darktama will rebase nouveau soon, there are too many conflicts to go through them :\
<Sarvatt> holy crap thats a lot of commits
<Sarvatt> it already missed the merge window so imagine they will
<ricotz> exactly ;)
<barry> hi folks.  i installed fglrx and it killed my display.  is there any useful diagnostics i can gather for you before i try to uninstall and reinstall the free driver?
<Amaranthus> any idea who I should poke about bug 603599 and bug 698009
<ubot4> Launchpad bug 603599 in mesa (Ubuntu) "Please build the vmwgfx driver (affects: 2) (heat: 14)" [Wishlist,Triaged] https://launchpad.net/bugs/603599
<ubot4> Launchpad bug 698009 in linux (Ubuntu) (and 1 other project) "Request to enable vmwgfx driver in kernel config (affects: 1) (heat: 15)" [Wishlist,Confirmed] https://launchpad.net/bugs/698009
<bryceh> Amaranthus, apw would probably be the best guy to talk to about kernel graphics drivers
<Amaranthus> good, you just pinged him for me :)
<bryceh> might be EOD; you might want to email him just in case Amaranthus
<Amaranth> Didn't even notice my nick was wrong
<Sarvatt> Amaranth: while vmwgfx in mesa requires X to build and X requires mesa to build I dont see it getting fixes unless you have any ideas on how to get around that
<Sarvatt> s/fixes/fixed/
<Amaranth> ah, right
<Amaranth> well, just getting the kernel side would help me :)
<Amaranth> and we don't need the X driver for GL, do we?
<Prf_Jakob> You do
<Sarvatt> it builds both the X driver and GL driver inside mesa
<Sarvatt> i guess one way would be to have another mesa source package that builds it just for vmwgfx with its own packages that replace the mesa ones like the proprietary drivers?
<Sarvatt> that'd be a nightmare
<Prf_Jakob> Sarvatt: do you really need to replace libGL, can't you just get the vmwgfx_[dri|drv].so from there?
<Sarvatt> thats a good point, you'd know better than me :) if thats the case it'd be a lot easier though, i'll try it out
<Amaranth> Sarvatt: You only need the files Prf_Jakob mentioned, I just did a manual build and copied those to the right places
<Prf_Jakob> Amaranth: you got it to work?
<Amaranth> Prf_Jakob: I've been running Ubuntu in fusion with working GL/GLES acceleration for like 3 weeks now, it works fine
<Prf_Jakob> Nice!
 * Prf_Jakob works for VMware and on that driver.
<Amaranth> some weird screen corruption sometimes but usually forcing a redraw fixes it
<Prf_Jakob> Which compositor?
<Prf_Jakob> Unity?
<Amaranth> yeah
<Prf_Jakob> Ok
<Prf_Jakob> I haven't seen anything like that I think
<Prf_Jakob> Next time it happens can you take a screenshot?
<Amaranth> may have to do it with a camera, usually touching anything makes it go away
<Prf_Jakob> Doing it in Mac should be enough (cmd + shift + 4) 
<RAOF> Sarvatt: We could have cyclic build-depends just fine.  It'd make bootstrapping a new architecture that much less fun, but I don't plan on bootstrapping a new architecture anytime soon :)
#ubuntu-x 2011-08-17
<Sarvatt> looks like i just hit the upgrade problem too on my machine updated this morning
<Sarvatt> lightdm fails to start
<bryceh> Sarvatt, exit code 127?
<Sarvatt> gnome-session: symbol lookup error: /usr/lib/gio/modules/libgiozeitgeist.so: undefined symbol: g_desktop_app_info_launch_handler_get_type
<Sarvatt> Amaranth: darnit, you convinced me to buy fusion while i915 doesn't work with these new macbook airs :)
<Amaranth> Sarvatt: hehe
<Amaranth> it works surprisingly well
<Amaranth> supposedly it'll even show you battery status
<Amaranth> I use it because wifi doesn't work in ubuntu on the latest MBP
<Prf_Jakob> Sarvatt: I'm sure I can set you up with a license.
<Sarvatt> already bought it, appreciate it though man!
<Prf_Jakob> Sarvatt: ok, let me know if some ubuntu dev needs any license's, as long as its for vmw related stuff I have been able to get a license issued.
<Prf_Jakob> before*
<Prf_Jakob> Now is time for sleep
<Sarvatt> Amaranth: quite a lot of commits enabling the HT PHY broadcoms for b43 in 3.1, it may actually work by 3.2
<Amaranth> yay
<Sarvatt> http://www.amazon.com/AirLink101-AWLL5088-Wireless-Ultra-Adapter/dp/B003X26PMO/ref=sr_1_2?ie=UTF8&qid=1313556752&sr=8-2 works great if you dont mind dkms realtek drivers btw :P
<Amaranth> Sarvatt: I have that exact one
<Amaranth> But the hassle of using up a USB port plus some oddness with the intel driver and various other things drove me away for now
<tseliot> tjaalton, RAOF: is it expected to have X stuck in a loop (and eventually backtracing) because of evdev in Oneiric?
<RAOF> tseliot: No, that's a new one on me.
<tseliot> hmm...
<tjaalton> not seen that either
<tjaalton> and it's likely a hung gpu anyway
<tjaalton> so.. depends on the driver i guess ;)
<RAOF> Right.  Generally MI: EQ overflow is a hung gpu.
<tseliot> RAOF: it seems weird to me as I'm using the same NVIDIA driver I was using yesterday and I only updated my system
<RAOF> It's entirely possible that something else is broken.
<RAOF> Just, generally, EQ overflows are GPU hangs.  Because GPUs are the most fragile part of X :)
<tseliot> I'm switching to nouveau to see if I can start X
<RAOF> tseliot: You're not being hit by the libzeitgeist-gio craziness?
<RAOF> If you've got that installed, it'll break almost everything.
<tseliot> RAOF: yes, I think I've see that error too when upgrading
<tseliot> oh, I think it I messed up my system yesterday
<tseliot> s/it//
<tseliot> RAOF, tjaalton: oh, maybe it's "Desktop failing to start today due to glib2.0 update" (see the ubuntu-devel mailing list)
<tseliot> i.e. https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/827753
<ubot4> Launchpad bug 827753 in glib2.0 (Ubuntu) "libglib 2.29.16-0ubuntu1 breaks desktop session - downgrade fixes (affects: 2) (heat: 16)" [Critical,Fix released]
<tseliot> oh, same issue
<RAOF> tseliot: Yup ;)
<tseliot> RAOF: also, did you add an alternative (with ld.so.conf) on libGLES?
<RAOF> tseliot: No.
<RAOF> My thinking was that libGLES/libOpenVG are going to be tied to their associated libEGL implementations.
<RAOF> So the egl alternative suffices.
<RAOF> If there *is* any time when you might want to use nvidia's libGLES with mesa's libEGL, then I'd need to rethink that.
<RAOF> So what you should do is ship libGLES/OpenVG in the same directory as your libEGL; then the libEGL alternate will take care of them.
<tseliot> RAOF: I was just thinking of the driver for Tegra on ARM which right now conflicts with mesa-utils, etc.
<tseliot> yes, I guess that's how it works now
<RAOF> tseliot: I've dumped some thoughts on https://wiki.ubuntu.com/X/EGLDriverPackagingHOWTO but they need tidying up.
<tseliot> RAOF: nice, thanks, I'll have a look at it
<mterry> There haven't been any updates recently that would cause an intel driver to not start in oneiric, has there?
<mterry> Alternatively, how do I force use of vga and not the intel driver in X?
<jcristau> boot with nomodeset
 * mterry tries
<mterry> Well, that worked and got me the VESA driver.  But x still won't start...  /me digs deeper
<Duke`> wow new fresh xorg-intel driver, with no more image corruptions \o/ has SNA been disabled? (i945)
<tseliot> mterry: are you sure it's not bug #827753 ?
<ubot4> Launchpad bug 827753 in glib2.0 (Ubuntu) "libglib 2.29.16-0ubuntu1 breaks desktop session - downgrade fixes (affects: 3) (heat: 20)" [Critical,Fix released] https://launchpad.net/bugs/827753
<mterry> tseliot, it is, but in a different place.  The known issue was about zeitgeist-gio, but I found a similar problem with wncksyncdaemon using the dropped symbol
<tseliot> oh
<mterry> sorry, should have followed up in this chat room  :)
<lamalex> hey guys, in O my external monitor is no longer found at all
<lamalex> makes testing unity/compiz multi-monitor bugs... hard
<tjaalton> lamalex: file a bug with 'ubuntu-bug xorg'
<Sarvatt> Amaranth: are you using oneiric in fusion?
<Sarvatt> Amaranth, Prf_Jakob: http://sarvatt.com/downloads/vmwgfx1.png http://sarvatt.com/downloads/vmwgfx2.png does not like 3D enabled :)
<lamalex> tjaalton, https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/828286
<ubot4> Launchpad bug 828286 in xorg (Ubuntu) "External monitor not detected on macbook pro 7.1 (affects: 1) (heat: 6)" [Undecided,New]
<tjaalton> lamalex: ah, nvidia. you need to configure it with nvidia-settings, or use nouveau instead
<Sarvatt> note to self: dont enable 2DAccel in xorg.conf for vmwgfx :)
<tjaalton> I'd be happy if vmware workstation worked on an oneiric host, but the kernel modules won't compile
<tjaalton> which is hardly surprising, but means i can't test it
<bryceh> is there a simple command line tool that does an XUngrabPointer action, so if an app has an invalid grab on the cursor you can force it to let go?
<tjaalton> how would you run that?-)
<Duke`> Sarvatt, did you disable SNA in latest xorg-intel driver?
<tjaalton> (from a vt, yes)
<Sarvatt> Duke`: yep!
<bryceh> tjaalton, like via ssh with DISPLAy set?
<Duke`> Sarvatt, that works better now :D
<Sarvatt> Duke`: was trying to find you on IRC to tell you, ya beat me to it :)
<Duke`> hehe
<Duke`> unfortunatly, I haven't found a lot of work for the graphic corruptions
<Duke`> s/work/activity
<Duke`> +for some weeks
<Duke`> x_x
<tjaalton> bryceh: yeah, and usually keyboard works so that you can change the vt too
<Sarvatt> its odd I never could reproduce them but I had so many complaints
<Sarvatt> one person was even using the same exact machine I use most of the time
<Duke`> Sarvatt, I could reproduce 100% some of them. Eg. moving a file on the desktop from one place to another: the icon is totaly corrupted
<Duke`> note that I'm using a 64-bit install
<Sarvatt> Duke`: natty or oneiric?
<Duke`> natty
<Sarvatt> what kernel?
<Duke`> 3.0
<Duke`> wut I had the same problem with 2.6.39
<Duke`> and 2.6.38 I think
<Sarvatt> so like almost all the complaints are in natty now that i'm looking
<Duke`> ah !
<Sarvatt> i wonder if it isnt something that was fixed in unity/compiz in oneiric as to why i didnt have problems, no natty machines
<Duke`> but what would differ on the graphic side from natty to oneiric?
<Duke`> ah maybe!
<Duke`> It does not happen with compiz disabled/metacity
<Duke`> hum yeah there's probably something with compiz
<Sarvatt> Duke`: how are you using edgers on natty? do ya not use wine at all?
<Sarvatt> i'm just curious if you have multiarch set up
<Duke`> I don't use wine currently (haven't used for a year maybe)
<Sarvatt> heck, now that i think about it theres absolutely no way multiarch works in natty, need to multiarch all those mesa depends in there
<Duke`> mainly desktop work, and some old dosbox games + some games requiering low hardware
<Sarvatt> it doesnt even work in oneiric without libpciaccess multiarched still
<Sarvatt> do you use x64 flash or something?
<Duke`> I'll check
<Sarvatt> because 32 bit looks for ia32-libs mesa thats totally busted
<Duke`> seems to be the 32-bits version, since the installed package requires ia32-libs
<Duke`> and I experiments white graphic corruptions on some flash animations
<Duke`> s/experiments/have experimented until latest edgers update/
<Duke`> I'm happy today, no graphic corruption anymore, flash works fine, shadows under windows/menus/panel are back on my desktop \o/
<Sarvatt> yeah thats due to not having any kind of mesa available for 32 bit, ya want to grab x64 flash for sure. i'm not sure that i'm going to fork the packaging for natty to disable multiarch, that'll end up with me not updating natty at all when it breaks most likely (mesa builds still break and need too much time to fix up 2x weekly already)
<Duke`> dunno how is flash64 stable today, did you test it?
<Sarvatt> yep its good, it'll be released soon as the stable 11 version
<Sarvatt> Duke`: what was the unity/SNA bug # for your bug again?
<Sarvatt> on fdo
<Sarvatt> let me try that again, what the was bug number on fdo for the unity/SNA problem you had?
<Duke`> #38732
<Duke`> https://bugs.freedesktop.org/show_bug.cgi?id=38732
<ubot4> Freedesktop bug 38732 in Driver/intel "[sna unity] windows have white borders from time to time." [Normal,New]
<Duke`> of course, if it's not reproductible with a recent compiz/unity, xorg developers may not show a lot of activity on this bug...
<Duke`> gonna sleep, bye
<bryceh> Sarvatt, btw in the call with Intel Max sounded interested in getting a list of SNA/unity bugs that are showstoppers for us; would you be able to compile a list of bug#'s?
<Sarvatt> bryceh: sure thing, https://bugs.freedesktop.org/show_bug.cgi?id=38732 is the only fdo one I know off the top of my head but I'll dig up some of the others and ask these people emailing me to file bugs because peope were saying like the whole right click context menu popup was white so you couldn't interact with it instead of just shadows, and other people saying icons and random graphics were corrupted like Duke`
<ubot4> Freedesktop bug 38732 in Driver/intel "[sna unity] windows have white borders from time to time." [Normal,New]
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=39044
<ubot4> Freedesktop bug 39044 in Driver/intel "[SNA unity] Desktop is messed up" [Normal,New]
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=38733
<ubot4> Freedesktop bug 38733 in Driver/intel "[sna unity] drag & drop desktop icon contains uninitialised junk" [Normal,New]
<Sarvatt> bryceh: they actually have them all tagged on fdo
<bryceh> Sarvatt, ah good
<Sarvatt> there are a few duplicates of those 3 but those look like the major ones
<Sarvatt> KDE wont be happy when its enabled from the looks of it https://bugs.freedesktop.org/show_bug.cgi?id=39321
<ubot4> Freedesktop bug 39321 in Driver/intel "[sna kde] swrast on common paths?" [Major,New]
 * bryceh forwards
<ScottK> How is Intel GMA 3150 support in Natty/Oneiric?
<RAOF> As far as I'm aware, pretty stable.
<RAOF> Might be slightly better in oneiric than natty.
<Sarvatt> ScottK: probably the most robust of all the intels, outside of the external montior fun generation 3 entails
<ScottK> Don't care about external monitor for this particular use case, so sounds good.
<ScottK> Thanks.
<ScottK> Whatever SNA is, it sounds like I don't want it.
<bryceh> yeah don't think I've ever seen a pineview bug report
<bryceh> ScottK, actually the performance numbers I've seen with SNA are very exciting
<bryceh> just seems it has some bugs still to be worked out
<ScottK> Right, but the breaks KDE part I don't like.
<bryceh> I'm glad Intel is holding off on  it, rather than pushing it hard like we saw with EXA and UXA
<bryceh> ScottK, true but who uses KDE?
<ScottK> I know a few people.
<bjsnider> there are 6 people in the world that are confirmed to use kde
#ubuntu-x 2011-08-18
<Amaranth> Sarvatt: I think I ended up with 2D accel disabled and debug disabled, only 3D acceleration left on
<Sarvatt> using unity-2d?
<Sarvatt> all 3D apps have problems still here, http://sarvatt.com/downloads/vmwgfx3.png
<Prf_Jakob> Sarvatt: are you using Unity-2D?
<Prf_Jakob> Sarvatt: that bug should be fixed on master
<Sarvatt> in that screenshot yeah, i linked 2 screenshots earlier where i was using 3D and it was completely busted
<Sarvatt> master what?
<Prf_Jakob> git master of mesa
<Sarvatt> sweet, thanks for the heads up
<Sarvatt> i was just using oneiric packages there
<Prf_Jakob> yeah that exactly the bug we saw.
<Sarvatt> dont usually use anything but master but wanted to see how it'd be out of the box
<bjsnider> ricotz, nvidia 285.03 released. i'm not putting it in x-updates because it's marked beta, but it should go in edgers
<Sarvatt> bjsnider: I went to update it but he already put it in there :P
<ricotz> bjsnider, as you noticed - it is already there ;)
#ubuntu-x 2011-08-19
<RAOF> Hm.  Apparently it's time for another round of "what if we made X run on GL".
<tjaalton> RAOF: what did you have in mind?-)
<RAOF> tjaalton: glamour, on intel-gfx@
<RAOF> Nice suggestion of loving GL, though.
<tjaalton> oh, that
<RAOF> Not _me_ trying to revive glitz, xgl, orâ¦ what was the other one?  :)
<tjaalton> hehe, ok
<tjaalton> nothing on phoronix yet, weird..
<RAOF> Glucose!  That was it.
#ubuntu-x 2011-08-20
<raevol> hey all- i am running xorg-edgers on xubuntu 11.04, and today i am seeing an update for my kernel
<raevol> but it appears to be coming from the normal repository, not the ppa
<raevol> should i avoid installing it? or is it safe to let the update run and i'll still be running my edgers kernel?
<raevol> also is there a mailing list or something that i should be on to get pertinent updates about this sort of thing?
<raevol> (or is there a better channel i could ask in?)
<soreau> raevol: Your package manager should do The Right Thing
<raevol> ok thanks
<soreau> it's probably updating to a newer kernel than the one provided by the ppa
<raevol> well, it's not
<raevol> version number wise
<raevol> the ppa provides .39
<raevol> the update is for .38
<soreau> well it probably wont remove the ppa version
<soreau> so just let it do whatever then select which kernel you want in your boot loader
<raevol> ok
<soreau> raevol: might want to check software-properties-gtk and make sure the repo is still enabled
<raevol> it is, in the same batch of updates i have a bunch of driver updates from xorg edgers
#ubuntu-x 2011-08-21
<ricotz> hello, are there packages for the cuda sdk available?
<ricotz> bjsnider, ^
<bjsnider> no, i don't think so. i think you have to build that manually
<bjsnider> only the cuda header is included with the blob packages
<ricotz> bjsnider, ok, i was hoping there are some already since this is a pretty big thing ;)
<bjsnider> ricotz, did you check debian?
<ricotz> http://packages.qa.debian.org/n/nvidia-cuda-toolkit.html
<bjsnider> i don't remember if i did
<ricotz> bjsnider, just did
<bjsnider> i guess there just isn't enough interest yet to get it fully tested and into ubuntu and whatnot
<ricotz> probably, but it looks like it could be just synced
<bjsnider> i don't know what the rules are
<bjsnider> is it ok to sync something in experimental?
<ricotz> yes, this isnt a problem
<ricotz> but as you said there wasnt an interest to add it to ubuntu yet
<ricotz> the packaging is also multiarch compatible
<bjsnider> cool
<ricotz> but it is probably too late for oneiric and it isnt important enough for a FFe
<bjsnider> i don't know what it hurts
<bjsnider> it's not there now at all, so i don't see how it's going to break anything just to have it available
<ricotz> right, it shouldnt do no harm, but this isnt a reason for a FeatureFreezeException ;)
<bjsnider> is khronos-opencl-headers in ubuntu? it's a dependency
<ricotz> no
<bjsnider> well, you can put it in a ppa anyway
<ricotz> exactly
#ubuntu-x 2012-08-13
<ripps> Anybody have any idea what could be causing 1 second stutters every 5-10 minutes in Quantal?
<ripps> It's like my video freezes for about a second, but everything keeps running. If I'm watching a movie, the sound keeps playing and the video starts up again, if I'm playing minecraft, it's like the framerate drops to 1-2fps, and apparently my keybard was still working, because things I click and do in a panic at that point had occured while the video was frozen.
<bjsnider> ripps, check dmesg
<bjsnider> and .xsession-errors
<ripps> bjsnider: hmmm... it appears i have a few kernel oops, it seems to be with lowmem_reserve()
<bjsnider> even one kernel oops ain't not good
<ripps> ah, it seems it's coming from java and ps3mediaserver
<ripps> I have ps3mediaserver running as a service
<ripps> java seems to be stealing more memory than usual, didn't have any issues with 12.04
<bjsnider> must be pretty ugly software
<ripps> hmm... lots of errors in my .xsession-errors, most have to do with wonky japanese fonts, but I get a few relating to java and synapse
<ripps> man, clutter seems to be a mess in gnome-shell. I keep seeing actor is null being raised by clutter for my extensions and other things
<ripps> man, i'm not even sure if half of this is relevant, it seems i have things in here that are weeks old. I didn't know xsession-errors never cleaned itself out
<mlankhorst> morning
<tjaalton_> yeah
<mlankhorst> seems that ppa3 updates worked :)
<tjaalton> worked how?
<mlankhorst> it rejected all the ones that didn't update and rest compiled
<mlankhorst> https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<mlankhorst> but still seems displaylink is missing
<tjaalton> yeah I'll fix that
<mlankhorst> and libdrm 2.4.38 came out, I'll fix that :)
<mlankhorst> going to nbeed to do a testbuild on armhf because iirc omap symbols changed again
<tjaalton> huh, I thought -displaylink had been pushed to git
<tjaalton> can't find it
<tjaalton> and I packaged it :P
<mlankhorst> haha
<mlankhorst> now to build on arm
<tjaalton> ahhh
<tjaalton> no it was -modesetting that I packaged
<tjaalton> phew
<tjaalton> this one needs to be moved to git
<mlankhorst> might be why I missed it then
<mlankhorst> ok debian-experimental updated to 2.4.38 :)
<mlankhorst> tjaalton: Could you upload libdrm-2.4.38?
<tjaalton> sure
<tjaalton> mlankhorst: will you merge or should I
<mlankhorst> tjaalton: there's no changes in libdrm, so just take debian-experimental version and call it 0ubuntu1 :)
<mlankhorst> or at least I thought that's how it was supposed to work
<tjaalton> oh, ok
<mlankhorst> just look, ubuntu branch is missing 2.4.32 etc :)
<tjaalton> so it seems. I'll still merge it to the ubuntu branch
<mlankhorst> sure
<tjaalton> hmm, building the source package fails
<mlankhorst> you need to remove some files and fix symlinks iirc
<mlankhorst> see README.source :)
<tjaalton> ah
<mlankhorst> that find command should be enough, but might want to delete some of the untracked files too
<tjaalton> those are fine
<tjaalton> I wonder though if rules should be updated too for the new symbols
<tjaalton> the dh_makeshlibs lines
<mlankhorst> hm, maybe change them to -V ?
<mlankhorst> well looks like most of them would need to be bumped to v2.4.38 indeed
<tjaalton> yeah
<mlankhorst> except nouveau1a, that one isn't going to change any more
<mlankhorst> but I don't get that part, I'm not sure if updating would be needed or not
<tjaalton> see commit 7d6eca41f92c247e0be2b1562c833e6ef410977f for an example
<mlankhorst> yeah but is it needed if nobody uses the exports for example?
<mlankhorst> but then again I'm a packaging noob, just do what is best :)
<tjaalton> yeah I bumped it for intel and nouveau2
<mlankhorst> omap too btw
<tjaalton> true, but it hasn't had the version there
<tjaalton> guess without the version there the dep could be too tight
<tjaalton> ok I'll add it for omap too
<tjaalton> uploaded
<mlankhorst> great :)
<mlankhorst> now I just need to evilly sneak in the mesa patch and I'd only need intel/nouveau in my prime repository
 * popey waves bug 1036186 around the place
<ubottu> Launchpad bug 1036186 in virtualbox (Ubuntu) "virtualbox-guest-x11 ABI break in quantal" [Undecided,New] https://launchpad.net/bugs/1036186
<tjaalton> popey: you have -proposed enabled?
<popey> tjaalton, ya
<tjaalton> vbox needs to be fixed and reuploaded there to build against the new abi
<tjaalton> -re
<popey> its blocking some testing I am doing :(
<popey> because unity 2d is now gone, i can only use unity in virtualbox, and can only do that if virtualbox-guest-x11 is there
<tjaalton> downgrade the x stack?
<tjaalton> will be fixed later this week tho
<popey> it's automated testing, I'd rather not have to bodge things to test it
<popey> the point is to run autopilot in a vm
<tjaalton> why do you have -proposed there?
<mlankhorst> tjaalton: did you push libdrm to git?
<tjaalton> mlankhorst: yes
<mlankhorst> oh woopd expected it to be top commit :)
<popey> tjaalton, testing bleeding edge stuff, will try without it
<popey> tjaalton, thanks :)
<mlankhorst> Just need the xorg drivers, a patch to mesa, xrandr, and kernel for intel + nouveau prime in lts-q-backports
<tjaalton> popey: will get sorted out later this week
<tjaalton> hmm, wondering if -displaylink is unnecessary at this point where we have the kms driver and -modesetting..
<mlankhorst> I don't think it would be needed, prime uses modesetting driver I think
<tjaalton> yeah
<tjaalton> so, I won't push it to git then, instead file a request for removal :)
<mlankhorst> I should probably have to track those cases then, see what drivers didn't update for quantal
<c10ud> hello there, just got home and saw the new nvidia 304.37 (which should fix some bugs i am experiencing) any ETA on the PPA?
<ricotz> c10ud, soon
<c10ud> ricotz, thanks. i'd install by hand but i like keeping my system clean..let's hope i can play soon (since precise, gaming has been a no-no)
<ricotz> c10ud, jfyi, i will upload it to xorg-edgers though, not x-updates
<c10ud> power loss -- ricotz i'm with x-updates, what's the chance of getting it soon?
<c10ud> or, if only a rebuild is needed, i could do the trick in my ppa
<ricotz> c10ud, you should be able to use the x-edgers packages directly, so cherry picking the packages from there without a rebuilt is possible
<c10ud> as soon as they're built i'll try them, thanks
<ricotz> will take some minutes -- https://launchpad.net/~xorg-edgers/+archive/ppa/+sourcepub/2607543/+listing-archive-extra
<c10ud> yes i was just looking at the x64 build, thanks
<c10ud> ricotz, nvidia-current depends on xserver-xorg-core (>= 2:1.11.99.901); so it's a no-no
<c10ud> if there's no x dependant file i can try overriding the dep (!)
<mlankhorst> speaking of which
<mlankhorst> does nvidia-current hardcode the abi yet?
<ricotz> c10ud, ah :\
<ricotz> mlankhorst, yes it does
<mlankhorst> ah great :)
<ricotz> mlankhorst, 11, 12 and 13
<mlankhorst> I should remove the versioned xserver-xorg-core dep and add it to the qbp tree then :)
<mlankhorst> s/tree/ppa/
<tjaalton> bryceh: I had a chat on #ubuntu-release with stgraber and infinity about the mesa in precise-proposed, and we decided it would be best to drop the current version there, and only add the (critical) ivb patch to the one in precise. we can then proceed with further testing of the upstream bugfix releases and provide them post .1 if they're good
<tjaalton> it's ugly but oh well..
<tjaalton> I'll probably create a new branch for this one, or maybe skip pushing it to git since it's a one-off thing
<bryceh> tjaalton, hrm, ok
<mlankhorst> bryceh: finally getting some serious feedback on my fence patches, hopefully close to getting it in dma-buf next now :)
<bryceh> tjaalton, think we should still target 8.0.3 for precise, or move to looking at 8.0.4, or ...?
<mlankhorst> did you take a look yet at lts-backports-quantal stack btw?
<tjaalton> bryceh: yeah.. but this way we can move straight to 8.0.4 or even 8.0.5 since it should be released soon
<bryceh> tjaalton, also did you get a chance to run the piglit tests yourself?
<tjaalton> bryceh: didn't have time to set up the rig today, but will look at it tomorrow
<bryceh> ok, well no hurry, sounds like we have time
<tjaalton> yeah
<bryceh> I'm going to try to get a couple more test boxes constructed and try to get the tests a bit more automated
<tjaalton> I only have one box to test on, and then swap cards as needed :)
<bryceh> I've been setting up stuff to dd reimage the systems between tests to hopefully make it easier to isolate changes and get better fidelity
<mlankhorst> ah, I've been considering using btrfs snapshots for that..
<tjaalton> heh, and I have cobbler
<bryceh> kees had some llvm setup he used
<bryceh> but just dd'ing the images wfm
<mlankhorst> bryceh: but seriously can you look at q-lts-backport? I need some feedback if it's workable or not :)
<bryceh> mlankhorst, sure, what specifically needs reviewed?
<mlankhorst> if you agree with the mechanics
<mlankhorst> for example x11proto don't get renamed, neither does libdrm, mesa gets a patch to build against newer libdrm with old nouveau abi, just to still be able to build from source :)
<mlankhorst> xserver-xorg gets replaced by xserver-xorg-lts-quantal, needs a bit of finetuning though.
<bryceh> maybe given the above discussion, your patched mesa should target 8.0.2 for now; it's unclear if/when we'll get 8.0.3 in precise
<bryceh> mlankhorst, so would you say the critical assumption here is that uprevving libdrm in precise is going to be accepted by the sru crew?
<mlankhorst> pretty much
<mlankhorst> but other than that you can freely switch between new and old xorg stack
<mlankhorst> I still need to add a recommends for linux-lts-quantal to xserver-xorg-lts-quantal so it automatically gets installed, but those who roll custom kernels can still remove it. :)
<bryceh> I personally don't have a problem with putting new libdrm in precise, but I suspect getting it through SRU is going to take some doing
<bryceh> is there a test suite for libdrm?
<mlankhorst> not really
<bryceh> hmm, there's a tests/ dir
<mlankhorst> it's a joke
<bryceh> oh
<bryceh> mlankhorst, what specifically are we needing from libdrm?  any chance we could just cherrypick stuff?
<mlankhorst> nouveau rewrite..
<mlankhorst> and all the parts that the newer drivers require
<mlankhorst> so not really
<mlankhorst> that's the whole reason for updating it in the first place :)
<bryceh> ok well the proto lib stuff is probably minor (although could also take work to get through sru).  The mesa change is fine, basically goes with the libdrm change right?  So really I think we need a definitive answer on libdrm sru-ification
<mlankhorst> yeah
 * bryceh ponders
<bryceh> alright, first let's bring this up to ogasawara.  If we can get kernel team support, that may help.
<mlankhorst> libdrm update makes my life a lot easier, and I've shown that the major obstacle for updating libdrm (nouveau) is solved. :)
<bryceh> but I think before we go further we need to pow wow with an SRU person
<mlankhorst> yeah
<mlankhorst> lets wake up raof now :)
<mlankhorst> he should be used to waking up at strange times
<bryceh> that'd be mean!  ;-)
<bryceh> I'll open an email with ogasawara.  Can you reply and follow up with a more detailed description of the issue?
<mlankhorst> sure
<mlankhorst> but not now, bed :)
<bryceh> mlankhorst, yep
<mlankhorst> Fortunately libdrm is rarely the cause of breakages EXCEPT WITH NOUVEAU :p
<bryceh> mlankhorst, I wonder if we're likely to see similar problems with libdrm in the r and s stacks, or if this'll be a one time thing
<bryceh> (I mean, obviously nouveau isn't going to get rewritten every 6 months, but could be changes in radeon or intel next time...?)
<mlankhorst> I think it's best to keep updating libdrm if it's sane
<mlankhorst> i think there was 1 more thing scheduled for nouveau but fortunately not there yet, new userspace<->kernel abi
<mlankhorst> but seems sna doesn't really require a wild new api in libdrm, so hopefully libdrm becomes boring for now :)
<bryceh> mlankhorst, remind me again what was preventing libdrm from being renamed?
<mlankhorst> plymouth and other things hated it
<mlankhorst> and if libdrm explodes your initramfs might no longer boot
<bryceh> dah plymouth
<mlankhorst> losing xorg can be recovered though 
<mlankhorst> apt-get remove .*lts-quantal will return you to precise x stack
<mlankhorst> or if it removed xorg, apt-get install xorg again after that
<bryceh> mlankhorst, ok and the initramfs issue... what explodes exactly?
<mlankhorst> I ended up with no libdrm.so.2 at all so if you regenerate your initramfs with that..
<mlankhorst> plus i think it was causing the rest of the stack to not switch so easily back and forth
<bryceh> ok
<bryceh> mlankhorst, how much testing have you done of the newer libdrm with the original linux/X stack (plus the driver fixups you've already listed)?
<mlankhorst> 13
<mlankhorst> woops panda hung from io :)
<mlankhorst> bryceh: a light amount, mostly if it builds or not, I should probably test some more locally first
<mlankhorst> but I have the old and new abi for xxv-nouveau in that tree, and old abi mesa. I've built the new abi mesa succesfully too
<bryceh> ok email sent.  sleep well, hopefully leann can give an answer today
#ubuntu-x 2012-08-14
<mdeslaur> is anyone here using an acer iconia W500 tablet with precise?
<mdeslaur> touch events seem to get all messed up after a couple of minutes
<bryceh> mdeslaur, don't think anyone here has that hw.  certainly haven't heard of that problem so far, although I haven't been perusing the precise input bugs
<bryceh> mdeslaur, not aware of any recent sru's for X's input bits, possibly kernel got some update?  Tried booting an earlier kernel?
<mdeslaur> hrm, using mtview...when the problem occurs, mtview is drawing events two inches away from my finger
<mdeslaur> them I switch windows and back, then it's back to being fine for a bit
<mdeslaur> bryceh: I tried with precise release, precise with updates, and precise with proposed
<bryceh> mdeslaur, I do have a fujitsu touch screen, which tjaalton tinkered with last uds, which  had a problem like that, except it was like that all the time
<bryceh> and iirc it was only the x coord that was off
<mdeslaur> hrm, i bought this one because everyone was saying oneiric worked great on it...so I guess I'll try oneiric
<bryceh> mdeslaur, ok so all three of those versions have the same problem?
<mdeslaur> bryceh: yeah, precise is a no-go
<bryceh> precise has the franken-xserver as far as the input stack goes.  that's been at the heart of a variety of input bugs in precise
<bryceh> mdeslaur, alright so booting different kernels probably won't do anything.  xorg-edgers *might* be worth testing.  But I'd check with tjaalton since he might know something relevant.
<mdeslaur> bryceh: cool, thanks
 * mdeslaur tries xorg-edgers crack
<bjsnider> this makes mdeslaur a crackhead
<bjsnider> would you like treatment?
<mdeslaur> bjsnider: this free sample is great!
<mdeslaur> :)
<mdeslaur> lol
<mdeslaur> xorg-edgers broke unity
<mdeslaur> \o/
<bjsnider> "broke' is such a strong word.
<bjsnider> it is functionally challenged
<mdeslaur> hehe
<mdeslaur> unity looks all nice and clean without any icons being drawn in it
<bjsnider> that's a glass-half-full approach
<tjaalton> mdeslaur: that's thd mesa blocker bug for us.. anyway, you could've tried the backport stack ppa
<Sarvatt> mdeslaur: if you need to revert and are on amd64, dpkg -l | egrep 'sarvatt|ricotz|edgers' will give you a full package list, you just remove the ppa sources, apt-get update then add every package returned there to a sudo apt-get install package1/precise package2/precise package3/precise line, just ignore libdrm-nouveau2
<tjaalton> uploaded  mesa_8.0.3+8.0.2-0ubuntu3.2
<tjaalton> to precise-proposed
 * mlankhorst slaps Sarvatt 
<tjaalton> what did he do this time?-)
<mlankhorst> he knows what he's forgotten :D
<tjaalton> i'll package -omap, obsoletes -omapfb
<tjaalton> oh it's packaged already
<tjaalton> and git messed up
<tjaalton> uploaded anyway
<tjaalton> didn't push the branch, it's maintained in collab-maint but wanted to ask the maintainer first
<tjaalton> meh, -msm
<tjaalton> no upstream changes since 2010
<tjaalton> why do we still carry it?
<tjaalton> ogra_: do you know where xf86-video-msm is used?
<tjaalton> oh htc dream / nexus one
<tjaalton> i say purge it
<tjaalton> vbox next, and after that the stack can move
<tjaalton> debfx: i'm looking into patching vbox to build against 1.13..
<mlankhorst> tjaalton: if you want I can do that, it needs 2 things, 1. Disable XAA, 2. compat header
<tjaalton> mlankhorst: ok, go ahead :)
<tjaalton> i started but still trying to figure out the way it's built
<mlankhorst> who cares, debuild it.. :p
<tjaalton> i'll just look at a build log :)
<mlankhorst> debuild -nc >:)
<mlankhorst> but I don't see vboxmouse being built so I guess it uses another way :)
<mlankhorst> oh great it's too dumb to even have xaa, makes things easier though :)
<tjaalton> yeah
<tjaalton> compat-api.h is identical on every driver?
<mlankhorst> no
<mlankhorst> but the idea is the same
<tjaalton> ok
<mlankhorst> the only difference is in those #ifdef XF86_SCRN_INTERFACE, I think things are changed there as needed by the specific driver :)
<mdeslaur> tjaalton: hi, so xorg-edgers didn't solve my touch issue anyway...cnd said it's probably a bug in the gesture stack they're aware of
<tjaalton> mdeslaur: ok, good to know
<tjaalton> sigh
<tjaalton> mlankhor1t: wanna fix -msm too?-)
<mlankhor1t> aw was just done with virtualbox :p
<tjaalton> trying to update sbuild so it supports cross-building
<mlankhor1t> seems virtualbox builds now
<tjaalton> cool
<mlankhor1t> do you have ubuntu in a vm to test with?
<tjaalton> not vbox
<tjaalton> hm, could install it on the quantal machine
<tjaalton> or maybe not
<mlankhor1t> I'll see if I can make it do the netboot thing
<tjaalton> if the dependencies get right, just ship it
<mlankhor1t> because netboot
<mlankhor1t> nah I want to send it in if it's not too much trouble
<tjaalton> let debfx handle that part :)
<mlankhor1t> heh sure
<tjaalton> in the meantime we can upload it to proposed
<mlankhor1t> I'm just rechecking if it builds on old one first
<mlankhor1t> if so I'll just make it a dumb quilt patch
 * mlankhor1t assumes building == working
<mlankhorst> tjaalton: where's msm then?
<mlankhorst> ok seems to work until it complains I overrode my opengl, ship it.. http://people.canonical.com/~mlankhorst/vbox-x1.13.patch
<tjaalton> dget https://launchpad.net/ubuntu/+archive/primary/+files/xf86-video-msm_1.0.1%2Bgit20100122.5f7df591-1ubuntu5.dsc
<tjaalton> thanks
<mlankhorst> tjaalton: yeah but it is really a 2010 snapshot? :o
<tjaalton> yup
<tjaalton> no new upstream versions
<tjaalton> have fun with it kthxbye :)
<mlankhorst> can we drop it and never speak of it again?
<mlankhorst> :o
<tjaalton> well, you can probably wait until we've got confirmation that it's still used
<mlankhorst> yay
<mlankhorst> so ship it to quantal? >:D
<tjaalton> mlankhorst: can't VBOXDRIScreenInit use SCREEN_INIT_ARGS_DECL as well?
<mlankhorst> probably but this works so why bother
<tjaalton> heh
<tjaalton> yeah
<mlankhorst> that function converts it anyhow
<mlankhorst> would also mean defining SCREEN_INIT_ARGS to pass it along
<mlankhorst> it's mostly meant to make xorg<->driver api easier, and this is driver internal :)
<tjaalton> i mean so that it builds against earlier abi too, ie. upstream could take it as-is
<tjaalton> but oh well, they can sort it out
<mlankhorst> it will build against earlier api now..
<mlankhorst> I've built against both for testing
<tjaalton> ah, ok
<mlankhorst> VBOXDRIScreenInit is no longer SCREEN_INIT_ARGS_DECL with either X api, it doesn't pass the pScrn or index on newer :)
<tjaalton> gotcha
<mlankhorst> but geode was a bigger mess, at least this one followed the standard api making it easy :)
<tjaalton> test building before upload
<tjaalton> yep, ship it
<tjaalton> mmh, -ivtvdev is hopefully the last one that remains
<mlankhorst> skip it
<mlankhorst> it's part of universe right?
<tjaalton> multiverse
<tjaalton> even worse :)
<tjaalton> not much happened there either since 2010
<tjaalton> if anything
<tjaalton> so yeah skip it
<tjaalton> added it to the purge list
<tjaalton> 14 drivers there now
<mlankhorst> :-)
<tjaalton> afk for a bit ->
<mlankhorst> I'm going to need that list at one point! :D
<tjaalton> mlankhorst: bug 1034793 :)
<ubottu> Launchpad bug 1034793 in xserver-xorg-video-voodoo (Ubuntu) "Please remove obsolete video drivers from the archive" [Wishlist,Confirmed] https://launchpad.net/bugs/1034793
<mlankhorst> yeah omapfb has been replaced and doesn't even work right in precise
<mlankhorst> brb
<ricotz> mlankhorst, tjaalton, hi :), be aware that 304.37 still seems to be broken with 1.13rc4
<mlankhorst> sigh ._.
<tjaalton> tough
<mlankhorst> ricotz: what's broken then?
<ricotz> mlankhorst, xorg crashes while just starting firefox or running g-s, same issue since 304.x introduced 1.13 support
<ricotz> http://paste.debian.net/plain/183527
<ricotz> havent retraced it though since it has the same symptom
<ricotz> (i mentioned it to aaronp)
 * mlankhorst tries i915 with valgrind
<mlankhorst> hey a conditional jump depending on uninitialised bytes in vprintf..
<mlankhorst> oh and still no synaptics debugging symbols? what went wrong there
<mlankhorst> oh, no merge from debian-experimental which had it
<mlankhorst> tjaalton: hey can you upload synaptics?
<tjaalton> mlankhorst: yup, uploaded
<mlankhorst> thanks :)
<tjaalton> hmm, rejected
<mlankhorst> o.O
<tjaalton> did I not push the previous changed, meh
<tjaalton> yup.. oh well, I'll merge with origin
<tjaalton> there
<mlankhorst> ah k :)
<Sarvatt> holy crap, unity work with today's mesa checkout
<Sarvatt> \o/\o/
<mlankhorst> Sarvatt: ship it!
 * mlankhorst is having some fun with wine
<Sarvatt> someone actually respond to the pull request?
<Sarvatt> sending one with a commit starting with [HACK] maybe wasnt a good idea :P
<mlankhorst> Sarvatt: do you think they honestly care about what I send any more?
<mlankhorst> I was hoping to stir up some discussion but that seemed to have failed
<tjaalton> where was this?
<mlankhorst> wine ml
<mlankhorst> sent a pull request to their patch mailing list in the hopes of stirring up some discussion, surprised Sarvatt knows :p
<tjaalton> ah
 * mlankhorst pokes Sarvatt 
<Sarvatt> mlankhorst: #nouveau scrollback :)
<mlankhorst> ah ofc
<mlankhorst> really frustrating though
<Sarvatt> was surprised to see fedora was shipping it even, any idea if YokoZar is going to enable it in ubuntu?
<mlankhorst> no idea, I've been using it for ages lol
<Sarvatt> holy crap, wine in wheezy got upgraded to 1.4.1
<mlankhorst> the ubuntu-wine ppa has it though
<mlankhorst> quite stable
<mlankhorst> Sarvatt: fedora ships wine modifications? not that I know of at least..
<Sarvatt> http://pkgs.fedoraproject.org/cgit/wine.git/tree/wine.spec
<Sarvatt> check out may 28th
<mlankhorst> oh :p
<Sarvatt> http://pkgs.fedoraproject.org/cgit/wine.git/tree/wine-pulse-1.5.4.patch they use that, no attribution on it so no clue if its yours or the other one
<mlankhorst> well it is, just an old version
#ubuntu-x 2012-08-15
<tjaalton> mlankhorst: bad news, best to keep -msm for now :)
<tjaalton> so if you could port it as well that would be great
<mlankhorst> sigh I'll look into it :p
<tjaalton> :)
<tjaalton> i started it tho, want the preliminary patch?
<RAOF> Hey all!
<tjaalton> howdy!
<tjaalton> and congrats :)
<RAOF> Ta!
<mlankhorst> tjaalton: sure
<mlankhorst> my job of today is mostly poking an intel guy till he reviews stuff anyway :)
<tjaalton> mlankhorst: http://paste.ubuntu.com/1148310/ the compat-api.h was just dumped from some other driver, edit as needed :)
<tjaalton> not tested in any way, other than that the driver does not build on amd64 :P
 * mlankhorst tries on his panda
<Sarvatt> debian/patches/111_armel-drv-fallbacks.patch might need fixing after all these drivers being dropped
<tjaalton> RAOF: back to work or just popping in?-)
<tjaalton> Sarvatt: yep
<mlankhorst> tjaalton: well was on canonicaladmin, tuesday was his last day off :p
<Sarvatt> RAOF: what the heck are you doing on? contrats man!
<tjaalton> mlankhorst: hah, ok :)
<tjaalton> Sarvatt: actually, rsalveti is trying to get rid of the patch
<Sarvatt> RAOF: all your mesa commits got commited, out of tree builds work again and unity works so the system compositor ppa could be updated where robert_ancell can use it
<Sarvatt> today was the first day where unity works, good timing :)
<mlankhorst> and we're about to break nvidia by moving x1.13 from proposed
<mlankhorst> :p
<Sarvatt> oh noes!
<Sarvatt> but it compiles
<Sarvatt> driver bug we cant fix, darn
<mlankhorst> oh and slashdot ran an article linking to phoronix about the shame of wayland not being in quantal, I think suppuku is the honorable way ;)
<tjaalton> seppuku you mean? getting prepared..
<mlankhorst> :D
<mlankhorst> darn I need the quantal stack on my panda now..
<Sarvatt> mlankhorst: but you'll need to test the backport stack tomorrow and wont be able to
<mlankhorst> oh no, you were supposed to test it :p
<Sarvatt> mlankhorst: are blobs in there by any chance?
<mlankhorst> not yet, suppose I could copy nvidia-current over
<Sarvatt> i'm running edgers on my main machine where ppa-purge doesnt work so thats the main demotivation atm
<Sarvatt> i have another precise machine with the blob i could remove edgers and test
<Sarvatt> libdrm is up in the air
<mlankhorst> tjaalton: great that driver is messed up
<tjaalton> mlankhorst: you don't say..
<mlankhorst> oh hey it has a strcasecmp..
<mlankhorst> I can only confirm it doesn't break existing compiles at the moment..
<mlankhorst> that's all I can do, sorry :(
<tjaalton> it compiles?
<mlankhorst> on old x abi, but I think it would on new one too now
<mlankhorst> oh wait I can compile armel in my ppa
<tjaalton> nice
<tjaalton> uploaded evdev 2.7.3
<mlankhorst> I'll see if it builds there or not
<seb128> you guys noticed that our libxrandr is outdated compared to Debian (1.3.2 vs 1.4)? is that wanted?
<tjaalton> seb128: the new one is in quantal-proposed
<seb128> tjaalton, no it's not
<tjaalton> no?
<seb128> no
<seb128> that's why I'm pointing it
<seb128> our version pages uses proposed :p
<seb128> http://people.canonical.com/~platform/desktop/versions.html
<mlankhorst> woops forgot to check if that ppa had proposed enabled or not
<tjaalton> seb128: ok, let's sync it then
<tjaalton> done
<seb128> tjaalton, thanks
<tjaalton> thanks for the reminder :)
<mlankhorst> tjaalton: https://launchpad.net/~mlankhorst/+archive/x-1.13/+build/3725585
<tjaalton> :)
<seb128> tjaalton, you also have those in red
<seb128> libxvmc 	2:1.0.6-1ubuntu2 	2:1.0.7-1
<seb128> xinput 	1.5.99.1-0ubuntu2 	1.6.0-1
<seb128> xserver-xorg-input-evdev 	1:2.7.0-2~ubuntu1 	1:2.7.1-1
<seb128>  xserver-xorg-input-mouse 	1:1.7.2-2build1 	1:1.7.2-3
<seb128>  
<tjaalton> I just uploaded evdev
<seb128> in case you didn't notice them either ;-)
 * seb128 pets versions
<mlankhorst> but seems I used a too old version number since i used the precise one
<tjaalton> yeah we have another list I'm following: http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/package_status.html
<mlankhorst> oh great xorg 1.13 does a bunch of incompatible crap :(
<debfx> tjaalton: what do I need to handle?
<tjaalton> debfx: there's a patch added to virtualbox in quantal-proposed, builds against the new abi
<tjaalton> debfx: so if you have channels to shove that upstream it would be nice :)
<debfx> tjaalton: is it compatible with all the prehistoric x server versions? ;)
<mlankhorst> still builds against the old abi, too!
<tjaalton> should be
<mlankhorst> or at least against the one in precise
<tjaalton> mlankhorst tested against the current one
<tjaalton> oh that
<Sarvatt> does the new virtualbox release from today already compile against 1.13? :P
<mlankhorst> not that I know of?
<mlankhorst> or at least not last time I checked svn
<Sarvatt> by today i mean my today, yesterday
<tjaalton> beta1 was released aug 3rd, it doesn't
<Sarvatt> 4.2 beta 1 august 14th?
<tjaalton> oh rc1 tagged on 13th
<mlankhorst> Sarvatt: svn trunk didn't seem capable of building it..
<Sarvatt> i dont see anything in the notes :(
<Sarvatt> just 1.12 support for solaris
<mlankhorst> so what made you think it would?
<mlankhorst> anyhow that patch makes it build at least
<mlankhorst> next build attempt for msm..
<tjaalton> seb128: merged libxvmc :)
<seb128> tjaalton, great ;-)
<tjaalton> and put the changes to git
<mlankhorst> https://launchpad.net/~mlankhorst/+archive/x-1.13/+build/3725654 next msm attempt
<mlankhorst> hopefully last one :)
<Sarvatt> seb128: thanks for the heads up
<seb128> yw ;-)
<tjaalton> xinput can be synced
<tjaalton> updated the branch though
<Sarvatt> i tend to merge crap and don't find out its actually uploaded to debian till way later, like libxvmc just then
<Sarvatt> should have been on the ball, april!
<tjaalton> who uses that anyway, doesn't matter one bit :)
<mlankhorst> xvmc is mostly dead
<Sarvatt> yeah that update had like no actual fixes lol
<mlankhorst> when you have fast enough hardware to call xvmc, you don't need xvmc
<mlankhorst> yessss it's compiling msm :D
<tjaalton> for how long? :)
<mlankhorst> vdpau on the other hand is pretty nice
<mlankhorst> https://launchpad.net/~mlankhorst/+archive/x-1.13/+build/3725654
<mlankhorst> done compiling afaict
<mlankhorst> ship it?
<tjaalton> obviously
<mlankhorst> ok just grab it from ppa and bump version number
<Sarvatt> mlankhorst: you actually fixed msm??
<mlankhorst> wasn't that broken
<mlankhorst> tjaalton: ok so just omapfb being replaced by omap then?
<tjaalton> mlankhorst: yeah, basically just needs the omap driver enabled in the kernel, then -omapfb removed from the archive
<Sarvatt> the msm driver traditionally has just been driver drops from the vendor, who stopped caring forever ago, i spent a few days fixing it up for one xserver abi update to get ignored because it got updated in a new drop from the vendor so stopped caring
<mlankhorst> would be a great thing to have
<tjaalton> -msm uploaded
<mlankhorst> Sarvatt: oh the thing is I don't care either about msm or virtualbox one hoot, it was just getting in the way of getting new xorg-server ready :)
<Sarvatt> debian/patches/111_armel-drv-fallbacks.patch in xserver is probably totally hosed, wonder if anyone cares
<Sarvatt> yeah i agree but those are universe packages that are community maintained, why we need to care.. who knows
<mlankhorst> because x is special
<mlankhorst> :p
<Sarvatt> meanwhile, something like fglrx is broken and wont be fixed until a few months after we break it, thats a million times more important than any of that crap
<RAOF> Sarvatt, mlankhorst: Last time I spoke with orga about that (which was during 11.10, IIRC), he intimated that he just wanted a heads-up on xserver transitions and we could palm off arm-specific drivers to his team to fix.
<Sarvatt> and if we dont break it it wont ever be fixed
<RAOF> That said, things have changed vis-a-vis the importance of arm-specific drivers, so we probably need to care :)
<mlankhorst> RAOF: oh sure, but in this case I know the procedure so it would have been more work to make him do it then to do it myself
<Sarvatt> RAOF: back when ubuntu-arm existed?
<RAOF> Sarvatt: Yeah, pretty much :)
<mlankhorst> RAOF: do you still want to do the radeon fencing thing?
<RAOF> I won't have the time, much as I'd like to.
<mlankhorst> ok I gathered as much, was already investigating at doing it myself..
<tjaalton> huh, power cut off
<tjaalton> need to shutdown
<tjaalton> was writing that rsalveti is trying to fix the arm driver loading in the server
<Sarvatt> do default drivers in the xorg metapackage need to be changed?
<tjaalton> Sarvatt: the big difference is that we can fix this shit..
<tjaalton> no
<tjaalton> arm* depends on silly drivers..
<Sarvatt> yeah bryce tried to reach out to the arm people years ago and noone responded
<tjaalton> not any of this arm-specific stuff
<Sarvatt> they dont use xserver-xorg-video-all
<Sarvatt> cirrus sisusb fbdev vesa? that doesnt make any sense hmm
<Sarvatt> modesetting omap fbdev maybe would be better
<mlankhorst> yeah :s
 * mlankhorst wonders if failsafe-x works on arm
<ogra_> mlankhorst, at times :)
<ogra_> though it usually gets me into a stuck situation (like no pointer working so that i have to switch to tty and stop lightdm)
<ogra_> we definitely default to fbdev on all arm devices ... and we use xserver-xorg-video-all on all arm images 
<ogra_> (ubuntu-arm images only differ in bootloader and kernel from x86 images in quantal, seeds are identical across the archies)
<ogra_> as for the three binary arm video drivers we have in the archive .... we dont have armhf binaires for the omap3 one, feel free to ignore it ... for omap4 pvr we are supposed to get a new binary blob very soon (current one doesnt work with the current kernel), for nvidia tegra we are waiting for a fixed binary blob that supports xorg abi 13
<ogra_> if you have any other questions, #ubuntu-arm still exists ... even though there isnt a team called like that anymore ;)
<Sarvatt> vesa and cirrus definitely don't make sense and thats being brought in via xserver-xorg-video-all on arm, omap is the only real open source driver available, xf86-video-modesetting is for exynos  and any other kms driver, fbdev for the other stuff like tegra and fallback with out the blobs installed, debian/patches/111_armel-drv-fallbacks.patch in xorg-server could be updated to load the blob drivers automatically without an xorg.conf like it was do
<Sarvatt> ing except not touching it will make omap blobs still work
<Sarvatt> its just loading the pvr driver if /sys/devices/platform/omap exists right now, none of the other matches will do anything since the drivers are being dropped
<Sarvatt> tegra should be added there at least, now sure how to tell if its a tegra, if those fail fbdev would be used, loadin pvr for omap might not make sense because xf86-video-omap exists
<Sarvatt> 7 am? not asleep yet? goodnight :)
<mlankhorst> ;)
<mlankhorst> ogra_: yeah I'm just using the ti omap ppa, seems to work for me on omap4 a lot better than stock precise
<Sarvatt> mlankhorst: play a divx video in totem
<ogra_> apart from installing a ton of unsupported packages :)
<mlankhorst> and yet it still works better than precise.. what does that mean? :)
<ogra_> mlankhorst, that TI didnt invest much time into making the driver work with the official kernel
<Sarvatt> they're forcing a specific gstreamer output sink via a gconf setting, which doesnt support normal videos only stuff that can be accelerated :P
<ogra_> we dont have any control over it 
<mlankhorst> Sarvatt: heh... have you tried playing video unaccelerated then? :D
<mlankhorst> count the frames..
<ogra_> Sarvatt, well, only if you installed the packages from the PPA
<ogra_> (there is a reason we couldnt ship their codecs ;) )
<Sarvatt> i just looked over the ppa when i was doing some nightmare with cedarview (aka poulsbo aka pvr sgx545 used there) video acceleration, not playing back anything but low profile h264 isn't really an option on the desktop :)
<mlankhorst> shrug :p
<mlankhorst> it's not the profile that matters, it's the resolution :D
<Sarvatt> it can play back 1080p h264 3.1 high profile fine
<Sarvatt> play a divx video.. haha
<Sarvatt> something not gpu accelerated
<Sarvatt> it just wont even play if you force the output sink to pvrwhateversink in gconf like the ppa is doing
<Sarvatt> and thats the only way to use gstreamer-vaapi in gnome
<mlankhorst> >implying you can call the unaccelerated slideshow 'playing' :D
<mlankhorst> tjaalton: anything else I can do for x1.13?
<tjaalton> mlankhorst: can't think of anything atm
<mlankhorst> ok great :)
 * mlankhorst reading into radeon
<mlankhorst> I feel like being evil and convert radeon_fence to dma_fence :p
#ubuntu-x 2012-08-16
<tjaalton> doing mesa update for quantal
<tjaalton> according to the list it should be possible to build osmesa and the rest in a single pass
<tjaalton> with current git
<tjaalton> hmm, maybe I'll drop the extra osmesa bits from the current version first, then mess with the new one
<tjaalton> should have a branch somewhere..
<tjaalton> in other news, the x stack will be moved to quantal later today
<tjaalton> and the obsolete drivers (15) removed as well
<RAOF> Hurray!
<ogra_> tjaalton, is there a list with these 15 ?
<tjaalton> ogra_: yup, bug 1034793
<ubottu> Launchpad bug 1034793 in xserver-xorg-video-voodoo (Ubuntu) "Please remove obsolete video drivers from the archive" [Wishlist,Confirmed] https://launchpad.net/bugs/1034793
<ogra_> merci :)
<ogra_> oh, displaylink :(
<tjaalton> -modesetting replaces it
<ogra_> ah, there is a replacement :)
<tjaalton> there's a kms driver for it in the kernel
<tjaalton> and 12.10 will have hotplug :)
<ogra_> yeah, great
<tjaalton> or, should have
 * ogra_ is surprised to not see geode ... i doubt our kernel can even run on them nowadays
<ogra_> (i686 and PAE ...)
<tjaalton> ogra_: true, but at least it got ported, so keeping it for now
<tjaalton> ok, let's see if this beast builds..
<tjaalton> stole whatever was useful on the edgers mesa snapshot
<tjaalton> nope
<tjaalton> probably needs a newer wayland..
<tjaalton> 0.95 available
<tjaalton> huh, dpkg in precise doesn't know how to handle xz?
<tjaalton> insists on building a native package even though I have the tarball.xz
<mlankhorst> yay scoping
<mlankhorst> the dma-buf stuff keeps getting more complicated the longer you look at it :p
<ricotz> tjaalton, using xz tarballs works like forever ;) (at least since lucid)
<tjaalton> ricotz: yeah, with source format 3.0
<tjaalton> which then continues to annoy git users
<ricotz> tjaalton, right
<tjaalton> just trying to upload wayland 0.95
<ricotz> i see
<tjaalton> alright, updating wayland wasn't enough
<tjaalton> to build mesa
<tjaalton> /usr/bin/makedepend: warning:  vmw_target.c (reading /usr/include/features.h, line 324): cannot find include file "bits/predefs.h"
<tjaalton> that's where it starts..
<tjaalton> to go wrong
<tjaalton> for some reason doesn't search the multiarch path
<tjaalton> and this on precise
<tjaalton> mlankhorst: hey, forgot to ask you to test something.. test what driver the panda uses with the quantal stack, and if it works
<mlankhorst> sure
<tjaalton> thanks, when that's done I'll poke infinity to move the lot
<tjaalton> so, I broke weston, which then needs newer libxkbcommon
<bryceh> tjaalton, oops :-)
<tjaalton> yeah, someone already mailed me..
<tjaalton> nearly done with it, weston can wait until tomorrow..
<tjaalton> there
<bryceh> anyone know why tseliot uses github for nvidia-settings rather than alioth?
<bryceh> oh hrm debian maintains it in svn
<tjaalton> heh, besides they're basically forked for good
<tjaalton> In file included from xwayland.h:28:0, from window-manager.c:36:
<tjaalton> ../compositor.h:334:2: error: unknown type name 'PFNEGLQUERYWAYLANDBUFFERWL'
<tjaalton> meh
<tjaalton> no weston today
<tjaalton> Sarvatt: if you have ideas how to make weston 0.95.0 build, I'm all ears (tomorrow)
<tjaalton> but now ->
#ubuntu-x 2012-08-17
<tjaalton> woohoo, the new stack has moved, and 15 video drivers purged
<RAOF> Woo!
<bryceh> yay
<bryceh> yay is one of the two words ZoÃ« knows
<bryceh> the other word being 'dada'
<bryceh> (yay!)
<tjaalton> :)
<Sarvatt> bryceh: which was first? :)
<bryceh> Sarvatt, of course they came together ;-)
<ripps> okay, latest xserver-xorg updates prevent me from logging in now
<tjaalton> using nvidia?
<tjaalton> teh blob
<tjaalton> heh
<RAOF> Blobitty blob blob.
<RAOF> BOOM!
<tjaalton> yeah it'll do that :)
<tjaalton> lo and behold, --enable-gl-osmesa breaks xa-vmwgfx build?
<tjaalton> nice
<RAOF> Win!
<ripps> I've managed to login using gnome classic (no effects), can someone help me figure this out?
<tjaalton> using the nvidia blob?
<ripps> tjaalton: yes, only choice, nouveou doesn't work with my card
<tjaalton> you're screwed then
<tjaalton> sorry
<ripps> that wasn't the answer i wanted... any workarounds, maybe i can help figure out what's going wrong
<tjaalton> the driver is broken
<tjaalton> not much we can do about it
<tjaalton> than wait for a newer version
<tjaalton> nvidia is aware of it AIUI
<tjaalton> you can roll back of course
<tjaalton> though it's kinda tedious
<tjaalton> i'll send a note to ubuntu-devel
<ripps> well, things seem to work well enough in gnome-classic, I can even run glxgears, so it must only be in the compositing. I can survive here for a little while
<tjaalton> iirc it's related to glx
<tjaalton> breaks with the current xserver
<ripps> ha, I'm even able to use minecraft, so if it's glx, then it's pretty specific part of it that's causing it
<tjaalton> ok maybe it wasn't that
<tjaalton> hm it's the swrast targets that make the build fail, damn threads making the output nonlinear :)
<tjaalton> mesa build
<tjaalton> maybe we can drop it anyway
<tjaalton> probably best to break the build more on the ubuntu branch :P
<tjaalton> RAOF: quick ack; drop swrast, we have llvmpipe anyway?
<RAOF> Does that work on arm?
<RAOF> Or !{x86_64,i386}?
<tjaalton> it's not built elsewhere
<tjaalton> ie. not tested either i guess
<RAOF> So we'd no longer have a software fallback on !{x86_64,i386}?
<RAOF> That seems bad
<RAOF> (Sorry for slow replies; baby)
<tjaalton> sure
<tjaalton> I'll check the actual failure then :)
<tjaalton> /usr/bin/ld: cannot find -l-O2
<tjaalton> eh
<tjaalton> typo somewhere?
<tjaalton> oh it was reported already
<tjaalton> on mesa-dev
<tjaalton> --disable-shared-glapi should do the trick
<tjaalton> well, it got further
<RAOF> We don't want to build with --disable-shared-glapi, though.
<tjaalton> it doesn't make sense for swx11
<RAOF> Oh, we're still building swx11?
<tjaalton> that's what I meant yes :)
<tjaalton> sorry, not swrast then
<tjaalton> ln -f .libs/libGL.so.1.6.0 ../../../../x86_64-linux-gnu/libGL.so.1 CC     fakeglx.lo
<tjaalton> ln: accessing `.libs/libGL.so.1.6.0': No such file or directory
<tjaalton> how it fails now
<RAOF> We should just dump swx11 like a month-old tuna
<RAOF> As far as I can tell it's entirely pointless.
<tjaalton> yeah
<RAOF> If you'd said swx11 in the first place, rather than swrast, I'd have been all for it :)
<tjaalton> i'll do it on the ubuntu branch though
<tjaalton> hehe
<mlankhorst> morning
<tjaalton> howdy
<tjaalton> mlankhorst: enjoy the new x in quantal :)
<mlankhorst> I saw :)
<mlankhorst> \o/
<tjaalton> i hope to get mesa ready for testing today
<mlankhorst> 804 or 8.1?
<tjaalton> probably not a good idea to upload it before the weekend though
<tjaalton> 8.1
<tjaalton> 8.0.4 is there already
<mlankhorst> indeed not, just leave it for monday :)
<mlankhorst> although I can't argue against swx11 being gone
<tjaalton> yeah it was the diff from edgers that should make it build
<tjaalton> lots of packaging changes needed though
<mlankhorst> no surprises there, they're finally fixing the make procedure :)
<tjaalton> ooh, a single-pass build comes as a result of dropping swx11 and --enable-gl-osmesa
<mlankhorst> yay
<RAOF> WIN!
<mlankhorst> thanks raof :p
<tjaalton> RAOF: should 116_use_shared_galliumcore.diff or the equivalent be upstream?
<RAOF> tjaalton: Bits of it are, I think.
<RAOF> I forget precisely what happened to it.
<tjaalton> ok just wondering since it failed to apply but can't find where it should apply
<tjaalton> I'll probably disable it for now
<RAOF> Yeah, should be fine.
<RAOF> Upstream would ideally like that to be turned into ârejig things so that *all* the dri drivers are built into a single, monolithic soâ
<tjaalton> oh
<RAOF> But has been moderately happy with what has actually gone upstream: ie - the dricore & co patches.
<tjaalton> yeah
<tjaalton> ok, build passed, now on to debian/*.install.in..
<seb128> tjaalton, hey, do you have a bug reference for the nvidio,xorg 1.13 issue?
<tjaalton> seb128: bug 1037896 seems like a good master bug
<ubottu> Launchpad bug 1037896 in nvidia-graphics-drivers (Ubuntu) "Starting Firefox kills xserver immediately" [Undecided,Confirmed] https://launchpad.net/bugs/1037896
<seb128> tjaalton, thanks
<seb128> tjaalton, you don't have any bug with a stacktrace or details?
<seb128> how come we pushed a stack which we knew would break nvidia?
<tjaalton> seb128: no, it's nvidia so no point getting one
<tjaalton> -release wanted to get it in
<seb128> who in release?
<tjaalton> -proposed is not meant for testing, but for getting the archive in shape
<seb128> right
<tjaalton> can't remember
<seb128> so, why was that stack pushed to proposed when it was knew to break nvidia? ;-)
<tjaalton> should blobs prevent us moving forward?
<tjaalton> fglrx will not work until closer to release..
<seb128> not that discussion again ;-)
<tjaalton> most likely
<tjaalton> hehe
<tjaalton> ok
<seb128> the issue is that breaking most of product stategy boxes a week before feature freeze is not a smart move for us
<seb128> it means they are not able to work on compiz,unity anymore
<seb128> and that screw us all
<tjaalton> just put xserver on hold
<seb128> you need to reach the people and told them before they press their morning upgrade button
<seb128> they have been told Ubuntu was to be usable every day
<tjaalton> I've sent an email to ubuntu-devel
<tjaalton> meh
<seb128> right, not everybody reads ubuntu-devel in the world :-(
<seb128> we have lot of users out of -devel subscribers
<tjaalton> "don't upgrade a week before FF" is what the small print should say :)
<seb128> they upgraded a long time ago
<seb128> on the promise that Ubuntu was usuable every day
<tjaalton> well I can't reach out to everyone
<seb128> and they just got screwed
<seb128> yeah, I'm not blaming you
<seb128> but we need to stop breaking users this way
<seb128> we need to figure a way to put xserver on hold for a class of users
<tjaalton> it should've been copied there last week
<seb128> like nvidia users
<tjaalton> that's easy
<tjaalton> tseliot: upload a new nvidia-current that doesn't provide the new abi
<tjaalton> why didn't I think of this before..
<tjaalton> now lunch ->
<seb128> why is the driver providing the abi if it's not working?
<seb128> tjaalton, thanks
<tseliot> tjaalton: I'm about to upload 304.37 which should work with the new abi
<tjaalton> well it's _supposed_ to work with it
<tjaalton> tseliot: fixing the issues?
<seb128> tjaalton, and sorry the discussion landed on you, good work for the transition, it's nothing personal ...  it's just creating issues and it would be nice to figure how we can do better about that
<tjaalton> no problem
<tseliot> tjaalton: I have to test it on quantal first
<tjaalton> well the current one is broken, you can't break it any more :)
<tseliot> heh
<tjaalton> anyway, now that nvidia-* (and in future fglrx?) provide the static list of abi's they work with, we can drop the latest one if there are issues..
<tjaalton> to prevent this from happening again
<tseliot> right
<tjaalton> it would still allow us to move forward, just keeps the sorry users from upgrading
<tjaalton> of course some would still say "screw it, I'm installing it by hand!" and come here later..
<tjaalton> besides, it would be great for the devs to use vesa+llvmpipe for a change, and fix it ;)
<om26er> Hi! there have been a bug in nvidia which have caused X to crash and return users to login screen. People are not reporting that the latest version of  nvidia driver have fixed the issue for them
<om26er> bug 973096
<ubottu> Launchpad bug 973096 in nvidia-graphics-drivers (Ubuntu) "Nvidia driver causes xorg crash" [Critical,Triaged] https://launchpad.net/bugs/973096
<tjaalton> eh, this bug is old
<om26er> how will we get it fixed in 12.04?
<tjaalton> oh I thought you meant quantal
<om26er> tjaalton, yeah, I am talking about 12.04
<om26er> is there any way to provide 12.04 users with latest nvidia driver as updates? or do we just update point releases of nvidia drivers as well?
<tjaalton> hm, glsl fails to build properly
<tjaalton> ie. no .so
<tjaalton> ah, airlied had noticed it as well
<tjaalton> might be something else though, it's not a fatal error here
<agrester_1> Is anyone available to give some emergency advice
<tjaalton> if you're on quantal + nvidia, no
<agrester_1> Okay, no Precise 12.04 LTS, basically heres my problem, I manually installed the Nvidia 304.37 drivers manually through the *.run from Nvidia, and each time Ubuntu pushes software updates and packages some file gets changed and the Nvidia installation gets corrupted
<tjaalton> tseliot: had time to test the driver yet?
<tjaalton> agrester_1: you get to keep both pieces
<tjaalton> once you touch the upstream installer, all bets are off
<agrester_1> If I was to use X-SWAT PPA and install drivers from there, would this endless --sanity check and reinstall dance end?
<agrester_1> tjaalton, would the X-Swat PPA driver packages solve this problem?
<tjaalton> i don't know, but i'm sure it would bring other issues
<agrester_1> This is hopeless, I have to switch back to Windows
<agrester_1> Im so demoralized by this
<agrester_1> Most of what I do in Ubuntu these days is just fixing stuff constantly...
<agrester_1> Rather than actually getting work done
<tjaalton> such is life
<agrester_1> Then Shuttleworth's idea is impossible...
<Prf_Jakob> Btw, is it possible to test the no Unity2D quantal stuff?
<tjaalton> Prf_Jakob: yes, just move your dri driver aside
<tjaalton> gone ->
<Prf_Jakob> Well that or turn off 3d in the guest :)
<agrester_1> Heres the messed up thing...according to the Nvidia sanity checker a recent Ubuntu update has "The installed symbolic link '/usr/lib/libOpenCL.so' no longer exists.", I checked apt-file and the only possible update that could have removed that file is either Nvida-Current (which I don't have installed) or FGLRX which is part of an ATI driver package...
<tseliot> tjaalton: I had to reinstall Quantal but I'll test the driver today
<bjsnider> tseliot, what do you think of: https://launchpadlibrarian.net/112810892/buildlog_ubuntu-precise-amd64.nvidia-settings_304.37-0ubuntu1~precise~xup1_FAILEDTOBUILD.txt.gz
<mlankhorst> sigh from time to time this whole reservation business makes me crazy..
<tseliot> bjsnider: I'll investigate the issue
<bjsnider> thanks. keep me posted
<bjsnider> the i386 versions all build fine
<tseliot> tjaalton: lightdm starts but then Unity dies
<tjaalton> tseliot: ok, so please upÃ¶oad a version that drops the abi providws for the xserver
<tseliot> tjaalton: yes, that's exactly what I plan to do. I'll have a chat with Nvidia today
<agrester> Having gone out for a light walk and cleared my mind...if I use X-SWAT PPA to install the Nvidia 304.37 drivers will I have any problems with Nvidia dependencies and libraries being messed with by other updates or will they be left alone by apt-get?  And are there major advantages to doing X-SWAT versus using the NVIDIA-304.37.run scripts? 
<agrester> If anyone has any advice or suggestions feel free...
<bjsnider> https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia?action=show&redirect=RestrictedDrivers%2FNVIDIA
<bjsnider> if you used the nvidia-installer you may have damaged your system
<bjsnider> you need to re-run the installer with --uninstall
<agrester> Okay, then add 'ppa:ubuntu-x-swat/x-updates', update and then install nvidia-current to obtain the 304.37 drivers?
<bjsnider> install through jockey so it works right, yes
<agrester> Okay...
<agrester> bjsnider: thanks for the help appreciate it
#ubuntu-x 2013-08-16
<Sarvatt> so.. people got signed up for debian X backports by a kernel guy...? libdrm rename in stable like its that easy?
<RAOF> Yeah, there's no problem there, right? :)
<Sarvatt> who's gonna do all this packaging new mesa that only binds the drivers to new pciids and stuff? you can't use dri drivers from 9.2 (for broadwell) with 8.0 libGL anymore..
<Sarvatt> err sorry, 9.3, 9.2 dri drivers work fine
<Sarvatt> we may end up having to do something similar for ubuntu to get broadwell on 12.04.4 but at least it'll be 9.3 or 9.4 libGL and the dri driver will work
<Sarvatt> new mesa source package that only ships i965_dri.so that is
<Sarvatt> ah wait, just realized the plan is broadwell in 13.10, before any friggin code is released
<RAOF> Heh.
<Sarvatt> kernel side is easy, just ship http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/ in dkms format.. mesa is gonna be a PITA
<Sarvatt> jcristau: are you at debconf to say how crazy that is? renaming the rest of the stack is a huge hack but it "works", libdrm is nuts. we actually update libdrm directly in the lts regardless of the stable rules because renaming it breaks the world
<Sarvatt> then again plymouth isn't basically "essential" in debian thanks to upstart..
<Sarvatt> http://cgit.freedesktop.org/mesa/mesa/commit/?id=9f07ca11c1797ac12de1e1c6aef13cf58824b5f5 breaks using newer dri drivers with squeeze mesa
<jcristau> Sarvatt: vorlon wants to change that (upstart)
<jcristau> Sarvatt: i don't think anyone signed up for the mass rename though
<jcristau> so far the only thing that was agreed is to try and ship compat-drivers for the kernel
<jcristau> and have the installer use it if you have such and such hw
<tjaalton> ooh, xorg bof in 25 :)
<tjaalton> @debconf
<jcristau> yeah.  probably not video though, i submitted the bof last night at like 11:30pm
<jcristau> we were like "hey, look, there's an empty slot in the main talk room, let's steal that"
<tjaalton> hehe, ok
<jcristau> tjaalton: actually there are video team people in the room, so maybe they'll do it anyway
<tjaalton> nice
<tjaalton> that went well :)
<mlankhorst> because the mass rename worked so well for ubuntu
<mlankhorst> i haven't even tried only backporting the drivers and rename them, you have to be pretty crazy to do that
<tjaalton> mlankhorst: heh, rick has a new hybrid machine, and nouveau thinks there's vga-1 connected, lp1212677
<tjaalton> nice, stuck touch input with saucy.. now to test the same with the latest xserver
<tjaalton> it finally got unblocked
<tjaalton> yup, seems to be fixed
<jcristau> mlankhorst: actually i have no clue how the mass rename worked for ubuntu.  all i know is it seems like a crazy amount of work that there's no way we can pull off in debian.
<mlankhorst> jcristau: renaming mesa is even crazier..
#ubuntu-x 2014-08-12
<pwuertz> Hi, I found a conflict when loading "libGL.so" on systems with the nvidia driver installed. The "libgl1-mesa-dev" package installs a symlink "/usr/lib/x86_64-linux-gnu/libGL.so" that defaults to mesa.
<pwuertz> That symlink shouldn't exist, right?
#ubuntu-x 2014-08-13
<ScottK> Would some X smart person (i.e. not me) have a look at Bug 941826 and tell me what package gets the blame?
<ubottu> bug 941826 in python-qt4 (Ubuntu) "PyQt cannot compile shaders with Ubuntu's Nvidia drivers" [Undecided,Confirmed] https://launchpad.net/bugs/941826
<RAOF> That bug title promises much!
<ScottK> I'm pretty convinced it's not PyQt's fault, but ICBW.
<RAOF> Yeah, it's not PyQt's fault.
<ScottK> Great. I can relax then.
 * ScottK was not looking forward to convincing a somewhat grumpy upstream to care. 
<ScottK> Would you please comment in the bug (if you didn't).
<RAOF> Just wrangling the bug stati now.
<ScottK> Thanks. 
<RAOF> My, nvidia-331's postinst is pretty big!
<RAOF> Hm. On first inspection, I don't see how that happens.
<RAOF> Anyway; retitled, and invalidated the Qt* tasks. It'll be one of nvidia-331 or libgl1-mesa-dev's fault.
<pwuertz> RAOF: I'd say the mesa package is to blame. The symlink /usr/lib/x86_64-linux-gnu/libGL.so shouldn't exist. It makes libGL.so always default to mesa instead of the choice made in /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf.
<tjaalton> pwuertz: eh, of course it defaults to mesa since the package installs it
<pwuertz> Since /usr/lib/x86_64-linux-gnu has precedence over anything else
<tjaalton> if some other pkg wants something else, then it needs to provide the solution
<pwuertz> tjaalton: the idea of the setup as i understand it is to have multiple libGL versions living peacefully next to each other, and you select the one you want to have as the default by linking the right /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf
<tjaalton> well nvidia et al used to divert the files instead of relying on ldconfig priorities, and back then this wasn't a problem I guess
<pwuertz> tjaalton: by just owning a symlink in the global lib directory you always claim to be the default libGL.so.. and there is nothing another package can do to prevent that
<tjaalton> sure there is, divert the link
<pwuertz> but it is owned by the package.. you cannot override it, can you?
<tjaalton> but diversions come with other problems, which is why they got replaced by this
<tjaalton> google dpkg diversion
<tjaalton> man dpkg-divert
<pwuertz> if 2 packages claim ownership over the same file the package management reports a conflict, doesnt it?
<tjaalton> no
<tjaalton> not if the other one diverts it
<pwuertz> ok... lets put it in a different way.. there is already a mechanism in ubuntu to select the correct libGL instead of using the global lib directory.. why not just use that?
<pwuertz> its a mistake
<tjaalton> so what is it?
<pwuertz> you don't see libGL.so.1 in the global lib directory, do you?
<RAOF> We really should have a /usr/lib/libGL.so, too.
<tjaalton> pwuertz: no, because that was moved under mesa exactly to cater the blobs
<pwuertz> i don't know what "cater the blobs" means
<tjaalton> hmm ok now I see, so .so should be moved too?
<tjaalton> pwuertz: it's a diff to debian
<tjaalton> we ship the libs under mesa/
<RAOF> Well, I don't think we *can* move the .so
<tjaalton> so that the ldconf dance works
<tjaalton> RAOF: ah right
<RAOF> Because you need the linker to be able to resolve it, and that doesn't care about ld.so
<tjaalton> so there you go, diversions then?
<RAOF> I guess so :/
<RAOF> Actually...
<RAOF> Alternatives!
<RAOF> There's no reason /usr/lib/libGL.so can't be an alternative.
<tjaalton> then there's multiarch :)
<RAOF> Yeah, we'd obviously have /usr/lib/$arch_triple/libGL.so being an alternative.
<RAOF> And I guess we can ignore the /usr/lib/libGL.so requirement of the Linux OpenGL ABI :)
<pwuertz> Wouldn't the linker just pick anything ldconfig is configured for? Or are you saying that there are some occasions where the linker just looks for /usr/lib/libXY.so without asking anyone else?
<RAOF> The linker doesn't use ldconfig
<RAOF> The dynamic loader (ld.so) does, but the linker is totally separate.
<RAOF> The linker just looks for lib$foo.so in a bunch of hardcoded paths.
<pwuertz> RAOF: Oh, so the linker dynamically links against mesa/libGL.so, then when you call ldd on the binary or run it it switches to the one suggested by ldconfig
<pwuertz> RAOF: I had no idea :)
<RAOF> The linker just encodes "this DSO needs symbols from libGL.so.1" in the binary; it's ld.so's job to take âlibGL.so.1â and load it.
<RAOF> (As in: the binary literally contains the string âlibGL.so.1â, and the dynamic loader takes that string and goes âis there a library called libGL.so.1 in my search pathsâ)
<RAOF> ldd does the same sort of lookup as ld.so
<pwuertz> RAOF: yea, but the linker also checks if these symbols exist, so if I'd (hypothetically) expect it to successfully link to some functions only present in an alternative libGL.so it wouldn't succeed
<RAOF> No, that's the point of the OpenGL ABI; the set of symbols exported from Mesa's libGL.so is exactly the same as the set of symbols exported from NVIDIA's libGL.so.
<pwuertz> thats why i said hypothetically ^^
<RAOF> Well, and the linker actually only resolves symbols on first use, too.
<RAOF> So if the program never uses a symbol from libbar.so.1 then it's never resolved, even if your particular libbar.so.1 doesn't actually have that symbol.
<pwuertz> I see
<pwuertz> Thanks for explaining! I really didn't know how exactly the linker did its job ;)
<pwuertz> I.e. not involving ldconf
<pwuertz> RAOF: Ok, i got another idea.. do you know who is responsible for creating /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf ?
<pwuertz> RAOF: Because the problem is also solved by prioritizing that file with a "0" prefix in the filename, thus dynamically loading the nvidia/libGL
<pwuertz> No other actions required
#ubuntu-x 2015-08-12
<ricotz> so do we want a dedicated nvidia ppa? aka "ppa:graphics-drivers/nvidia"
<mamarley> I set that version a long time ago to keep my own packages ahead of other packages of the same driver version so I didn't need to recompile and reboot multiple times when a new driver was released.
<mamarley> Back then, it was just a personal thing and I never expected anyone else to actually use it.
<mamarley> ricotz: I think so.
<tjaalton> why driver specific ppa's?
<ricotz> not sure, that is why I am asking ;)
<tjaalton> I don't see a point
<ricotz> "ppa:graphics-drivers/ppa" is fine for me
<mamarley> I guess I don't have any logic behind my opinion, so just one PPA is fine.
<tseliot> ricotz, mamarley: I've just pushed my 355 code
<mamarley> I had also been packaging the latest version of libvdpau and vdpauinfo.  Should that go in the same PPA or a different one?  Or not under this team at all?
<tjaalton> if this place will also get backported mesa + llvm, then I hope we could ditch the stupid renaming business on lts-stacks
<tseliot> still on github
<tjaalton> which is nothing but pain
<tjaalton> assuming enough people use it and file issues which get fixed early enough for "blessed" backports in the main lts repo
<tseliot> mamarley: where does come from? (debian?)
<mamarley> tseliot: The VDPAU packages?  I based those on what is already in Ubuntu, just new upstream releases.
<tseliot> and yes, a non-driver-specific ppa would be better
<ricotz> I am going to copy libvdpau from edgers too
<mamarley> So should I create a separate PPA under this team for VDPAU stuff then?
<ricotz> tseliot, vdpau is pretty much connected since it will be removed from the blob soon 
<tjaalton> mamarley: imo no
<ricotz> mamarley, no
<mamarley> OK
<tjaalton> if it's supposed to be a one-stop place for "everything" driver related
<tseliot> yes, using the same PPA makes sense
<mamarley> OK, that works.
<tseliot> ricotz: https://github.com/tseliot/nvidia-graphics-drivers/tree/355
<ricotz> tseliot, got it
<tseliot> ricotz: you might want to rebase on that
<ricotz> i know
<ricotz> jcastro, could you ask for more ppa space and armhf support?
<ricotz> https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+packages
<jcastro> sure, how does that work, I file a bug?
<tseliot> 352 is still stuck in NEW in wily...
<ricotz> jcastro, a question against "launchpad"
<ricotz> jcastro, or ask wgrant ;)
<jcastro> ack
<jcastro> on it!
<ricotz> thanks
<jcastro> feel free to task me with all the administrative work
<mamarley> Are we going to keep using the "-0ubuntu0~xedgers15.10.1"-style version string?  (Just wondering for when I upload new versions.)
<ricotz> jcastro, a nice ppa desciption too? ;P
<jcastro> ok, I'm on it
<ricotz> mamarley, no, i guess "-0ubuntu0~gpu15.10.1", to simplify is a bit
<mamarley> ricotz: OK, got it.  Thanks!
<mamarley> If you guys want me to handle the day-to-day uploads of new driver releases, that would be fine.  I check for updates every morning, so my response time is quite fast.
<tseliot> that would be nice
<jcastro> https://answers.launchpad.net/launchpad/+question/270278
<mamarley> OK, great.  I will handle that then.
<tseliot> thanks
<ricotz> mamarley, alright, let us know when you before you start to avoid clashes
<mamarley> ricotz: OK, sure thing.
<tseliot> good
<ricotz> mamarley, you know how to create a proper package?
<mamarley> ricotz: I think so, but now I am doubting.
<tseliot> do you mean a new flavour?
<ricotz> mamarley, you didnt use a orig-tarball iirc
<tseliot> as in -355, -390, etc
<tseliot> oh, that (.orig) would save bandwidth
<mamarley> ricotz: I wasn't.  What is the procedure for that?  I had only used .orig tarballs before when upstream actually shipped one.
<ricotz> look into one e.g. for 355 and recreate it like that, and use it as usual
<ricotz> of course include amd64, i386 and armhf bins
<ricotz> bbl
<mamarley> But PPA uploads are source-only right?
<tseliot> what do you mean?
<ricotz> the "bins" provided by nvidia should be in the orig tarball
<tseliot> the .run installers
<mamarley> OK
<mamarley> But the current packages don't include armhf, do they?
<tseliot> they do
<tseliot> there's an easy way to do it
<tseliot> 1) enter the directory with the source (e.g. nvidia-graphics-drivers-355)
<tseliot> 2) download the installers by doing: debian/rules get-orig-source
<tseliot> 3) create a tarball that only contains the 3 installers and excludes the debian and .git directory
<mamarley> So the .run files should be in the root directory of the archive?
<tseliot> the archive will contain a directory e.g. nvidia-graphics-drivers, which, in turn, contains the .run files
<mamarley> OK
<tseliot> mamarley: follow the name scheme of the other orig tarballs and you'll be all set
<mamarley> Thanks!  That does sound easier than what I was doing.
<tseliot> :)
<mamarley> And soon I will likely be getting Google Fiber so I won't have to wait hours for the packages to upload either!
<jcastro> rub it in!
<jcastro> so hey guys, where's the git source to the packages? I'd like to refer them in the description
<tseliot> mamarley: then, only for your first upload, build with "debuild -S -sa" (so as to include the orig tarball). For the next uploads that use the same tarball you can create the sources using just "debuild -S", so that you won't have to reupload the orig tarball
<mamarley> tseliot: OK, but I will still need to reupload the orig.tar for new upstream releases, right?
<tseliot> my sources are here: https://github.com/tseliot/nvidia-graphics-drivers  (look for the different heads, not master)
<tseliot> mamarley: correct
<tseliot> mamarley, ricotz: you might want to set up a git repository (you choose where) for the packaging scripts, so that you can pull in my changes and add yours
<mamarley> Sure, I can just fork that repository.
<mamarley> tseliot: ricotz: OK, I forked it to https://github.com/mamarley/nvidia-graphics-drivers/ and added push access for ricotz.
<tseliot> mamarley: thanks
<mamarley> tseliot: Should I put my vdpauinfo 1.0 package in ppa:graphics-driver/ppa too?
<tseliot> mamarley: sure
<mamarley> OK, will do.
<ricotz> tseliot, did you tested and built the kernel module of 355 on i386?
<ricotz> (with you packaging)
<tseliot> ricotz: probably not (I can't remember) but those changes mostly come from NVIDIA
<ricotz> tseliot, i could be wrong but this likely fails
<tseliot> ricotz: where exactly?
<ricotz> while it will try to build the uvm module on i386 too
<jcastro> ricotz: space sorted, thanks to wgrant 
<ricotz> jcastro, great
<tseliot> ricotz: let me check
<ricotz> tseliot, the module source is taken from the amd64 pack
<ricotz> passing -jX isnt useful imo
<ricotz> tseliot, also please tweak the kernel 3.18 patch as i suggested
<tseliot> ricotz: right, the new build system builds all modules by default. I need to use NV_EXCLUDE_BUILD_MODULES=''
<tseliot> ricotz: can you point me to that change (for 3.18) again, please? (too much stuff on my plate...)
<ricotz> tseliot, look at the edgers package
<tseliot> ricotz: ok
<ricotz> regarding the uvm problem too
<tseliot> ok
<tseliot> ricotz: do you have a git repository too?
<ricotz> tseliot, just a local private one
<tseliot> ok
<ricotz> I won't rebase/update the 355 packages then ;)
<mamarley> Also, were we going to make some sort of staging PPA to upload things to initially and then copy them once they are built and tested?
<tseliot> ricotz: I've just downloaded nvidia-graphics-drivers-355 (355.06-0ubuntu0~xedgers15.10.1), and I don't see the uvm work
<tseliot> mamarley: a staging ppa sounds like a good idea
<mamarley> Is there any way to make it hidden so people don't try to use it?
<tseliot> that would have to be a private PPA. jcastro ^^
<jcastro> is private the best thing to do?
<jcastro> or just really big warnings?
<tseliot> whatever you're more comfortable with, guys
<mamarley> Either one is fine with me.
<jcastro> I would prefer to keep everything open, with just clear warnings that the staging area is for developers and not end users
<mamarley> Sure
<tseliot> ricotz: oh, you meant to say that you didn't do that kind of work, and that pulling in the new work will break it. I'll fix and test that soon
<ricotz> tseliot, a plain diff http://paste.debian.net/plain/291679
<ricotz> "nv-kernel.o_binary" is correct I think
<ricotz> mamarley, jcastro, warnings dont help
<jcastro> yeah that's fine
<ricotz> mamarley, testing things locally as good as possible
<jcastro> unless you really think the other way is better
<tseliot> ricotz: ok, I'll have a look at it tomorrow, thanks
<jcastro> I don't feel strongly about it either way
<mamarley> ricotz: Of course, but I don't have much in the way of hardware on which to test yet.
<ricotz> maybe disable ppa publishing before starting a new upload
<mamarley> That would make it harder to test on my own systems.
<ricotz> mamarley, meaning check the kernel modules and such, and a runtime check
<mamarley> I always install them on my laptop before uploading.
<ricotz> much more isn't possible and this ppa is meant to get things tested
<ricotz> user won't be automatically transitioned to newer beta series
<mamarley> So no staging PPA then?
<ricotz> e.g. make sure to drop all "transitional" packages before uploading
<ricotz> mamarley, i dont see much of a point for one
<mamarley> OK.  I never put transitional packages between major releases.
<ricotz> the ubuntu package contains some, so those should be stripped
<mamarley> OK.
<ricotz> tseliot, alright
<mamarley> Which are they?  I am looking at 346 and 352 and not seeing any transitional packages.
<ricotz> mamarley, http://launchpadlibrarian.net/212442914/nvidia-graphics-drivers-352_352.21-0ubuntu1_source.changes
<ricotz> tseliot, make sure those don't land in the archive http://launchpadlibrarian.net/214273992/nvidia-graphics-drivers-legacy-340xx_340.76-6_amd64.changes
<mamarley> Ah, OK.  It looks like those have already been removed for the PPA builds though.
<ricotz> right, as I said
<mamarley> Sorry
<ricotz> alright, so much for x stuff today
<tseliot> ricotz: I don't see how they could end up in the archive, since I'm not going to upload 355, and I'm the only maintainer ;)
<tseliot> ricotz: oh, that
<ricotz> tseliot, I am talking about the syncs from debian
<tseliot> :/
<ricotz> mamarley, use https://launchpad.net/ubuntu/+source/vdpauinfo/1.0-1
<tseliot> ricotz: I've just asked in #ubuntu-release
<mamarley> ricotz: Yeah, I just realized my dependencies are goofed up.  Just a sec...
 * ricotz really gone now
<ricotz> mamarley, :\ dont override existing ubuntu packages
<ricotz> in this case "1.0-1~gpu14.04.1"
<ricotz> mamarley, don't hesitate to ask and wait a bit
<mamarley> I'm really sorry.
<ricotz> and still there is also precise ;)
<mamarley> OK, I will fix the version and upload for Precise.
<ricotz> mamarley, you cant fix the version
<ricotz> it would be lower which doesnt work anymore now
<mamarley> I should be able to for precise because I haven't uploaded the incorrect version yet.
<ricotz> for precise yes
<mamarley> So I have "vdpauinfo (1.0-1~gpu12.04.1) precise; urgency=medium", is that OK to upload?
<ricotz> yes, and still works in regard of the other versions
<ricotz> but wait until the libvdpau is published to avoid a failure/dep-wait
<mamarley> OK, I will upload it after lunch.  Sorry for the trouble.
<ricotz> https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+packages?field.name_filter=vdpau&field.status_filter=published&field.series_filter=
<jcastro> so hey guys, will kind of brings up a good point
<jcastro> if we want to convince the TB to allow a GUI hook from the driver tool to a PPA, they're going to want to know it's tested
<jcastro> so maybe doing a staging thing would be a good idea, if anything to show that we break there first?
<mamarley> That's fine with me; I don't have a strong opinion one way or another.
<tjaalton> filed https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1484279
<ubottu> Launchpad bug 1484279 in mesa (Ubuntu) "[FFe] Mesa 11.0.0" [Medium,Triaged]
<tjaalton> feel free to modify [Changes]
<tjaalton> or anything really
#ubuntu-x 2015-08-13
<jcastro> mamarley: ricotz: tseliot: I've added an agenda to the next Techboard meeting on Tuesday to discuss how best to proceed
<tseliot> jcastro: ok, thanks
<ogra_> did xorg lose support for using the void driver for keyboards ?
<ogra_> i'm tryin to brin up xorg in a snappy setup, did set the driver to void but xorg still tries to compile a keymap and fails on that 
#ubuntu-x 2016-08-16
<mamarley> soee: NVIDIA 370.23 is out. :)
 * mamarley is, of course, working on the package.
<soee> it is my job to announce it ;D
<mamarley> Sometimes these new major releases can be tricky.  Especially with no changelog posted yetâ¦
<soee> hmmm
<mamarley> I'm not saying this one is or isn't yet.  Just sometimes they can be.
<soee> still it does not include much http://www.nvidia.com/download/driverResults.aspx/105855/en-us
<mamarley> I don't see anything packaging-relevant in there.
 * mamarley crosses fingers.
<mamarley> Well, it packages cleanly.  That's a good sign.  Now for the guinea-piggingâ¦
<soee> -.-
<mamarley> (I haven't uploaded it yet; I need to check if any kernel module patches are necessary.)
<mamarley> soee: It appears to work. :) Now I just have to get the packaging ready for the rest of the Ubuntu releases, then I can upload.
<soee> than i can test :)
<mamarley> This driver also compiles against Linux 4.7 without a patch.
<soee> \o\
<ricotz> oh nice :)
<ricotz> mamarley, make sure to base it on the current 367 ppa packaging
<ricotz> and check if the 4.8 patch still applies
<mamarley> ricotz: Already based on the PPA packaging, and do you mean the 4.7 patch?  We don't have a 4.8 patch yet.
<mamarley> Regardless, the 4.7 patch is no longer necessary.
<ricotz> if so, you didnt base it on the current packaging
<mamarley> Oh, you must have uploaded something more recently that I didn't see.  Darn.
 * mamarley starts over.
<ricotz> updated it last week
<ricotz> nvidia-graphics-drivers-367 - 367.35-0ubuntu2~gpu16.10.2 	(changes file) 	ricotz 	2016-08-11
 * mamarley slaps himself around a bit with a large trout.
<mamarley> I will let you know when I am ready again.  Sorry.
<ricotz> mamarley, didn't you add the ppa yourself? you should have noticed by receiving this update
<mamarley> ricotz: I do have that PPA enabled, but I also have my staging PPA enabled, which has 367.36.02 in it.  Therefore, I never saw the update.
<mamarley> I didn't upload anything to the main PPA though, so no harm done.  I can just re-upload it in staging.
<mamarley> The 4.8 patch is definitely still needed.
<mamarley> This code uses "goto".  I have a bad feeling that I am about to be attacked by a velociraptorâ¦
<mamarley> ricotz: I have uploaded everything to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.  It isn't published yet though.
<ricotz> mamarley, thanks, will take a look later
<ricotz> ... including a test-run
<ricotz> mamarley, so, you forgot to tweak the 4.8 patch-number in dkms_nvidia.conf.in which must start with [0]
<mamarley> Oh, sorry, I didn't realize that was required.  I will fix that.
<ricotz> if dmks doesnt find a [0] (and so on) it skips patching
<mamarley> ricotz: Should I leave the numbers for all the commented-out patches as they are?
<ricotz> yes
<ricotz> will be back in a few hours
<mamarley> I apologize for the error.  The fixed packages are now uploaded.
<mamarley> ricotz: soee states in another channel that he has tested 370.23 and that it works for him.  I have also tested it on two systems and not had a problem.
<soee> http://i.imgur.com/QusGYfs.png yes
<ricotz> mamarley, looks good
#ubuntu-x 2016-08-18
<Sarvatt> thanks for doing 370 drivers already mamarley, just got a laptop that needs them :)
<mamarley> No problem :)
#ubuntu-x 2016-08-19
<pimpMyNick> I need to add resolution of 1600x900 on my Full HD monitor, using ubuntu 16.04. Xrandr and Xorg-conf method is not working, although it works on all previous versions. May I get some help from here?
#ubuntu-x 2016-08-21
<oroo> Xrandr and xorg.conf method of adding new screen resolution does not work on 16.04 ubuntu. Can someone help? I need to add screen resolution of 1600x900.
<oroo> This method works on all previous versions of ubuntu
<oroo> but not on 16.04
#ubuntu-x 2017-08-16
<soee> NVIDIA Releases Vulkan 381.26.13 Beta Linux Driver
<mamarley> soee: https://launchpad.net/~mamarley/+archive/ubuntu/nvidia-dev/+packages
<soee> :D
#ubuntu-x 2020-08-10
<KitsuWhooa> idk about you, but this is terrible https://vps.tasossah.com/uploader/files/sigh.png
<KitsuWhooa> ...
<KitsuWhooa> Sorry, compeltely wrong room
<KitsuWhooa> *completely
<KitsuWhooa> That's not even the link that was supposed to go with that text either! :p
