#ubuntu-x 2007-03-21
* Starting logfile irclogs/ubuntu-x.log
<Ubugtu> New bug: #94349 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94349
<Ubugtu> New bug: #94364 in compiz (main) "[apport]  compiz.real crashed with SIGSEGV in viaGetLock() (dup-of: 90850)" [Medium,Rejected]  https://launchpad.net/bugs/94364
<Ubugtu> New bug: #82135 in earth3d (universe) "[apport]  earth3d crashed with SIGSEGV in viaGetLock() (dup-of: 90850)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82135
<Ubugtu> New bug: #93852 in mesa (main) "trigger crashes before start" [Undecided,Confirmed]  https://launchpad.net/bugs/93852
<Ubugtu> New bug: #94384 in xserver-xorg-input-synaptics (main) "Emulation of non existant buttons with synaptics mouse" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94384
<Ubugtu> New bug: #93604 in xorg (main) "gparted is missing in iso image for feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93604
<Ubugtu> New bug: #94411 in xorg-server (main) "horizontal lines on desktop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94411
<Ubugtu> New bug: #94481 in gnome-terminal (main) "Ctrl-A causes zoom out in Feisty. (dup-of: 23244)" [Medium,Rejected]  https://launchpad.net/bugs/94481
<Ubugtu> New bug: #94541 in xorg (main) "xorg and memory leaks on Toshiba laptop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94541
<Ubugtu> New bug: #94517 in xorg (main) "essential drivers on festy herd5 don't support nvidia 7950 GX2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94517
<Ubugtu> New bug: #79339 in xorg (main) "[Edgy]  Forth mouse button isn't supported" [Undecided,Needs info]  https://launchpad.net/bugs/79339
#ubuntu-x 2007-03-22
<Ubugtu> New bug: #73554 in Ubuntu "Can't boot off cd/install Ubuntu Edgy Eft with Dell 2405FPW Monitor (dup-of: 40422)" [Undecided,Confirmed]  https://launchpad.net/bugs/73554
<Ubugtu> New bug: #73213 in xorg (main) "Videos do not work with an i810 GPU" [Undecided,Unconfirmed]  https://launchpad.net/bugs/73213
* Starting logfile irclogs/ubuntu-x.log
<Ubugtu> New bug: #94676 in xorg (main) "doesnt default to tty7 on boot up and X does not restart" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94676
<Ubugtu> New bug: #94673 in xorg (main) "Feisty : wrong screen definition" [Undecided,Needs info]  https://launchpad.net/bugs/94673
<Ubugtu> New bug: #94695 in xorg (main) "it keyboard detected as us when reconfiguring" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94695
<Ubugtu> New bug: #94708 in xserver-xorg-video-nv (main) "xorg nv driver needs XaaNoSolidTwoPointLine" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94708
<mvo> has anyone seen a bug with the ati driver that it randomly only allows 640x480 for a r200 based card on amd64? 
* mvo wonders if his HW is failing or we have a bug somewhere
<tepsipakki> could be.. try setting values for the monitor
<Mithrandir> mvo: yes, my old CRT used to have that problem.
<Mithrandir> I fixed it by getting an LCD instead
<mvo> I have LCD :)
<mvo> tepsipakki: I haven't changed the settings and it randomly works or fails
<tepsipakki> oh
<mvo> interestingly it seems to always work with the i386 live CD
<tepsipakki> I have a radeon 8500.. isn't that a r200?
<mvo> yes
<tepsipakki> but on i386
<tepsipakki> it has worked fine
<tepsipakki> check the cooling
<mvo> I have a 7500 
<mvo> cooling is a good idea
<mvo> its *old*
<mvo> I just wanted to raise it just in case it shows up in some other bugreport
<tepsipakki> I changed the fan to a passive sink, and sometimes when playing in windows it used to do very funky stuff ;)
<Ubugtu> New bug: #94670 in compiz (main) "[apport]  compiz.real crashed with SIGSEGV in viaGetLock() (dup-of: 90850)" [Medium,Rejected]  https://launchpad.net/bugs/94670
<Mithrandir> tepsipakki: I have had the exact same problem as mvo, and it was amd64-only too.
<Mithrandir> I spoke with airlied about it, but nothing really ever came of it.
<tepsipakki> oh ok
<Mithrandir> https://bugs.freedesktop.org/show_bug.cgi?id=6886
<Ubugtu> Freedesktop bug 6886 in Driver/Radeon "DDC for Hansol 900P sometimes fails" [Normal,New]  
<tepsipakki> yep, the timeouts seem to suck
<tepsipakki> I need to test patching the intel-driver so it might have a chance of getting the native resolution on Lenovo D221
<mvo> Mithrandir: that sounds familiar indeed. the logs seems to have gone unfortunately
<Ubugtu> New bug: #94634 in compiz (main) "Menu Bar Entries Aren't Highlighted (dup-of: 89189)" [Undecided,Needs info]  https://launchpad.net/bugs/94634
<Ubugtu> New bug: #46874 in linux-restricted-modules-2.6.15 (restricted) "Freeze in Dapper RC when logging out or shutting down" [Medium,Unconfirmed]  https://launchpad.net/bugs/46874
<Ubugtu> New bug: #94365 in xorg (main) "[feisty]  Error activating XKB configuration" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94365
<Ubugtu> New bug: #94748 in xorg (main) "install asks for X resolution" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94748
<Ubugtu> New bug: #94767 in xorg (main) "x11-common conflicts with xephem" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94767
* Starting logfile irclogs/ubuntu-x.log
<Ubugtu> New bug: #94557 in compiz (main) "window or dialog boxes do not show or refresh content (dup-of: 89189)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94557
<Ubugtu> New bug: #93208 in gparted (main) "GParted no longer on LiveCD? Feisty Herd-5 (dup-of: 93604)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93208
<tepsipakki> duh, mvo just quit
<tepsipakki> found a possible dupe for his issue with radeon, bug 93925..
<Ubugtu> Malone bug 93925 in xserver-xorg-video-ati "xserver bug: random lockups, blank/garbled screen, resolution changes" [Undecided,Needs info]  https://launchpad.net/bugs/93925
<tepsipakki> well, it's very recent so I didn't need to look for it :P
<Ubugtu> New bug: #48077 in linux-restricted-modules-2.6.15 (restricted) "Running nvidia-glx-config enable breaks X." [Medium,Confirmed]  https://launchpad.net/bugs/48077
#ubuntu-x 2007-03-23
<tepsipakki> mvo: take a look at bug 93925, is it similar to your situation?
<Ubugtu> Malone bug 93925 in xserver-xorg-video-ati "xserver bug: random lockups, blank/garbled screen, resolution changes" [Undecided,Needs info]  https://launchpad.net/bugs/93925
<mvo> tepsipakki: hello! I looked over the ati bugs today but found noone that looked similar. I do not have garble or lockups, it works fine. but in ~50% of the time with 640x480. it also seems to be not DDC releated. the monitor infomration looks correct in the log
<mvo> (II) RADEON(0): Total of 2 CRTC2 modes found for MergedFB------------ 
<mvo>  <- that is what I have in both logs. I wonder why it is telling me anything about mergefb?
<tepsipakki> beats me
<mvo> :)
<tepsipakki> mvo: have you had the issue for how long?
<mvo> ~one week but I *think* it correlates with the upgrade to the latest x xservers
<mvo> but that might just be me trying to make connections to events
<mvo> I report it now and attach the logs so that those are not getting lost, but as long as I'm the only one don't bother too much
<tepsipakki> ok :)
<tepsipakki> the patches that are in the latest xorg-server should be safe
<mvo> the thing is we had similar issue in the past were errors looked like HW problems and it turned out that they weren't. so its good to have it somewhere
<tepsipakki> sure
<tepsipakki> yay, my application for core-dev was approved :P
<Mithrandir> tepsipakki: yay!
<mvo> tepsipakki: rock!
<tepsipakki> yeah, thanks...
<tepsipakki> Mithrandir: "Approving based on feedback from TechBoard and Mithrandir" :)
<mvo> tepsipakki: I rejected my issue, it seems to be kvm releated
<tepsipakki> ah :)
<tepsipakki> you mean kvm-the-hardware?
<tepsipakki> yes
<mvo> yes
<mvo> the hardware
<mvo> it seems to be a race condition, one of them answers first
<mvo> and the kvm helpfully reports 640x480 it seems (if no monitor is attached)
<tepsipakki> heh
* Treenaks hands mvo a soldering iron
<Ubugtu> New bug: #95028 in xorg (main) "X crashes when testing screen savers" [Undecided,Needs info]  https://launchpad.net/bugs/95028
<Ubugtu> New bug: #19476 in xorg (main) "want support for RDP" [Wishlist,Rejected]  https://launchpad.net/bugs/19476
<Ubugtu> New bug: #95021 in xserver-xorg-video-ati (main) "Comes up with wrong screen resolution" [Undecided,Rejected]  https://launchpad.net/bugs/95021
<Ubugtu> New bug: #95100 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95100
<Ubugtu> New bug: #94737 in libx11 (main) "[apport]  gdmgreeter crashed with SIGSEGV in _XkbReadGetMapReply()" [Medium,Confirmed]  https://launchpad.net/bugs/94737
<Ubugtu> New bug: #21468 in xserver-xorg-video-i810 (main) "[i810]  dri produces blank screen" [Medium,Fix released]  https://launchpad.net/bugs/21468
<Ubugtu> New bug: #95065 in linux-restricted-modules-2.6.20 (main) "(EE) AIGLX: reverting to software rendering" [Undecided,Rejected]  https://launchpad.net/bugs/95065
<Ubugtu> New bug: #52314 in xorg (main) "Cannot use 1400x900 screen resolution for nvidia Ge 6800" [Undecided,Unconfirmed]  https://launchpad.net/bugs/52314
<Ubugtu> New bug: #95189 in xorg (main) "Support for Radeon x1650xt W Dell 3007WFP " [Undecided,Needs info]  https://launchpad.net/bugs/95189
<Ubugtu> New bug: #95236 in xorg (main) "Savage IX with dri  enabled locks T22  on boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95236
#ubuntu-x 2007-03-24
<Ubugtu> New bug: #95253 in xorg (main) "X fails to start on Macbook Pro - missing hsync/vertrefresh issue?" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95253
<Ubugtu> New bug: #95258 in xorg (main) "Ctrl-Alt-Backspace should request confirmation before killing Xorg" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95258
<Ubugtu> New bug: #95323 in xorg (main) "Adept won't install certain x11 packages" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95323
<Ubugtu> New bug: #40523 in xserver-xorg-video-i810 (main) "wrong frequency for Fujitsu Siemens P20-2 (dup-of: 32504)" [Medium,Unconfirmed]  https://launchpad.net/bugs/40523
<Ubugtu> New bug: #95437 in mesa (main) "[apport]  glxinfo crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95437
<Ubugtu> New bug: #95453 in mesa (main) "[apport]  glxinfo crashed with SIGSEGV in calloc()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95453
<Ubugtu> New bug: #43276 in kde-guidance (main) "Please include Dell UltraSharp 2405FPW 24-inch Wide Aspect Flat Panel LCD Monitor in hardware database" [Wishlist,Rejected]  https://launchpad.net/bugs/43276
<Ubugtu> New bug: #95448 in xorg (main) "video not visible experience ubuntu in samples folder" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95448
<Ubugtu> New bug: #89712 in compiz (main) "Invisible windows when desktop effects is enabled (dup-of: 89189)" [High,Rejected]  https://launchpad.net/bugs/89712
<Ubugtu> New bug: #95490 in xrdb (main) "I dont now what this service is good for, but it crashed while restarting x" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95490
<Ubugtu> New bug: #95515 in xorg (main) "[Feisty Beta] synaptic touchpad not detected during setup" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95515
<Ubugtu> New bug: #94330 in xorg (main) "Ubuntu video failure on LiveCD boot/install - 6.06LTS, 6.10 and Feisty Fawn" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94330
<Ubugtu> New bug: #95555 in linux-restricted-modules-2.6.12 (restricted) "Wrong screen resolution after enabling nvida restricted driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95555
<Ubugtu> New bug: #44810 in xserver-xorg-video-i810 (main) "DPMS standby, suspend, off does not work." [Medium,Needs info]  https://launchpad.net/bugs/44810
<Ubugtu> New bug: #95583 in xserver-xorg-input-synaptics (main) "touchpad: scroll-region flaky" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95583
<Ubugtu> New bug: #95606 in xorg (main) "google earth does crash xorg on feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95606
<Ubugtu> New bug: #95643 in xrandr (main) "[apport]  xrandr crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95643
#ubuntu-x 2007-03-25
<Ubugtu> New bug: #95710 in xorg-server (main) "gxine crashes Xorg" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95710
<Ubugtu> New bug: #94325 in linux-source-2.6.15 (main) "After waking up from suspend, a skype call hangs machine (dup-of: 53216)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94325
<Ubugtu> New bug: #95782 in xorg (main) "dual-head second monitor video" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95782
<Ubugtu> New bug: #95810 in xorg (main) "keyboard i18n is completely borked in feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95810
<Ubugtu> New bug: #95534 in xorg (main) "GeForce 8800GTX makes installation impossible" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95534
<Ubugtu> New bug: #95858 in xserver-xorg-input-synaptics (main) "feisty. scrolling too slow for synaptic touchpad" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95858
<Ubugtu> New bug: #95880 in xorg (main) "X.org randomly picks 800x600 on a monitor capable of doing 1024x768" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95880
<Ubugtu> New bug: #89555 in mesa (main) "[apport]  vlc crashed with SIGILL in __glXInitialize()" [Medium,Unconfirmed]  https://launchpad.net/bugs/89555
<Ubugtu> New bug: #87943 in mesa (main) "[apport]  xskewb crashed with SIGSEGV in glViewport()" [Medium,Confirmed]  https://launchpad.net/bugs/87943
<Ubugtu> New bug: #95863 in xorg (main) "Intel 945 Video 1680X1050 resolution display outside physical dimensions of the monitor" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95863
<Ubugtu> New bug: #47927 in linux-restricted-modules-2.6.15 (restricted) "3D driver install fails to update xorg.conf" [Medium,Rejected]  https://launchpad.net/bugs/47927
<Ubugtu> New bug: #95919 in mesa (main) "[apport]  glxinfo crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95919
<Ubugtu> New bug: #63206 in r-base (universe) "font path isn't correct set either in R or X [Edgy]  (dup-of: 63408)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/63206
<Ubugtu> New bug: #95934 in xorg-server (main) "[apport]  Xorg crashed with signal 5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95934
<Ubugtu> Announcement from my owner (Seveas): ubugtu will be taken offline and integrated with ubotu - epect some downtime
<ubotu> New bug: #96035 in xorg-server (main) "[apport]  Xorg crashed with signal 5 in ioldrmOpen()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96035
<ubotu> New bug: #54371 in xserver-xorg-video-ati (main) "Mouse cursor garbeled when using EXA on ATI Technologies Inc RV380 0x3e50 [Radeon X600]  with radeon driver" [Undecided,Needs info]  https://launchpad.net/bugs/54371
<ubotu> New bug: #96082 in xserver-xorg-input-synaptics (main) "[feisty]  BottomEdge=4144 too low!" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96082
<ubotu> New bug: #96085 in xorg (main) "[feisty]  Ctrl-Alt-Backspace crashes gdm" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96085
<ubotu> New bug: #37773 in linux-restricted-modules-2.6.15 (restricted) "[madwifi]  Semi-random system lockups in Dapper" [Critical,Confirmed]  https://launchpad.net/bugs/37773
<ubotu> New bug: #41979 in xserver-xorg-video-nv (main) "xserver-xorg crashes when handling newer nvidia cards" [High,Needs info]  https://launchpad.net/bugs/41979
<ubotu> New bug: #95641 in xserver-xorg-video-ati (main) "desktop effects don't work on Dell D600" [Medium,Confirmed]  https://launchpad.net/bugs/95641
#ubuntu-x 2008-03-17
<ubotu> New bug: #199455 in mythtv (restricted) "mythfrontend.real crashed with SIGSEGV in memset()" [Undecided,Invalid] https://launchpad.net/bugs/199455
<seb128> bryce: I fixed the gnome-settings-daemon crasher, that was due to conflicting variable names
<ubotu> New bug: #197759 in gnome-settings-daemon (main) "Unable to start the settings manager 'gnome-settings-daemon'. (dup-of: 198951)" [Undecided,Incomplete] https://launchpad.net/bugs/197759
<ubotu> New bug: #203181 in xorg (main) "Xorg crashed with SIGSEGV in free()" [Undecided,New] https://launchpad.net/bugs/203181
<bryce> seb128: excellent
<seb128> bryce: that's a 3 line changes ;-)
<seb128> bryce: I wrote some explanations on the bug if you are interested
<seb128> there is still the gnome-display-properties crasher though
<seb128> I think you can reproduce it easily by using Xnest
<seb128> I might look at this one too later but I've spent already quite some time on the g-s-d issue and I've other things to do this week
<bryce> likely it needs the same fix
<bryce> yes I know the feeling
<seb128> not likely
<seb128> the gsd crasher was due to a variable name conflict
<seb128> the other one seems to be an another issue
<bryce> do you have the name of the XError in this case?  
<seb128> yes
<seb128> be back in a minute
<seb128> will give you that then
<seb128> bryce: bug #199960 is an interesting one
<ubotu> Launchpad bug 199960 in gnome-settings-daemon "error starting GNOME Settings Daemon" [High,Confirmed] https://launchpad.net/bugs/199960
<seb128> bryce: XRRGetScreenSizeRange() seems to be the crasher for this user
<bryce> seb128: what is the proper way for people to get debug symbols for gsd and gnome-desktop?  comment #28 said he installed debug symbols, but his traces only have symbols for Xorg calls
<seb128> bryce: add the dbgsym source as indicated on the wiki page about crashes and install libgtk2.0-0-dbgsym libgnome-desktop-2-dbgsym and gnome-settings-daemon-dbgsym
<ubotu> New bug: #197161 in xorg (main) "[Hardy] Macbook trackpad not detected as trackpad" [Undecided,New] https://launchpad.net/bugs/197161
<ubotu> New bug: #135023 in xorg-server (main) "wrong resolution autodetected" [Undecided,Incomplete] https://launchpad.net/bugs/135023
<ubotu> New bug: #159634 in xorg-server (main) "Display detected as 1680x1050 but is 1680x1040" [Undecided,Incomplete] https://launchpad.net/bugs/159634
<ubotu> New bug: #197740 in xorg-server (main) "[Hardy] gnome-display-properties does crazy things" [Undecided,Incomplete] https://launchpad.net/bugs/197740
<ubotu> New bug: #203296 in xserver-xorg-input-synaptics "[hardy] Drag fails with keyboard stick and touchpad buttons" [Undecided,New] https://launchpad.net/bugs/203296
<bryce> seb128: on 199960, the original reporter's issue has been solved.  But the commenter that provided the backtrace appears to be using a non-xrandr 1.2 driver, which seems to need that gtk.patch from ssp that I forwarded to you earlier.  I also attached it to the bug for you.
<seb128> bryce: that is not clear to me, what difference would it make?
<seb128> bryce: I'm not comfortable using those gtk changes in hardy and fedora doesn't do that either
<bryce> see Soren's comment at the end of http://bugzilla.gnome.org/show_bug.cgi?id=521371
<ubotu> Gnome bug 521371 in gdk "XRRGetScreenResources error (libXrandr.so.2)" [Normal,Unconfirmed] 
<seb128> bryce: right, what soren wrote that is that the gtk call to XRRGetScreenResources is conditional to the tests before
<seb128> bryce: the bug you pointed is a similar gtk crash, not the g-s-d one
<seb128> bryce: which means libgnomedesktop should have tests similar to the ones he copied in the comment
<seb128> libgnome-desktop doesn't use the gtk xrandr functions, otherwise it would not build without patching gtk
<seb128> we need to check whether the libgnome-desktop checks are correct
<seb128> and if they are and there is some buggy drivers we need to trap the gdk errors as I told you the other days (which is what sorens mentions on the bug too)
<seb128> bryce: does it make sense to you?
<seb128> bryce: ok, libgnome-desktop has no such tests
<bryce> I am getting so frustrated by this
<seb128> why?
<seb128> the main crasher is fixed now
<seb128> the other issue is that the code dpes xrandr 1.2 only
<seb128> does
<bryce> well you keep threatening to drop the code unless this is done and that is done, and keep throwing aside patches I send
<seb128> hum
<seb128> that's not really true
<seb128> I said we need to get the crasher at startup fixed, which we mainly did
<seb128> you don't argue for shipping hardy crashing out of the box for radeonhd, i855, etc users, do you?
<seb128> and I don't reject patches for the fun of it
<bryce> no, which is why I put in several days last week putting in a patch to only run on ati and intel which we know work (which was difficult, being sick), but you dropped it
<seb128> but I try to minimize the api changes and the distro specific code we have to support
<bryce> I'm not saying you're wrong, just that I'm feeling frustrated
<seb128> I'm sorry about that
<bryce> in any case, I put in a 1.2 check in apply_settings() in gsd-xrandr-manager.  Maybe that just needs to be done throughout.
<seb128> but parsing the xorg log to determine if the card used is in a list is just not scalable and ugly
<bryce> but it looks to me like this gtk.patch takes care of it globally without having to patch checks into a bunch of different functions
<seb128> we would need to make gnome-desktop use those functions then
<seb128> and gtk is one of our base libs
<seb128> I'm not a big fan of changing behaviour over upstream and carry this patch
<seb128> and if the redhat guys are not shipping it but are shipping the capplet they might have a reason
<seb128> I would like to try to figure that before running into issues with gtk
<ubotu> New bug: #202121 in linux-restricted-modules-2.6.24 (restricted) "Latest linux-restricted-modules-2.6.24-12-generic breaks FGLRX?" [Undecided,New] https://launchpad.net/bugs/202121
<ubotu> New bug: #203327 in xorg (main) "Can`t change refresh rate" [Low,Invalid] https://launchpad.net/bugs/203327
<ubotu> New bug: #192144 in xorg-server (main) "Xorg crashed with SIGSEGV in _dl_relocate_object()" [Undecided,New] https://launchpad.net/bugs/192144
#ubuntu-x 2008-03-18
<ubotu> New bug: #200160 in ubuntu "[hardy] french keyboard layout broken (dup-of: 200813)" [Undecided,New] https://launchpad.net/bugs/200160
<ubotu> New bug: #203387 in xorg-server (main) "Ubuntu cannot handle multiple monitors" [Undecided,New] https://launchpad.net/bugs/203387
<ubotu> New bug: #203435 in linux-restricted-modules-2.6.24 (restricted) "nvidia-glx-new Fullscreen Problems" [Undecided,New] https://launchpad.net/bugs/203435
<ubotu> New bug: #203445 in xorg-server (main) "bogus bug for testing apport hook" [Undecided,Invalid] https://launchpad.net/bugs/203445
<Ng> hmm
<Ng> I just updated and something sent gdm SIGABRT
<ubotu> New bug: #203507 in xorg (main) "cursor does not always appear when starting xsession." [Undecided,New] https://launchpad.net/bugs/203507
<ubotu> New bug: #203539 in xserver-xorg-video-intel (main) "[hardy] screen brightness controls do not work on ThinkPad R61 with GM965 graphics controller" [Undecided,New] https://launchpad.net/bugs/203539
<Ng> dup!
 * Ng marks it such
<ubotu> New bug: #203552 in linux-restricted-modules-2.6.24 (restricted) "Suspend/hibernate does not work with HP Pavilion dv9340ea" [Undecided,New] https://launchpad.net/bugs/203552
<ubotu> New bug: #202802 in linux-restricted-modules-2.6.24 (main) "[Hardy] jockey-gtk prevents activation of "Visual Effects" with nvidia-glx" [Undecided,New] https://launchpad.net/bugs/202802
<Exilant>  Hi, I am running hardy(kubuntu) and experience a kind of system lock whenever i try to restart X or log out of it. No clue if that is a kdm or X or another problem. It happens on my machine(with fglrx) and on a friend's machine with intel graphics.
<Exilant> Can anyone point me to some bug description(if tracked, found none myself), or tell me wich logfiles are important in that case?
<Exilant> Also, no clue what to make of the channel topic, complains about the line "exec >&3"
<bryce> Exilant: http://wiki.ubuntu.com/X/Debugging
<james_w> Hi all.
<james_w> I'm looking in to https://bugs.launchpad.net/ubuntu/+source/displayconfig-gtk/+bug/147721
<ubotu> Launchpad bug 147721 in displayconfig-gtk "displayconfig-gtk crashed with IndexError in _syncXorgConfig()" [Medium,Confirmed] 
<james_w> it seems that guidance-backends is assuming that it will get at least one usable resolution from the current running screen or the monitor (I haven't followed the logic to find which it is looking at in this case).
<james_w> it appears as though that is an unsafe assumption, is that correct?
<bryce> right, especially with current xorg config
<bryce> james_w: btw note that we're disabling displayconfig-gtk from the menu for Hardy, in preference for the new xrandr gui
<bryce> tjaalton: btw I notice that intel_reg_dumper is not being built since 2.2.1-1ubuntu2 due to libpciaccess being in universe, however even if I install it, I still cannot get it to build - does this also require a newer xserver or something?
<tjaalton> bryce: no, e
<tjaalton> uh
<tjaalton> bryce: i don't recall what I did in order to disable it, but it also needed a newer libpciaccess
<bryce> tjaalton: ahh
<bryce> tjaalton: I notice the entry in rules was commented out; don't know if there were additional changes to disable it.
<tjaalton> probably not
<bryce> tjaalton: are we holding back on uploading a newer libpciaccess because of beta freeze, or were there additional reasons against it?
<tjaalton> I filed a freeze exception for it, but I backed off since it would have needed promotion to main
<bryce> hmm, since it's in universe, could would upgrade it to the newer one regardless of the freeze?
<bryce> I could take care of doing that, if there aren't any other reasons to hold it back
<bryce> it's not a huge deal, but jesse was asking about it yesterday
<tjaalton> nope, paperwork was needed so I didn't think it was that important
<bryce> okies, I'll work on it a bit
<james_w> bryce: thanks. This bug is on the Hardy QA list, should it be dropped from there?
<james_w> http://people.ubuntu.com/~ogasawara/qa-hardy-list-archive/sort-by-package/platform-buglist.html if you don't know what I refer to
 * bryce looks
<bryce> james_w: the "displayconfig-gtk loads with all widgets empty" is a known issue due to the xorg.conf hotplug stuff that went in for Hardy, and is the primary reason why we've dropped displayconfig-gtk from the menus in favor of the new xrandr gui
<bryce> james_w: so yes, this can be closed.  Do you want me to do it, or would you like to?
<james_w> bryce: I'm happy to do it, but I think that you will be able to explain the reason better than I.
<bryce> james_w: sure no prob
<james_w> thanks.
<bryce> james_w: done (I may have gone overboard with the details... but hopefully it gives the complete story)
<james_w> thanks.
<ubotu> New bug: #132199 in ubuntu "[needs-packaging] volume knob on dell keyboard (knob) (dup-of: 139582)" [Wishlist,New] https://launchpad.net/bugs/132199
<bryce> tjaalton: I reopened your existing sync request for libpciaccess.  hope that's ok.  
<tjaalton> bryce: I don't mind ;)
<james_w> bryce: that's an impressive level of detail
<james_w> I have a couple of questions though.
<james_w> The bug that these users were experiencing were a consequence of the stuff that displayconfig-gtk could not handle?
<bryce> correct
<james_w> and does the xrandr gui still use guidance-backends? Does anything?
<james_w> I think that's where the bug really is.
<bryce> xrandr gui does not use guidance-backends
<bryce> I believe kde has a tool which still uses guidance backends
<bryce> also like I pointed out, displayconfig-gtk is still used for bulletproof-x mode, so guidance-backends is still required.
<seb128> hey bryce
<james_w> thanks, I'll ask the kubuntu team about it.
<seb128> bryce: I've uploaded your gnome-control-center changes, you might want to ask slangasek for a freeze exception but that's likely late for beta now
<james_w> and I'll open a guidance-backends task on the bug so that it shows up there.
<bryce> hi seb128
<bryce> seb128: yeah sounds like it's late for beta but it should be ok as long as it goes in right after beta 
<seb128> right
<ubotu> New bug: #203505 in linux-restricted-modules-2.6.24 (restricted) "[hardy] screen stays black when using fglrx driver" [Undecided,New] https://launchpad.net/bugs/203505
<ubotu> New bug: #203748 in xserver-xorg-input-synaptics (main) "too many interrupts from synaptics touchpad" [Undecided,New] https://launchpad.net/bugs/203748
#ubuntu-x 2008-03-19
<ubotu> New bug: #203637 in xorg (main) "X crashed during update" [Undecided,New] https://launchpad.net/bugs/203637
<bryce> tjaalton: I've got a new version of the greedy patch for testing
<bryce> (attached to bug 177492)
<ubotu> Launchpad bug 177492 in xserver-xorg-video-intel "EXA is balls-achingly slow" [High,In progress] https://launchpad.net/bugs/177492
* bryce_ changed the topic of #ubuntu-x to: Ubuntu Hardy beta
<tjaalton> bryce: cool, is it post-beta material?
<bryyce> yeah
<bryyce> the greedy patch needs ample testing
<Ng> did our gutsy X server carry extra patches for handling funky laptop keys?
<Ng> acpid is calling acpi_fakekey for the blue button on my thinkpad, but xev doesn't see anything
<Ng> this hasn't worked since gutsy, so I'm wondering if a patch has been dropped or something
<ubotu> New bug: #193563 in linux-restricted-modules-2.6.24 (restricted) "compiz freezes desktop completely (backtrace included)" [Undecided,New] https://launchpad.net/bugs/193563
<ubotu> New bug: #203862 in xserver-xorg-driver-sis "SiS 716 only works with vesa and 800x600 in Hardy" [Undecided,New] https://launchpad.net/bugs/203862
<ubotu> New bug: #148274 in xserver-xorg-video-nv (main) "Nvidia new-glx problem with Gutsy  twin monitor" [Undecided,New] https://launchpad.net/bugs/148274
<qense> hello
<qense> I've got a question about bug  bug 192508, which I've been triaging
<qense> bug 192508
<ubotu> Launchpad bug 192508 in xorg "mouse keys turns on randomly" [Low,Confirmed] https://launchpad.net/bugs/192508
<qense> I think the best option would be to ask for xorg.conf and forward it to X's bug tracker
<qense> do you agree?
<qense> anyone?
<bryce> qense: the xorg.conf couldn't hurt, but is unlikely to have information that would explain why it's occurring
<qense> ok
<qense> I'll just ask for that file and forward it upstream and we'll see what X is going to do with it
<bryce> Pedro said that upstream thinks it's an X issue - a more detailed explanation of why they think that would be helpful
<bryce> also ask for Xorg.0.log, as that has a lot more useful info for troubleshooting
<qense> ok
<bryce> I think I agree it sounds like an XKB issue, which suggests we need to know which xkb config the users are using
<bryce> presumably there is an error in some config file in /etc/X11/xkb/rules/ or something
<bryce> if we know which of the maps they're using, we could look to see if there was a change to that for gutsy.
<qense> but that directory has a lot of files :)
<ubotu> New bug: #204019 in xorg-server (main) "Xorg crashed with SIGSEGV in free() (dup-of: 195767)" [Undecided,New] https://launchpad.net/bugs/204019
<qense> which files do you think are needed?
<bryce> the way it works, is X selects one of those files to use as the keymap, so we just need to know which one is selected (this gets reported in Xorg.0.log), so having the Xorg.0.log should be sufficient for first order debugging
<bryce> if you look in your Xorg.0.log, you can see lines with "XkbRules", "XkbModel", etc.
<qense> ok, thanks
<qense> do you think the version of xkb-data will help?
<bryce> yes it almost certainly will
<bryce> we can make the assumption that if they run gutsy, they have the current gutsy version installed, but verifying that would be of good use
<qense> he's running hardy :)
<qense> ok, thank you for your help
<bryce> well, one is using hardy, the other gutsy.  but yeah verifying the version in both cases would be useful
<qense> anyway,  I go, bye
<ubotu> New bug: #204035 in xserver-xorg-video-intel (main) "945GM: server crashes with "Fatal server error: lockup"" [High,Confirmed] https://launchpad.net/bugs/204035
<ubotu> New bug: #204055 in xserver-xorg-video-openchrome (main) "X11 fails on VIA  UniChrome Pro IGP" [Undecided,New] https://launchpad.net/bugs/204055
<ubotu> New bug: #118458 in linux-source-2.6.22 "Acer Aspire 1510LMi won't go to sleep or hibernate" [Undecided,Won't fix] https://launchpad.net/bugs/118458
<ubotu> New bug: #203701 in xkeyboard-config (main) "Dell Keyboard misspelling" [Low,Confirmed] https://launchpad.net/bugs/203701
<ubotu> New bug: #181531 in xserver-xorg-video-intel (main) "Toshiba Tecra M8 has a short gnome panel on Gutsy" [Medium,Fix committed] https://launchpad.net/bugs/181531
<ubotu> New bug: #203936 in xorg (main) "Intel Santa Rosa - No Video, could not configure X, cannot start GDM" [Undecided,Incomplete] https://launchpad.net/bugs/203936
#ubuntu-x 2008-03-20
<ubotu> New bug: #204104 in xorg (main) "Wrong resolution on ATI Mobility Radeon 9000" [Undecided,New] https://launchpad.net/bugs/204104
<ubotu> New bug: #204109 in xorg (main) "[Hardy] radeon-driver is no providing proper 3D" [Undecided,New] https://launchpad.net/bugs/204109
<bryce> tjaalton: here's a better fix for the displayconfig-gtk removal:  http://people.ubuntu.com/~bryce/Uploads/displayconfig-gtk_0.3.10.dsc
<ubotu> New bug: #204065 in xserver-xorg-video-intel (main) "Hardy - severe graphical issues with i945GM graphics" [Undecided,Incomplete] https://launchpad.net/bugs/204065
<ubotu> New bug: #204127 in xorg (main) "tc1100 tablet - pen works in Gutsy not in Hardy" [Undecided,New] https://launchpad.net/bugs/204127
<tjaalton> bryce: ok, thanks
<bryce> tjaalton: also the greedy patch looks good (177492), so once we're out of freeze I guess that can be uploaded too
<tjaalton> yep
<bryce> btw, seems one of our 855 patches for gutsy causes another bug 182865
<ubotu> Launchpad bug 182865 in xserver-xorg-video-intel "[Gutsy backport] Cannot switch to console after installing "xserver-xorg-video-intel 2:2.1.1-0ubuntu9.1"" [Medium,In progress] https://launchpad.net/bugs/182865
<bryce> not sure what to do there.
<bryce> anyway, night.
<ubotu> New bug: #45742 in linux-restricted-modules-2.6.15 "TV-out works but only in colourless mode" [Medium,New] https://launchpad.net/bugs/45742
<ubotu> New bug: #204137 in xorg (main) "openoffice.org always crashes as soon as i access a menu." [Undecided,New] https://launchpad.net/bugs/204137
<ubotu> New bug: #188690 in transmission (main) "does not create a PO template on build" [Undecided,In progress] https://launchpad.net/bugs/188690
<ubotu> New bug: #202487 in ubuntu "ATI: after update, desktop settings (compiz) asks to install "fglrx" to be re-enabled (dup-of: 200086)" [Undecided,New] https://launchpad.net/bugs/202487
<ubotu> New bug: #204423 in xorg (main) "ctrl+alt+backspace sometimes reboots instead of restarting X" [Undecided,New] https://launchpad.net/bugs/204423
<mario_limonciell> tjaalton, you here still?
<ubotu> New bug: #188287 in dell (restricted) "dependencies installs -386 kernel which hangs on boot" [High,Confirmed] https://launchpad.net/bugs/188287
<ubotu> New bug: #197847 in mythbuntu "8.04 install default kernel in grub was -386 not -generic (dup-of: 188287)" [Undecided,New] https://launchpad.net/bugs/197847
#ubuntu-x 2008-03-21
<ubotu> New bug: #203282 in xorg-server (main) "Ctrl + Alt + F1 restart X in Kubuntu Hardy" [Undecided,New] https://launchpad.net/bugs/203282
<ubotu> New bug: #204483 in xserver-xorg-driver-ati "[Hardy] Closing Laptop lid corrupts screen and beeps" [Undecided,New] https://launchpad.net/bugs/204483
<ubotu> New bug: #204497 in xorg (main) "white screen of death after hibernate in hardy" [Undecided,New] https://launchpad.net/bugs/204497
<ubotu> New bug: #204502 in xorg (main) "[hardy] keyboard stops responding after adjusting screen brightness" [Undecided,New] https://launchpad.net/bugs/204502
<ubotu> New bug: #199562 in ubuntu "white screen on resume from hibernate (dup-of: 160264)" [Undecided,New] https://launchpad.net/bugs/199562
<ubotu> New bug: #204519 in xserver-xorg-input-aiptek (universe) "Cursor movement but no contact/pressure detection on Aiptek USB tablet " [Undecided,New] https://launchpad.net/bugs/204519
<bryce> tjaalton: http://people.ubuntu.com/~bryce/Xorg/status_current.html
<bryce> (inspired by http://qa-2.ubuntuwire.com/weatherreport/)
<pwnguin> bug report on that page
<pwnguin> -nv is the same as -intel
<pwnguin> bryce: fyi, it looks like you used the same link for 5+ subscribers for both -intel and -nv
<bryce> pwnguin: ah, good catch
<bryce> fix will be up in <10 min hopefully
<pwnguin> heh
<pwnguin> too bad nv is a piece of crap
<bryce> :-/
<pwnguin> fortunately, there's only 4 bugs that more than 5 people care about
<bryce> I was testing it on a projector yesterday, and it did impressively well
<bryce> only thing it failed at was doing xrandr rotation
<pwnguin> nouveau is better
<pwnguin> i like it already
<pwnguin> just for supporting rotate 180
<pwnguin> and it supports things that NV marks wontfix
 * bryce nods
<bryce> I finally broke down and ordered 2 new nv cards and 2 new ati cards
<pwnguin> i guess thats why they pay you the big bucks ;)
<bryce> the stuff I have is embarrassingly old
<pwnguin> heh
<pwnguin> i have a tnt2 somewhere
<bryce> fortunately my criteria was "popular stuff", which tends to correlate with "cheap"  ;-)
<pwnguin> i can confirm that nouveau 3d barely works on 6600gt's
 * pwnguin wonders at what point Ubuntu would consider shipping nouveau
<bryce> pretty much when me and timo feel it's ready
<bryce> we're relatively close to switching to radeonhd over ati, maybe for Intrepid or Intrepid+1
<pwnguin> well, im not asking for defaults, just availability
<pwnguin> browsing the changelog, i guess it's still ironing out randr12 bugs
<bryce> hmm, well there's little reason why not to put it into universe at this point
<bryce> I'm surprised it isn't actually
<pwnguin> ive been leeching raof's ppa
<pwnguin> i think his goal is to track a fast moving project with nightly builds from git, rather than conform to universe's policies
 * bryce nods
<bryce> gods I hate rhythmbox
<pwnguin> heh
<bryce> hate to admit it but I miss xmms
<pwnguin> i hate xmms :P
<pwnguin> unreadable, anti-theme software
<pwnguin> terrible playlist support
<bryce> yeah yeah but it did exactly what I wanted
<pwnguin> sure, it plays all five of your songs :P
<bryce> hey, it never failed me
<pwnguin> i like being able to rate songs and make a playlist of nonsuck music
<pwnguin> or being able to put the top 700MB of songs onto a CD
<bryce> with rhythmbox I get all this popping, and I can never tell what's playing
<pwnguin> i admit, i havent used rb on hardy
<pwnguin> although i think i filed a bug about it crashing
<bryce> well, it's better than gutsy; it was unusable on gutsy due to the crashing
<ubotu> New bug: #184822 in linux-meta (main) "kernel vga mode setting not working with 2.6.22 (dup-of: 129910)" [Undecided,Incomplete] https://launchpad.net/bugs/184822
<pwnguin> really?
<pwnguin> i must have worked around that and forgotten
<pwnguin> also, fun suggestion: grab music-applet for non-intrusive one click interface to RB once you've set it up
<pwnguin> though i guess these days kids have fancy media keyboards
 * bryce updates http://people.ubuntu.com/~bryce/Xorg/status_current.html
<pwnguin> man, the rhythmbox bug page scares me
<pwnguin> segfauls galore
<bryce> that's the scent of neglect, my friend
<pwnguin> from rhythmbox or ubuntu?
<bryce> rhythmbox
<bryce> I'm fairly sure seb128 is rb's ubuntu champion, but he's so busy...
<pwnguin> heh. if you really want to know the smell of neglect, i recommend adventuring into xkb
<jcristau> no, that's the smell of despair
<bryce> night.
<ubotu> New bug: #204593 in xserver-xorg-video-intel (main) "3D acceleration is enabled only for the first user (intel driver)" [Undecided,New] https://launchpad.net/bugs/204593
<jcristau> haha
<ubotu> New bug: #204603 in xserver-xorg-video-intel (main) "occasional hard crash on vt switch" [Undecided,New] https://launchpad.net/bugs/204603
<ubotu> New bug: #204633 in xorg (main) "touchscreen only outputs right angles" [Undecided,New] https://launchpad.net/bugs/204633
<ubotu> New bug: #204671 in xserver-xorg-video-nv (main) "hardy beta screen corrupt with nvidia card using open source nv driver" [Undecided,New] https://launchpad.net/bugs/204671
<ubotu> New bug: #204693 in compiz (main) "[hardy] enabling compiz installs "fglrx" although "ati" works fine (dup-of: 200086)" [Undecided,New] https://launchpad.net/bugs/204693
<tjaalton> bryce: nouveau needs drm from git master, but hopefully that's stabilized for 2.6.26, and then we can consider including it. Some time ago I tried the package by RAOF, and meant to push it to git.d.o, but never got that far
<tjaalton> and radeonhd does not support anything below r5xx, so it can't replace -ati as is :)
<jcristau> tjaalton: i uploaded a few libs with your epoch changes from last year this week btw :)
<tjaalton> jcristau: woohoo :)
<jcristau> (they had new upstream releases for 7.4)
<ubotu> New bug: #204721 in xorg (main) "screen rotated to left on Intel 945 card after login on hardy" [Undecided,New] https://launchpad.net/bugs/204721
<ubotu> New bug: #204734 in xorg (main) "[hardy] AIGLX can't find i915_dri.so" [Undecided,New] https://launchpad.net/bugs/204734
<ubotu> New bug: #204747 in xserver-xorg-video-intel (main) "[Hardy] Screen corruption on Toshiba laptop with intel driver" [Undecided,New] https://launchpad.net/bugs/204747
<ubotu> New bug: #204762 in xserver-xorg-video-intel (main) "[Hardy] No DRI with Intel GMA 950 (aka 945GM)" [Undecided,New] https://launchpad.net/bugs/204762
<ubotu> New bug: #204750 in linux-restricted-modules-2.6.24 (multiverse) "[Hardy]Glest crashes with Segmentation fault" [Undecided,New] https://launchpad.net/bugs/204750
#ubuntu-x 2008-03-22
<ubotu> New bug: #204990 in xserver-xorg-video-intel (main) "X does not start at all on Intel  945GM/GMS" [Undecided,New] https://launchpad.net/bugs/204990
<ubotu> New bug: #205019 in xorg (main) "black screen randomly (hardy heron)" [Undecided,New] https://launchpad.net/bugs/205019
<ubotu> New bug: #200475 in jbidwatcher (multiverse) "Does not start (dup-of: 87947)" [Undecided,Confirmed] https://launchpad.net/bugs/200475
<ubotu> New bug: #200592 in jabref (multiverse) "Jabref coredumps on startup because of locking assertion (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/200592
<ubotu> New bug: #199661 in netbeans (universe) "netbeans 6.0.1 assertion failure in ubuntu 8.04 alpha 6 (dup-of: 87947)" [Undecided,Confirmed] https://launchpad.net/bugs/199661
<ubotu> New bug: #205045 in xorg (main) "[Hardy beta] Xorg fails to configure an usable xorg.conf" [Undecided,New] https://launchpad.net/bugs/205045
<ubotu> New bug: #205054 in xserver-xorg-driver-i810 "[Hardy Beta] Intel 845 card - correct drivers not detected" [Undecided,New] https://launchpad.net/bugs/205054
<ubotu> New bug: #204193 in sun-java6 (multiverse) "sun-java 6 x64 crashes (dup-of: 87947)" [Undecided,Incomplete] https://launchpad.net/bugs/204193
<ubotu> New bug: #205053 in xorg (main) "Screen Resolution utility doesn't check settings work" [Undecided,New] https://launchpad.net/bugs/205053
<ubotu> New bug: #173682 in xorg (main) "Kde freeze after approx an hour inaction" [Undecided,Incomplete] https://launchpad.net/bugs/173682
<ubotu> New bug: #205096 in xorg (main) "package xserver-xorg 1:7.3+10ubuntu7 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/205096
<ubotu> New bug: #205093 in xorg (main) "[Hardy] Screen detection problems with xorg, nvidia and an Acer AL2216W" [Undecided,New] https://launchpad.net/bugs/205093
<ubotu> New bug: #104613 in linux-restricted-modules-2.6.24 (restricted) "restricted-manager does not correctly enable XvMC with nVidia binary graphics drivers" [Undecided,New] https://launchpad.net/bugs/104613
<ubotu> New bug: #205198 in xorg (main) "install xserver-xorg in chroot whoes about /lib/modules/2.6.24.3/modules.dep" [Undecided,New] https://launchpad.net/bugs/205198
<ubotu> New bug: #204929 in xserver-xorg-video-intel (main) "Slow scrolling" [Undecided,Confirmed] https://launchpad.net/bugs/204929
<ubotu> New bug: #205004 in linux-restricted-modules-2.6.24 (restricted) "mythfrontend.real crashed with SIGSEGV" [Undecided,Confirmed] https://launchpad.net/bugs/205004
<ubotu> New bug: #35930 in linux-restricted-modules-2.6.15 "Nvidia Driver + Consolle ttyXX = Problem" [Medium,New] https://launchpad.net/bugs/35930
<ubotu> New bug: #205293 in xf86-input-evtouch (universe) "Hardy / touchscreen calibration doesn't work on panasonic t2 (driver evtouch)" [Undecided,New] https://launchpad.net/bugs/205293
<ubotu> New bug: #205264 in compiz (main) "hardy slow while compiz running (dup-of: 177492)" [Undecided,New] https://launchpad.net/bugs/205264
<ubotu> New bug: #205314 in xkeyboard-config (main) "layout switching with both alt keys doesn't work" [Undecided,New] https://launchpad.net/bugs/205314
<pwnguin> interesting question
<pwnguin> if a user has both an ati and nvidia graphics card
<pwnguin> and install xorg-video-fglrx and nvidia-glx-new
<pwnguin> what should happen to libGL?
<tjaalton> not possible
<tjaalton> they conflict
<tjaalton> apparently they don't, and that's a bug
<bryce> heya
#ubuntu-x 2008-03-23
<tjaalton> hey
<tjaalton> damn stubborn parents for not having a decoder box for digital tv.. kids watching a dvd of Brambly Hedge for the Nth time
<tjaalton> must bring one the next time
<pwnguin> and expose the children to heretical secular television?
<tjaalton> whatever buys more time in the morning :P
<ubotu> New bug: #203991 in gnome-control-center "keyboard layout switching combination keys work only partially" [Unknown,Confirmed] https://launchpad.net/bugs/203991
<ubotu> New bug: #205480 in xserver-xorg-input-evdev (main) "evdev mouse driver breaks dga input for mouse" [Undecided,New] https://launchpad.net/bugs/205480
<ubotu> New bug: #205508 in linux-restricted-modules-2.6.22 "nvidia driver install  dpkg: failed to open diversions file: Input/output error" [Undecided,New] https://launchpad.net/bugs/205508
<Q-FUNK> re
<ubotu> New bug: #205548 in xorg (main) "[hardy] x-server falls back to low resolution" [Undecided,New] https://launchpad.net/bugs/205548
<ubotu> New bug: #205639 in xserver-xorg-video-intel (main) "no video output with xorg-intel drivers and intel 945GM" [Undecided,New] https://launchpad.net/bugs/205639
<ubotu> New bug: #205676 in linux-restricted-modules-2.6.24 (restricted) "nvidia quadro fx 1400 driver not loaded" [Undecided,New] https://launchpad.net/bugs/205676
<ubotu> New bug: #205725 in linux-restricted-modules-2.6.24 (restricted) "Screen "out of range" after installing Nvidia drivers " [Undecided,New] https://launchpad.net/bugs/205725
#ubuntu-x 2009-03-16
<lool> Hey folks
<lool> -intel fails to build under jaunty ATM
<lool> ../../src/i830_quirks.c:248: erreur: âQUIRK_BROKEN_ACPI_LIDâ undeclared (first use in this function)
<lool> This was reported to the list recently too
<lool> Since the 4th of March
<lool> Reported
<lool> https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/343574
<ubottu> Ubuntu bug 343574 in xterm "xterm (actually all Xt clients) does not run" [Undecided,New]
<lool> Does that ring a bell to anyone?
<lool> xterm Xt error: Unresolved inheritance operation
<jcristau> never seen that before
<lool> It seems the Xt error is a stub which is triggered when something isn't implemented
<lool> jcristau: It's likely armel specific
<jcristau> i was going to try on agricola when i get some time..
<lool> jcristau: Thanks; if you have any idea of how to debug this, I'm interested :)
<jcristau> it's Xt. debugging likely to involve drinking.
<lool> Argh
<lool> jcristau: http://launchpadlibrarian.net/23910522/.xsession-errors.1 do you think it could be related to the ICE warnings at the top?
<jcristau> no. those probably just mean the kernel's missing ipv6
<bryce> booted -ati 6.12.0.  All looks good, uploading...
 * bryce waves to tormod
<tormod> hi bryce!
<tormod> notice we have less than 100 -ati bugs :)
<bryce> :-)
<bryce> btw I put in 6.12.0 this morning
<tormod> and none New-Undecided
<bryce> excellent, now to just get them all forwarded upstream
<tormod> yeah, I saw that. When do we get the kernel bits? nothing it kernel git so far
<bryce> presently, the kernel team is waiting on Alex to send a git branch for ubuntu with the essential drm changes cherrypicked
<tormod> nice. good boy alex
<bryce> so... hopefully something that can get resolved within the day
<bryce> I hope so anyway... we're getting down to the wire
<tormod> btw I have a couple of bugs with patches, for savage and i128 (yuck)
<bryce> and... in other ati news...  http://people.ubuntu.com/~bryce/fglrx-8.60.jpg
<tormod> seems like i128 never worked in intrepid and Jaunty...
<bryce> might be; I've never tested that one myself
<jcristau> tormod: people still have that hw?
<tormod> apparently :)
<tormod> at least two Ubuntu users 
<tormod> for Intrepid, SRU will be needed I guess, but the chances of regressions are very small :)
<tormod> jcristau: I guess these fixes apply for Debian as well
<jcristau> have a link to the bug handy?
<tormod> bug #306970 and bug #340750 for i128
<ubottu> Launchpad bug 306970 in xserver-xorg-video-i128 "startup crash - undefined symbol xf86usleep" [Undecided,Fix released] https://launchpad.net/bugs/306970
<ubottu> Launchpad bug 340750 in xserver-xorg-video-i128 "startup crash - bad unmap with libpciaccess [patch]" [Undecided,Confirmed] https://launchpad.net/bugs/340750
<jcristau> sounds like server-1.5 bugs :)
<tormod> oh the first is only for SRU
<jcristau> so if they're fixed upstream i'm good
<tormod> the second is not committed upstream, there's a patch in a bug report
<tormod> now for savage there is bug 294899, which just needs a cherrypick, or a new snapshot
<ubottu> Launchpad bug 294899 in xserver-xorg-video-savage "No signal with Samsung SyncMaster 570s and ProSavage8 [patch]" [Undecided,Fix committed] https://launchpad.net/bugs/294899
<tormod> then I have a controversial patch for bug 33617 - let PCI be default for savage, since AGP makes so much trouble
<ubottu> Launchpad bug 33617 in xserver-xorg-video-savage "[agp] X.org does not initialize screen on IBM T20, T21, T22" [High,Confirmed] https://launchpad.net/bugs/33617
<tormod> I asked on #xorg-devel last night but nobody cares about savage
<jcristau> tormod: mind to file a debian bug for 294899, so i can try to get it in a lenny update?
<tormod> jcristau: ok, will do (but not tonight, I need to go to bed like 2h ago)
<tormod> bryce: anything else I can do for these bugs? debdiffs?
<jcristau> tormod: thanks!
<bryce> tormod: debdiffs are almost always helpful
<tormod> bryce: for the i128 SRU should it be one debdiff for the two bugs?
<bryce> tormod: that'd probably be okay
<bryce> tormod: fwiw, today and possibly tomorrow I'm focusing on finalizing package uploads for beta-freeze; after beta-freeze I'll be focusing exclusively on bugs, so assign me any bugs with debdiffs that should go in for jaunty
<tormod> bryce: ok
<tormod> I got a funny PPA failure now: configure: error: C compiler cannot create executables
<bryce> ouch, that sounds bad
<tormod> that is on lpia (the others are
<tormod> sorry, amd64 is fine, i386 is waiting
<bryce> I've booted both -ati 6.12.0 and the new -fglrx on an R630 card, and it seems to be working.  Now to try my 7xx card...
<tormod> bryce: so there will be an fglrx before Beta?
<bryce> what I'm testing is non-redistributable, but we definitely have a working -fglrx for jaunty at hand
<crdlb> but they're not changing their mind on having no r300-500 driver for xserver 1.6, I assume?
#ubuntu-x 2009-03-17
<bryce> crdlb: I'm not at liberty to discuss that
<crdlb> proprietary drivers suck so much ...
<bryce> agreed wholeheartedly
<crdlb> so I guess nvidia is going to drop 6 and 7 support soon :)
<bryce> really?  I hadn't heard anything about that
<crdlb> no, I just mean they can follow ATI's lead now
<bryce> ah, well -nvidia of course has the legacy driver situation going on
<bryce> thankfully they've been providing updated builds of those
<tormod> if it means they will concentrate (as in reassign) efforts on the open-source drivers, let fglrx slowly die
<bryce> sweetness, -fglrx on hd4850 is good to go too
<bryce> (previous test was on hd2600)
<bryce> mm, fast too
<tormod> bryce re hd2600, do you get issues like in bug 339647
<ubottu> Launchpad bug 339647 in xserver-xorg-video-ati "[M76] Screen tearing when playing back video on HD2600" [Undecided,Confirmed] https://launchpad.net/bugs/339647
<bryce> heh, wish you'd asked like 15 min ago
<bryce> I can give it a try later though
<tormod> you're sitting with the card in your hand now :)
<bryce> yeah I pulled it out to put the 4850 in; so am going to test that one a bit first
<bryce> sad; 6.12.0 no workie on the hd4850 (white screen)
<tormod> bryce: and that's not the white screen of compiz?
<bryce> # ls -l /usr/bin/compiz
<bryce> -rw-r--r-- 1 root root 12206 Mar 16 07:37 /usr/bin/compiz
<bryce> also tried disabling dri, dri2, and glx, no change
<bryce> also it's occurring before the gdm screen; usually the compiz whitescreen happens after login, right?
<crdlb> always :)
<crdlb> well, unless you have a gdm that uses compiz
<bryce> startx fails too
<bryce> XAA and EXA both failing same way
<bryce> hmm, do we know any other tricks?
<tormod> nothing in the logs?
<bryce> http://bryceharrington.org/files/Xorg.0.log
<jcristau> tried noaccel?
<tormod> there is no XAA support for r6/7xx but I guess your option is just ignored
<bryce> jcristau: good point
<bryce> hmm, noaccel -> black screen instead
<bryce> hmm, well maybe it's just dependent on the kernel stuff
<bryce> speaking of which... alex just sent in the kernel patch to tim
<bryce> heh, avivotool crashes the box
<bryce> er, locks it up anyway
<bryce> interesting; the reporters on bug 325394 found it fixed with the git snapshot
<ubottu> Launchpad bug 325394 in xserver-xorg-video-ati "[RV770 HD 4850] ATI Radeon HD 4850 not supported - white screen and system freeze" [High,Fix released] https://launchpad.net/bugs/325394
<bryce> down to 13 bugs against xorg
<tjaalton> whoa, less than 1700 bugs
<tjaalton> btw, a fresh install doesn't seem to run dexconf at all, resulting in an empty xorg.conf
<bryce> is that intentional?
<tjaalton> don't think so
<tjaalton> having no xorg.conf would be better
<bryce> btw, I also noticed xserver-xorg-video-vesa doesn't seem to be installed by default (at least, it was missing on my test box after intrepid->hardy upgrade)
<tjaalton> which means that -video-all was removed too?
<bryce> yeah
<bryce> # apt-cache policy xserver-xorg-video-all
<bryce> xserver-xorg-video-all:
<bryce>   Installed: (none)
<bryce>   Candidate: 1:7.4~5ubuntu15
<bryce>   Version table:
<bryce>      1:7.4~5ubuntu15 0
<bryce>         500 http://us.archive.ubuntu.com jaunty/main Packages
<tjaalton> they seem to be installed on our fresh installations
<bryce> hmm
<tjaalton> so maybe a driver wasn't rebuilt when you did the upgrade?
<tjaalton> unless it was recently
<bryce> the upgrade was today
<bryce> (for testing -ati 6.12.0 and the new -fglrx)
<tjaalton> ok, the logs might have something
<bryce> maybe.  It's also my pretty heavily pummeled test box, so I don't trust bugs I see on it as representing ordinary users ;-)
<bryce> although I would have thought the upgrade would pull that stuff in...
<tjaalton> even --fix-policy doesn't seem to install -video-all
<bryce> lp's funky for me; pops open the edit title widgets even when I don't want to edit them
<bryce> tjaalton: 340807
<bryce> down to 10 xorg bugs, and soon will be down to 6!
<bryce> tjaalton: bug #134401 you might know how to triage better than I
<ubottu> Launchpad bug 134401 in xorg "[needs-packaging] add support for fujitsu tablet input device" [Wishlist,Triaged] https://launchpad.net/bugs/134401
<tjaalton> bryce: yeah, that looks good now
<bryce> maybe it belongs somewhere other than xorg
<tjaalton> test it locally first :)
<bryce> yeah, tomorrow maybe
<tjaalton> uh, yet-another touchscreen driver
<tjaalton> looks like it's a modified evtouch
<bryce> maybe ought to recommend merging into that upstream, and wontfix in ubuntu?
<tjaalton> yes
<bryce> bug #250372 can probably be closed now, sounds like the issue is no longer present for the user.  You should check that one though.
<ubottu> Launchpad bug 250372 in xorg "Do not add /usr/bin/X11 to path, causes problems with relative symlinked binaries" [Wishlist,Triaged] https://launchpad.net/bugs/250372
<bryce> right, bedtime for me.  cya tomorrow.
<tjaalton> night
<tjaalton> bryce: looks like he modified the PATH locally, which fixed it. I'm not sure if the symlink is still needed or not
<seb128> somebody talked to me about a bug before?
<seb128> tjaalton: was that you?
<tjaalton> seb128: yes, I forwarded it upstream
<tjaalton> about nautilus
<seb128> tjaalton: no clue about it I've no nfs, but does it crash?
<seb128> you can run "gnome-desktop-item-edit .desktop" on the command line
<seb128> hum, the issue is with the nautilus properties?
<seb128> I've no launcher tab there
<tjaalton> let me check
<tjaalton> not quite the same, that one works :)
<seb128> do you get any error when the nautilus dialog close?
<tjaalton> no, it just closes
<tjaalton> nothing in .xsession-errors
<seb128> really weird
<seb128> not crashing?
<tjaalton> nautilus is still running
<tjaalton> it doesn't crash
<tjaalton> and at least the jaunty version doesn't have a launcher tab (anymore?)
<tjaalton> hmm, gotta run for now
<tjaalton> I can debug it more tomorrow
<seb128> ok
<seb128> I doubt upstream will reply
<seb128> they mostly don't read bugzilla and I'm not sure they use nfs
<tjaalton> yeah, bugtrackers are such a pain :)
<tjaalton> but ->
<marijus1> i got kms to work now. but compiz doesnt work. metacity is fine except for video playback. do i have to take care of something special for compiz to work?
<bryce> heh, 313027 has turned into a FOSS-vs-proprietary discussion forum already
<marijus1> hm?
<bryce> tjaalton: for -intel I think I'm going to try a kludge to get around the kernel dependency so we can get 2.6.3 in.  I'm guessing we probably can't hope for a kernel update for -intel at this stage.
<bryce> assuming that works, then we need a quick decision on EXA vs. UXA for -intel for beta.
<bryce> ok, it builds
<bryce> and boots
<bryce> froze up on gdm shutdown though (wtf?)
<bryce> not a freeze; actually just the wireless connection dropped when I closed gdm
<tjaalton> bryce: so you included the header with the driver?
<bryce> tjaalton: not even that; I just s/I915_SETPARAM_NUM_USED_FENCES/4/
<tjaalton> heh
<bryce> alright, seems stable enough.  I'm uploading.
<tjaalton> nice, something to upgrade tomorrow :)
<bryce> ok, -fglrx next
<bryce> superm1: (unless you would prefer handling it...)
<bryce> superm1: hrm, looks like they did not list EPR#'s fixed, so our work flagging bugs seems to have been entirely for naught
<bryce> packaging done, builds/installs ok, time to test
<RAOF> I suppose it'll soon be time to ask for some nouveau FFe's.
<bryce> ok looks good; uploading
#ubuntu-x 2009-03-18
<stgraber> bryce: did you try fglrx on amd64 ?
<stgraber> bryce: X: symbol lookup error: /usr/lib/xorg/modules/extensions//libdri.so: undefined symbol: atiddxAbiDixLookupPrivate
<stgraber> hmm, might just be not working autodetection ... my bad I forgot the device section when writing the xorg.conf (installing by hand so no jockey there)
<stgraber> bryce: Yeahh, looks like the best driver from ATI I've ever seen :) Dual-head with 1920x1080 and 1680x1050 working with Compiz and everything.
<stgraber> Working RandR really rocks
<bryce> stgraber: :-)
<bryce> stgraber: yeah remember to update xorg.conf and reboot.  I found it still needed the DefaultDepth parameter too
<stgraber> that screen is just too big :) what can I do with 3600x1080 :)
<bryce> Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 3840 x 1200
<bryce>  ;-)
<bryce> new large desktops are like new large hard drives.  The first time they seem impossibly huge, but then you get used to it and everything else seems dinky after that
<stgraber> well, the issue is that the second screen is too far, I just can't read it :)
<bryce> tell you what, you *don't* play most full screen games on such a setup...
<stgraber> I've ET:QW around, will give it a try, I guess it's the first time I'll really use that beast. Basically the first time it works, I've been using mostly my netbook till now because it's an Intel and works fine with dual-head :)
<bryce> wow http://people.ubuntu.com/~brian/complete-graphs/xorg/plots/xorg-fullyear-open.png
<bryce> another nice one http://people.ubuntu.com/~brian/complete-graphs/xserver-xorg-video-ati/plots/xserver-xorg-video-ati-fullyear-open.png
<jldugger> do one for invalid bugs ;)
<bryce> heh
<bryce> http://people.ubuntu.com/~brian/complete-graphs/xorg/plots/xorg-fullyear-invalid.png
<jldugger> actually, it might help to do one of those graphs where all the categories stack up
<jldugger> im clearly going to have to google the actual name for them
<bryce> file:///home/bryce/xorg-packagebugs/totals.svg
<jldugger> fail
<bryce> hehe, oops
<bryce> http://people.ubuntu.com/~bryce/totals.svg there we go
<bryce> that's total open across all packages under ubuntu-x
<jldugger> well, i was thinking more the state of the bugs than which package
<jldugger> the idea being you might get a sense of where bugs are flowing to
<jldugger> but im not sure that style really helps
<jldugger> so nvm
<jldugger> like, there's a big bump in nvidia, for example
<jldugger> it winds up creating a spike in everything above it
 * bryce nods
<bryce> yeah, the rate of -nvidia bugs being reported is fairly surprising
<bryce> particularly so since there's not much we can do to fix them
<jldugger> alternatively, its not surprising, because theres nothing else users can do to fix it
<bryce> true
<jldugger> and given that upstream has piss poor upstream support, the nvidia package bug page on LP probably rates highly on the google
<bryce> ah that'd be a good point
<jldugger> (it would be a good point, but it mostly explains me toos, not initial reports)
<bryce> it'd be interesting to sum up nvidia -96, 173, 177, 180, fglrx-installer, lrm-2.6.22 and lrm-2.6.24 to see what % of our bugs are proprietary code's fault
<jldugger> heh
<jldugger> thats a challenge
<jldugger> depends on how you define fault
<bryce> I think I can do it
<jldugger> lemme bring up a hilarious example
<bryce> I define it as the ug reporter's fault since they insist on using the drivers in the first place ;-)
<jldugger> https://bugs.launchpad.net/bugs/156133
<bryce> +b
<ubottu> Ubuntu bug 156133 in linux-firmware "bcm203x firmware improperly capitalized" [Low,Fix released]
<jldugger> the open source stuff is apparently looking for ALL CAPS, while the package offered lowercase
<jldugger> who's fault is that?
<bryce> heh
<stgraber> hmm, I just have one problem with my dual-head setup, when maximizing a window it takes all the space on both screen instead of only the current one (as I think it used to do), any idea of what's wrong there ?
<bryce> what window manager are you using?
<bryce> stgraber: you're using -fglrx?
<stgraber> bryce: yes
<stgraber> same result with metacity and compiz
<stgraber> I configured the dual-head using xrandr and a Virtual of the right size, haven't used ati's tool
<bryce> not sure, maybe fglrx is bugged
<stgraber> bryce: http://paste.ubuntu.com/132801/
<stgraber> I guess it's not the expected behavior ? (works though except that window placing/resize issue)
<bryce> stgraber: yeah I was getting that on all my xrandr calls too
<bryce> however they seemed to work otherwise
<bryce> jldugger:  - http://people.ubuntu.com/~bryce/totals-proprietary.svg - proprietary stuff on the bottom now :-)
<bryce> hmm, someone's been doing some massive triaging on lrm-*
<tjaalton> RAOF: it's been synced already, but FTBFS
<RAOF> It'll also need an updated kernel module, I think.
<tjaalton> ok
<superm1> bryce, well that list of EPR's is likely updated at the time this release turns public and what not
<superm1> since they'll publish a PDF then
<jcristau> lool: fwiw, Xt apps (xclock) seem to run just fine on agricola.d.o
<lool> jcristau: read that, and I have no clue how to debug this
<marijus> hello, im using 2.6.29-rc8 with kms but starting compiz seems to freeze X... where do i look for error messeges... couldnt find any in xsession-errors or xorg.log?
<tjaalton> doubt people here are that far in the future yet.. try #dri-devel
<marijus> ok... tx
<seb128> tjaalton: there?
<tjaalton> seb128: yes, but not at work to be able to debug the launcher issue :)
<tjaalton> just got home
<seb128> tjaalton: ok, too bad alex had some debug clue on #nautilus
<tjaalton> ok, should I join and write it down?
<seb128> well you can join tomorrow from work if you want
<seb128> that will probably be easier
<tjaalton> ok, I'll poke him then
<seb128> he's usually around during european work hours
<tjaalton> he's swedish, so -1h from finland :)
<mnemo> im on xorg-edgers PPA right now, how can I revert back to ubuntu proper??
<maxb> Remove the PPA from your sources.list, use apt-show-versions to locate packages which have a newer version than available in your enabled sources
<mnemo> "apt-show-versions | grep -v uptodate" did the trick
<mnemo> thanks
<bryce> tjaalton: you around?
<tjaalton> bryce: yup
<bryce> tjaalton: I've done some testing on the xorg update I'm going to upload today
<bryce> unfortunately the fix to 60x11-localhost doesn't seem to work
<tjaalton> oh right
<bryce> X runs fine, but the file is not removed
<bryce> but I don't grok the code well enough to spot what the flaw is
<jcristau> the 'remove obsolete conffile' thing seemed incomplete
<jcristau> as far as i could tell from the commit mail
<bryce> jcristau: what else is required?
<jcristau> you need to call remove_conffile_prepare in preinst, and _rollback in postrm abort-upgrade
<jcristau> as far as i can tell you only had remove_conffile_commit, right?
<bryce> right
<tjaalton> hmm
<tjaalton> so it was more complex than I thought
<tjaalton> well, once xserver 1.7 is in karmic or karmic+1, we probably don't need the file at all, since it looks like the default will be changed
<bryce> jcristau: thanks, I'll give that a shot
<tjaalton> AIUI
<jcristau> preinst moves foo to foo.x11-common-tmp; postinst removes it if successful, and postrm moves it back in the rollback case
<bryce> oh, I should add to preinst too?
<jcristau> the more common approach is to just remove the conffile in preinst, but we have inherited these functions from branden, and he was pretty anal about his maintainer scripts so they handle failed upgrades :)
<tjaalton> bryce: yes, I can see that the xorg-common -scripts are in all three files (preinst, postinst, postrm), duh
<tjaalton> which I added a while back
<tjaalton> (removals)
<bryce> ok, giving it a go
<jcristau> xutils uses them too, if you need an example usage
<tjaalton> that's what I used too, IIRC
<bryce> hrm, still not working
<bryce> what does the $2 mean here?
<bryce>   if dpkg --compare-versions "$2" lt-nl "1:7.4~5ubuntu16"; then
<jcristau> $2 is the version you're upgrading from
<jcristau> (or empty for initial install)
<tjaalton> so it won't work if you reinstall the same version
<bryce> I've been downgrading x11-common back to 5u15 for testing
<tjaalton> ah
<bryce> is that the right package or ...?
<jcristau> yeah
<bryce> hrm
<bryce> shall I just commit what I have so far to git, for you guys to review?
<bryce> otherwise I'm tempted to just leave this fix out of this 5u16 and work on it later
<bryce> this is what I have for committing -> http://people.ubuntu.com/~bryce/localhost_2.patch
<jcristau> bryce: s/xinit/x11-common/?
<tjaalton> heh :)
<bryce> well, the other Xsession.d scripts say xinit
<tjaalton> because they used to be in xinit
<tjaalton> IIRC
<bryce> oh
<tjaalton> but removed in x11-common for some reason I can't remember
<jcristau> the package name there is used to look up the conffile's checksum in dpkg's status db
<bryce> finally, that did it
<bryce> ok thanks
<bryce> ok, everything is pushed
<bryce> xorg-7.4~5ubuntu16/debian/apport/server-0.xkb ???
<tjaalton> hm?
<bryce> just a stray file I guess.  Not sure where that came from
<bryce> http://people.ubuntu.com/~bryce/xorg_7.4~5ubuntu16.debdiff
 * bryce adds x11-common.preinst.in, x11-common.postrm.in to changelog
<bryce> final changes pushed; 5u16 uploaded to jaunty.  thanks again.
<bryce> tjaalton: did you see http://lwn.net/Articles/323668/ ?
<bryce> seems there are as many people thinking we should have stuck with 2.5 as there are pushing us for going to 2.7.  heh
<tjaalton> bryce: hehe
<andersk> It seems that current fontconfig-config in Jaunty forces the creation of /etc/fonts/conf.d/10-no-sub-pixel.conf and is no longer configurable? 
<tjaalton> talk to asac
<tjaalton> but first update to ubuntu10
<andersk> I have 2.6.0-1ubuntu10. 
<tjaalton> ok
<andersk> `dpkg -c fontconfig-config_2.6.0-1ubuntu10_all.deb` indicates that it really does contain /etc/fonts/conf.d/10-no-sub-pixel.conf. 
<tjaalton> so talk to asac
<tjaalton> and file a bug
<jcristau> andersk: 'sudo rm /etc/fonts/conf.d/10-no-sub-pixel.conf' doesn't make you happy?
<bryce> https://bugs.edge.launchpad.net/ubuntu/+source/xorg/ --> down to 5 bugs
<andersk> jcristau: It does, but only until the next fontconfig-config upgrade. 
<andersk> Anyway, reported as bug 345123. 
<ubottu> Launchpad bug 345123 in fontconfig "Jaunty fontconfig-config forces subpixel off" [Undecided,New] https://launchpad.net/bugs/345123
<jcristau> andersk: no
<jcristau> it shouldn't come back on upgrade
<andersk> Well, it has disappeared during the last few upgrades, and I also tested it with `aptitude reinstall`. 
<andersk> I tested again by downgrading to -ubuntu9, removing the symlink, and upgrading to -ubuntu10; the symlink came back. 
<jcristau> weird.
<bryce> jcristau: should the /usr/bin/X11 symlink still exist?
<bryce> root@dorset:/etc/X11# ls -ld /usr/bin/X11
<bryce> lrwxrwxrwx 1 root root 1 Mar 19  2008 /usr/bin/X11 -> .
<bryce> oh nevermind, I got it.
<andersk> Even if I create an empty file 10-no-sub-pixel.conf, it is deleted and the symlink is recreated on reinstall. 
<jcristau> bryce: yes, that's ok
<andersk> According to /var/lib/dpkg/info/fontconfig-config.conffiles, /etc/fonts/conf.avail/10-no-sub-pixel.conf is listed as a conffile but /etc/fonts/conf.d/10-no-sub-pixel.conf is not. 
<andersk> Debian #421344 and #421345 might be relevant. 
<ubottu> Debian bug 421344 in dpkg "dpkg: does not gracefully handle symlink conffiles" [Normal,Open] http://bugs.debian.org/421344
<ubottu> Debian bug 421345 in lintian "lintian: does not alert on non-conffile symlink in /etc" [Normal,Open] http://bugs.debian.org/421345
<andersk> And Debian #421346 
<ubottu> Debian bug 421346 in debhelper "debhelper: should automatically mark symlinks in /etc as conffiles" [Normal,Open] http://bugs.debian.org/421346
<bryce> sweet, 'xorg' bugs are all done.
<bryce> I pity the fools who insist on installing the latest drivers (e.g. -fglrx) yet don't know anything about xorg.conf configuration and get screwed up as a result... 
<marijus> bryce: well, learning by doing... isnt it?
<bryce> guess it'll have to be ;-)
<bryce> I put a more kindly worded variant of the above onto bug #313027
<ubottu> Launchpad bug 313027 in fglrx-installer "MASTER: fglrx does not support xserver 1.6" [High,Fix committed] https://launchpad.net/bugs/313027
<marijus> :)
#ubuntu-x 2009-03-19
<bryce> heh, people are still complaining about CAB - https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/343690/comments/3
<ubottu> Ubuntu bug 343690 in xserver-xorg-video-intel "[Jaunty] 82865G Integrated Graphics Controller fails to load X" [Medium,Incomplete]
<tjaalton> jcristau: asac dropped the debconf templates from fontconfig..
<tjaalton> I'm not sure why
<bryce> tjaalton: libdrm has one bug left, but I'm uncertain what to do about it
<tjaalton> bryce: actually it should be fixed by the one we have
<tjaalton> jcristau fixed it, libdrm1-intel.symbols referenced libdrm and not the package itself :)
<bryce> ok, so can we just close it then?
<tjaalton> yes
<bryce> awesome
<tjaalton> and -intel could drop the direct dependency
<bryce> ok... I'll add that for my next -intel upload
<bryce> tjaalton: hmm, what was the specific change in libdrm that enabled this to be dropped?  I'm sort of sketchy understanding this
<tjaalton> bryce: commit a87c1a081b77a29fe3430d
<bryce> hmm, we seem not to have that change?
<bryce> libdrm_intel.so.1 libdrm2 #MINVER#
<tjaalton> oh
<bryce> wait nevermind, I was looking at the wrong git checkout
<tjaalton> it should be merged
<bryce> yep, it's good.  I just have a lot of stray broken git trees from when I did the libdrm merge.  Guess I need to tidy up a bit.
<tjaalton> btw, -joystick is uninstallable, but maybe it's time for a FFe as well since the current one doesn't build
<bryce> what needs done?
<tjaalton> upload a new upstream version
<tjaalton> there's 1.4.0 available
<bryce> can we sync?
<tjaalton> it's not in debian
<bryce> oh
<bryce> er, weird.  why not?
<tjaalton> because hardly anyone uses it, and xserver 1.6 is still in experimental
<bryce> oh you mean 1.4 isn't in debian, not that -joystick isn't in debian
<tjaalton> so when it's moved to unstable, every driver needs to be rebuilt
<tjaalton> yeah
<bryce> sorry, it's late, my brain must be going, again
<tjaalton> heh
<tjaalton> and early here
<bryce> ok, if it's just a matter of updating to the new tarball I can take care of that right now
<bryce> but I see there's some notes... "drop the fdi file and push for hal recognising joysticks (patch by mjg59)" - not sure what that means
<tjaalton> well, I could sort that out
<tjaalton> the fdi file needs a cleanup
<bryce> ok thanks
<bryce> I should have this uploaded in 15 min or so
<tjaalton> k, gotta go now ->
<bryce> tjaalton: ok, 1.4 uploaded.  Have at it with the fdi changes whenever's convenient.
<tjaalton> bryce: sure, thanks
<tjaalton> seb128: what nick does alex use?
<seb128> alex_
<seb128> he's not there yet apparently
<tjaalton> ok, not there yet
<tjaalton> right
<federico1> tseliot: any further progress on bgo#572876, by the way?
<tseliot> federico1: no, sorry, I've been very busy with my new job. It's on my TODO list though
<federico1> ah, ok
<federico1> new job?
<tseliot> federico1: at Canonical ;)
<tseliot> federico1: I work for the OEM team on X stuff now
<federico1> oooh, the pain of OEMs
<federico1> good luck, and congrats :)
<tseliot> thanks :-)
#ubuntu-x 2009-03-20
<superm1> bryce, i'm starting to think it makes sense to include some type of patch that would force fglrx to be the active graphics driver when installed given bulletproofx is entirely shot and you can't use radeon/radeonhd when it's installed..
<tjaalton> radeon should work, just not with DRI
<superm1> well the majority of people won't know to put NoDRI or what not in xorg.conf tho
<bryce> tjaalton: I couldn't get radeon to work at all as long as fglrx was installed
<bryce> although I didn't try NoDRI
<tjaalton> ok
<tjaalton> weird
<bryce> I've been spotting various bug reports (including one where the guy deleted libdri.o to get radeonhd working again)
<tjaalton> maybe the kernel module is hostile
<bryce> maybe
<superm1> well radeon and fglrx's kernel modules can't be loaded simultaneously afaik
<tjaalton> so radeon doesn't work at all without it then
<superm1> oh how about adding modprobe options to radeon to rmmod fglrx 
<superm1> if its loaded 
<tjaalton> it should be unloaded before the server starts
<tjaalton> so where exactly?-)
<superm1> gah, that's unfortunate
<bryce> one user thinks we should ship two versions of xorg with each ubuntu release, so we can retain backwards compatibility for an older fglrx that supports their r3xx card
<superm1> oh that would be fun
<bryce> tjaalton: what's the status of the vblank stuff?  I've been seeing some scattered error messages mentioning vblank, is that just a stray warning?
<bryce> superm1: I laughed.  They didn't appreciate it though.
<superm1> bryce, yeah from their perspective i suppose it looks like "ubuntu is breaking fglrx" rather than "fglrx isn't supporting the latest releases"
<tjaalton> bryce: yes, it's disabled by default in the dri driver
<tjaalton> we'll all be laughing a year from now ;)
<RAOF> When nouveau is the default nvidia driver, and radeon{,hd} supports all cards with 3d?
<bryce> RAOF: that'll be an enjoyable day
<bryce> RAOF: of course by then everyone will be owning GMA500's and wanting -psb working
<tjaalton> RAOF: even I am not that optimistic, meant that r6xx-> should be supported by the dri driver by then ;)
<tjaalton> bryce: hehe
<bryce> tjaalton: noticed most recently on https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/xorg/+bug/345714/
<ubottu> Ubuntu bug 345714 in xorg "[Mobile 4 IGC] X exits when switching ttys on 2.6.3" [High,Incomplete]
<bryce> Mar 19 22:42:15 laptop kernel: [ 4495.802798] [drm:gm45_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
<tjaalton> I don't think the message is related, but best ask upstream what they think
<tjaalton> related to the crash..
 * bryce nods
<bryce> I'll shoot it upstream next week.  Just need a bit more info from robbie.
<bryce> I hate upstreaming to Intel with incomplete info, they always nitpick
<tjaalton> :)
<maco> anything change in -intel lately to explain why i cant enable compositing in kwin?
<bryce> 2.6.3
<maco> er...string to go with those numbers?  "new upstream version" or some such?
<bryce> yep
<maco> was that in the last month?
<tjaalton> this week
<maco> oh, im not that far behind then
<maco> ya know, on finding out a chunk of functionality just disappeared
<tjaalton> which chip?
<tjaalton> try with a new user first
<maco> i965
<maco> Subsystem: 1043:8265
<maco> ok
<tjaalton> compiz works on mine
<tjaalton> so doubt it's the driver at fault
<maco> i did try "reset to defaults" on the kwin settings
<maco> the message that came up said to check the X config
<maco> and the compositing type
<tjaalton> sure, "blame someone else" ;)
<tjaalton> check the x log if dri is enabled
<tjaalton> glxinfo should reveal it too
<maco> fails on a new user too
<maco> direct rendering: Yes
<maco> (i assume thats what you mean?)
<tjaalton> yes
<maco> i dont have uxa explicitly enabled anymore, but the default is to not enable uxa, isnt it? so that should make no difference?
<tjaalton> shouldn't
<RAOF> Won't the software renderer _also_ return 'direct rendering: Yes' in Jaunty?
<maco> well my xorg.conf currently looks like what dexconf outputs, except that it has a commented out 'Option "AccelMethod" "uxa"' line
<RAOF> I suppose that check can pick up partially working, but broken.
<bryce> look at OpenGL renderer string to see if software rendering is going on 
<tjaalton> maco: just try compiz next :)
<maco> darn, people that know i still have gnome installed
<maco> :P
<tjaalton> I didn't, but apt-get works :)
<maco> "desktop effects could not be enabled"
<maco> lately all the whining ive done while testing has been of the "good for you gnome-only people, but that totally breaks for people using kde and gnome!" variety
<crdlb> my new general-purpose 3d checker is glxinfo | egrep 'direct|software' :)
<maco> crdlb: no lines matched for software
<tjaalton> try a daily live-cd, if it doesn't work, then I'll believe there's something wrong in the driver :) 
<maco> note that the last few days' live cds have been over 700mb...
<tjaalton> too bad
<crdlb> did you look at the compiz output to see exactly what failed?
<maco> no i just tried the appearances window that i hate...will switch consoles
<maco> though i should point out: vt switching is broken more weirdly now
<tjaalton> compiz --replace in a terminal
<maco> from the kdm screen on which the other user was logged in, i cant ctrl+alt+f7 back to here. it just keeps refreshing kdm. cant get from there to a tty either. even when i do it twice in a row
<tjaalton> uh
<tjaalton> you don't have dri in the second sessionÃ¤
<tjaalton> -Ã¤
<tjaalton> so you need to try it in the primary session
<maco> software rasterizer detected: abortingaborting, falling back to /usr/bin/metacity
<maco> i thought it just couldnt be in use in two sessions at once
<tjaalton> right, what I said :)
<crdlb> oops, I forgot -i :)
<maco> oh ok well that works...compiz does run
 * maco glares at kwin for lying
<crdlb> what happened to multi-master drm?
<maco> ah! who made the compiz window switcher so busy?!
<tjaalton> crdlb: WIP
<maco> hrm well then i guess i should go ask in #kubuntu-devel
<tjaalton> probably so
<crdlb> tjaalton: heh, it just seems like it should have gotten in by now
<tjaalton> there's a wikipage on wiki.x.org about it
<tjaalton> iirc
<maco> ctrl+c'ing compiz didnt bring kwin back. and plasma died. and my keyboard stopped working.  adding "use compiz inside kde" to the list of things i shouldnt do
<tjaalton> there's a wikipage on wiki.x.org about it
<maco> well i dont think the kbd was the window manager's fault
<maco> that happens from time to time
<tjaalton> uh
<RAOF> Heh.
<tjaalton> the previous comment was an error
<tjaalton> put the phone in my pocket
<maco> ?
<maco> the "uh" or the wiki.x.org comment?
<tjaalton> wiki
<RAOF> OK.  There's a nouveau-kernel-source package that'll build a drm module that's compatible with the driver in Jaunty in bzr.  Tomorrow shall be FFe filing time :/.
<maco> wont work
<maco> bah wrong channel
<maco> my mouse missed
<jcristau> tormod: thanks for filing the savage bug.  uploaded to stable-p-u now.
<tormod> jcristau: great
<tormod> jcristau: btw, why didn't you use debian/patches?
<jcristau> git cherry-pick -x is faster :)
<jcristau> for stuff that's upstream, i tend to just do that
<jcristau> and use debian/patches/ for stuff that either is debian specific or we need to keep longer term
<tormod_> oops, solid lock-up on RV410 (compiz+googleearth)
<tormod_> jcristau: ok make sense. I wondered if it be helpful to post a debdiff, but figured you would use git anyway.
<jcristau> tormod_: yeah with a bug to point the RMs at, it was just a matter of cherry-picking your patch, writing a changelog entry, waiting for an ack, and building the package :)
<jcristau> (and the ack came very fast, so.)
<tormod_> jcristau: yes, I was impressed how fast that went! I thought SRU on Debian would take months :)
<jcristau> tormod_: actually including it in stable will take more time, since that only happens at the point release. but the next one is scheduled for april 4th, so pretty soon too.
<tormod_> let's see how long it takes in Ubuntu, with beta freezes and all that ;)
<bryce> tormod_: which bug is this?
<bryce> tormod_: if it's the pci by default bug, it's already in
<tormod_> bryce: no, it's another
<tormod_> bryce: just assigned it to you tonight: bug 294899
<ubottu> Launchpad bug 294899 in xserver-xorg-video-savage "No signal with Samsung SyncMaster 570s and ProSavage8 [patch]" [Undecided,Confirmed] https://launchpad.net/bugs/294899
<bryce> tormod_: uploaded
<bryce> ok, I'm supposed to be off work today so am going to try to spend the day away from the computer ;-)
<tormod_> bryce: cool, as fast as Debian :)
<bryce> tormod_: touch base with slangasek on beta freeze permission (I already mentioned it to him) but I think this one should sail through fine
<tormod_> bryce: I see. go away from screen
<tormod_> bryce: just want to congratulate you (and tjaalton and others) for getting such an up to date xorg stack in Jaunty! rocks
#ubuntu-x 2009-03-21
<RAOF> Hah!  That's why nouveau DDX wasn't building on amd64; libdrm-dev wasn't pulling in libdrm-nouveau1.
<bryce> RAOF: well that'd explain it.  got a patch?
<RAOF> bryce: Yes, in libdrm git.
#ubuntu-x 2009-03-22
 * hyperair notices xserver-xorg-video-intel is in jaunty
<hyperair> wonder if the performance regressions were fixed by that =\
<hyperair> s/xserver-xorg-video-intel/xserver-xorg-video-intel 2.6.3/
<geser> anyone around who can look at bug 273386 and comment on how to resolve this?
<ubottu> Launchpad bug 273386 in x11proto-xext "libxi-dev may be missing as a Depend" [Undecided,New] https://launchpad.net/bugs/273386
<geser> another package affected by this: https://lists.ubuntu.com/archives/ubuntu-autotest/2009-March/020881.html
<geser> I guess there are some more
<jcristau> have those packages add a build-dep on libxi-dev
<geser> why?
<geser> shouldn't a -dev package depend on the headers it's include files need?
<jcristau> in general, yes
<jcristau> but not in this case, imo.  it'd introduce a dependency loop, and proto package depending on a lib package isn't a good idea.
<jcristau> the problem is, XTest.h has both proto and lib stuff in it.
<geser> ok, will do that
<jcristau> RAOF: why the x86 restriction for the libdrm-dev dependency on -nouveau?
#ubuntu-x 2010-03-22
<Sarvatt> bryceh: where is the codename attachment to the bug title done in your scripts? it would be a lot more useful to have chipset codenames like RV515 instead of say M64P
<Sarvatt> ah fix-titles.py found it
<Sarvatt> bryceh: extending fix-titles to have all ati pci ids and use the chipset codename if you dont mind
<Sarvatt> helps a lot more tracking down bugs if i know the codename like RV515 and there are a *ton* missing in here
<bryceh> Sarvatt, great thanks
<bryceh> yeah the nvidia chipsets are missing there too if you feel ambitious
<bryceh> I run fix-titles.py on -intel manually from time to time, and run it less frequently on -ati
<bryceh> once you've got your changes in I can re-run it on both (unless you'd rather do it)
<bryceh> I figure eventually we'll want it for nouveau too
<RAOF> Yeah, that'd be useful.
<RAOF> (Although it's not always obvious which set of codenames to use; many nvidia chips have at least 2 :/)
<Sarvatt> yup will do, 1/4 the way through ati and will do nvidia after
<Sarvatt> nvidia is easy, theres a nice wiki document having them all
<Sarvatt> http://nouveau.freedesktop.org/wiki/CodeNames
<Sarvatt> i've got a list of all pci ids somewhere around here to map that to
<Sarvatt> phew, gonna take a break at R500 generation :D
<libv> Sarvatt: check radeonhd code, i spent several days in july 2007 doing the same thing
<Sarvatt> ok got everything except cypress hemlock juniper cedar and redwood, not sure on those codenames
<Sarvatt> bryceh: anything special I should do running this? already changed it to dryrun
<Sarvatt> hmm   ---------> Renamed to [RV530] [X1600] jaunty: X session (radeon) slows down, crashes
<hyperair> Sarvatt: i still get my artifacts =\
<Sarvatt> there we go, all ati bug titles with proper logs tagged with the gpu chipset name, kind of throws off incomplete bugs running this though since it resets expiration time
<Sarvatt> ahh darn, things originally filed against xorg dont have PciDisplay: in the description
<Sarvatt> pushed it here but it needs handling for already tagged bugs like cleanup_intel has http://bazaar.launchpad.net/~sarvatt/arsenal/working/revision/491
<vish> hi.. i'm noticing my screen being badly corrupted with artifacts > and the xorg log is showing :
<vish> (II) RADEON(0): Printing DDC gathered Modelines:
<vish> (II) RADEON(0): Modeline "1280x800"x0.0   68.90  1280 1301 1333 1408  800 804 808 816 -hsync -vsync (48.9 kHz)
<vish> (II) RADEON(0): EDID vendor "QDS", prod id 65
<vish> but i'v selected 60kHz in the display settings [which is the default]
<vish> this is in Lucid^
<vish> 60*Hz
<vish> brb , the screen looks horribly disfigured :(
<vish> if i take a screenshot , its doesnt show these problems..
<RAOF> Which suggests that the problem is in how radeon is driving your screen, as you suspected.
<RAOF> Has this issue arisen recently?
<vish> RAOF: hmm , that Xorg log entry might not be the error , but there is no error/message recorded other than those lines..  but yes , this has started recently , i notice the screen corrupted and a restart is the only thing that fixes it and screenshots dont catch the problem :(
<RAOF> But a restart fixes it?  It wouldn't seem to be mode-related then.
<vish> yeah , the restart restores the screen to normal ,  i have never had such bad display , I'v been using Ubuntu for on this system for nearly 2.5yrs
<vish> laptop*
<RAOF> Is there a particular action that you've discovered which triggers the corruption?  Is it only after leaving the computer for a while?  Is it while doing a lot of 3D stuff?  Is it just anytime?
<vish> i have notice the problems when i return from screensaver[rather after the screen has been switched off during idle].. not while any other usage/3D
<RAOF> Always after the return from screensaver?
<vish> it has been random .. i'm not sure what triggers it.. but i have noticed the problem only after i return from screensaver
<vish> no errors in the Xorg/sys logs . no messages , nothing is recorded :s
<vish> i could take foto of the error , but i dont think it would be helpful , not sure where/how i can debug this :(
<RAOF> A photograph of the problem can be surprisingly useful.
<vish> ok , i'll take one the next time it happens
<RAOF> This only happens after a return from screensaver, though?  Is it a particular screensaver?
<vish> i use the GLXMatrix.. i could try switching to a different screensaver
<RAOF> Might be worth checking, yeah.
 * vish switches screensaver
<vish> there has also been another similar error , but it is "fine black noise"[1px black horizontal lines] which also doesnt get caught when using a screenshot as well.. but this started happening several times *while* i was using the system , no fancy 3D stuff , or anything.. this too is solved only by a restart
<vish> same no errors/messages :(  
 * vish thinks the new drm from .33 kernel might be the cause of these problems 
<RAOF> If you think that's the case then you could try booting into the old -15 kernel
<vish> yeah i should, i didnt notice them earlier , its been happening only for the last couple of weeks.  These random errors are quite bugging :s  if it is something i can reproduce it can be pinned down
<vish> RAOF: if the bug happens again , anything else i need to log? to narrow down the bug? [other than a foto , which might help the first bug,  but i'm not sure it would help the black noise]
<RAOF> dmesg & xorg.0.log are the obvious candidates; I'm not aware of anything else for radeon.
<vish> neat.. thanks [but hope they log errors the next time ;-)]
<RAOF> It's quite possible that you can pass some debug parameters to the kernel module, but I'm unfamiliar with them.
<RAOF> And they're likely to be *hugely* verbose.
<vish> whom/where can i ask about those debug parameters? [#u-kernel?]
<RAOF> I'd just wait for the moment.
<vish> k.. thanks :)
<Sarvatt> vish: in /sys/module/radeon/parameters/ can you tell me what the values for dynclks and new_pll are?
<vish> Sarvatt:  dynclks is -1   and new_pll   is 1
<Sarvatt> try booting with radeon.new_pll=0
 * Sarvatt thought that was the default...
<vish> Sarvatt: so the  new_pll one i just change to 0   right?
<vish> or   > radeon.new_pll=0
<vish> ah , got it.. you want me to edit the kernel line :)
<Sarvatt> yeah, sorry
<Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=26358
<ubottu> Freedesktop bug 26358 in DRM/Radeon "new_pll algo gives flickering LVDS on rv620 (HD 3470 mobility) laptop" [Normal,Resolved: fixed]
<Sarvatt> weird refresh bugs and quirks abound because of new_pll=1..
<Sarvatt> you're like the third person in here today to say they have a weird undescribable corruption they cant screenshot on radeon, sheesh
<vish> \o/ i'm not alone ;p  
<vish> btw , this is the Xorg.0.log > http://paste.ubuntu.com/399115/
<vish> Xorg.1.log > http://paste.ubuntu.com/399114/
<Sarvatt> you're the second with an RV515 today too
<Sarvatt> other guy couldn't file a bug because of some KDE problem :(
<Sarvatt> <Consul_Falx> [18:03:35] +Sarvatt: flickery, snowy or like that ...
<Sarvatt> whatever that meant :)
<vish> Sarvatt: you want a bug logged for this? 
<vish> [to switch the default new_pll=0]
<Sarvatt> doubt thats a good idea globally, probably need to make a quirk for your machine and the hundreds of others that need them too
<libv> heh, i cannot believe deucher is still struggling with that, i had that fixed before he even started writing his driver.
<Sarvatt> yuck, all the odd flickering bugs the past few days in -ati are all rv515 and rv530 :D
<libv> m52 or rv515/530?
<Sarvatt> 2xM56P and a x1300 RV515 on this page
<Sarvatt> at least yours doesnt look like this vish - http://launchpadlibrarian.net/41493534/543265_bug_P04.jpg 
<libv> that's not a pll issue
<libv> or...
<vish> ;p 
<libv> hrm...
<RAOF> Whee!  I like my framebuffer well sliced!
<Sarvatt> Everytime I start Ubuntu 10.04 from Live CD, after few minutes screen start to shaking and i cant do anything (Ctrl+Fn is working, but screen is shaking too).
<Sarvatt> (description for that last one)
<Sarvatt> with the screenshot
<libv> ctrl-fn on kms no doubt
<superm1> Sarvatt, i've seen something similar to that on my netbook too
<superm1> but i can't come up with a reproducible scenario for it, it's quite random
<libv> i fear that this photo is that messed up because of the camera
<RAOF> And that the true state of affairs would not include duplicate pieces of screen?
<libv> not for a modesetting issues indeed.
<Ng> interestingly enough, I think I've found a couple of other people seeing similar weird random flickery events on G45s in Lucid
<Sarvatt> tell them to boot with i915.powersave=0 and mention in the bug if that fixes it :)
<Sarvatt> that was default in -15 but not anymore in -16
<tseliot> Sarvatt: unfortunately I experienced some weird corruptions with nouveau (and I had to update libdrm too)
<Sarvatt> tseliot: i told ya in the email you have to update *everything* in the ppa, not just xserver-xorg-video-nouveau too :D
 * tseliot nods
<Sarvatt> got it running though? didn't work? :(
<tseliot> well, it depends on what you mean by "work" ;)
<Sarvatt> what kinds of corruptions?
<tseliot> first of all plymouth didn't work (and it used to work) but I got mode setting. Then I could enter the desktop but the menus and the indicator were blank
<Ng> Sarvatt: interesting. the problem is that it's *really* intermittent, so all I'd be able to say is that it's not happened for a few days ;)
<freeflying> hi all, does xserver-xorg-video-ati works well with xrandr in karmic
<tseliot> Sarvatt: http://albertomilone.com/2010-03-21 19.08.04.jpg
<tseliot> :-/
<tseliot> err... http://albertomilone.com/2010-03-21%2019.08.04.jpg
<freeflying> a 17" crt monitor has been recoganized as 16" 
<Sarvatt> i haven't seen any flickering bugs on 965+ recently, looked like they ironed them all out but powersave=0 for sure should get rid of them Ng
<freeflying> using xserver-xorg-video-ati in karmic
<Ng> Sarvatt: ok, I've passed it on to the other folks and we'll try to start keeping track. Would anything else have changed between -15 and -16 wrt intel? I probably only rebooted into -16 fairly recently
<Sarvatt> yeah *tons*, the entire 2.6.32-2.6.33 drm backport
<Ng> oh hrm, I rebooted longer ago than I thought
<Ng> 17th I think
<Ng> ok well we'll keep an eye on it and see how it goes :)
<tseliot> Sarvatt: can you add this, please? http://0x04.net/~mwk/0001-drm-nv50-Add-NVA3-support-in-ctxprog-ctxvals-generat.patch
<Ng> ok, I was just using another intel laptop in the office that just had a fresh install of beta1 and it was doing the screen flickering thing just like mind, so I'll reboot wit powersave=0 and see if it goes away
<bjsnider> tseliot, i noticed last night that nvidia-settings control file still says build on lpia in lucid
<tseliot> bjsnider: as the rest of the nvidia packages
<bjsnider> why doesn't the build system complain about it?
<tseliot> I don't know
<bjsnider> i find it easier and safer to just put "any" int he architecture
<tseliot> no, why should we?
<tjaalton> just drop lpia
<tjaalton> "any" doesn't work
<tjaalton> no reason to build it on ia64 or sparc
<bjsnider> well, when you use the ppa build system, and tell it to build on lpia/lucid, it errors out. the ppa system doesn't build on ia64 or sparc
<tjaalton> but the main buildd's do
<bjsnider> ia64 is the intel itanium?
<tjaalton> yep
<bjsnider> i thoughtt hat was an experiment?
<bjsnider> are there ia64 production systems out there?
<tjaalton> "amd64 armel i386 ia64 powerpc sparc", those are the archs that "any" would make it build on
<tjaalton> ask HP
<tjaalton> i guess there are, don't know about ubuntu on them
<tjaalton> but that's besides the point
<tjaalton> even though _your_ ppa packages build fine with "any", there's no need to change the main package to do the same
<marcus___> hello
<marcus___> i was curious if it is possible to have the gallium3d nouveau drivers in lucid via the xorg swat/edgers ppa
<marcus___> can someone offer some insight into this? :)
<ara> bryceh, ping
<superm1> tseliot, re https://edge.launchpad.net/ubuntu/+source/fglrx-installer/2:8.721-0ubuntu5 , that shouldn't have been necessary once the binaries were deleted from the archive should it?
<Sarvatt> tseliot: uploaded now, sorry had to sleep a bit there :)
<tseliot> superm1: you might want to discuss this with pitti (who requested transitional packages)
<Sarvatt> it's linux-backports-modules-2.6.32_2.6.32-16.999~git20100321.4d950853~xorgedgers
<superm1> tseliot, ah i'll take a look at bt 
<tseliot> Sarvatt: thanks a lot. Getting some sleep can help from time to time ;)
<superm1> tseliot, but then those changes just need to be local, and not in the amd phorogit stuff, right?
<superm1> i'm guessing they help dist-upgrader's is the particular reason
<tseliot> superm1: right
<superm1> ara, with your proprietary driver testing, is one of your test cases hardy fglrx->lucid fglrx now too?  hardy still had LRM if i'm remembering correctly, i'm wondering how well that would go over
<tseliot> oh, and BTW suspend/resume works with nvidia now (even here!)
<ara> tseliot, \o/
<tseliot> :-)
<ricotz> Sarvatt, hello could you please upload a lbm package for 2.6.32-17 as well?
<Sarvatt> is it the default already?
<ricotz> not yet
<Sarvatt> i dont see a -17 linux-meta
<Sarvatt> yeah not yet sorry, can only have one in there at a time
<ricotz> Sarvatt, ok
<Sarvatt> might need to update 16 again for tseliot here
<ricotz> Sarvatt, perhaps you can look at this patch http://repo.or.cz/w/mesa/mesa-lb.git/commit/432b8cc477344fc7fcbb24b747d56ab087403d09
<ricotz> which might solves the crash on my nv49
<tjaalton> lbm doesn't have nouveau anymore aiui
<Sarvatt> i'm added it back to lbm on edgers since its alot easier to update that
<tjaalton> ah, k
<Sarvatt> one day i'll work out how to properly create a PPA kernel :D
<technoviking> My nvidia driver goes into safe mode when I boot into Lucid. restarting gdm will make the nvidia and X load properly. Anyideas what is causing the problem. https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/532436
<ubottu> Ubuntu bug 532436 in nvidia-graphics-drivers "nvidia driver sometime does not load at boot" [Undecided,New]
<tseliot> technoviking: can you reproduce the problem if you uninstall (with --purge) plymouth?
<Sarvatt> looks like a regression with ati 6.12.192 https://bugs.freedesktop.org/show_bug.cgi?id=27186
<ubottu> Freedesktop bug 27186 in Driver/Radeon "Visual corruption with new r6xx/r7xx accel code" [Normal,New]
<Consul_Falx> hello folks
<Sarvatt> radeon.new_pll=0 quirk needed here https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/543045
<ubottu> Ubuntu bug 543045 in xserver-xorg-video-ati "[RV530] screen flickers in lucid lynx" [High,Incomplete]
<Sarvatt> i'm thinking it should be the default for all RV515 and RV530 mobiles
<Sarvatt> i'm just going to tag them needs-pll-quirk to start making a list to give to the kernel guys to selectively use that option. having the generation in the title sure does help spot these
<Consul_Falx> ey folks
<Consul_Falx> any progress in ati radeon open driver support in lucid?
<bryceh> Sarvatt, sounds good
<tormod> anyone who can sponsor bug #287475 please?
<ubottu> Launchpad bug 287475 in xserver-xorg-video-sis "ASUS A6000 / SIS M760GX grainy graphic display" [Undecided,Confirmed] https://launchpad.net/bugs/287475
<jcristau> i can sponsor it to sid :)
<tormod> jcristau, very well, would you like a debdiff or would you just copy in that patch yourself?
<tormod> or let me commit it to git :)
<vish> i'm having a weird problem , the system slows down and everything is slow to react[random]. the mouse pointer has no lag though... earlier i used to SAK and return to session and everything would be fine.. ..  now , i seem to have a workaround of sorts.. when i switch to a guest session and return , everything is normal and works fine... nothing in the logs or .xsession-errors .. where do i need to look to file a bug?
<jcristau> tormod: i'd say just push it to git.d.o.  you have commit access, right?
<tormod> jcristau, no not to the x packages
<vish> not sure if this means anything > [ 5291.324934] __ratelimit: 3 callbacks suppressed  kern.log > http://paste.ubuntu.com/399544/
<jcristau> tormod: should we fix that? :)
<tormod> jcristau, thanks could be handy :)
<jcristau> tormod: should be done now.  or whenever that thing gets updated.
<tormod> jcristau, should I keep it "unreleased" or "unstable" ?
<jcristau> i don't think there'll be any more changes so unstable should be fine.  iirc there's a debian bug that this could fix, too.
<tormod> thanks, I'll look for it
<tjaalton> just got seven packages synced from unstable
<tormod> jcristau, actually do you usually add a debian/patches/foo or use git cherrypick there?
<jcristau> tormod: usually cherry-pick -x.  and keep debian/patches/ for not-yet-upstream stuff.  but i don't really mind, debian/patches/ works for this too if you prefer.
<bryceh> hi tormod, do you still plan to update debian's intel-gpu-tools package to latest?
<tormod> hi bryce, I was thinking to wait for a release.
<RAOF> Man.  You watch the nouveau bug lists, and note that people hardly ever ask for mmiotraces.  Then we turn nouveau on by default, and all the bugs we send up are âoh, yeah, could you get an mmiotrace of that?  We've never had one for that card beforeâ :X
<bryceh> hehe
<alkisg> Is Intel 82852/855GM ok with xorg in Lucid? Or I'd better keep running Karmic?
<bryceh> Sarvatt, yeah with that pll quirk, as you verify bugs are resolved with that, repoint those bugs to linux for the kernel team.
<bryceh> Sarvatt, might be good to also set a milestone and target them to lucid
<alkisg> Ah ok, I was lacking xv and I was afraid that 855GM wasn't working at all in Lucid, but it's just a kms combination problem: https://wiki.edubuntu.org/LucidLynx/ReleaseNotes#No%20Xv%20support%20for%20Intel%2082852/855GM%20video%20chips%20with%20KMS
<tormod> jcristau, I pushed the cherry-pick. I hope I got that right.
<tormod> hmm maybe I got the version wrong :(
<jcristau> ah yeah the changelog entry should be merged with the previous one
<jcristau> DEBCHANGE_RELEASE_HEURISTIC=changelog in ~/.devscripts helps with that
<jcristau> (if you're using dch)
<jcristau> tormod: didn't you want to close the lp bug in the changelog too?
<tormod> I thought at the time that 1:0.10.2-2 was already released...
<jcristau> it says UNRELEASED ;)
<tormod> jcristau, oh yes, I will add it
<tormod> jcristau, I was not sure if it was so consistent :) but of course it was
<tormod> un-goofing it now
<tormod> jcristau, getting there :) pushed
<jcristau> looks good
<tormod> jcristau, not sure how I update upstream-unstable The Right Way
<tormod> git push origin upstream-unstable tells me Everything up-to-date
<jcristau> yeah upstream-unstable stays on the 0.10.2 tag
<tormod> yes, it was upstream-experimental I had updated ! time for sleep maybe
<jcristau> thanks, and good night!
<tormod> good night! btw, will you release soon so we can sync in ubuntu instead of patching?
<jcristau> yes
<jcristau> either now, or tomorrow morning when i get to the office.
<Sarvatt> http://lists.x.org/archives/xorg-devel/2010-March/006436.html \o/ we have so many bugs about that
<jcristau> ok, tormod's sis fix is in incoming now.
<stgraber> hey there !
<stgraber> I have a few thin clients (Netbook like hardware) with Intel 945GM (8086:27a6) showing a LVDS1 output since a few days on Lucid. It used to be a problem back in Jaunty if I remember well where I had to make a few scripts to automatically blacklist that output on non-netbook but it was fixed in karmic/early-lucid.
<stgraber> I quickly went through a few bugs on LP and it's not very clear if it's a known issue or not and if it's something that we plan on fixing for lucid or not (if we don't, I'll restore the old hack in the ltsp package and upload it to Lucid to fix the issue immediately)
<jcristau> so the bios pretends there's an lvds?
<stgraber> might be, yep. A few thin clients seem to have BIOS reporting LVDS output
<stgraber> though usually they are blacklist (in the driver IIRC) because the Chassis type and some other info report that it's desktop hardware and not laptop
<RAOF> Do they have ACPI lid switches?  i915.ko shouldn't attempt to bring up LVDS screens without a lid-switch, I think.
<stgraber> RAOF: no /proc/acpi/button/lid (only button/power is there)
<RAOF> Hm.  Maybe that commit isn't in our kernel?
<stgraber> I'd certainly love to see that check in as it'll solve a lot of issues I have with Atom-based thin clients (exact same hardware as netbooks but used as desktop with a single DVI-I output usually)
<jcristau> RAOF: 11ba159288f1bfc1a475c994e598f5fe423fde9d reverted that
<RAOF> jcristau: Ah, ok.
<jcristau> apparently there's stuff with a lid switch but no lvds
<jcristau> so the driver trusts the bios.
<stgraber> hmm, if the issue is stuff with a lid switch and no lvds, how can it hurt to disable LVDS if it's reported by the BIOS and no lid switch is found ?
<stgraber> I'd guess the issue is for stuff with LVDS but no lid switch
<RAOF> Right.
<jcristau> stgraber: there's a quirk list in drivers/gpu/drm/i915/intel_lvds.c where your stuff could be added
<jcristau> static const struct dmi_system_id intel_no_lvds[] = {
<jcristau> "These systems claim to have LVDS, but really don't"
<stgraber> good, only issue is to make a rule that matches my hardware but not a generic netbook then
<jcristau> with mac minis, aopen something, and dell studio hybrid in there already.
 * stgraber updates his copy of ubuntu-lucid.git
<stgraber> jcristau: http://paste.ubuntu.com/399595/
<stgraber> Is that something you can commit yourself or should I open a bug on LP + poke the kernel team about it ?
<jcristau> should probably poke your kernel team, or send it upstream to eric@anholt.net, dri-devel@lists.sf.net
<stgraber> jcristau: ok, I'll open a bug on LP and e-mail the patch to these two e-mails as well
#ubuntu-x 2010-03-23
<Sarvatt> byebye klingon? :D
 * Sarvatt slaps forehead
<Sarvatt> mistook the libXi sync for libX11 :)
<Sarvatt> RAOF: savage DRI sucks huh?
<RAOF> Sarvatt: Looks like it :)
<RAOF> That said, in hindsight I should probably have pushed that bug on the DDX; running with swrast kills X.
<Sarvatt> every time I see bug mail from you for desktop app crashes it's always savage DRI :D
<RAOF> Yes! :{
<Sarvatt> the crashes fixed by http://lists.x.org/archives/xorg-devel/2010-March/006436.html seem to be triggered by kmail mostly
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/401045
<ubottu> Ubuntu bug 401045 in xserver-xorg-video-ati "X crashes in FindGlyphByHash" [Undecided,Confirmed]
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/442144
<ubottu> Ubuntu bug 442144 in xserver-xorg-video-intel "Xorg crashes with SIG 11 in FindGlyphRef" [Undecided,Incomplete]
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/479031
<ubottu> Ubuntu bug 479031 in nvidia-graphics-drivers-180 "Ubuntu 9.10 Crash in /usr/bin/X(FindGlyphRef+0x2c) [0x5277cc] on nvidia nvidia-glx-185, SMP quadcore" [Undecided,Confirmed]
<Sarvatt> lots :)
<Sarvatt> will give it a few days and see if anyone reviews it before building test packages for people, not sure if its correct. the commit its referencing is from 2007 so its been around awhile
<Sarvatt> ok, updated the wiki some more with these new symptoms
<Sarvatt> https://wiki.ubuntu.com/X/Bugs that is
<RAOF> Balls.  It looks like just *loading* vga16fb can annoy the precious flower that in nouveau.
<Sarvatt> huh RAOF? vga16fb isn't loading at all in that guys blacklist=vga16fb dmesg
<RAOF> Right.  And in that dmesg you'll note that nouveau complains a lot less? :)
<Sarvatt> oh i didnt look at the one with it, the blacklisted one still locks up as soon as it starts
 * Sarvatt has WAY too many tabs open
<RAOF> :)
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/447159
<ubottu> Ubuntu bug 447159 in xserver-xorg-video-intel "[i945gm] Xorg assert failure: X: ../../src/i830_batchbuffer.h:79: intel_batch_emit_dword: Assertion `pI830->batch_ptr != ((void *)0)' failed." [Medium,Confirmed]
<Sarvatt> needs some serious love
 * Sarvatt todo's
<Sarvatt> RAOF whats the bug# for the nouveau guy?
<Sarvatt> i just had the dmesg tab open
<Sarvatt> nevermind I see it in #nouveau
<RAOF> 542950
<RAOF> Yah.
<Sarvatt> hmm, first though, that an AGP card?
 * Sarvatt looks
<Sarvatt> oh 6100 IGP..
 * Sarvatt has a 6150IGP booted up right next to me with nouveau
<Sarvatt> sure wish it was easier to see what commits we have in our kernel
<RAOF> I recently learnt that âgit log nouveau/master...â is git for âthe commits in nouveau/master that aren't in your current HEADâ
<Sarvatt> all of nouveau was added in one commit
<RAOF> That's quite true.  Why was that command useful to me again?...
<RAOF> Oh!  Because we know that lucid has drm from 2.6.33, so you can find the commits in nouveau/master that aren't in 2.6.33
<RAOF> Acutally, we now have drm from 2.6.33.1 I believe, but there weren't any nouveau commits of interest.
<Sarvatt> dont know what i'm gonna do with lbm-nouveau now that its 2.6.34
<Sarvatt> theres more changes that touch nouveau outside of drm, some acpi change
<RAOF> How much does drivers/gpu/drm interact with stuff that's out of that tree?
<RAOF> Ah.
<RAOF> Maybe it's time to switch to providing full-on kernels?
<RAOF> That shouldn't be *that* much more effort than updating lbm-nouveau.
<RAOF> âlshw causes display to freak outâ.  That's my sort of bug title.
<Sarvatt> yeaaah drivers/gpu/drm/nouveau/nouveau_irq.c where the messages are happening is a pretty rough read
<Sarvatt> thats happening for alot of people on intel right now for some reason
<Sarvatt> the lshw -C video making the screen trippy, doesn't happen here
<RAOF> I think there are rather a lot of duplicates of bug #535640 wandering in at the moment.
<ubottu> Launchpad bug 535640 in xserver-xorg-video-intel "[gm45] GPU lockup de05bf80bf83cd22541cb55f1a2ee99e (xorg crash when opening the laptop lid)" [Unknown,Confirmed] https://launchpad.net/bugs/535640
<Sarvatt> yeah which is odd since we had a patch to fix that in -15
<Sarvatt> something tells me it got dropped with the drm backport and its not in there
<Sarvatt> is EIR: 00000000 in those? batchbuffer I/O errors?
 * Sarvatt looks
<Sarvatt> [   74.800222] render error detected, EIR: 0x00000000
<Sarvatt> [   74.800252] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 2128 at 2125)
<Sarvatt> yup we are missing the patch, looking into it
<Sarvatt> it wasn't upstream yet and I think it got dropped
<Sarvatt> i'll ping smb since apw is on vacation, we did drop the patch
<Sarvatt> that affected *alot* of machines, theres probably dozens of other dupes of that now
<RAOF> Yup.  I'm wandering through them.
 * RAOF sings the â...upon closing the laptop lid...â song.
<RAOF> ...and that's the last of the intel bugmail.  Has the nouveaufixes kernel built yet? :)
<Sarvatt> nouveaufixes kernel?
<RAOF> Just pulling a couple of patches from nouveau/linux-2.6
<RAOF> Particularly: mark LVDS as unknown if lid-closed, the slight monitor timing fix for VGA outputs, and fixing framebuffer fonts with width%8 != 0
<RAOF> I'm going to guess that bug #540017 is *also* that missing patch :)
<ubottu> Launchpad bug 540017 in xserver-xorg-video-intel "i915 crashes after resume (not powersave mode problem)" [Undecided,Incomplete] https://launchpad.net/bugs/540017
<Sarvatt> theres a few grctx update commits too
<Sarvatt> yeah but that guy is on a 945, i haven't seen that issue on <965 so I didn't dupe it yet but it does look the same
<RAOF> Yeah.
<RAOF> Sarvatt: Have you seen a number of intel bugs where the drm bails because agpgart loads *after* drm tries to initialise?
<Sarvatt> no actually, I haven't come across any of those yet in ubuntu
<RAOF> bug #542251 seems to be one, but I think I saw some more during my mail-purge.
<ubottu> Launchpad bug 542251 in xserver-xorg-video-intel "Compiz broken in Lucid Beta 1" [Undecided,Confirmed] https://launchpad.net/bugs/542251
<RAOF> I wonder if it's reproducible?
<Sarvatt> with these 5 second SSD boots I bet it is a big problem..
<Sarvatt> RAOF: if you see an error like agp loading after drm in dmesg would ya mind pasting that chunk into the bug description so its searchable?
<RAOF> Ok.
<Sarvatt> helps *alot* later on finding dupes like https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=*ERROR*+Cannot+initialize+the+agpgart+module&orderby=-importance&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.
<Sarvatt> omit_dupes=on&field.has_patch=&field.has_no_package=
<Sarvatt> err
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=*ERROR*+Cannot+initialize+the+agpgart+module
<Sarvatt> upstream people really want all agp modules built in :(
<RAOF> Really?  Why?
<Sarvatt> i'd have to dig through mails to find reasons, i've just seen it brought up by the radeon and intel people a ton of times over the past year
<Sarvatt> think there was a recent thread on intel-gfx about it, lets see..
<Sarvatt> here we go
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1f7a6e372e9cb4d749f34c0738d832e6cadb4071
<RAOF> Ok, so that's probably not in our tree.
<Sarvatt> nope was post .33
<Sarvatt> thought i saw it recently
<Sarvatt> hmm it looks like it just fails to load if agp isn't already loaded, not sure that it tries again?
<RAOF> It uses the magic of linkage.
<RAOF> You'll notice that intel-agp.c exports the symbol that i915 consumes?  That should ensure that intel-agp is loaded before i915.
<RAOF> At least, that's my understanding of it.  By explicitly depending on a symbol in intel-agp, i915 will be guaranteed to load after intel-agp, which will have done its init.
<RAOF> Are you going to attach that patch to the bug?
<Sarvatt> ok so thats 3 patches now I'll see if stable will take
<Sarvatt> yepyep
 * RAOF :note to self.  Don't try to rsync /proc
<tjaalton> airlied mentioned it once that he's probably going to make the agp modules mandatory (built-in)
<RAOF> It seems like a rich seam of bugs is possible if drm only depends on the agp core, which won't actually provide the necessary stuff until the platform-specific module is loaded.
<Sarvatt> i've seen it happen on radeon too and they just say agp should be built into the kernel
<Sarvatt> sheesh so many dupes for that 965 hang
<Sarvatt> at least its super easy to spot, EIR is 0000000 and do_wait_request returns -5 (which is -EIO) in current dmesg
<Sarvatt> found a bunch more dupes for the agp one too
<ara> bryceh, hello, still around?
<Sarvatt> thats a new one - intel_gpu_dump: page allocation failure. order:8, mode:0x40d0
<Sarvatt> getting close to  hitting 50 dupes tonight on https://launchpad.net/bugs/535640 :D
<ubottu> Ubuntu bug 535640 in xserver-xorg-video-intel "[gm45] GPU lockup de05bf80bf83cd22541cb55f1a2ee99e (xorg crash when opening the laptop lid)" [Unknown,Confirmed]
<Sarvatt> oh only 27 so far, i was going by the total bug count on -intel and someone else must be working it :D
<Sarvatt> ahhh so these two bugs are intertwined
<Sarvatt> we've got DPMS events hanging the GPU, then batchbuffer I/O errors, then in comes the "X: ../../src/i830_batchbuffer.h:79: intel_batch_emit_dword: Assertion `pI830->batch_ptr != ((void *)0)' failed." from the other bug with tons of dupes
<Sarvatt> found one of the dupes that showed both bugs happening in one log and it all makes sense now :)  http://launchpadlibrarian.net/41051827/GdmLog2.txt
<jcristau> Sarvatt: ewww order 8 allocation?  that's... bad.
<RAOF> Sarvatt: I've wandered through and duped a bunch of bugs that one. :)
<bryceh> ara, hi
<jibel> could you have a look at bug 544781 . nvidia-96 failed to upgrade from 9.10 to 10.04. Thanks.
<ubottu> Launchpad bug 544781 in nvidia-graphics-drivers-96 "nvidia-96 96.43.14-0ubuntu11 failed to upgrade from 9.10 to 10.04: Error! Application of patch fall_back_on_mtrr_if_no_pat.patch failed." [High,Incomplete] https://launchpad.net/bugs/544781
<RAOF> Well, that's pretty cool.  We've managed to russtle up a guy with some hardware where the -nv driver can only drive the LVDS and the nvidia driver can only drive an external monitor.
<bryceh> %-)
 * tormod curses xchat-gnome
<bjsnider> tormod, just use xchat
<bjsnider> xchat-gnome is notable for being functionally challenged
<tormod> bjsnider, thanks I'll try it, this time connections were acting up after resume
<komputes> bryceh: So, any ideas what is causing gnome-session to flip my screen (Bug #544813). Any testing/troubleshooting you would like me to preform?
<ubottu> Launchpad bug 544813 in xserver-xorg-video-intel "[Lucid Beta] after gdm, screen is backwards, upside down." [Undecided,Confirmed] https://launchpad.net/bugs/544813
<jcristau> komputes: bogus stuff in ~/.config/monitors.xml (or whatever it's called)
<komputes> jcristau: would you like me to remoce and test again (I think I have already tried this)
<tjaalton> create a new user and try with it
<komputes> jcristau: the monitor is not flipped upside down as gnome-display-properties proposes it, if you look carefully, the items are flipped inside out
<komputes> tjaalton: I have done this as well, but will try it again now
<tjaalton> nice effect
<tjaalton> so just the upper panel flipped over
<tjaalton> both actually
<tseliot> komputes: I guess your problem is that you're using the wrong libraries for your driver
<tseliot> komputes: how did you switch between drivers?
<tjaalton> this isn't a driver issue
<tjaalton> the panels are mirrored somehow
<komputes> tseliot: jockey-gtk
<tseliot> tjaalton: which is why I didn't call it driver issue ;)
<komputes> yes, but when entering and exiting gnome-session, the windows/screen is notmal for a second
<tjaalton> tseliot: wrong libGL could do that?
<tseliot> tjaalton: yep
<komputes> tseliot: however I did reproduce it to see if it constantly fails after installing the nvidia driver and it does seem to be the root cause 
<tjaalton> alrighty
<tseliot> komputes: let me rephrase my question, what did you do to switch between drivers in Jockey?
<tseliot> and did you restart your computer?
<tseliot> I suspect that you're using Nvidia's libGL with intel
<komputes> tseliot: i plugged in the usb key, ran kockey, downloaded nvidia driver, rebooted, changed the resolution and wrote to xorg.conf, moved usb key to mini 9, removed xorg.conf from tty, restarted, and screen was flipped.
<komputes> tseliot: shouldn't bulletproof-X know better?
<tseliot> komputes: you should have disabled nvidia from Jockey first
<komputes> tseliot: I don't remember having to do this before
<komputes> tseliot: how can I disable it from a TTY?
<tseliot> yes, provided that X fails to start
<tseliot> komputes: sudo update-alternatives --config gl_conf
<tseliot> sudo ldconfig
<komputes> tseliot: so i need to diable nvidia from jockey and remove the xorg.conf every time i move my USB key to another computer?
<tseliot> sudo update-initramfs -u
<tseliot> and reboot
<tseliot> komputes: yep, or you can do it manually
<tseliot> disabling nvidia shouldn't remove the package though, I'll talk again to pitti about this
<komputes> tseliot: any way around this, that it could be made to auto-detect?
<komputes> (as I believe this has worked in previous releases)
<tseliot> komputes: things were quite different in previous releases
<tjaalton> and they didn't work
<tjaalton> like you suggest
<tjaalton> komputes: ^
<komputes> thanks Alberto
<komputes> tjaalton: will test to make sure, cheers
<tseliot> np
<Sarvatt> hmm, newest blob is failing to resume about 1 in 5 times and not having any luck finding out why unlike before
<Sarvatt> hmm, think this would work? I know its a horrible hack, not sure if it's correct and wont be around a machine I can try it on until tonight - http://sarvatt.com/downloads/patches/0001-hw-xfree86-common-xf86AutoConfig.c-Append-Module-sec.patch
<Sarvatt> nvidia works without an xorg.conf but it loads libglx.so from /usr/lib/xorg/modules/extensions/ instead of /usr/lib/extra-modules/ where nvidia-current puts it unless there's a module section explicitly loading glx
<Sarvatt> so it loads SGI-GLX stuff instead of NV-GLX, thats the only thing stopping us from having no a xorg.conf nvidia blob. not sure about fglrx though
<Sarvatt> fglrx looks strange, its not installing stuff to /usr/lib/xorg/extra-modules like nvidia is and still has an xsession script changing LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH?
<tjaalton> still, if you have a conffile it'll only try the one on the top of the list
<tjaalton> so if you put a blob in there it'll fail if you don't have it installed...
<Sarvatt> i dont know for sure but it looks like disabling nvidia-current will unset the extra-modules alternative link so the libglx from there wouldn't be used anyway and wouldn't hurt?
<Sarvatt> i'll put it on a ppa with a change to prefer nvidia first then nouveau and test it out on a bunch of configurations
<Sarvatt> oops, thought disabling FBC didn't actually work afterall since I started getting hangs again today but I didnt notice we got a -17 kernel update that overwrote my old one :D
<bryceh> heh
<Sarvatt> hmm, anyone else having problems with gnome-terminal after todays updates? its blacking out my screen except a sliver of the panel until i move the cursor out of the gnome-terminal window, this has been happening for awhile but its happened at least 10 times today vs once a week for the past few weeks
<Sarvatt> ok *thats* odd, someone reporting lshw corrupts their display on my exact machine
<tjaalton> xserver merge pushed to git, not build-tested though. wondering if more of the udeb support needs to be dropped
<Sarvatt> hmm, I wonder if lshw screwing up the display might be related to having vga16fb on fb1, only difference i can see between me and this bug report with my machine
<tjaalton> or bdeps relaxed
<RAOF> Sarvatt: That's an excellent guess.  Let's see...
<Sarvatt> rebooting now to find out
<RAOF> Well, doesn't kill *this* laptop.
<Sarvatt> hmm, i should use a livecd incase its different, all these bugs are
<BUGabundo> I'm truly disappointed... installed Lucid on a recently new Desktop PC, running on a 64GB SSD, with Win7 and VirtualBox. install time inside the VM: 2-3min. boottime: 2-3 sec till gdm.  after installing guest additions X would not start :(
<Sarvatt> yay
<Sarvatt> livecd + lshw -C network = trippy colors
<BUGabundo> ahaha
<BUGabundo> oh man
<BUGabundo> I remember gusty
<BUGabundo> I had so many colors on my screen back then
<kklimonda> BUGabundo: hmm? you have a computer with win7?
<BUGabundo> no
<BUGabundo> it wasn't mine
<BUGabundo> from a friend
<BUGabundo> he was showing off how fast the SSD was
<BUGabundo> so I installed Ubuntu on it
<kklimonda> inside vm?
<BUGabundo> yep
<BUGabundo> virtual box
<BUGabundo> it was SOOOOOOOOOOOOOOO fast
<BUGabundo> I was planning buying a 32GB ssd. now I definitely want one
<kklimonda> :)
 * baptistemm have a 160 GB ssd disk :p
<BUGabundo> you did???
<baptistemm> and yes this blazing fast to boot
<BUGabundo> how much did that baby cost
<baptistemm> and even for testing vm this really really valuable
<baptistemm> BUGabundo, too much
<BUGabundo> I bet
<BUGabundo> at current cost its around 400-500â¬
<BUGabundo> for a 128GB
<BUGabundo> so a 160 who whooo
<baptistemm> I paid mine 350â¬
<baptistemm> coming from taiwan
<kklimonda> how long is life expentancy for ssd disks?
<BUGabundo> ahh that's _cheap_
<BUGabundo> kklimonda: depends *very* much on manufacture and series
<RAOF> And correlates well with cost - the best ones will be single-level cells, and will cost a bomb.
<BUGabundo> on those without realiners you can count with about 10k re-writes for sector
<BUGabundo> on the most recent, dynamic reallocation , and extra sectors, from high brand manufactures (intel, coz, etc) something like 500k-1M re-writes
<BUGabundo> you got entry level kingston for 150â¬ for 32GBs
<BUGabundo> and intel is launching a new series of their famous X25 for entry price
<baptistemm> BUGabundo, mine is a x25 g2
<BUGabundo> don't know the g2 series
<bryceh> RAOF, btw when you get a chance look at #545493 - this is from a friend of mine here in Portland
<RAOF> Hm.  Someone complaining about poor compiz performance with nouveau.
<Sarvatt> lol
<RAOF> Actually, it seems to be just mis-filed against nouveau; the user doesn't seem to be using the PPA, so...
<tormod> bryceh, now that Benjamin has triaged bug 544904, is anything else needed or can I trust the archive managers to get to it?
<ubottu> Launchpad bug 544904 in xserver-xorg-video-sis "please sync xserver-xorg-video-sis 1:0.10.2-2 from Debian unstable main" [Wishlist,Triaged] https://launchpad.net/bugs/544904
<Sarvatt> not a single 965 GPU hang report that isn't a dupe of the DPMS problem
<bryceh> Sarvatt, wow
<bryceh> tormod, should be good.  Note that the sync processing crew is a bit slow so might be a few days
<tormod> is anyone gonna merge -ati? I can volunteer but not today
 * tormod reboots into 2.6.32-17
<Sarvatt> not sure its a good idea :D
<bryceh> Sarvatt, why?
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=27186 
<ubottu> Freedesktop bug 27186 in Driver/Radeon "Visual corruption with new r6xx/r7xx accel code" [Normal,Resolved: fixed]
<bryceh> oh yeah
<RAOF> Sarvatt: There's no lbm-nouveau for -17 yet, is there?
<Sarvatt> fixed just today but the fix isnt in 6.12.192
<bryceh> Sarvatt, but it's marked fixed
<RAOF> Sorry, should just look myself :/
<bryceh> well, we can pull the patch in
<Sarvatt> RAOF: i uploaded it like 8 hours ago but its mozilla-ed I think
<bryceh> tormod, if you can get to it tomorrow I'll be happy to sponsor it
<bryceh> otherwise it's on my todo list to do this week
<Sarvatt> looking through the lshw code to see how to get around it turning the drmfb into the vga16fb..
<RAOF> Can we just make vga16fb fail to load when we've got a real framebuffer?
<RAOF> As I say, then nouveau guys are paranoid about it messing things up.
<Sarvatt> we've got a silly patch to vga16fb making it bind to all video devices 
<tormod> bryceh, ok I'll either try tomorrow or not at all :)
<RAOF> Sarvatt: Why?  Can we drop that patch?
 * Sarvatt wishes plymouth could be deferred to MM..
<bryceh> Sarvatt, what's that patch against? kernel?
<Sarvatt> so there's a FB for plymouth to use for any video card always
<Sarvatt> yeah its in ubuntu-lucid.git
<Sarvatt> they added that back in november or december
<RAOF> Can't we just have that keybuk's swanky text-boot?  That looks awesome :)
<Sarvatt> swanky text-boot?
<Sarvatt> you mean the splash you see when you dont have KMS?
<RAOF> Yeah; the one you'll get currently if you don't have kms.
<Sarvatt> because that needs a color framebuffer
<RAOF> bryceh: #545493 dealt with; nouveau kernel ABI bump in xorg-edgers strikes again!
<RAOF> Now, coffee.
<Sarvatt> heyo tormod! :)
<tormod> hey sarvatt :)
<Sarvatt> tormod: you have an rv515 don't you? do you have any problems with lucid at the moment?
<tormod> Sarvatt, I haven't got to test it with lucid yet. maybe friday.
<Sarvatt> ahh ok, there are alot of complaints from people on RV515 and RV530 with 2.6.33's drm
<Sarvatt> radeon.new_pll=0 is fixing it for RV530 people but haven't figured out the RV515 flickering problems yet
<tormod> the irc log mentions savage DRI trouble? I have to test that again also, now that the X crasher got fixed
<Sarvatt> yeah savage is horrible at the moment with so many clutter based apps, clutter completely falls apart on savage because it only has 16 bit visuals and breaks some assumptions it has
<tormod> I think savage can do 24 bit, but 16 bit is default because it works better and many cards have little VRAM
<tormod> will clutter be fixed?
<RAOF> Isn't clutter 1.2 supposed to be better about that?  That's getting merged in soon.
<Sarvatt> sweet, it is?!
<RAOF> Yup.  GNOME 2.30 requires it, apparently.
<Sarvatt> 1.2 is a lot better about it but it still needs fixes
<Sarvatt> oh mutter counts for gnome 2.30? thought that was the only thing requiring 1.2
<Sarvatt> one sec, I'll find the bug where some guy posted some patches for clutter 1.2 branch to work on savage
<Sarvatt> it was that netbook launcher bug you were working on RAOF
<Sarvatt> https://bugs.launchpad.net/bugs/467474
<ubottu> Ubuntu bug 467474 in mesa "netbook-launcher crashed with SIGSEGV in glGetString()" [Undecided,Confirmed]
#ubuntu-x 2010-03-24
<Sarvatt> hmm that guy followed up more with a mesa patch
<RAOF> Sarvatt: Yeah, sweet.
<jcristau> there's people reporting server crashes on closing clutter apps fwiw
<tormod> wow knarf really rocks, looking forward to testing that stuff
<tormod> jcristau, do you think the debian -ati should be updated for  fdo 27186 mentioned above?
<jcristau> tormod: i don't know, brice handles radeon.  is updating for the next RC or release not good enough?
<bryceh> -intel apport freeze hook OFF
<tormod> jcristau, ok I can ask brice. this would be a regression from the previous version.
<Sarvatt> hmm, seen a few bugs with this problem, wonder if the patch works - https://bugs.freedesktop.org/show_bug.cgi?id=25607
<ubottu> Freedesktop bug 25607 in Driver/Radeon "drmCheckModesettingSupported fails if X loaded radeon modeset=1 just before" [Normal,New]
<bryceh> we need our log scanner :-)
<RAOF> Lets test these mmiotrace scripts.
<RAOF> Hm.  Not exactly a turnkey solution.
<RAOF> Stop losing events, damnit.
<RAOF> Ah, my old friend IPEHR: 0x01800020
<Sarvatt> heh notice anything interesting about this log? http://pastebin.com/bKV4UuPL
<Sarvatt> just added a check for KMS to vesa and made it not load if a KMS driver is in use
<RAOF> Sarvatt: I, too, have done that.
<RAOF> There's a bug on xserver-xorg-video-vesa & b.fd.o
<Sarvatt> oh?
<RAOF> Shouldn't it fallback to fbdev though?
<Sarvatt> good because mine is incredibly hacky, darn autotools
<RAOF> Ah.  Mine might be better, then :)
<Sarvatt> thats only because i forced vesa in xorg.conf, it'd fail to load right if it was autoconfiguring
<RAOF> Mine should do things like allow vesa to be built without libdrm and such.
<Sarvatt> would unload vesa and move on to fbdev I mean
<Sarvatt> oh?
<RAOF> bug #531736 btw
<ubottu> Launchpad bug 531736 in xorg-server "VESA driver should fail to load when KMS is active" [Unknown,Confirmed] https://launchpad.net/bugs/531736
<RAOF> drmCheckModesetting makes that pretty easy, though.
<Sarvatt> http://sarvatt.com/downloads/patches/vesa.diff
<Sarvatt> (ignore the screwy includes)
<Sarvatt> checking out that bug
<RAOF> It's basically a placeholder to say âthis should be done, I'm doing itâ
<RAOF> Hm.  xf86LoaderCheckSymbol is nicer that what I'm doing, which is to just snprintf a busid string :)
<Sarvatt> kay, control+alt+f1, sudo service gdm stop, screen shuts off and power key brings it back up with the plymouth shutdown screen
<RAOF> That's fun.
<Sarvatt> thats new from some update today
<Sarvatt> oh yay its after midnight, i can upload mesa with all the fixes now
<RAOF> ?
<RAOF> New snapshot date?
<Sarvatt> Mesa 7.7.1 Release Notes / March 26, 2010 woohoo
<Sarvatt> yeah launchpad handles version numbers weird now
<Sarvatt> it wont accept say mesa_7.9.0~git20100323.fffffffff as being newer than mesa_7.9.0~git20100323.00000000
<Sarvatt> so wont let me upload new orig.tar.gz's unless I use +
<Sarvatt> 7.9.0+git20100323.ffffffff is > mesa 7.9.0+git20100323.00000000 and accepted but 7.9.0~git20100323.ffffffff is < 7.9.0~git20100323.00000000, i dont get it
<Sarvatt> i thought it was dpkg since it started right at a big dpkg upgrade last november but dpkg still evaluates them right
<Sarvatt> nv40 should be all fixed up with this mesa upload
<RAOF> Yay!  Compiz for me!
<RAOF> (Until it dies in gem_cpu_prep)
<Sarvatt> the mesa 7.7.1 release notes make it look boring, then you look at the git log and see all the actual fixes :)
<Sarvatt> oh whoops, forgot i had a hard dep on the kernel abi version in the nouveau ddx on edgers
<bryceh> cool
<Sarvatt> not cool, broken all day :D
<bryceh> I see tjaalton has done the xserver 1.7.6 merge, it's in git
<Sarvatt> oh sweet!
<bryceh> Sarvatt, broken in edgers or in lucid?
<Sarvatt> just edgers, no biggie :)
<tjaalton> hmm, did bugabundo file a but about the vbox issue?
<bryceh> hi tjaalton
<tjaalton> hey bryceh 
<bryceh> ubuntu-bug may refuse to do vbox bugs against xorg
<bryceh> (at least it should for crashes)
<tjaalton> right, but manual ones probably work
 * bryceh nods
<tjaalton> sounds like the vbox video driver is autoloaded but it doesn't support the server abi
<bryceh> what's new
<tjaalton> heh
<bryceh> tjaalton, do you mean it's in video-all?
<bryceh> maybe it should be drummed out then
<tjaalton> bryceh: no, but adding the guest additions will install it
<bryceh> ah
<tjaalton> there's a bug to split the driver from the vbox package though, to let it install with video-all, but it's not trivial
<bryceh> I don't think we'd want to accept it anyway
<tjaalton> and then there's the proprietary version too
<tjaalton> of vbox
<tjaalton> so yeah, pointless imo
<bryceh> I talked with kirkland and he confirmed vbox is not something we need to support
<tjaalton> i'd be nice if it supported usb
<tjaalton> the free one that is
<bryceh> so I'd say if they want to insert their own X stuff into the xserver, then it's on them to maintain
<tjaalton> right
<bryceh> (by "them" I mean the vbox proponents in ubuntu)
<bryceh> I've gotten a pretty hard attitude about it after going through tons and tons of vbox crash bugs due to not supporting the right xserver api in karmic ;-)
<tjaalton> actually those ones were kinda strange, since the additions did support the server, but the server would crash on start (or shutdown) for some strange reason.. never bothered to check that, though I have it installed and confirmed myself
<tjaalton> and that only happened on the first time
<bryceh> right
<Sarvatt> ok the gnome-screensaver-gl-helper bugs for nvidia are all silly, you get that crash report when you activate the nvidia drivers and the screensaver kicks in before you reboot
<Sarvatt> i think thats gnome-screensaver's fault personally
<tjaalton> whoa! there's a proper fallback patch for the xorg-conf-available situation
<tjaalton> https://bugs.freedesktop.org/show_bug.cgi?id=27229
<ubottu> Freedesktop bug 27229 in Server/general "Video driver autoselection does not work with xorg.conf/xorg.conf.d in place" [Critical,New]
<bryceh> great
<tjaalton> should we switch to xorg.conf.d now :P
<bryceh> tjaalton, gonna pull it in?
<bryceh> tjaalton, sure
<tjaalton> bryceh: not without discussion
<tjaalton> with debian too
<Sarvatt> you guys are insane :)
 * bryceh nods
<tjaalton> have to read the thread first
<tjaalton> Sarvatt: this is in 1.8 anyway, and I've got a backported patch already
<tjaalton> about xorg.conf.d
<Sarvatt> doh, looks like nvidia-current's blacklist alternative dealie doesn't work from a liveusb with persistant storage either
<Sarvatt> http://pastebin.com/raw.php?i=DxS2J1X7
<Sarvatt> wrong glx loading :(
<Sarvatt> ahhhhhhhhh I was completely wrong, it's not libglx that's the problem it just requires 24 bit depth being forced in xorg.conf. I made an xorg.conf with just a screen section that had DefaultDepth 24 and it works
<tjaalton> uploaded wacom 0.10.5 to my ppa
<tjaalton> superm1: ^ it has the udev rule fix to match the vendor id too when setting x11_driver, so your laptop should work with this version
<tjaalton> bah, didn't bump the epoch
<RAOF> xorg gets all narky when you call xf86DMsg () in a probe function.
<bjsnider> tseliot, is nvidia-settings creating a menu entry in lucid?
<tseliot> bjsnider: yes, why are you asking?
<bjsnider> it didn't in karmic
<bjsnider> i'll have to investigate
<tseliot> well, nvidia-$flavour does it
<bjsnider> that explains it
<bjsnider> i really only wanted the polkit patch. i went too far
<tseliot> bjsnider: the polkit patch shouldn't work without lucid's version of screen-resolution-extra
<bjsnider> i changed the dependency so it just asks for screen-resolution0extra without specifying a version
<tseliot> that won't work
<tseliot> unless you have that specific version installed
<tseliot> which has the polkit code
<tseliot> nvidia-settings calls that
<bjsnider> i don't understand that
<bjsnider> i asumed there would just be a button that says "click here to unlock" or something
<bjsnider> maybe there's another patch somewhere
<tseliot> the button needs to call something else, right?
<bjsnider> policykit
<tseliot> that something else is in screen-resolution-extra
<bjsnider> all it needs to do is elevate privileges so the user can save the xorg.conf file
<tseliot> privileges of what?
<tseliot> you have a polkit agent and a mechanism
<tseliot> the mechanism runs with root privileges and the agent (with user privileges) talks to it through dbus
<bjsnider> privileges to edit system files
<tseliot> it works as I explained, for further information you might want to have a look at the documentation
<bjsnider> /usr/share/screen-resolution-extra/nvidia-polkit.py
<bjsnider> that's why it won't work
<tseliot> yep
<bjsnider> and if i take that file and add it as a patch to nvidia-settings
<bjsnider> or not even a patch but just install it
<bjsnider> i could do that easily
<tseliot> yes, I guess that should work (if I remember correctly what I did)
<Sarvatt> tjaalton: matching n-trig vendor id too?
<tjaalton> Sarvatt: no, that's missing
<tjaalton> but I've finished the xorg.conf.d/inputclass -backport, pushed it to my personal repo on alioth. will send an email next
<tjaalton> tseliot: ^ it includes the suse patch which makes autoconfig work if there are conffiles around (but no screen sections in them)
<tseliot> tjaalton: I would like to see that
<tjaalton> git://git.debian.org/users/tjaalton-guest/xorg-server.git
<tjaalton> debian-unstable branch
<tjaalton> haven't merged it in ubuntu yet
<tjaalton> but will do so next
<tjaalton> since unstable doesn't build on lucid (udeb stuff)
<Sarvatt> why isn't xf86-input-wacom in pkg-xorg already? can we create it?
<jcristau> because it's maintained independently
<Sarvatt> guess thats a good one to start maintaining the ubuntu changes in bzr then
<jcristau> Vcs-Git: git://git.debian.org/users/ron/xf86-input-wacom.git
<jcristau> you could maintain the ubuntu branch in pkg-xorg though
<jcristau> if you wanted
<tseliot> tjaalton: thanks, I'll have a look at it
<tjaalton> Sarvatt: I have it on my personal repo atm
<tjaalton> huh, the ubuntu patches applied as-is
<tjaalton> and builds too
<tjaalton> and works
<tjaalton> need to check the fallbacks too
<tjaalton> that's the whole point of this sillyness .. :)
<Sarvatt> you removed an input abi bump though, dont forget we're going to need to remove all the input abi 9 ifdefs from input drivers now :(
<tjaalton> which means wacom
<tjaalton> it's the only one
<tjaalton> i should have them all cloned on my hd
<Sarvatt> as much as I dislike bzr because it is *really* a pig with big repos, the idea of keeping ubuntu deltas in bzr and setting up bzr-builddeb for everything is really growing on me these days, i just wish I knew a way to go backwards and merge our debian/ bzr branches if we had them into git without a lot of pain. having one ubuntu branch in debian git doesn't seem to be enough and there is a divide between that branch and SRU stuff thats in bzr.  
<Sarvatt> also there's a split if we do decide to do something like stable mesa version updates in released versions, and there are a number of packages with no ubuntu branch at all because we usually track upstream like intel and ati.
<tjaalton> heck yeah, fallbacks work (at least it loads vesa/fbdev too)
<tjaalton> Sarvatt: well, no-one has bothered to create other branches
<Sarvatt> tjaalton: do you think 1 month really is enough time to really convert everything and get enough feedback on issues if we backported that? it's such a major change
<tjaalton> Sarvatt: dunno, we'll see
<tjaalton> and it's just for configuration, the drivers itself won't care
<Sarvatt> for the debian upstream-* branches, do they just pull master into that branch and merge a tag from that branch into unstable or experimental?
<Sarvatt> if so, can we just update upstream-unstable daily? i'm thinking about the packages where we have a newer version in ubuntu than debian and can't just merge from a debian branch in git
<tjaalton> no, the same tag is pulled to the upstream branch
<tjaalton> the you can get the exact diff by checking against the debian branch
<tjaalton> apart from nouveau I can't find such packages atm
<Sarvatt> so thats another hinderance, we can't maintain stuff in git that has newer versions than debian which is why intel and ati don't have ubuntu branches and libdrm gets *really* out of sync when we do git snapshots. how can we alleviate that? if packaging branches were in bzr we could just point it at a different branch to merge, upstream vcs's (including debian's) are imported into bzr automatically multiple times a day and we can automatically cr
<Sarvatt> eate tarballs and releases any time we wanted
<jcristau> i don't understand this
<tjaalton> Sarvatt: that's not the reason why ati/intel are not maintained in git
<tjaalton> the ubuntu branch doesn't have to use upstream-*
<tjaalton> if you've added the upstream remote then feel free to pull from there :)
<Sarvatt> ah that works, jcristau I don't either thats why I'm asking :)
<tjaalton> having it all in bzr makes it easier for drive-by-committers to add crappy patches :)
<tjaalton> though it's just as easy now
<jcristau> speaking of which i think xorg-server -1u4 is not in git :)
<tjaalton> true
<tjaalton> because I told asac to upload it if he was in a hurry :)
<tjaalton> since 1.7.6-1u1 is still shaping up
<tjaalton> (i guess)
<jcristau> right
<Sarvatt> so what would be the workflow to use if I wanted to say, merge xserver 1.8 in git in the ubuntu branch today? 
<asac> jcristau: blame me ;)
<asac> we wanted this in so we can verify the feature. some folks are waiting for it downstream
<jcristau> asac: no blame needed :)
<asac> heh ... thanks for being kind
<tjaalton> Sarvatt: add the remote, git merge <tag>; git mergetool etc
<Sarvatt> add fdo as a remote, merge the tag from it and push?
<jcristau> Sarvatt: yes
<tjaalton> oh and git fetch upstream too
 * Sarvatt nods.
<Sarvatt> I thought I'd need to push a new remote branch containing that remote first
<tjaalton> nope, not needed. remotes are local
<Sarvatt> tjaalton: I know driveby crappy patches suck, but I just dont see them being able to update the actual package anyway with it because they are core-dev and us having to bring it into git manually as any kind of hinderance towards it happening :D
<tjaalton> Sarvatt: yeah, but if it was enforced (probably won't happen though) :)
<superm1> tjaalton, cool thanks
<Sarvatt> i think i'm going to go ahead and bzr-ify xorg-edgers at some point though, keeping packaging in bzr and setting up bzr-builddeb to work with it would insanely simplify things. that or move packaging into git somewhere so we only have to update that instead of making an increasingly insane amount of hooks and manual packaging adjustments every time I update
<tjaalton> yeah whatever works for you
<tjaalton> email sent, but I think it'll get on the queue since my address has changed
<mpt_testpc> Could someone please help me with a keyboard that has stopped working in Lucid?
<mpt_testpc> Ubuntu is still detecting that I'm using it (the cursor in a Terminal window stops blinking when I type), but no characters come out
<mpt_testpc> Making things worse, the Onboard on-screen keyboard isn't working either (it just shows a blank grey window), so any debugging that requires text entry may be tricky
<mpt_testpc> I could install GOK or Kvkbd from Ubuntu Software Center, but that would require typing my password
<tjaalton> so you can't start apps from the terminal?
<mpt_testpc> tjaalton, correct
<mpt_testpc> https://wiki.ubuntu.com/X/Troubleshooting/HalBreaksKeyboardAndMouse suggests the problem might be that hal isn't running, but I thought HAL was removed in alpha 2.
<tjaalton> mpt_testpc: could you put the logfile somewhere? or file a bug
<tjaalton> udev is used instead of hal
<mpt_testpc> tjaalton, System Monitor doesn't list a process called udev. Should it?
<mpt_testpc> tjaalton, which log file?
<tjaalton> /var/log/Xorg.0.log
<tjaalton> well if udev isn't running you'd have no mouse either
<mpt_testpc> hooray for USB keys
<tjaalton> you could start xev and see if it lists any events
<mpt_testpc> tjaalton, http://pastebin.ubuntu.com/400671/
<mpt_testpc> Any suggestion for starting xev using a mouse? :-)
<tjaalton> oh I thought you had a usb keyboard
<tjaalton> so if you do, just plug it in :)
<mpt_testpc> I do, and that has exactly the same problem
<mpt_testpc> I figured it out though
<tjaalton> oh i see
<mpt_testpc> I saved "xev<carriage return>" to a text file on this computer
<mpt_testpc> saved it on the USB key
<mpt_testpc> plugged it into the sick computer
<mpt_testpc> opened it up, copied and pasted it into a terminal window
<tjaalton> hehe
<mpt_testpc> tjaalton, http://pastebin.ubuntu.com/400680/
 * hyperair grumbles that i915's ACPI-based brightness keys still don't work with KMS.
<tjaalton> mpt_testpc: huh, weird. is it a fresh install or an upgrade?
<tjaalton> mpt_testpc: try changing the model from gnome keyboard options
<mpt_testpc> tjaalton, upgrade. The keyboard was working fine on Lucid until today.
<tjaalton> ok
<mpt_testpc> wey-hey!
<jcristau> i blame gdm
<jcristau> :)
<mpt_testpc> I changed it from "Apple" "MacBook/MacBook Pro" (which it is) to "Apple" "Apple", and now most keys work
<tjaalton> oh right, it had to work at least on the login screen, right?-
<tjaalton> )
<mpt_testpc> No, it didn't, but Onboard worked at the login screen
<tjaalton> hmm ok
<mpt> now to try a restart
<mpt_> So far, so good
<mpt_> Thank you very much tjaalton 
<tjaalton> still weird that it'd break so badly
<tjaalton> try with a new user, and check what's in /etc/default/console-setup (XKB*)
<tjaalton> bbl, sauna while it's still hot ->
<mpt_testpc> so now I'm back to bug 319221
<ubottu> Launchpad bug 319221 in xkeyboard-config "Option+key combos in "USA Macintosh" keyboard layout don't work" [Undecided,Fix released] https://launchpad.net/bugs/319221
<mpt_testpc> I can't log in to a new user account, it says "Authentication failure" when I type the password
<mpt_testpc> but I was having that problem before the keyboard problem, so it's probably unrelated :-)
<mpt_testpc> And I'm still experiencing bug 524406.
<ubottu> Launchpad bug 524406 in libxklavier "Frequent "Error activating XKB configuration"" [Low,New] https://launchpad.net/bugs/524406
<tjaalton> mpt_testpc: if you can reproduce the original problem again, please get a dump from 'setxkbmap -print' and 'xkbcomp :0 -'
<mpt> tjaalton, ok, I'll copy and save that in preparation :-)
<tjaalton> heh
<bryceh> tjaalton, I see 1.7.6 xserver is staged in git; is it pending any other changes before it can be uploaded?  (Want me to upload?)
<tjaalton> bryceh: the patch that asac uploaded is probably the only one
<tjaalton> so the changes in -1u4 need to be merged
<bryceh> ok
<bryceh> shall I take care of that?
<tjaalton> you may
<tjaalton> i'll futz with the backports
<tjaalton> huh, of the 40 openchrome bugs open, 15 have patches
<tjaalton> though I've no idea how many of them are valid
<bryceh> yeah but that's because there is an upstream guy who asks users to test possible fixes by posting patches to the bug
<tjaalton> yep
<bryceh> I looked through those a while ago and found most looked not viable for us to pull in
<tjaalton> right
<bryceh> I think they get kinda fussy if we include patches unique to ubuntu in the packaging
<bryceh> or I should say, they did get fussy once, so I've kept my hands off since
<tjaalton> hehe
<bryceh> tjaalton, can you link me to the .orig.tar.gz I should use for this upload?
<tjaalton> bryceh: you can find it here for instance http://packages.debian.org/source/unstable/xorg-server
<tjaalton> linked from http://packages.qa.debian.org/x/xorg-server.html
<tjaalton> where you get from versions_current ;)
<bryceh> hey, I've messed it up before, I figure best to ask ;-)
 * bryceh pbuilders
<tjaalton> :)
<tjaalton> so we can sync packages ourselves, that's great
<tjaalton> there aren't much to sync atm though
<tjaalton> *isn't
<bryceh> yeah saw that
<tjaalton> bryceh: did you see my email about the backports?
<bryceh> tjaalton, yep
<tjaalton> so i'm thinking that it's either both take it or leave it
<bryceh> yeah sounds like a smart strategy
<bryceh> the changes sound cool but a bit scary given we've got just a month to go
<bryceh> it sounded like we'd need to touch a bunch of packages to update their config stuff, is that correct?
<bryceh> e.g. turn udev rules into xorg.conf snippets etc.
<tjaalton> evdev, synaptics, wacom, joystick
<bryceh> nice, xserver built w/ no issues.  uploading...
<tjaalton> vmmouse maybe
<tjaalton> evtouch too
<tjaalton> but those are trivial
<tjaalton> need to check serial wacom support too
<tjaalton> how to handle it
<tjaalton> probably just a matter of matching the right string or so
<bryceh> uploaded.
<tjaalton> ah actually the udev rule sets ID_INPUT_TABLET, so the normal rule will match then
<tjaalton> and fedora has 10-wacom.conf already
<jcristau> is sis synced with tormod's fix?
 * hyperair thinks that the source of his graphical corruption is xserver-xorg-video-intel..
 * hyperair tickles Sarvatt 
<hyperair> hmm maybe i should just revert to 2.9.0 and see what happens
<bryceh> hyperair, no it's probably drm stuff
<bryceh> hyperair, so boot an earlier kernel
<hyperair> bryceh: oh so it's a kernel thing?
<hyperair> bryceh: is this a known issue?
<bryceh> dunno check launchpad
<hyperair> bryceh: i'm running karmic and xorg-edgers.. i don't think such bugs would appear in launchpad.
<hyperair> and a 2.6.34 kernel
<bryceh> wow, pretty jacked out
<hyperair> heheh
<hyperair> it's a custom compiled 2.6.34 kernel in fact
<bryceh> you're a crazy man
<hyperair> ;-)
<hyperair> i blame it all on intel.
<hyperair> after they screwed over the performance of i915, i followed xorg-edgers and never stopped
<hyperair> i think i began compiling my kernels around then as well
<hyperair> no wait i think i started compiling them even before that because i needed phc
 * hyperair tries restarting X
<bryceh> yeah Intel's really bad about pushing everyone to bleeding edge stuff
<bryceh> but it gets people into weird configurations that are too far from stock for us to deal with
<bryceh> hyperair, really with your config you should be asking on #intel-gfx
<hyperair> bryceh: i did.
<bryceh> great
<hyperair> with no reply =\
<hyperair> well, at least i got a response on the backlight keys issue
<hyperair> and so i'm compiling a new kernel to check
<hyperair> bryceh: i think it is xserver-xorg-video-intel after all. i just install 2.9.0 from karmic-updates and i don't see any graphic corruption
<hyperair> well for the time being
<hyperair> let's see whether it returns
<bryceh> hi tormod
<tjaalton> hah, I made it on phoronix \o/
<tjaalton> jcristau: not yet
<jcristau> hah, he calls you mad.
<tjaalton> well put
<tormod> hi bryceh, I fear I won't get far with -ati today...
<tjaalton> maybe I should create an account to comment on the phoronix thread :)
<tjaalton> but not today ->
<jcristau> the peanut gallery is having so much fun
<Sarvatt> tjaalton: did you throw it up on a PPA?
<bryceh> More Phoronix Madness
<bryceh> people who can't spell, giving their advice on how X should be maintained in ubuntu
<jcristau> it's not advice, really.  it's obviously The Truth.
<Duke`> lol
<bryceh> I like airlied's reply #17 though
<jcristau> airlied knows what he's talking about.  that should disqualify him for phoronix comments
<bryceh> hehe
<bryceh> jcristau, don't worry I'm sure his comment will be ignored into oblivion
<BUGabundo> evening
<RAOF> bryceh: Good morning.  I've got a fix for bug #531736 in x-x-v-vesa in the ubuntu branch of pkg-xorg git; could you check it out & sponsor?
<ubottu> Launchpad bug 531736 in xserver-xorg-video-vesa "VESA driver should fail to load when KMS is active" [High,Fix committed] https://launchpad.net/bugs/531736
<bryceh> hi RAOF, certainly
<RAOF> bryceh: Have you uploaded vesa yet?  If not, could you hold off on it - I may have outsmarted myself with the build-time checks :X
<bryceh> haven't uploaded yet
<bjsnider> bryceh, just because they can't spell and don't know what they're talking about doesn't mean we shouldn't listen to their worthless opinions'
<RAOF> bryceh: There we go.  I *had* outsmarted myself.  x-x-v-vesa git now has the correct build-dependencies to actually enable the patch!
 * RAOF reinstalls xserver-xorg-video-all again
<bryceh> RAOF btw a convention we've been using is to number ubuntu patches starting with 100, so we can more easily distinguish them from debian's patches
<RAOF> Ok.  I'll update git to follow that convention.
<bryceh> mm I like the patch, looks good
<RAOF> Ok.  git updated to make the patch number start at 100
<aboSamoor> I would like to ask about Poulsbo for the dell netbook, it is not working in lucid, any news or related bugs that I look at ?
<bryceh> no news on psb
<bryceh> W: xserver-xorg-video-vesa source: patch-system-but-direct-changes-in-diff ChangeLog and 1 more
 * jcristau ignores that warning
<RAOF> Yeah; that's unchanged from the debian package.
<bryceh> yep
<bryceh> RAOF, uploaded
<RAOF> Thanks!
<Sarvatt> RAOF: what did you end up doing? something like http://sarvatt.com/downloads/patches/vesa.diff ?
<RAOF> I incorporated some of that; mainly the DRICreatePCIBusID bit rather than hand-creating my own pciid string.
<RAOF> I stuck it in the PCI probe function, though.
<RAOF> So X probes the vesa driver, which detects kms, and doesn't create a screen object.
<RAOF> You can have a look http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-vesa.git;a=blob;f=debian/patches/001_ubuntu_bail_when_kms_active.patch;h=4d2880fdcc6954225303db0cca31b06209c933ee;hb=22017c781ac34e1bbc62908eeccc830709fbe2f3
<bryceh> btw if you guys are interested, kees and I set up a bzr tree with some scripts to revert some of the design annoyances...  https://code.edge.launchpad.net/~ubuntu-wilson/ubuntu-wilson/main
 * kees recommends reading each and picking the ones you want instead of running the bulk installer.  :)
<bryceh> moves the toolbar buttons back to the right.  I got an inkscape friend to fix the buttons so they're all rotated correctly although don't have the packaging to install those
 * RAOF actually rather likes the buttons on the left.
<RAOF> Gah!  vga16fb, I stab at thee!
<Sarvatt> oh nice, the only thing that bugged me was the button graphics being dependant on the changed button ordering and all other themes not looking right with that configuration
<Sarvatt> thanks for that kees and bryceh :)
<bryceh> Sarvatt, you have to manually copy them into place for now, I'm not sure how to set up the diversions properly
<bryceh> but they look great
<bjsnider> "Timo Aaltonen has now published a patch to Ubuntu-X that brings most of the X Server 1.8 features back atop their 1.7 server."
<bryceh> bjsnider, <3 phoronix
<bjsnider> it's true because i read it in the interwebs
<Sarvatt> yeah apparently the ubuntu-x mailing list is a good ad money maker :) can't have a discussion there without it showing up as news and interpreted as exactly whats going to happen
<bryceh> we should totally get them for apr-1st
<Sarvatt> lucid upgrading to xserver 1.8 and mesa 7.8? :)
<jcristau> or lucid delayed 2 months because X is too broken
<Sarvatt> someone else got them last year with xorg 7.5 release :)
<bryceh> jcristau, :-)
<jcristau> "we'll wait for 2.6.34"
<bryceh> full source for psb?
<jcristau> heh
#ubuntu-x 2010-03-25
<Sarvatt> i'd quite like to see a 2 month delay where people actually keep the packages frozen so it can stabilize :)
<jcristau> Sarvatt: come join the other side.
<Sarvatt> I didn't say 12 month!
<Sarvatt> :)
<jcristau> ;)
<aboSamoor> is xserver 1.8 has a solution to the Poulsbo cards ? 
<Sarvatt> no, quite the opposite
<Sarvatt> you want to stick with older releases if you want to use poulsbo because they only ever put out drivers for the older releases
<RAOF> Sarvatt: Next time you roll a lbm-nouveau for xorg-edgers could you add http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blobdiff;f=drivers/gpu/drm/drm_edid.c;h=7e608f4a0df95563e81e40d3efbaa57903fadbba;hp=f97e7c42ac8e1f7bdf53573e491feb0a80f2989f;hb=44fef22416886a04d432043f741a6faf2c6ffefd;hpb=725398322d05486109375fbb85c3404108881e17 to the drm?
<Sarvatt> uploading now
<RAOF> Oh, that was quick!
<RAOF> Well, there we have it.
<RAOF> gallium nvfx, while it seems to have improved compiz speeds considerably, hasn't prevented nouveau from locking up waiting for gem.
<Sarvatt> try NOUVEAU_VTXIDX_IN_VRAM=1  compiz --replace?
<RAOF> What is *that* meant to do?
<Sarvatt> http://cgit.freedesktop.org/mesa/mesa/commit/?id=3428a305150e98c8002e0fb339f5667c5533c0d1
<RAOF> Hm.  I don't think that's what I'm seeing; my problem is X becoming unkillable while waiting in gem_something_or_other_cpu_init 
<Sarvatt> radeon external monitor flickering bug, didn't someone here have that problem? superm1? - http://bugs.freedesktop.org/show_bug.cgi?id=25741
<ubottu> Freedesktop bug 25741 in DRM/Radeon "[R600/KMS] external display flickering" [Normal,Resolved: fixed]
<superm1> Sarvatt, external monitor doesn't work at all for me with radeon kms
<superm1> at least not when X starts
<Sarvatt> ok will try to see if I can dig into it more, working on a list of drm patches we need to send to the kernel team list. did you have a bug or can ya tell me the GPU generation? how is the external monitor connected?
<superm1> Sarvatt, i haven't file a bug yet.  let me check the GPU info
<superm1> it's in a port replicator, hooked up via DVI
<superm1> lets see, how do i translate this to a generation? 01:00.0 VGA compatible controller: ATI Technologies Inc M10 NT [FireGL Mobility T2] (rev 80)
<Sarvatt> can ya get the pci id?
<superm1> 1002:4e54
<Sarvatt> RV350, thanks
<superm1> er wait, i think i see something really weird going on that might explain things..
<superm1> http://pastebin.com/Y3TLzChg
<superm1> does that mean it's trying to use VESA?
<RAOF> Yes.
<Sarvatt> yeah..
<RAOF> Is modesetting enabled?  That's (a) not going to end well, and (b) be resolved with the recent vesa upload.
<superm1> -radeon is installed though
<Sarvatt> can't open the ati driver
<superm1> i wonder if on the upgrade it decided not to pull in -ati though, i didnt realize they were separate packages, didn't even think to check that
<RAOF> Or, rather, given the rest of that log, will result in X failing entirely 'cause it can't open the ati driver or the fbdev driver.
<Sarvatt> do you have xserver-xorg-video-ati installed?
<Sarvatt> yah that explains it
<superm1> it appears i dont
<RAOF> Do you have xserver-xorg-video-all installed?
<Sarvatt> odd
<Sarvatt> i'm sure he doesn't
<superm1> i had all sorts of upgrade problems on this box
<superm1> it was a hardy->lucid jump
<superm1> i've filed bugs where i could, but i'm certain that this is caused by some of the earlier ones that are resolved now
<bryceh> superm1, yeah I tried doing that on a box earlier this month and it was a PITA
<bryceh> ended up just wiping it
<superm1> i salvaged this, but there was a lot of --force-overwrite and --force-depends going on
<superm1> i should have waited on it i think
<bryceh> yep
<Sarvatt> hmm yeah thats a odd bug, theres no xserver-xorg-video-radeon in hardy, it pushed him from -ati to -radeon
<bryceh> yeah I ran into that one too with -radeon
<Sarvatt> xserver-xorg-video-radeon Replaces: xserver-xorg-video-ati (<= 1:6.8.191-1)
<superm1> oh swell, no internal display now
<superm1> let me get this fully upgraded to current packages and i should be able to at least file an accurate bug
<Sarvatt> can boot with radeon.modeset=0 to get it working to file the bug at least, thats pretty major
<Sarvatt> should xserver-xorg-video-radeon conflict as well as replace the old ati maybe?
<superm1> i've got external display, so even if it's not fixed after the upgrade, i should at least be able to work off that for filing the bug
<Sarvatt> unless you were on the -15 kernel and it breaks both upgrading to -17 :D
<superm1> don't you go jinxing me
<superm1> luckily i'm on -16 though :)
<Sarvatt> i've noticed radeon users tend to have some crazy setups that are just asking for trouble, dvi to hdmi to hdmi switch to receiver to tv and such :D
<superm1> haha
<Sarvatt> This is strange - like really really strange, twilight zone of strange. VGA ports have DDC buses, but sometimes for some reasons the BIOS says we don't and we oops - AMD mentioned bios bugs so we'll have to add quirks.
<Sarvatt> yay..
<tjaalton> Sarvatt: it's not in a ppa yet, but it'll happen today with the drivers
<tjaalton> looks like the amd64 build of the new wacom failed
<tjaalton> make[3]: *** No rule to make target `wcmTilt2Rotation.lo', needed by `wacom_drv.la'.  Stop.
<Sarvatt> funny how 2.6.33's radeon seems less stable than 2.6.32 going by the bug reports, a lot of flickering screen or external monitor problems
<superm1> Sarvatt, well it looks like i got my internal display back with the upgrade to -17, yay, no bugs necessary
<Sarvatt> theres like 15 commits queued up for 2.6.33.2 though
<Sarvatt> oh phew good to hear
<Sarvatt> glad because I couldn't find anything rv3xx specific
<tjaalton> hmm, need to get breakfast before replying to the thread
<RAOF> Woot!  While this box may claim it's a power supply it's really a graphics card so I can join you in the wonders of radeonland.
<bryceh> drives me nuts when people file bugs against xorg "well I have no idea what is causing my random bug, but I'll just guess and file against xorg"
<RAOF> Without using ubuntu-bug?
<bryceh> I mean I sympathize that it's hard to figure out what to file bugs against, but we're not a babysitting service and there's plenty of guides out there to help
<bryceh> no, he used ubuntu-bug
<bryceh> lp #544836
<ubottu> Launchpad bug 544836 in ubuntu "Slow boot performance" [Undecided,Invalid] https://launchpad.net/bugs/544836
<bryceh> probably a compiz or nautilus bug
<RAOF> I wonder if just running âubuntu-bugâ and getting the symptom-based reporty thing would have sent it somewhere more useful.
<bryceh> possibly
<bryceh> or maybe I'm just grumpy after doing my taxes this evening with a fussy baby screaming at the same time
<RAOF> :(
<bryceh> is vinagre something like vbox that has its own X bits?
<RAOF> It's a VNC server, isn't it?
<bryceh> yeah
<bryceh> I haven't ever played with it
<bryceh> interesting vbox *is* installed, wonder if it is causing a conflict
<Sarvatt> RAOF: you know, we could just do it with libpciaccess
<Sarvatt> if (pci_device_has_kernel_driver(dev))
<RAOF> Sarvatt: For the VESA fun?
<RAOF> Or for framebuffer McGraw?
<Sarvatt> vesa fun without libdrm
<RAOF> What happens when someone runs nouveau with nomodeset?
<bryceh> RAOF bad stuff
<bryceh> in fact I tried that
<bryceh> just get corruption
<RAOF> I thought I tried that and it fell back nicely to something that didn't die...
<RAOF> It *should* fall back to vesa, and since nouveau hasn't programmed a mode that shouldn't cause flames to shoot from the GPU's eyes.
<Sarvatt> nv needs updating to check that too :D
<bryceh> in fact I wanted to ask - we don't have documentation on the X/KernelModeSetting page for un-KMSing -nouveau and going back to -nv
<Sarvatt> blacklist=nouveau
<bryceh> I seem to recall testing it at the sprint with alberto and it worked on that hardware, but the one with my tv attached was a no-go
<Sarvatt> i wonder if our fglrx works with xserver 1.8's video abi..
<bryceh> ha
<Sarvatt> heck, why does nouveau even have the vgacon hook to work with nomodeset still in the first place
<RAOF> VESA drives my netbook as well as I could expect when nomodeset is passed
<RAOF> Sarvatt: Because people might want to use libdrm_nouveau directly without actually using the driver - CUDA type stuff.
<Sarvatt> does nv work RAOF?
<tjaalton> Sarvatt: the video abi is the same
<Sarvatt> i dont mean with your patch, I mean with an actual xserver 1.8
<tjaalton> hmm no
<Sarvatt> abi changed a few times and i think they just bumped it once
<tjaalton> it was changed yes
<tjaalton> just a long time ago
<Sarvatt> thats when i dropped xserver master from xorg-edgers :D
<tjaalton> ah it was in december, it touched the input and extension abi as well
<RAOF> Hm.  Why does nv not try to drive the display?
<RAOF> Sarvatt: Yup. nv works, but for some reason will only load if I specify it in xorg.conf.
<bryceh> Sarvatt, gonna try running fix-titles on ati...
<Sarvatt> bryceh: did you make it not change already fixed ones?
<bryceh> just did
<Sarvatt> sweet!
<bryceh> hang on found one more issue... dryrunning again
<tjaalton> hmm, need to get a diffstat from the backported patches.. seems like diffstat accepts multiple patches
<tjaalton> as arguments
<tjaalton> but it's not accurate
<tjaalton>  39 files changed, 1348 insertions(+), 344 deletions(-)
<tjaalton> minus the libudev which we already had
<tjaalton> which is over 400 insertions
<tjaalton> and of the rest 155 touch the manpage
<tjaalton> *190 touch the manpages
<tjaalton> sorry, 230 :)
<Sarvatt> will have to try a hardy-lucid upgrade this weekend and see if that ati/radeon problem is happening to everyone
<Sarvatt> oh mvo has logs, thanks google :)
<Sarvatt> Setting up xserver-xorg-video-radeon (1:6.12.99+git20100126.e5933fd7-0ubuntu2) ...
<Sarvatt> Setting up xserver-xorg-video-ati (1:6.12.99+git20100126.e5933fd7-0ubuntu2) ...
<tjaalton> bryceh: you forgot to finalize the changelog
<tjaalton> but I've done it now
<tjaalton> uh
<tjaalton> uploading the backport to my ppa..
<tjaalton> xserver, evdev and synaptics uploaded here https://edge.launchpad.net/~tjaalton/+archive/test
<tjaalton> hmm, looks like evtouch doesn't have a proper hotplug udev rule currently
 * Ng booted a lucid beta1 USB stick last night on a friend's new Vaio. It has a Core i5 and whatever the accompanying Intel chipset is...
<Ng> *very* broken. the display had what appeared to be inverted colours, or at least very wrong, and the touchpad didn't work at all
<Ng> It was a Vaio Z11X9E/B
<tjaalton> doubt those are supported yet
<tjaalton> but, lunch->
<Ng> I wonder if that sort of thing is worth an entry in the release notes
<tseliot> superm1: as regards your upload of jockey, I'm working on the fglrx handler and I'll re-enable it soon
<tjaalton> sigh, the ppa build backlog is huge
<superm1> tseliot, what else needed to be changed other than the package name?
<superm1> that should at least allow people to enable it now i'd think
<tseliot> nope
 * tseliot -> phone call
<Sarvatt> Ng: that should be supported fine, try booting with blacklist=vga16fb?
<Sarvatt> not sure about the touchpad though
<Ng> Sarvatt: I'm unlikely to be near the machine again for a week or two unfortuntaely
<Ng> but I will try that :)
<Sarvatt> by then it should be fixed hopefully if that was the problem :)
<tseliot> tjaalton: are you going to upload a new revision of mesa anytime soon?
<tjaalton> tseliot: 7.7.1 should be released tomorrow
<tseliot> tjaalton: I was asking as I committed my fix in git and bug #248392 needs it
<ubottu> Launchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] https://launchpad.net/bugs/248392
<tjaalton> that's an old bug, it can probably wait a few days?-)
<tjaalton> or you upload now and shuffle the changelog in git
<tjaalton> afk ->
<tseliot> tjaalton: no, I was just asking
<bryceh> Sarvatt, btw you'd signed up for the task to review patches in other distros... just wanted to check if you've had some time to do this and if so how it turned out?
<bryceh> tjaalton, I'm looking at backporting the Xv changes for i8xx from 2.10
<bryceh> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/?h=2.10&ofs=100
<bryceh> looks pretty self contained - the bits from Daniel Vetter between when 2.9.0 was released and before Eric started cutting out UMS bits
<RAOF> Yay!  One (class of) kms edid quirks seems dealt with upstream.
<bryceh> RAOF, kewl, are you flagging it for the kernel team to backport?
<RAOF> Yes.  I'm not sure precisely how to flag the bug for maximum effect, though.
<bryceh> here's how:
<bryceh> a) tag it 'xorg-needs-kernel-fix'
<bryceh> I've heard there is a report they look at with these tagged bugs.  dunno if that is still true but good just in case
<bryceh> b) nominate it for 'lucid' and set milestone to 'beta-2'
<bryceh> that should get it on the release team's radar at the very least
<bryceh> c) If you want to ensure it gets attention, also mention the bug to JFo on #ubuntu-kernel and ask he puts it in the kernel team's hopper
<bryceh> d) if it is extremely critical and you really don't want it to get lost, also assign it to one of the kernel engineers, like apw or sconklin.  But this should be used only in really critical cases
<RAOF> I don't think it warrants that.
<bryceh> e) Raise the bug on the kernel-team@ mailing list.  This is good for really earth shattering or highly risky things
<bryceh> for most bugs that I care for the kernel team to see I just do (a) and maybe (b)
<bryceh> and then (c) for important stuff
<RAOF> Thanks.
<bryceh> hmm, the Xv patch is pretty large
<jcristau> bryceh: i've got the xv changes in sid fwiw
<bryceh> jcristau, ah great
#ubuntu-x 2010-03-26
<Sarvatt> nice!
<Sarvatt> I guess it was the XvMC stuff that was the problematic one in the end looking at it not just play Xv overlay
<RAOF> Fortunately, no one cares about XvMC.
<Sarvatt> lots of people care if its disabled even if it's basically useless, you'd be surprised how much email I get about noting I disable it in xorg-edgers in the changelog on karmic because of the old libxcb :)
<RAOF> I'm surprised people care about MPEG2 decoding hand-off so much.  I remember watching the gallium XvMC development having trouble with the setup & teardown overhead being more than what it'd take for the cpu to actually just decode the streatm :)
<bryceh> they probably don't know, they probably just think it'll make their pr0n look better
<Sarvatt> were they testing with the right source for it to matter? it makes the most difference with huge interlaced mpg2 videos and the deinterlacing quality is better which is pretty important on a HTPC
<Sarvatt> but for like a progressive source it makes almost no difference
<RAOF> ...The other problem they were running into is that nouveau didn't have a memory manager then, so huge mpeg2 videos would ENOMEM :)
 * bryceh documents quirking in KMS-land - https://wiki.ubuntu.com/X/Quirks
<bryceh> RAOF, for blacklisting nouveau so it uses -nv, do we just put 'blacklist nouveau' in /etc/modprobe.d/blacklist.conf ?
<Sarvatt> does nouveau require blacklisting to use -nv? I still haven't tested that, wifes laptop HDD now says failure imminent  so shes back on my nvidia one :(
<Sarvatt> anyone familiar with libpciaccess know if pci_device_has_kernel_driver checks if KMS is in use or just if there is a kernel module loaded for the device?
<RAOF> bryceh: For some reason in my testing -vesa claimed the display rather than -nv unless I manually listed nv in xorg.conf.
<RAOF> That's certainly a fine way to blacklist nouveau, though.
<bryceh> ok stuck docs here https://wiki.ubuntu.com/X/KernelModeSetting
<bryceh> tjaalton, ok looks like http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/PkgList/versions_current.html is automatically updating once again
<bryceh> weird cron issues
<bryceh> tjaalton, let me know if you spot any troubles, I suspect I won't be watching it too closely henceforth
<Sarvatt> wow, death to vga16fb
<Sarvatt> turns on the suspend/resume problems I'm having now with the blob go away when I blacklist it again :D
<bryceh> huh
<bryceh> did you see the patch on kernel-team@ about it?
<Sarvatt> 11 suspends in a row with it blacklisted, second resume hung after removing the blacklist
<Sarvatt> nope not yet
<bryceh> heya rafiyr
<rafiyr> hi
<rafiyr> how are you
<bryceh> good, just finishing up a few bits before heading up to seattle for the weekend
<bryceh> (my sister's in a play)
<rafiyr> going for fun?
<Sarvatt> that fix on the mailing list wont affect the blob
<rafiyr> take that as a yes
<bryceh> Sarvatt, ok
<bryceh> rafiyr, :-)
<rafiyr> I'm heading up to see some family too.
<Sarvatt> so its basically, do you want suspend support or do you want a text splash up for 1 second at this point with the blob..
<rafiyr> Wish I was better at reading code in the car.
<RAOF> Sarvatt: Oh, sweet.  More reasons to hate on vga16fb :)
<RAOF> bryceh: About the Intel lid quirks - I'm pretty sure I've seen an upstream commit that's basically âStop using the lid status for lvds, it breaks too oftenâ
<RAOF> So that particular class of quirks might be easily solved.
<Sarvatt> RAOF: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=6e6c822868f113dabe3c33bdd91e883cc28fa11b
<RAOF> Sarvatt: :)
<RAOF> FWIW, nouveau also has a variant of that approach.
<Sarvatt> i was gonna change that part on the wiki but it was actually talking about other bugs that i think might still need quirks
<tjaalton> bryceh: ok, thanks!
<tjaalton> btw, looks like the autoconfig patch was not guilty for the crash-on-exit bug.. :)
<tjaalton> only happens with MALLOC_PERTURB_ set, and with vanilla xserver
<tjaalton> hmm, trying syncpackage with -sis
<tjaalton> basically it just downloads the source and runs debsign on it, the it's jut a dput away of being "synced"
<tjaalton> *just
<bryceh> tjaalton, heh
<bryceh> so that's all it's been all this time?
<ara> bryceh, thanks for the feedback on MT :-)
<bryceh> ara, sure; hope it helps
<tjaalton> bryceh: yeah, so it's nothing to worry about imo
<tjaalton> if you meant the crasher
<bryceh> tjaalton, no I meant, that's all we've had to do to sync a package?
<bryceh> I always assumed it involved more dials and levers
<tjaalton> bryceh: yeah, quite simple :)
<tjaalton> you still need to feed the url to it, and answer 'n' when it asks to use the original signature
<tjaalton> so there are some quirks left
<tjaalton> but I guess those are known and worked on
<tjaalton> +being
<bryceh> mm
<tjaalton> new synaptics (1.2.2)
<tjaalton> ok, vmmouse and joystick inputclass configs added and uploaded to my ppa, only evtouch to do
<tjaalton> hmm, the tag matching is not properly documented in the xorg.conf manpage, nothing mentioned that the backend needs to set ID_INPUT.tags for MatchTag to work
<tseliot> tjaalton: is the new mesa release a bug fix release?
<tjaalton> tseliot: yes
<tjaalton> we have a snapshot of that branch already
<tseliot> tjaalton: ok, so we should just wait for upstream to release it, right?
<tjaalton> tseliot: yep, I'll ping debian-x to upload it, or we can dput it as -0u1 if they're busy
<tseliot> tjaalton: ok, good
<tjaalton> tseliot: bug 546933
<ubottu> Launchpad bug 546933 in xorg-server "FFE: xorg.conf.d/inputclass backport" [Undecided,New] https://launchpad.net/bugs/546933
<tjaalton> https://edge.launchpad.net/~tjaalton/+archive/test/+packages
 * tseliot has a look
<tjaalton> the build queue is hopelessly long though
<tjaalton> but synaptics and evdev works with the previous set of packages
<tjaalton> lunch ->
<Consul_Falx> hello
<Consul_Falx> I'm affected with the following bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/545289
<ubottu> Ubuntu bug 545289 in linux "[RV515] XOrg malfunction - open radeon driver (X1450) - graphics flickering all time in lucid 64bit [Needs pll quirk]" [Undecided,Confirmed]
<Consul_Falx> what does the "pll quirk" stand for, and how is it done?
<solarion> is everything on the screen being upside-down and backwards a known bug?
<solarion> (lucid)
<solarion> (eee 901)
<tjaalton> yes
<tjaalton> wrong libGL
<solarion> excellent
<solarion> how do I get the right libGL, and which libGL do I have?
<tjaalton> dunno
<tjaalton> probably a poulsbo in it?
<solarion> no
<solarion> hell no
<solarion> :)
<solarion> 945GME
<tjaalton> check Xorg.0.log
<tjaalton> or pastebin it
<solarion> I can't atm, maybe when I get to work
<solarion> what am I looking for in xorg.0.log?
<tjaalton> what it says after loading libglx
<tjaalton> likely nvidia
<tseliot> solarion: "ldconfig -p | grep GL" and "update-alternatives --display gl_conf" should show what's wrong
<solarion> xorg foundation
<solarion> indeed
<tseliot> maybe you switched between drivers by simply changing your xorg.conf. This is not the right way to do it
<solarion> glcore is nvidia
<solarion> effing nvidia
<solarion> no
<solarion> I have no xorg.conf
<solarion> the entirety of what I did was update yesterday
<solarion> how do I set back to mesa?
<tseliot> please follow this paragraph "Problem: Need to manually review/tweak alternatives settings" here: https://wiki.ubuntu.com/X/Troubleshooting/NvidiaDriverSwitching
<solarion> why did it switch on my from just doing an update, though?
<tjaalton> good question
<solarion> I'd done *nothing* manually, and I've not selected *any* proprietary drivers
<solarion> this is also a pretty fresh install from beta 1
<tjaalton> check dpkg.log
<solarion> what specifically am I looking for?
<solarion> oh, 03-23 had update-alternatives --force with GL
<tjaalton> see what it installed
<solarion> yes
<solarion> nvidia-current seemed to force GL 
<tjaalton> nice :)
<solarion> 195.36.15
<solarion> -0ubuntu1
<tjaalton> what pulled it in?
<solarion> what pulled in nvidia-current?
<tjaalton> yes
<solarion> I've no idea
<tjaalton> as a dependency
<solarion> I'm guessing that's an apt thing that I always forget. :)
<tjaalton> apt-cache rdepends
<tjaalton> or use aptitude
<solarion> nvidia-glx-185
<tjaalton> had that installed?
<solarion> eh, I'm not sure where this is getting pulled in
<bigon> are you aware of that bug?
<bigon> http://bugs.freedesktop.org/show_bug.cgi?id=26394 
<ubottu> Freedesktop bug 26394 in Extensions/DRI "Server sometimes crashes when closing OpenGL programs" [Critical,New]
<tjaalton> no
<solarion> modealiases seems to have pulled in nvidia (first reference in dpkg.log)
<solarion> nvidia-173-modealiases
<tjaalton> those are installed by default
<tjaalton> the don't depend on nvidia-current
<tjaalton> they
<solarion> oooh
<solarion> I think I know what happened.
<solarion> hahahahah
<solarion> It's when I pulled the packages from my workstation (which has nvidia)
<solarion> I'm such an idiot
<tjaalton> proven ;)
<solarion> verily
<tjaalton> use pkgsync if you need to do that
<tjaalton> and list nvidia in mayhave
<solarion> not heard of pkgsync
<solarion> I was using the default tools (synaptic)
<tjaalton> install and see
<solarion> lemme kill this effing nvidia driver
<tjaalton> it's a tool to keep a predefined set of packages installed
<tjaalton> nothing more, nothing less
<solarion> hmmm
<tjaalton> so if you want to keep the same set of packages, copy the config around
<tjaalton> but keep hw related stuff in mayhave
<solarion> too bad that's not more automatic
<tjaalton> what do you mean?
<solarion> I mean, hw drivers are clearly hardware-dependent and a separate category from libs, which are separate category of package from apps
<tjaalton> well there aren't too many of them anyway
<solarion> too many of which?
<tjaalton> might as well handle them by hand
<tjaalton> hw drivers
<tjaalton> that you need to install
<solarion> sure, but it sucks more than it needs to. :)
<tjaalton> wfm
<superm1> tseliot, well while you are sorting out that fglrx handler in jockey, there's a few commits that need cherry picking from trunk of jockey to fix some other bugs too
<superm1> pitti should be able to point them out if you aren't sure
<solarion> until you forget something one day and have to put the pieces back together
<solarion> "wfm" isn't an answer to "it sucks more than it has to"
<tjaalton> it was just a suggestion
<solarion> I am a big fan of automatic things doing tedious things for me
<solarion> like this one. :)
<tseliot> superm1: maybe we should discuss this with pitti in, say, #ubuntu-desktop?
<solarion> Anyhow, thanks a lot for the pointer. I'll check out pkgsync
 * solarion heads to work
<superm1> tseliot, sure
<Sarvatt> gonna start doing something crazy on edgers - http://sarvatt.com/downloads/patches/exa_backport_to_1.7.6.patch
<Sarvatt> buh Applying patches...Patch 111_armel-drv-fallbacks.patch does not exist
<Sarvatt> ton of new tools in intel-gpu-tools now, just uploaded a new one to edgers. intel_error_decode looks nice :)
<Sarvatt> wow intel_reg_dumper doesn't hang the system anymore! \o/
<Sarvatt> http://lists.freedesktop.org/archives/xorg/2010-March/049749.html
<Duke`> hum nvidia announced deprecation of xf86-video-nv
<tjaalton> wow
<mdeslaur> wow, so no more 2d source code for newer nvidia chips
<bjsnider> they said that it would be better to use the vesa driver, which is true and beyond question
<tjaalton> didn't say a word about nouveau ;)
<bjsnider> nouveau has a different purpose than nv did
<bjsnider> nv was just for an initial x screen so users could install the blob
<tjaalton> yep
<bjsnider> nouveau is a replacement for the blob
<bjsnider> vesa does better that nv was supposed to be for
<jcristau> bjsnider: nv supported dual head.  vesa not so much.
<bjsnider> did you need dual-head to install the blob?
<jcristau> who said i cared about the blob
<bjsnider> nv's purpose is to provide an initial x screen to facilitate installation of das blob
<jcristau> well that's what nvidia wants it to be, yes
<BUGabundo> evening
<bjsnider> anyway, we figured out a patch to the gnome-shell that fixes all nvidia issues
#ubuntu-x 2010-03-27
<tjaalton> phew, backport-ppa finally built
<BUGabundo> bRoas
<Sarvatt> sent a mail to kernel-team with a list of major intel bugs that need kernel patches since I can't get through to anyone with apw being on vacation :D had a bunch of radeon ones listed as well but all of them were cc'd to stable already
<chrisccoulson> Should Xorg be able to control screen brightness when it's running on an inactive VT? I've noticed that gnome-power-manager is dimming the screen from an inactive user session (using xrandr), and I'm wondering if g-p-m needs to check if it's on the active console or not
<Sarvatt> chrisccoulson: related to http://git.gnome.org/browse/gnome-power-manager/commit/?id=c7728fddf901635794edd7db299c7247f4c27ab3 maybe? is it a recent regression?
<chrisccoulson> Sarvatt - that commit doesn't really affect brightess
<chrisccoulson> i'm not sure if this is a recent regression or not, perhaps i just never noticed it before ;)
<chrisccoulson> but gnome-power-manager has never checked whether it's on the active VT for display dimming
<Sarvatt> where to start cleaning up all these X: ../../src/i830_batchbuffer.h:79: intel_batch_emit_dword: Assertion `pI830->batch_ptr != ((void *)0)' failed. bugs.. 
<Sarvatt> dpms events are hanging the gpu and giving batchbuffer I/O errors, and you get that assert when you switch VT's after its hung with that. almost all are dupes but the kernel guys are saying we have the fix in our kernel already even though the fix isn't applied when I check out the kernel source and look at the lines affected by the commit
<Sarvatt> it's affecting a lot more than  just 965+ like I thought, seen it as far back as 845
<Sarvatt> i probably dont notice it because i have g-p-m set to do nothing when i close the lid and such, my laptop turns off the display automatically when i shut the lid no matter what
<Sarvatt> kind of annoying how it reloads the webcam every time i open the lid though :D
<chrisccoulson> Sarvatt - i'm sure I remember having a similar issue to that a few weeks back
<chrisccoulson> and then it worked
<chrisccoulson> and now it's regressed again ;)
<Sarvatt> chrisccoulson: yeah kernel guys are saying the fix is in the kernel  but I'm looking at the source and the code removed from the fix is still there so its definitely not
<Sarvatt> looks like it was just an oversight that it got dropped but we're getting a *massive* number of bugs about it
<chrisccoulson> yeah, it does seem to affect quite a few people :-/
<Sarvatt> hopefully it'll be fixed soon :)
<chrisccoulson> it will get escalated, as it's a beta-2 blocker now isn't it?
<chrisccoulson> hmmm, it's not a blocker for beta-2 actually
<chrisccoulson> Sarvatt - bug 447159 is the one isn't it?
<ubottu> Launchpad bug 447159 in xserver-xorg-video-intel "[i945gm] Xorg assert failure: X: ../../src/i830_batchbuffer.h:79: intel_batch_emit_dword: Assertion `pI830->batch_ptr != ((void *)0)' failed." [High,Confirmed] https://launchpad.net/bugs/447159
<Sarvatt> if its not already closed because they thought the fix was already released, i brought it up on the kernel-team list though and pointed out that it wasn't really included in the latest kernels. usually I can bug apw about stuff like this but he's on vacation :D
<Sarvatt> kind of, that assert happens when a VT switch occurs after the batchbuffer I/O error hang which happens when we dont have the kernel fix in but there are other things that can cause the batchbuffer I/O hangs too. I haven't seen any that weren't stemming from the kernel fix I'm talking about lately though)
<Sarvatt> https://launchpad.net/bugs/535640 is the main one
<ubottu> Ubuntu bug 535640 in xserver-xorg-video-intel "[gm45] GPU lockup de05bf80bf83cd22541cb55f1a2ee99e (xorg crash when opening the laptop lid)" [Unknown,Confirmed]
<Sarvatt> but almost all of those duped in the one you linked are dupes of the one i just linked
<chrisccoulson> ah right, i think i probably see all of those issues on my laptop at the moment
<chrisccoulson> i get hangs on lid close and VT switching
<Sarvatt> the original reporter in the one you linked has a problem because i915 loaded before the agp module did which is another fix, it's just getting *alot* of me-too's because its a problem now too
<Sarvatt> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=7b56712ff524ee55e38afaee3954d125f56a6070 is the fix
<Sarvatt> was only in the 2.6.32-15 kernel
<Sarvatt> what was that KMS wiki page again? I want to put a note on how to pack plymouth and such into the initrd so the boot isn't so ugly
#ubuntu-x 2010-03-28
<Sarvatt> dang, forcing it into the initrd gives me a high resolution text renderer splash now
<Sarvatt> hmm vga16fb doesn't load at all if i put all the gpu modules in the initrd actually
<Sarvatt> lol oops, KMS wiki page said to echo blacklist nouveau > /etc/modprobe.d/blacklist.conf ....
<Sarvatt> hope noone actually did that :D
<Sarvatt> what to do about this sisimedia driver..
<Sarvatt> i've been working on it for awhile not but it's a pain in the butt. they patched the heck out of a *really* old sis release and it needs a ton of fixes for xserver 1.7
<tjaalton> Sarvatt: don't bother, it should be merged with sis
<tjaalton> some distro has done that, but can't remember which one
<Sarvatt> mandriva
<tjaalton> right
<tjaalton> they should push it upstream
<Sarvatt> and it doesnt work in cooker there either
<tjaalton> though it doesn't matter who does the work, so go for it ;)
<Sarvatt> huh
<Sarvatt> #6  0x0816848c in RRScreenSizeSet (pScreen=0x8965720, width=1280, height=28864, mmWidth=169,  mmHeight=126) at ../../randr/rrscreen.c:185
<Sarvatt> thats some height
<Sarvatt> yeeeep bug 535640 happens on all generations for sure
<ubottu> Launchpad bug 535640 in xserver-xorg-video-intel "[gm45] GPU lockup de05bf80bf83cd22541cb55f1a2ee99e (xorg crash when opening the laptop lid)" [Unknown,Confirmed] https://launchpad.net/bugs/535640
<superm1> and it's annoying as heck too :)
<Sarvatt> yep!
<Sarvatt> fix will be in *soon*
<Sarvatt> kernel team thought it was still applied but it wasn't
<superm1> every time it's happened to me i've been stuck behind proxies and unable to upload a report, so i'm glad to hear it's more commo
<superm1> n
<Sarvatt> you can disable turning off the display in power management and not blank the screen with a screensaver for now to fix it
<superm1> cool, thanks
<superm1> there's one other big one i keep seeing on my intel boxes.  the bottom of the display turns all jittery whenever i type and gets worse as i type more.  if i vt switch or restart X it appears to go away for a bit though
<Sarvatt> that one i just saw reported for the first time today
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/549989
<ubottu> Ubuntu bug 549989 in xserver-xorg-video-intel "[gm45] flicker on bottom third of screen" [Undecided,New]
<superm1> yup
<Sarvatt> does it only happen with gnome-terminal for you?
<superm1> come to think of it, that's the only time i've ever noticed it
<superm1> let me grab it and see if it's acting up right now
<Sarvatt> yeah i dont think thats a problem in intel, i only get something similar in gnome-terminal
<Sarvatt> moving the mouse up to gnome panel clears it
<Sarvatt> it started when the CSD stuff was added to gtk+ but that was backed out and i still have it
<superm1> of course it's stable right now
<superm1> it's only when i'm doing important things that it likes to happen
<Sarvatt> yeah same here :D
<Sarvatt> i get it like once a week or so, but sometimes it gets real bad and i get it like 10 times in a day
<superm1> it's usually hourly for me
<Sarvatt> it makes my whole screen black except for a sliver up at the panel and moving the cursor up to the panel fixes it. really weird
<superm1> if i dont vt switch or log out / in i'm sure to get some kind of black out on the screen when it starts happening
<superm1> i'll keep that in mind next time it happens to see if i'm as lucky
<Sarvatt> it usually happens when I pageup or pagedown in nano
<Sarvatt> wish i could figure that one out
<Sarvatt> happens on 2.6.31-2.6.34, with or without compiz, and on intel 2.9.1 through 2.10.903
<Sarvatt> and only in gnome-terminal..
<Sarvatt> actually when the CSD stuff was in it happened in xchat too
<Sarvatt> scrolling up and down the screen there too
<superm1> can't seem to induce it with a pg up/down here
<Sarvatt> asking in ubuntu-desktop if anyone has any idea where to start digging into it :)
<superm1> lshw -c video corrupted it in a much more fun and colorful way
<Sarvatt> ok on 945 the error state looks like this instead of the easily recognizable 965+ ones even though its the same bug - http://launchpadlibrarian.net/41715185/i915_error_state.txt
<Sarvatt> i just enabled screen blanking and such and I get that same error state, there goes another 50 intel bugs to be duped :)
<Sarvatt> well thats what 915-945 look like i should say, not just 945
<Sarvatt> superm1: the lshw thing is fixed in 2.6.32-18 thats built just doesnt have a linux-meta yet
<Sarvatt> can blacklist vga16fb to fix that for now too otherwise :D
<Sarvatt> should be fixed I should say, I haven't tested it yet
<Sarvatt> sheesh the more I close intel bugs the more nouveau bugs go up
<Duke`> I feel a little performance regression in latest mesa/dri/i945
<Duke`> well, it's just glxgears, so maybe there is no real regression, but...
<Sarvatt> are you using a 2.6.32+ kernel?
<Duke`> 2.6.33
<Duke`> at glxgears, I experience a drop from 1200 to 900 fps
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/549318
<ubottu> Ubuntu bug 549318 in nvidia-graphics-drivers "Xorg crashes when I switch to console" [Undecided,New]
<Sarvatt> is that even supposed to work?
<BUGabundo> I had one of those Sarvatt
<BUGabundo> seems fixed now
 * BUGabundo reads the bug details
<BUGabundo> ok, not multicard nor multi monitor
<Sarvatt> BUGabundo: still hitting any of your old bugs with the blob?
<Sarvatt> suspend/resume working? can ya vt switch?
<BUGabundo> Sarvatt: all fine so far
<BUGabundo> suspend works, TTYs too
<BUGabundo> need to test hibernate
<BUGabundo> haven't in a while, last few times I tested it was broken.... and it takes SOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO darn long, I rather not use it anymore
<Sarvatt> sweet, mind closing those bugs you had open? i asked in the bugs if it was still happening and marked incomplete but dont have them handy :D
<BUGabundo> will have to search the email
<BUGabundo> were those comments recent? 
<Sarvatt> yeah hibernate makes no sense to me anymore, not when a normal boot is faster..
<BUGabundo> I'm up to date until last night
<BUGabundo> Sarvatt: there are two use cases for it:
<Sarvatt> oh i'll get it off your launchpad page
<BUGabundo> one is where you really need to keep an work flow of open docs
<Sarvatt> it was when nvidia-current was updated last right after beta 1
<BUGabundo> two when you want to turn of a machine to move around
<BUGabundo> no idea
<BUGabundo> haven't correlated dates 
<Sarvatt> session management in the text editor! :D
<Sarvatt> chrome/firefox remembering tabs, gedit and geany remembering docs open, thats all i need
<BUGabundo> ahh
<BUGabundo> kenvandine: FYI increasing gwibber timeout, seems to help me connect to brainbird.net (statusnet) without probs
<Sarvatt> oh sweet you have alot of bug reports that are fixed on your reported bug page :)
<BUGabundo> o...k...
<Sioux-33> hi anyone here?
<BUGabundo> no
<BUGabundo> we all ran cause of the splits
<Sioux-33> hahaha
<Sioux-33> hi, ubuntu 9.10 i updated kernel to version 2.6.31.21 and mousse cursor is gone dont know what happen any ideas?
<Sarvatt> Sioux-33: usb mouse or touchpad? 
<Sioux-33> touchpad
<Sarvatt> sudo apt-get install pastebinit && cat /var/log/Xorg.0.log | pastebinit
<Sarvatt> ^ paste that in a terminal and paste the pastebin link it gives if you dont mind :)
<Sioux-33> my dear <Sarvatt> u want me to use pastebin now? cos at the moment im using kernel 2.6.31.20 and the mousse cursor is working fine. if u want me to boot up to 2.6.31.21 then there will be diffucult to use anything cos of no moussse cursor so what do u want me to do?
<Sarvatt> did you boot to the non working cursor situation last?
<Sarvatt> if so /var/log/Xorg.0.log.old will have the info in it
<Sioux-33> <Sarvatt> one sec yes i booted 2.6.31.21  last let me see if i can find anything
<Sarvatt> /var/log/dmesg.1 would be handy too
<Sarvatt> for that one use 
<Sarvatt> zcat /var/log/dmesg.1.gz | pastebini
<Sarvatt> actually I would recommend filing a bug with ubuntu-bug linux after booting where you dont have the mouse working, you can press alt+f2 to run the command. do you have an external mouse you can use just to file it?
<Sioux-33> nope i dont 
<Sioux-33> u want me to zcat /var/log/dmesg.1.gz | pastebinit?
<Sarvatt> please
<Sioux-33> i did zcat /var/log/dmesg.1.gz | pastebinit and then got http://pastebin.com thats all
<Sarvatt> darn :(
<Sioux-33> what do u want me to do?
<Sarvatt> the karmic one must be messed up
<Sarvatt> well, run ubuntu-bug linux and attach /var/log/dmesg.1.gz and /var/log/Xorg.0.log.old to it if you dont mind, that would be alot more helpful anyway
<Sarvatt> just mention the touchpad doesn't work with 2.6.31-21 but does with 2.6.31-20
<Sioux-33> it doesnt with 2.6.31.21 generic it doesnt with 2.6.31.21 pae it doesnt with 2.6.31.20 pae
<Sioux-33> <Sarvatt> can be that it doesnt work cos of graphic card for example? 
<Sarvatt> i doubt it very much, it would be appreciated if you could file that bug though because thats a pretty nasty problem and that kernel is still in proposed so best to figure it out before it gets moved over to karmic-updates
<Sioux-33> ok i will report a bug 
<Sarvatt> it will automatically fill in almost all of the info, only thing you need to mention is what kernels it works on and which it doesnt and attach those extra logs after if you dont mind
<Sarvatt> i'm guessing its going to be http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=a36ea9e4ead28b3836ba4bd3abaab39fdf16f423 but wont know until I see the bug
<Sioux-33> i type in the terminal ubuntu-bug and then what ? i should use ubuntu-bug something 
<BenHoltz> I need help with ubuntu 10.04 w/integrated intel gfx so that i can use my flat screen TV via VGA. I have tried disabling kms with grub, and no luck. I tried setting it via the wiki suggestions and upon echoing to the i915-kms.conf get permission denied.  any ideas?
<Sarvatt> BenHoltz: sudo -i first, then do the echo command
<BenHoltz> Sarvatt: I'll try that...  how can we add that to the wiki?
<BenHoltz> Sarvatt: Still no dice, after grub it goes out of sync.
<BenHoltz> anyone have any clues/suggestions?
<BenHoltz> I need help with ubuntu 10.04 w/integrated intel gfx so that i can use my flat screen TV via VGA. I have tried disabling kms with grub, and no luck. I tried setting it via the wiki suggestions and echoing to the i915-kms.conf with no luck .  any ideas?
 * BenHoltz wishes for some x expert to magically fall into the room
<jcristau> why would you disable kms?
<BenHoltz> thats what everyone suggested
<BenHoltz> :(
<Sarvatt> BenHoltz: file a bug with ubuntu-bug xserver-xorg-video-intel, we dont even know what the problem is and its probably apparent in your logs
<jcristau> i don't know who everyone is, and they're usually wrong anyway :)
<BenHoltz> jcristau: I agree!
<BenHoltz> Sarvatt: via Help>Report a problem?
<Sarvatt> press alt+f2 and type ubuntu-bug xserver-xorg-video-intel
<BenHoltz> Sarvatt: 10-4.  Thanks!
<Sarvatt> be more descriptive of what the problem is outside of it doesn't work if you can :)
<BenHoltz> Sarvatt: I will do so.
<Sarvatt> thanks, will get the email when it shows up and take a look, hopefully its just something easy
 * BenHoltz hopes!
<Sioux-33> <Sarvatt> its done take look at it Bug #550396
<ubottu> Launchpad bug 550396 in linux "ubuntu 9.10 kernel 2.6.31.21generic and pae cursor bug" [Undecided,New] https://launchpad.net/bugs/550396
<Sarvatt> thanks Sioux-33, can you attach /var/log/Xorg.0.log.old to it too?
<Sioux-33> <Sarvatt> how?
<Sarvatt> click attach a file at the bottom and navigate to /var/log and pick Xorg.0.log.old
<BenHoltz> Sarvatt: submitted Bug #550405
<ubottu> Launchpad bug 550405 in xserver-xorg-video-intel "Flatscreen TV goes out of range after grub with integrated intel gfx and a Sony Bravia 32' Flatscreen TV connected via VGA cable. " [Undecided,New] https://launchpad.net/bugs/550405
<Sarvatt> hmm it is detecting your trackpad as a ImExPS/2 Generic Explorer Mouse
<Sarvatt> Sioux-33: looks like you booted with the non working touchpad setup this boot where you filed the bug?
<Sioux-33> yes
<Sioux-33> i booted 2.6.31.21 pae
<Sioux-33> and i attached the xorg old
<Sioux-33> just now
<Sarvatt> thanks, you're booted to a working setup now right? can you also attach /var/log/dmesg and note its from a working setup as well? sorry to be a pain
<Sioux-33> ok one sec
<Sarvatt> huh, wait a sec, this could very well be a graphics problem..
<Sarvatt> you dont have the proprietary drivers installed for the other kernels
<Sioux-33> <Sarvatt> i use ati card ati hd 4850 and i installed ati catalyst in kernel 2.6.31.20 so i should if i update kernel the same driver in 2.6.31.21?
<Sarvatt> did you install it outside of the package manager system Sioux-33?
<Sarvatt> thats what it looks like
<Sarvatt> when you do that you need to update it manually every time you install a new kernel
<Sioux-33> <Sarvatt> i updated kernel from synaptic and the driver was from ati website 
<Sioux-33> so i should boot up 2.6.31.21 and then install ati driver again?
<Sarvatt> yeah thats the problem here, its *really* not recommended to install it from the ati website by yourself because it doesn't automatically update when you update your kernel
<Sarvatt> yeah, that or uninstall it completely and install the ati driver through system - administration - hardware drivers
<Sarvatt> i'd really recommend the latter because that way you wont have to manually update it every time you install a new kernel
<Sioux-33> the problem is that in synaptic is just open source driver for ati 
<Sioux-33> so thats why i downloaded the one from ati web
<Sioux-33> let me try boot up again to 2.6.31.21 and install ati driver ok?
<Sarvatt> synaptic isn't what you want, you should have the proprietary drivers available (they're called fglrx) when you go to system - preferences - hardware drivers
<Sarvatt> you need to update it for every kernel, switching from generic to generic-pae counts as a new kernel too
<Sioux-33> ok brb 3 min 
<Sarvatt> that will quickly get old if you switch between generic and generic-pae alot and have karmic-proposed enabled :D
<BenHoltz> :)
<Sarvatt> BenHoltz: okie taking a look at yours..
<BenHoltz> Sarvatt: I appreciate your help. :)
<Sarvatt> well first thing i noticed is we need to backport http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=3d4b3f257fbbb69c6f236d9803abe54a90d7d434 to 2.9.1 (makes note)
<Sarvatt> [   15.576747] [drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module.
<Sarvatt> [   15.576793] DRM: Fill_in_dev failed.
<BenHoltz> also found a similar message to that in the GdmLog.txt
<BenHoltz> No such file or Directory
<Sarvatt> ok BenHoltz can you try removing your i915-kms.conf, then edit /etc/initramfs-tools/modules and add these lines (in this order)
<BenHoltz> 10-4
<Sarvatt> agpgart
<Sarvatt> intel_agp
<Sarvatt> drm
<Sarvatt> i915
<Sarvatt> then sudo update-initramfs -u after
<jcristau> that sounds wrong
<Sioux-33> <Sarvatt> i dont know who u are but one thing im sure u are the best man:) i been asking on ubuntu forum then ubuntu channel ubuntu bugs no one know what happen with mousse cursor u should change your nick to albert einstein u are the best man tnx very much i updated driver in 2.6.31.21 pae and everything is working fine 
<jcristau> i915 should be loaded automatically, not from /etc/modules
<Sarvatt> jcristau: its loading agp then drm then intel_agp then i915 for him and intel_agp needs to be loaded before, trying to get this commit in the lucid kernel because alot of people are having this problem  - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1f7a6e372e9cb4d749f34c0738d832e6cadb4071
<BenHoltz> Sarvatt: that is done. i'll give it a spin
<BenHoltz> Sarvatt: what do you need me to do now?
<Sarvatt> no worries Sioux-33, best to file a bug when you have problems like that because we really need to see logs :D
<jcristau> Sarvatt: right, i'm just saying drm and i915 don't need to be there
<Sarvatt> well reboot and see if its any different, thats just one issue i noticed you having still checking over your logs
<jcristau> (the debian kernel has all agp drivers builtin now for that sort of reason)
<Sarvatt> not having any luck convincing the kernel guys of that here :D
<Sarvatt> gpu modules arent even getting put into the initrd at the moment, boot looks so ugly
<jcristau> *shrug* gpu modules don't belong in the initrd
<BenHoltz> Sarvatt: still not working on the TV, but it loads on the dell monitor.
<BenHoltz> still
<Sarvatt> BenHoltz: can you install pastebinit and dmesg | pastebinit now?
<BenHoltz> Sarvatt: sorry kinda a noob with the commands... 
<Sarvatt> sudo apt-get install pastebinit && dmesg | pastebinit
<Sarvatt> paste that into a terminal
<Sarvatt> it'll give you a link to paste here
<BenHoltz> sudo apt-get install pastebinit && dmesg | pastebinit  ok 1 sec
<Sarvatt> do you have compiz enabled BenHoltz? does it work if you disable compiz?
<BenHoltz> i belive it is enabled, i'll try disabling
<benholtz_broken_> http://pastebin.com/NJjieabs
<BenHoltz> still not working with compiz disabled.
<BenHoltz> ok so here's my feeling, i think its starting in a resolution/refresh rate my tv doesnt like...
<Sarvatt> oh its out of sync during boot even, sorry
<BenHoltz> i just have no clue how to fix
<BenHoltz> yes
<BenHoltz> i should have been more clear. ;)
<BenHoltz> when i start it with my monitor plugged in, then change the cords to have the tv plugged in it seems to now work, but when i have it start with the tv and plug it into the monitor it is waay huge on the monitor.
<Sarvatt> hmm what drm debug level is for mode set logging..
<BenHoltz> ??
<jcristau> drm.debug=6 should work iirc
<Sarvatt> BenHoltz: with the connector setup that is being screwy for you, try holding shift while booting, scrolling down to where you see quiet splash written and add drm.debug=0x04 to it, then do the dmesg | pastebinit again
<BenHoltz> ok 1 sec
<Sarvatt> or drm.debug=0x06 even, sorry :D
<BenHoltz> no dice with holding shift it just reboots just past grub
<Sarvatt> 0x06 is DRM_DEBUG_KMS + DRM_DEBUG_DRIVER, driver has hotplug events but i think that might spam too much from the other things
<BenHoltz> i'm just in a loop when i hold shift
<Sarvatt> oh? well do a sudo nano /etc/default/grub and add the drm.debug=0x06 after quiet splash and sudo update-grub after, just remove it after all of this
<BenHoltz> ok 1 min
<BenHoltz> i could press esc to edit the grub?
<Sarvatt> if that works :D
<Sarvatt> you using grub1 or something?
<BenHoltz> i'll try that 1 sec
<BenHoltz> ??? how do i know?
<Sarvatt> how did you edit grub before like you said in the bug? just do it the same way
<BenHoltz> i pressed esc then e ten edited that way
<Sarvatt> yep just do that then
<BenHoltz> add it to the kernel line?
<Sarvatt> yep
<BenHoltz> ok started up with fail.
<BenHoltz> now going to go and get the patebin brb
<Sarvatt> wonder why mode sets dont show up in dmesg anymore, could swear they used to
<benholtz_broken> http://pastebin.com/WmwCinWy
<Sarvatt> it didnt take your extra option
<Sarvatt> no drm.debug there
<BenHoltz> hmmm... i'll try adding it to the .cfg
<BenHoltz> Sarvatt: i dont see the quiet flash in /etc/default/grub
<BenHoltz> splash*
<BenHoltz> wait i see it now
<BenHoltz> trying again
<BenHoltz> Sarvatt: upon looking in grub before its loading it doesnt loook like it took, pastebining now
<benholtz_broken> http://pastebin.com/B87g47Qr
<BenHoltz> ok i think i might have done it right... lets see here. >_<
<Sarvatt> nope :(
<BenHoltz> how long does the dmesg stay?
<BenHoltz> is it persistant through reboots?
<benholtz_broken> Sarvatt: try this one http://pastebin.com/vpyHk10K
<BenHoltz> it has stuff that was not befoee.. ;)
<BenHoltz> Sarvatt: any clues?
<BenHoltz> jcristau: any ideas?
 * BenHoltz points gun @ self
<BenHoltz> can someone help me?
<BenHoltz> ok, i give up....
<BUGabundo> :(
<Sarvatt> none of those dmesg's had drm.debug set.. couldn't sit here all night :(
<Sarvatt> ok so we need some *serious* testing of this xorg.conf.d stuff, tjaalton have you documented every change you've done somewhere? we should set up a wiki page about it to collaborate
 * Sarvatt tries to break things
<Sarvatt> ok xorg.conf.d stuff installed on 5 machines, lets see how this works out.
<Sarvatt> tjaalton: 10-synaptics.conf isn't getting installed, xorg.conf.d is located at /usr/lib/X11/, and the old udev rules are still getting installed in those packages and not removed on upgrade
<Sarvatt> only problems I've noticed so far
<jcristau> 2 is not a "problem"
<Sarvatt> yeah not really, I just thought it was supposed to be in /etc
<Sarvatt> other than that it's working like a charm. need to fix up the wacom udev rules and try that out
<jcristau> i think it's a bad idea to have the default input config in /etc
<jcristau> people can still tweak stuff in xorg.conf
<Sarvatt> would be nice if you could add snippets in /etc/X11/xorg.conf.d/ as well as the stock ones in /usr/lib/X11
<jcristau> that needs more code.
<jcristau> but, yes.
<Sarvatt> this is a *heck* of a lot better than asking people to do udev rules though
<Sarvatt> evtouch probably actually works now! :D
<jcristau> that's why i'm telling people to use the gnome dialogs instead, not udev rules.
<Sarvatt> if we do pick this up i'll volunteer to go through and translate a ton of old fdi stuff into snippets
<jcristau> sigh.  you're shipping a ton of fdi stuff for x config?
<Sarvatt> more like I'm trying to be helpful in any way I can, if its not wanted no sweat off my back :)
<jcristau> heh ok
#ubuntu-x 2011-03-21
<lucazade> Hi!  Can anyone enlighten me on this bug 726369?  There is also a video with the issue attached to bug report
<ubot4`> Launchpad bug 726369 in xorg-server "graphical glitches in menu (natty) (affects: 4) (heat: 47)" [Undecided,New] https://launchpad.net/bugs/726369
<RAOF> Hm.  That should probably be filed against xorg-server in Ubuntu :)
<RAOF> lucazade: Does that manifest with unity/compiz?
<lucazade> RAOF it manifests only with metacity.. with compiz is not visible
<RAOF> Yah, suspected as much.
<lucazade> tried clean installation on different machines.. same issue
<RAOF> How about if you turn on metacity compositing?
<lucazade> let me try!
<lucazade> still present
<tjaalton> i see that with savage
<lucazade> where is the issue? who is responsible?
<lucazade> which component i mean
<RAOF> Either X or the driver, I'd guess.
<lucazade> I can reproduce it with every gfx card (gts250, radeon 7500, gma500, vbox)
<lucazade> i've seen it when xorg 1.9.99 came out
<RAOF> By that I mean either X or the driver could backfill pixmaps.
<RAOF> gma500!  Lucky man :)
<lucazade> lol really lucky
<lucazade> pixman maybe?
<tseliot> RAOF: are we still using that patch to make X backfill pixmaps?
<tjaalton> wasn't it reverted upstream
<tjaalton> in 1.10-branch
<RAOF> tseliot: Nope.
<tseliot> ah, if it was reverted then I have no clue ;)
<tjaalton> hmm not that one, but post-1.10 there's this: http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.10-branch&id=edcf115800fef79d956c8e3d3e3c46a30cf77538
<cnd> bryceh, RAOF: I've had two people now complain about the new kinetic scrolling in synaptics
<cnd> because of the "scroll events as buttons" interface, it does wonky things when you have kinetic scrolling and then press a modifier key like ctrl
<cnd> if you see more people complain about it, we should consider disabling it by default in an xorg.conf.d snippet
<bryceh> cnd, ok
<bryceh> cnd, just "argh change!" type complaints, or definite usability regressions?
<cnd> there is a real bug that is exposed
<cnd> but there's no way to fix it
<cnd> other than completely overhaul scrolling in X
<cnd> I'll try to explain :)
<cnd> with kinetic scrolling, if you flick two fingers on a trackpad to scroll, the momentum continues the scrolling behavior for a bit
<cnd> so scroll button events are sent every so often, slowing down as though there's a friction force
<bryceh> ah
<cnd> if you flick like that, and the scroll is still going, then you press the ctrl button, something unexpected may happen
<cnd> like zooming
<cnd> to be fair, os x has issues here too
<cnd> for example, if you have a magic mouse with kinetic scrolling on
<cnd> you can flick it to scroll
<cnd> and move your mouse to a different window
<cnd> and the scroll will continue in the new window
<cnd> which is probably not intended
<cnd> it's just a corner case that shows how broken server side scroll handling is :)
<bryceh> yeah
<bryceh> mmrph threaded scrolling
<cnd> hopefully we can get utouch integrated into toolkits in the next cycle to fix this
<bryceh> cnd, for now could you add a note about this to the release notes?
<cnd> bryceh, how do I do that?
<bryceh> I agree at this stage it sounds unlikely to be easily fixable
<cnd> bryceh, there's one course we could do: disable kinetic scrolling by default
<cnd> but I'd only advocate that if enough people complain
<bryceh> cnd, its a wiki page just edit https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview and add a note in the appropriate section
<cnd> ok
<bryceh> or maybe add a section after Graphics and display
<bryceh> "Mice and Keyboards" or some such
<bryceh> would be nice to call it "Input devices" but that's probably too jargonny
<cnd> I wonder if it wouldn't be better to just throw it into graphics and display
<cnd> it's an X display system issue, though the categorization is jargony too
<bryceh> sure that'd be fine
<bryceh> I need to comb through that list and take out issues we've solved lately.  that should condense it into less of a wall of bullets
<cnd> heh
<bryceh> RAOF, what do you think we should do about bug #710762?  I'm still sort of on the fence
<ubot4`> Launchpad bug 710762 in xserver-xorg-input-evdev (Ubuntu) (and 1 other project) "Middle mouse button no longer works (affects: 3) (heat: 88)" [High,Triaged] https://launchpad.net/bugs/710762
<RAOF> So, we have the option of adding unnecessary latency to all mouse clicks if we turn emulation back on.
<RAOF> Or some people don't get middle-mouse clicking.
<RAOF> Actually, we had a third option, didn't we - quirk on emulation for known 2-button mice?
<bryceh> yeah
<bryceh> fwiw, given that there's been almost zero complaints since we made the change, I'm a lot less worried about if we just leave the change in
<RAOF> It's not exactly an obvious feature :)
<bryceh> I'm almost to a point of saying just plunk a comment about it in the release notes and call it done
<bryceh> if we have a way to quirk the 2-button mice, then maybe we could slap some bug handling directions in wiki for crafting quirks and leave it at that
<RAOF> That seems reasonable to me.
<RAOF> The qurik would be a udev tag + xorg.conf snippet, right?
<jcristau> 2 button mice exist?
<bryceh> RAOF, something like that
<RAOF> jcristau: Apparenty so.  Cannonical even sells one!
<jcristau> heh
<bryceh> http://shop.canonical.com/product_info.php?products_id=643
<tjaalton> bryceh: I'd go with that option (leave it as-is, add a not to the relnotes)
<bryceh> tjaalton, RAOF, ok if either of you can give me the details on how to do the quirks I'll take care of writing it up and closing out the bug
<tjaalton> the snippet is in the evdev commit
<tjaalton> ..and on the bug :)
<tjaalton> that's all there is, no need for udev rules
<RAOF> But that snippet will apply to everything, right?
<tjaalton> it could match the identifier
<RAOF> The udev rules are so that you can add a IM_A_STUPID_TWO_BUTTON_MOUSE tag and have the snippet only apply when that tag is found.
<tjaalton> but there is no way to know when to set that
<jcristau> RAOF: doesn't really matter, i think, people with multiple mice can live with the latency for the 3 button one
<tjaalton> automatically, i mean
<RAOF> tjaalton: Right.  We'd just accumulate a bunch of matches to apply that to.  Although if the xorg.conf snippet has enough data to weed those out by itself, that would be easier.
<tjaalton> RAOF: yeah, the same could be done just on the xorg.conf snippet. but if it's left for the user to set, we can just point to the generic one
<tjaalton> sigh @ spurious doubleclicks
<bryceh> what do we match on?
<tjaalton> MatchIsPointer
<tjaalton> is what the bug/commit has
<bryceh> no, how do we distinguish between a mouse that needs the snippet from one that doesn't?
<RAOF> But in this case, we'd want to match on a hardware identifier.
<bryceh> like, we know the ubuntu mouse needs it, so how do we identify when one of those is plugged in?
<bryceh> as opposed to requiring the user always having to manually paste the file in themselves
<tjaalton> MatchProduct
<bryceh> what's that match against?  lsinput out?
<tjaalton> for instance
<RAOF> tjaalton: How many product ids are going to clash?
<tjaalton> depends :)
<tjaalton> MatchUSBID uses ids
<tjaalton> MP the product name
<tjaalton> finer grained control with udeb tagging and MatchTag
<tjaalton> udev
<RAOF> Given that this mouse identifies itself as âLogitech USB wheel mouseâ, I feel confident in saying that matching on product name is likely to have overlaps :)
<jcristau> MatchProduct "PS/2 Mouse" ftw
<RAOF> Heh.
<tjaalton> yes, so if we really are going to ship a snippet for the two button mice, it should be by using udev & MatchTag
<tjaalton> but I thought it was about the general snippet for the relnotes
<bryceh> for the relnotes I'll just point to the bug report
<bryceh> or the wiki page
<tjaalton> the udev rule might even be upstreamable
<bryceh> but I've a feeling users are mostly going to consider "write xorg.confage" to be the same as not having a solution
<tjaalton> solution to what?-)
<bryceh> tjaalton, solution to their two button blues
<tjaalton> we can't please everybody
<bryceh> true, but we can choose whether to support the hardware we sell at canonical.com ;-)
<RAOF> That's easy.  We just ship an appropriate udev rule for it :)
<tjaalton> yes, so udev rule & xorg.conf snippet to evdev should cover it
<tjaalton> and that's easy to expand
<bryceh> alright great, what's the udev rule?
<seb128> bryceh, hey
<RAOF> I'd start with the rule in synaptics.
<seb128> bryceh, so that bug about memory usage issue on nvidia due to cairo 
<tjaalton> bryceh: I can create one, if only someone with the mouse can provide a dump of udev
<seb128> #725434
<bryceh> tjaalton, thanks
<seb128> bryceh, it's due to build cairo with gl
<bryceh> seb128, ok, you can close the bug report, probably not worth worrying about - seems to not cause any serious problems.
<seb128> bryceh, it's the second tradeoff we get from building cairo with gl (it also brings some extra things on the CD)
<seb128> bryceh, you think? it seems it's going to impact some users
<seb128> bryceh, I'm pondering suggesting we should roll back from that for this cycle
<seb128> while having wayland in universe is nice it's of no real user for most users
<seb128> seems the cost on the default installation is not worth the win
<seb128> like we impose extra depends on the CD and extra memory usage for some nvidia users just to be able to get something in universe that is of no real benefit to any user
<seb128> I'm open to comments from people there though or to discussion
<RAOF> I wouldn't have any qualms about dropping wayland from universe.  Then again, I didn't do the work to *put* it there :)
<bryceh> seb128, well, I'd have qualms, it was a lot of work to get it enabled
<RAOF> Although we'll have to deal with this cairo-gl problem sooner or later anyway, so it should be re-enabled once oneiric is open.
<seb128> bryceh, the work is not wasted, we can have wayland in a ppa this cycle and bring i back next cycle
<seb128> i->it
<seb128> it's not like the actual upload to universe what was costed much or that the review comments will not be useful for next cycle
<bryceh> seb128, no, it would be wasted; the whole point was to make it easy for people to install it, and making libcairo not have gl forces them back to rebuilding everything from git
<seb128> or to use a ppa?
<bryceh> no, a ppa wouldn't work
<bryceh> I mean, it has been too much effort to maintain it in a ppa for natty
<seb128> who is going to want to install something as new as wayland using a snapshot from a stable distro
<bryceh> every time libcairo has a change, it has to be re-updated in the ppa
<seb128> well, once natty turn stable it's not going to happen a lot
<seb128> you might have to 2 trivial uploads if we sru a fix or two
<bryceh> seb128, what are those depends you think it added?
<seb128> it seems weird to me that people who want to try wayland will be happy to get an old version rather than a daily or recent build
<seb128> I'm not on my natty box right know to check, we tracked it with pitti after a3, some extra gl things
<seb128> let me check if I find the irc log from irclogs.u.c
<bryceh> seb128, the thing they're happy about is not having to rebuild mesa, cairo, etc. etc. from git.  It's not that they prefer an old version, it's that there is a packaged version at all
<bryceh> seb128, further, this is viewed by upstream as a contribution ubuntu has made for upstream; if it is disabled after all then it makes us look silly
<RAOF> Do we have any idea of what the memory is used for?  IIUC, applications need to explicitly select a GL surface for any GL to be used - is this just overhead from *linking* to nvidia's libGL?
<seb128> ok, I don't find it in the log, it was something libglish
<seb128> one of the libcairo2 libelg or libgl depends I guess
<seb128> bryceh, ok, fine, I will think about it, you seem to really care about it
<bryceh> seb128, ok thanks
<seb128> I still think it's not a fair tradeoff for our users, we impact the default installation and nvidia memory use for something which is not user ready
<RAOF> seb128: I'd guess it's libegl1-mesa that you're thinking of.
<seb128> those who want to try wayland are probably really tech users
<seb128> RAOF, could be yes
<bryceh> RAOF, I've wondered the same - it seems there may be a real bug there, non-GL apps shouldn't be affected by the mere presence of GL functionality
<seb128> I can't really check now if that would be installed without cairo bringing it in
<RAOF> bryceh: Right.  There is a real bug there which we'll need to either fix, or ensure gets fixed, at some point fairly soon.
<RAOF> I'd be surprised if anything else pulled in libegl1.  I'm surprised *cairo* pulls in egl!
<seb128> ok
<seb128> so that was likely it
<seb128> is that any way we could figure if that memory use issue is affecting every nvidia users?
<seb128> and maybe to get if figured for natty?
 * RAOF hunts around for his spare geforce 6600
<seb128> I'm not sure we should spend time on that for natty rather than focus on unity
<seb128> but if that's affecting nvidia users and not only one of them I suggest that's something we need to address one way or the other
<RAOF> It looks like it should be easy to tell if it affects a given system, so I can check mine.
<bryceh> RAOF, tjaalton: https://wiki.ubuntu.com/X/Quirks#Input%20Quirks
 * RAOF wonders whether his freshly broken graphics are due to the card or the drivers.
<RAOF> Aaah.  I missed a power connector!
 * RAOF grumbles softly about the insane power requirements of gpus.
<bryceh> they may soon require a power supply of their own
<RAOF> This is an old card, too.
<RAOF> Merely a 7800GT.
<RAOF> Dear lord it's loud, too.
<RAOF> Hm.  Doesn't appear to like plymouth much, either.
<RAOF> Mmm, the glorious whiteness of vesafb.
<RAOF> :(  And it doesn't parse my edid.
#ubuntu-x 2011-03-22
<kklimonda> evening..
<kklimonda> any idea why I'm not seeing splash with nouveau? I get a scrambled screen - mostly black, with some random colors
<kklimonda> as soon X loads everything works fine
<kklimonda> ah, it's bug 723477
<ubot4`> Launchpad bug 723477 in xserver-xorg-video-nouveau (Ubuntu) "screen corruption instead of pylmouth on boot with nouveau (affects: 1) (heat: 159)" [Undecided,New] https://launchpad.net/bugs/723477
<RAOF> bryceh: Ok.  So, I too see a (smaller) memory delta (on amd64); my steady-state numbers change from ~500MiB to ~645MiB.
<RAOF> Hm.  And it looks like the mere act of loading nvidia's libGL dirties in excess of 4MiB of memory, doubling the dirty memory of my gnome-terminal.
<RAOF> bryceh: Looks like the mere act of linking to nvidia's libGL is going to increase the memory of the process by ~5MiB.  If cairo links to libGL, that's a lot of memory.
<bjsnider> why shouldn't it? it's not using the mesa libgl at all.
<bryceh> RAOF, could we prevent that from occurring with nvidia?  wayland won't work with nvidia anyway
<RAOF> bjsnider: You don't understand; that's 5MiB of *unsharable* memory.  If you have 30 processes linking to GTK you've uselessly eaten 150MiB of memory.
<RAOF> bryceh: We could get cairo-gl to dynamically load libGL when first constructing a GL context, I guess.
<bjsnider> RAOF, have you talked to nvidia about that?
<bryceh> anyway, need to get off the computer, bbl
<RAOF> bjsnider: No, I've only just noticed it.
<RAOF> bryceh: It's probably pretty easy to dynamically load libgl; I'll check it out.
<bjsnider> RAOF, surely that's not how nvidia _wants_ things to work
<RAOF> I can imagine reasons why nvidia would do that.
<bjsnider> RAOF, you're more qualified to imagine that kind of thing than i are
<RAOF> Specifically, runtime patching of code will cause that, and it's not unreasonable to do that in libGL (mesa did on i386, until I stopped it).
<bjsnider> RAOF, i'm sure if you notify aplattner he can either do something about it or explain why it works that way
<kklimonda> RAOF: hmm.. in my case it was more than 5MB I think.. I do remember that some basic Qt app I wrote used 45MB of ram, and 20MB came from one of nvidia libraries..
<kklimonda> but I've assumed I don't know how to read /proc/pid/smaps
<RAOF> kklimonda: Was that dirtied memory or a sharable library text?  nvidia's libGL is pretty big, and will show up as such, but should be sharable across all the processes linking to it.
<kklimonda> RAOF: right, I can't really remember right now - I'll check it out when I go back to nvidia.
<RAOF> Unless they've done something crazy like make a non-PIC libGL on i386.
<kklimonda> btw, is there something wrong with nvidia drivers that makes unity so slow on it?
<kklimonda> running dmesg takes seconds for example
<kklimonda> pretty much everything I do in terminal gets slowed down considerably the moment I start looking at it (it works fine when terminal is hidden)
<RAOF> Ah.
<RAOF> I'd guess you're hitting a font-rendering fallbakc.
<kklimonda> yeah, it's quite possible - at some point changing to "Best shape" gave me a lot of performance boost
<kklimonda> but when I tried doing that in natty it didn't help.. at least I don't remember the same boost :)
<RAOF> It's possible that switching your fonts will do somethnig, too.
<kklimonda> RAOF: http://paste.ubuntu.com/583614/ 
<kklimonda> Private Dirty: 16396 kB
<RAOF> Owch.  What process was that?
<kklimonda> gnome-terminal
<wgrant> RAOF: Hi.
<RAOF> wgrant: Howdie.
<RAOF> wgrant: After somethnig?
<RAOF> Other than a chat after a long period of no chatting? :)
<RAOF> Bah.  Dear Telstra: unless you're willing to buy out my existing phone contract you *definitely* won't be able to offer me a âfantastic deal on my mobile phoneâ.
<wgrant> RAOF: Sorry, back.
<wgrant> RAOF: Your 113_tls.diff in mesa has made it into xorg-edgers, and it breaks unity pretty badly (at least on r600g).
<wgrant> Is it meant to do that?
<RAOF> It is not.
<RAOF> What does it do?
<wgrant> Well, Unity basically doesn't render. It occasionally flickers up a very corrupt version of itself when hovered.
<wgrant> Normal compiz mostly works, except that some shadows are broken.
<RAOF> Hm.
<RAOF> And you're sure this is a tls problem?
<wgrant> (at least in the 20110318 xorg-edgers mesa build... I reverted the patch from that and it's all good again)
<RAOF> Oh.  Curses.
<wgrant> I might try building it with the patch locally, just in case. But the 20110316-20110318 diff is pretty minimal, apart from that patch, some 965 stuff, and some tiny refactorings.
<RAOF> wgrant: Are you on i386 or x86-64?
<wgrant> RAOF: x86-64
<RAOF> That makes it easier.  I *have* an x86-64 r600g system :)
<RAOF> Although I guess I could also break open the esprimo and throw in the radeon card.
<wgrant> It's a Radeon 5700 of some variety, FWIW.
<RAOF> Which, conveniently, is also what I have.
<wgrant> Excellent.
<RAOF> Oh, balls.  Something's broke in my monitor, and it's now sending invalid EDIDs.
<wgrant> :(
<wgrant> Sure it's not just X being really broken?
<RAOF> Nah; the kenel's throwing âchecksum invaliD!â into dmesg all the time.
<bjsnider> http://arstechnica.com/open-source/guides/2011/03/the-linux-graphics-stack-from-x-to-wayland.ars
<mvo> I get some really odd artifacts on my intel notebook with natty, looks like redraw problems, oddly enough with the unaccelerated desktop. 
<mvo> bryceh: are there any report on redraw artifacts on intel and noveau with the classic desktop? it happens for me on natty a lot when e.g. minimizing a window
<bryceh> mvo, 622068 725333 737967 are visual corruption bugs reported on -intel.
<mdeslaur> mvo: I see it, and kees sees it also
<mdeslaur> bryceh: ^
<mdeslaur> mvo: are you using metacity?
<bryceh> mdeslaur, hmm, didn't that get identified as a kernel bug and sorted out a couple weeks ago?
<mdeslaur> bryceh: I don't know...but I'm up-to-date
<mdeslaur> bryceh: it only happens with metacity, but it happened with my nvidia laptop and it happens with my new intel laptop this week
<bryceh> bug 717114
<ubot4`> Launchpad bug 717114 in xserver-xorg-video-intel (Ubuntu Natty) (and 4 other projects) "[i945gm] Screen Corruption with new Xorg stack with terminal programs (affects: 20) (dups: 3) (heat: 104)" [Medium,Triaged] https://launchpad.net/bugs/717114
<bryceh> set to fixed for linux on 3/18
<mdeslaur> bryceh: that's not the same issue
<mdeslaur> bryceh: I'll try and get a couple of screenshots...but am not sure under what to file the bug
<bryceh> mdeslaur, ok, mind digging up the bug report #?
<mdeslaur> bryceh: can I just file it under xorg until someone figures out what's causing it?
<bryceh> given this other one was a kernel issue, wouldn't you think yours is kernel too?
<mdeslaur> bryceh: you're just trying to get rid of me :)
<bryceh> hehe
<bryceh> mdeslaur, but no, if you feel there is value to having me involved in looking at it, go ahead and file against X, but I'm like 90% certain it's going to end up being another kernel issue
<bryceh> mdeslaur, I posted a list of other graphical corruption bugs to mvo up above, I'm going to forward them all upstream today, so if you file yours against xorg I'll send that one up too
<bryceh> even if it ends up being a kernel bug, when I upstream them they often will point out the patch for us
<mdeslaur> bryceh: does binary nvidia use the kernel?
<mdeslaur> bryceh: ok, let me reproduce and get a couple of screenshots, and I'll file it
<bryceh> it uses a lot less of the kernel than the foss drivers do
<mdeslaur> bryceh: bug 740387
<ubot4`> Launchpad bug 740387 in xorg (Ubuntu) "graphical corruption with multiple drivers and classic desktop (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/740387
<bryceh> mdeslaur, ah yeah that is quite different (and I think different from what mvo is mentioning)
<bryceh> mdeslaur, I would guess even if it looks similar, the issue on -nvidia and -intel could have different root causes.  Mind filing a second bug for the other machine?
<mdeslaur> bryceh: sure
<mdeslaur> bryceh: bug 740422 for issue on nvidia with nvidia screenshots
<ubot4`> Launchpad bug 740422 in xorg (Ubuntu) "graphical corruption with classic desktop (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/740422
<mvo> mdeslaur: yeah, I use metacity
<mdeslaur> mvo: are 740387 and 740422 what you are seeing?
<mvo> hold on a sec, let me check
<mvo> mine looks like this: http://people.canonical.com/~mvo/tmp/Screenshot.png
<mvo> except for the blur, I added that :)
<mdeslaur> mvo: looks similar
<mvo> indeed
<mvo> I have it on intel and noveau
<mvo> nouveau is not stable enough for me to run unity
<mvo> but that is a different matter
<mvo> mdz: thanks, I have a look at 740372
<bryceh> mdeslaur, mvo, do you recall about when you started seeing this regression?
<bryceh> trying to get a feeling for what kernel (or X) version brought the issue
<mdeslaur> bryceh: honestly, I'm investigating metacity now...I think it's a DX patch
<mvo> my gut feeling is the 1.9 - > 1.10 switch, but I may be wrong
<mvo> mdeslaur: interessting idea!
<tjaalton> is it the same corruption we discussed the other day?
<tjaalton> i'm seeing it with savage
<tjaalton> when opening menus etc
<bryceh> fwiw, I've seen something similar on -ati but it only shows up when launching URLs from xchat to firefox so dunno if it's the same issue.  Similar effect though (invalidly drawn areas of the region)
<bryceh> tjaalton, don't think so
<mvo> bryceh: this is what triggers it most reliable for me as well
<bryceh> that menu corruption was particular to -ati it seems (upstream has pointed to a kernel patch to revert)
<tjaalton> ah, looked at the screenshot, and it's not
<bryceh> I had been thinking perhaps the damage issue was a subset of the menu drawing issue since I started seeing both at the same time
<bryceh> but now I'm pretty sure they're distinct bugs
<bryceh> mdeslaur, should I hold off on upstreaming this bug?  (about to pull the trigger on it to go to -intel)
<mdeslaur> bryceh: yeah, you should probably wait a bit
<bryceh> alrighty
<mdeslaur> bryceh: I can't seem to reproduce it at the moment with the DX patches ripped out
<bryceh> mdeslaur, 06_Add_UXD_shadows_and_borders.patch ?
<mdeslaur> bryceh: maybe, I'm trying to figure out which one now
<mdeslaur> but that,s the one that I suspect
<bryceh> hmm, some of these metacity patches sound like they could have some performance implications
<AlanBell> wondering if someone could help me get a little further with bug 738330
<ubot4`> Launchpad bug 738330 in virtualbox-ose (Ubuntu) (and 1 other project) "Today's Natty update means no guest additions in virtualbox (affects: 9) (heat: 58)" [Undecided,Invalid] https://launchpad.net/bugs/738330
<AlanBell> this is the oracle virtualbox drivers, not the Free Software OSE ones - however the source is available and gets compiled with dkms I think
<AlanBell> the problem is an ABI issue with the new Natty xorg ABI 10 and the drivers
<jcristau> dkms is for kernel module, not X drivers
<tjaalton> so the guest-additions are opensource?
<tjaalton> if not, there's nothing we can do other than wait for oracle to fix it
<jcristau> tjaalton: virtualbox-guest-additions is in non-free in debian, so i guess not
<tjaalton> right
<AlanBell> interesting point about dkms, I was just reading up on that
<AlanBell> so it does build a video related driver, but I think that is the kernel part, so the xorg driver itself would be separate
<tjaalton> X.Org guests: support X.Org Server 1.10 pre-release and Ubuntu 11.04 Alpha. 
<tjaalton> from 4.0.4 changelog
<tjaalton> which means abi 9, so they just need to fix it
<jcristau> so they have both a closed and an open X driver?
<jcristau> sigh
<AlanBell> http://www.virtualbox.org/changeset/36301 does that look like the crucial change to you?
<AlanBell> jcristau: the source is all available
<AlanBell> the latest version comes prebuilt, the OSE version in Ubuntu lags behind
<jcristau> this stuff is so fucking broken..
<AlanBell> and unity only runs on the bleeding edge prebuilt version
<AlanBell> or did until recently :)
<tjaalton> AlanBell: so where is the vboxvideo_drv_110rc.so built?
<tjaalton> um, 110.so
<jcristau> AlanBell: "comes prebuilt" means without source then?
<AlanBell> jcristau: no, the stable release version is available built - just like anything else
<AlanBell> they don't have daily builds from SVN
<AlanBell> and the version in Ubuntu is older than the upstream stable release
<AlanBell> it really isn't much more insane than anything else out there tbh
<tjaalton> 4.0.4-dfsg-1ubuntu3
<tjaalton> don't see anything newer upstream
<tjaalton> 4.0.4 is the latest release
<AlanBell> ah, ok sorry, the latest is in Natty, but I am using a Maverick host
<tjaalton> virtualbox-ose-guest-x11 should depend on the correct abi
<tjaalton> what it supports
<tjaalton> not what it happens to be "built" against
<AlanBell> so for instant gratification I guess I compile from SVN and install those drivers in the guest Natty
<tjaalton> something like that
<speakman> Hi folks. Is there any tools to trace what's causing X to be extremely CPU intensive?
<speakman> I'm on a w3680 (6-core @ 3.33GHz) but I'm getting flashbacks from the mid -90.
<tjaalton> kill apps one by one, when it stops you have your culprit :)
<speakman> I've tried (of course) but it's still laggy no matter which apps are running
<speakman> I'm on two GPUs with four monitors if it may have anything to do with it. Both are Nvidia with the propretary drivers instaleld.
<tjaalton> likely does
<speakman> But anyway; is there a way to trace what's causing the X processes the CPU hogging?
<tjaalton> try a profiler
<speakman> There's no way to attach to the running X process?
<tjaalton> yes, but nvidia..
<tjaalton> besides, what would you benefit by hooking gdb to it?
<speakman> I've not mentioned gdb. But I thought there might be tools for profiling X.
<speakman> This can't be the only computer with X hogging the CPU?
<tjaalton> i said try a profiler
<tjaalton> there are tools
<tjaalton> i just don't have any docs handy
<speakman> is there any X profilers available?
<tjaalton> or try with a single gpu & monitor first
<tjaalton> why would x need a profiler of it's own?
<AlanBell> well virtualbox is now compiling away on my natty VM
<tjaalton> AlanBell: could you tell felix geyer about the issue?
<AlanBell> tjaalton: where do I find him?
<speakman> I just ran sysprof and it seems like nvidia_drv.so is the trouble
<AlanBell> nvm, devfx
<tjaalton> speakman: surprise :)
<tjaalton> it's also an unusual setup
<tjaalton> i guess
<speakman> tjaalton: not really... but now how to fix it :/
<bryceh> mdeslaur, good work narrowing down to patch 16; are you or someone you know going to disable that patch?
<bryceh> mdeslaur, if not I can take care of doing it
<bryceh> mdeslaur, have you also verified this was the cause of the -nvidia issue as well?
<mdeslaur> bryceh: I've pinged the author of the patch, let's see what he says
<mdeslaur> bryceh: I only tested it on -nvidia
<mdeslaur> bryceh: but will change the gconf key on my -intel laptop tomorrow
<AlanBell> yay, I have unity in 3d again, the virtualbox-ose-guest-x11 package in natty works just fine
#ubuntu-x 2011-03-23
<unity_supporter> Does anyone know whether the x-team is going to revert the intel i845 graphic driver back to intel or it is going to be fbdev like maverick (the mail archive is empty)?
<brobostigon> afternoonings everyone.
<brobostigon> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/715096
<ubot4`> Launchpad bug 715096 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[i945gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 22) (dups: 15) (heat: 233)" [High,Incomplete]
<brobostigon> is there anything more i can add to that bug to get things moving, i lost some serius work yesterday because of it.
<Sarvatt> RAOF: I had to refresh 113_tls.diff in edgers to apply to master, hope I didn't break it in the process -- http://bazaar.launchpad.net/~xorg-edgers/mesa/packaging/revision/79
<Sarvatt> RAOF, wgrant: radeon HD 5770 is fine with unity on edgers on i386, it must be amd64 specific
<Sarvatt> or it was fixed in the past few days of updates
<Sarvatt> multiarchifying mesa will be a fun adventure
<jcristau> Sarvatt: pretty much like anything involving mesa, right?
<Sarvatt> yeah, need to add guinness to the build-deps
<Sarvatt> RAOF: hmm, yeah, amd64 only is screwed with 113_tls.diff and git mesa
<Sarvatt> i386 sandybridge laptop is fine, amd64 one is trashed with unity. rebuilding without it to see if it fixes it just to be sure
<Sarvatt> yeesh, http://cgit.freedesktop.org/mesa/mesa/commit/?id=6c324777a685d28d0a81d23157e4863240552999 makes unity infinitely more usable on sandybridge
<Sarvatt> our 7.10 + that, no more 5 second waits to input text into the search popup
<Sarvatt> wish I caught that before feature freeze..
<jcristau> call it a bugfix
<vish> Sarvatt: make sure to mention that to didrocks or njpatel..  ;)
<Sarvatt> would be nice if sandybridge could go 5 minutes without a [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 69936, at 69936], missed IRQ? on 2.6.38
<Sarvatt> oh goodie, hangchecks look to be fixed in current linux master
<Sarvatt> wgrant: I backed 113_tls.diff out of mesa in xorg-edgers for now btw
<wgrant> Sarvatt: Thanks.
<LLStarks> hey bryceh, is nvidia-173 broken? it wants to remove a ton of packages.
<bryceh> haven't really looked at nvidia so far this week, but I see we have a large number of new bugs filed
<Sarvatt> yeah no nvidia-96 or 173 for natty
<LLStarks> can i just use the binary from the nvidia site?
<LLStarks> nouveau 3d is busted on this box. can't load unity.
<bryceh> LLStarks, most likely won't help
<LLStarks> can't brute-force it?
<Sarvatt> it wont work, and it'll break things when you do get it installed to boot
<bryceh> LLStarks, with the IgnoreABI stuff?  Not sure that's suitable in this case
<LLStarks> how about edgers?
<bryceh> I suspect only downgrading xserver would be sufficient to make 173 work
<LLStarks> that's a bit much since i'd have to downgrade everything else. what's killing 173 atm?
<tjaalton> the fact that it doesn't work with xserver 1.10
<RAOF> Sarvatt: Radeon HD5xxx works fine here with mesa master + the tls fixes + amd64?  I presume that the problem is in the particulars of 113_tls.diff; it probably needs to be updated for master.\
<LLStarks> is this something that will be fixed or just temporary?
<tjaalton> depends on nvidia
<LLStarks> wow. way to go nvidia. leave legacy support high and dry. are they finally deprecating the two?
<LLStarks> i hope edgers nouveau will work with unity.
<LLStarks> *crosses fingers*
<tjaalton> it's the same story every cycle, they are low prio
<LLStarks> ah. then that's okay.
<bjsnider> LLStarks, typically those old drivers are updated within 24 hrs of a new ubuntu release but not before. they just don't have the manpower for it
<LLStarks> heh\
<LLStarks> grrr. software rasterizer only? gallium y u no work?
<RAOF> With nouveau?
<tjaalton> you need libgl1-mesa-dri-experimental for nouveau
<LLStarks> yeah
<LLStarks> it is
<LLStarks> installed
<LLStarks> i have an nv34
<LLStarks> fx 5200
<bjsnider> new hardware would be a better idea, if possible
<LLStarks> this is just a screw-around box
<RAOF> Time for everyone's favourite LIBGL_DEBUG=verbose!
<LLStarks> lemme paste
<blah> libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
<blah> libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
<blah> http://pastebin.com/Snc93SFK
<LLStarks> really hofstra? really? you didn't give that pc a hostname?
<LLStarks> whatever
<LLStarks> raof, how's it look?
<RAOF> LLStarks: That doesn't seem to include the LIBGL_DEBUG=verbose output?
<blah> libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
<blah> libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
<tjaalton> LLStarks: do you have nouveau kms on?
<blah> libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
<blah> not sure
<blah> think so
<blah> i had a pretty plymouth
<tjaalton> post the full server logfile somewhere
<blah> k
<blah> http://pastebin.com/188iEmc8
<tjaalton> [    22.034] (EE) [drm] failed to open device
<tjaalton> so you are using vesa..
<tjaalton> nouveau blacklisted perhaps
<blah> how can that be? i had a native plymouth
 * blah checks
<tjaalton> that's grub2 doing the mode handover
<blah> ah
<blah> 	Kernel modules: nouveau, nvidiafb
<blah> \nothing listed in use
<blah> OH
<blah> wait
<blah> nvidia-installer-disable-nouveau.conf
<blah> lol
<blah> wouldn
<blah> work before that either though
<blah> brb
<tjaalton> you're on the x team and didn't even check your logfile >;)
<LLStarks> yeah, i had the nvidia installer blacklist.
<LLStarks> using nouveau now
<tjaalton> the symlink is probably listed as a conffile, so a normal removal of the nvidia package doesn't delete the file
<LLStarks> still no unity
<jcristau> i didn't think you could have symlinks as conffiles
<tjaalton> jcristau: dunno then, could be wrong
<jcristau> or me.
<tjaalton> at least nvidia-current.conffiles doesn't list it
<LLStarks> okay, lemme paste a new xorg log.
<tjaalton> why?
<LLStarks> tjaalton, this was the nvidia.com binary
<bjsnider> nvidia-current does not install that file, nore create any such link. it does blacklist nouveau by creating another conf file
<tjaalton> LLStarks: ok, you lose then
<LLStarks> because, unity doesn't load and the desktop icons just flash
<bjsnider> that file was probably created by nvidia's installer, which he shouldn't be using
<tjaalton> nvidia-graphics-drivers.conf -> /etc/alternatives/nvidia_modconf
<tjaalton> that's in /etc/modprobe.d
<tjaalton> here
<tjaalton> LLStarks: what was the name of the file?
<LLStarks> it didn't work before either.nvidia-graphics-drivers.conf 
<LLStarks> ack
<LLStarks> nvidia-graphics-drivers.conf 
<LLStarks> in modprobe.d
<tjaalton> nvidia-current does install that file
<bjsnider> that file is created by ubuntu, but the file mentioned by blah isn't
<tjaalton> so the nvidia.com binary creates the same file? hard to believe
<bjsnider> the file he mentioned was called nvidia-installer-disable-nouveau.conf
<LLStarks> wait. one sec.
<tjaalton> ok missed that
<LLStarks> wait, it was disable nouveau or what you said
<LLStarks> not the nvidia-graphics-drivers
<tjaalton> ok then, so created by the nvidia installer
<LLStarks> sorry for the brainfart
<bjsnider> LLStarks, you used the nvidia-installer?
<Sarvatt> LLStarks: I had to disable nouveau_vieux in edgers for the past few uploads because the build is broken
<blah> new xorg: http://pastebin.com/xk0K91j6
<Sarvatt> should be fixed in tomorrows upload
<blah> bjsnider, i tried it. didn't get past blacklisting nouveau.
<blah> libGL: OpenDriver: trying /usr/lib/dri/tls/nouveau_dri.so
<blah> libGL: OpenDriver: trying /usr/lib/dri/nouveau_dri.so
<tjaalton> Sarvatt: this uses nouveau_dri, not vieux
<blah> i think everything but unity-3d works fine now
<tjaalton> blah: everything looks normal there
<LLStarks> there's also the well-documented graphical corruption
<LLStarks> but that's another day, another battle
<LLStarks> thx
#ubuntu-x 2011-03-24
<lucazade> hi! I've seen that reverting to xorg 1.9 in natty solves bug 726369 
<ubot4`> Launchpad bug 726369 in xorg-server (Ubuntu) (and 2 other projects) "graphical glitches in menu and metacity (natty) (affects: 5) (heat: 28)" [Undecided,Confirmed] https://launchpad.net/bugs/726369
<lucazade> is there any proper fix planned?
<tjaalton> sure, when it's available
<lucazade> is there a bug bug upstream to follow?
<tjaalton> dunno
<lucazade> thanks
<tjaalton> probably https://bugs.freedesktop.org/show_bug.cgi?id=34427
<ubot4`> Freedesktop bug 34427 in Server/general "Graphical corruption when opening windows" [Normal,New]
<lucazade> really close to my issue.. but it is seems that bug occurs only when composite is enable. Here is the opposite, infact i see this also in gdm
<lucazade> if I enable compiz is no more present
<lucazade> anyway i get the same garbled frame like this bug report
<lucazade> thanks for updating bug tjaalton ... going to try to disable composite extension in xorg.conf
<tjaalton> would be more helpful to try 1.10 again with that commit disabled
<tjaalton> and report back if it helps or not
<lucazade> yes with 1.10
<lucazade> should i apply also the patch proposed or ubuntu xorg 1.10 is already patched?
<tjaalton> which proposed patch?
<lucazade> https://bugs.freedesktop.org/show_bug.cgi?id=34427#c13
<tjaalton> oh, that's the one that backs out the commit
<ubot4`> Freedesktop bug 34427 in Server/general "Graphical corruption when opening windows" [Normal,New]
<tjaalton> so yes
<lucazade> ugh!
<lucazade> not an easy road
<tjaalton> you haven't built debs before? then don't bother, it'll probably get reverted sooner or later
<lucazade> yes i've built some stuff.. but xorg is a bad beast
<tjaalton> and tbh I've seen it too, with savage
<tjaalton> it's just the server
<lucazade> ah ok
<tjaalton> drop the patch in debian/patches, add it to d/p/series and build
<lucazade> in xserver-xorg-core ?
<tjaalton> xorg-server is the source package
<lucazade> ok .. i'll try to do something ;)
<tjaalton> i'll try it myself some day if nothing else
<mdeslaur> bryceh: for #553789, could we at least quirk off accel (like this: http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-drv-nouveau.git;a=blob;f=nouveau-nva3-noaccel-info.patch;h=ddd6586069dc3558af30a20d17589e19bf42bfb8;hb=HEAD)
<Sarvatt> we weren't doing that already? we really need to be
<tjaalton> yep
<mdeslaur> tjaalton: yep we're doing it already, or yep we need to be doing it?
<tjaalton> "need to be.."
<tjaalton> I'll push that to git for now
<Sarvatt> tjaalton: that patch just adds info, the actual quirking is done in a kernel patch
<Sarvatt> I could swear we quirked them to noaccel shortly after lucid..
<Sarvatt> but I cant find it
<tjaalton> oh, heh
<tjaalton> of course, duh
<tjaalton> http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=blob;f=drm-nouveau-nva3-noaccel.patch;h=7dd9678f459282b5128dfa3d6cb4ed40b8cea0a7;hb=refs/heads/f14/master
<Sarvatt> https://bugs.freedesktop.org/attachment.cgi?id=44779 yay nouveau_vieux builds again
<Sarvatt> http://kernel.ubuntu.com/~sarvatt/2011Q1/ -- if anyone else wants kernels that actually work on sandybridge :P
<tjaalton> not available yet :/ (the hw)
<Sarvatt> waiting for lenovo?
<Sarvatt> wonder how much shipping would be to finland.. lol
<tjaalton> hehe
<tjaalton> well, a new desktop & server too
<tjaalton> why not replace them all at once
<Sarvatt> sandybridge desktop stuff isn't available in finland? how the heck?
<tjaalton> the mb availability is still shown as "in a few weeks"
<tjaalton> they were available before the flaw was announced
<tjaalton> shipments should've started on week 10, but..
<Sarvatt> oh dang
<Sarvatt> bryce got his replacement fixed motherboard already so hopefully wont be too much longer over there
<tjaalton> my core2duo is still ok though, but would like to build the server asap :)
<Sarvatt> mesa builds in 8 minutes on a i7-2600 :)
<tjaalton> heh, even with current packaging..
<bryceh> Sarvatt, yep, and I'm booted on the new board and sent the old one out via ups today
<Sarvatt> bryceh: think its too late for an intel-gpu-tools update?
<Sarvatt> didn't realize the one in ubuntu was so old, no wonder I have to run all  the error states from the kernel through intel_error_decode :)
<tjaalton> there's also libx11 1.4.2 waiting in git.. forgot to upload it
<tjaalton> earlier
<bryceh> Sarvatt, would be nice to get that up to date
<Sarvatt> I added a get-orig-source target in the rules for edgers intel-gpu-tools packaging since they never release tarballs, makes it a lot easier
<Sarvatt> ok I'll package it up, there's actually a bug requesting a recent bug fix commit in it too
<bryceh> ok
<Sarvatt> funny, the one in natty is exactly 1 year old today
<bryceh> I think it's probably very low risk of regression so might be includable in beta.  In any case would be nice to have it post-beta for dealing with gpu lockups
<Sarvatt> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/?id=56167d8bfd7dcd6959e3f0465b09833f2906baec
<Sarvatt> that may be a problem :)
<Sarvatt> so basically we want to just capture the error state from the kernel and drop all the intel_gpu_dump handling
<Sarvatt> makes sense, I haven't looked at a dump since the middle of maverick since all the info is in the intel_error_decode output and then some
<bryceh> yeah that's a good point
<bryceh> I haven't been attaching those to upstreamed bug reports, just because they're too dang big
<bryceh> plus I know ickle doesn't seem to care about the intel_gpu_dump output
<bryceh> maybe I should rejigger the apport hook to use the kernel error codes
<Sarvatt> the act of dumping it repeatedly that has been happening sometimes has triggered bugs on its own too
<tjaalton> bryceh: did you see my comments on #u-d re: xorg?
<bryceh> tjaalton, yeah, you think we should omit it for armel and powerpc?  I wasn't sure whether it's valid there but guessed maybe?
<tjaalton> so, is qxl useful on powerpc or armel, and use tabs instead of 8*space in vars*
<Sarvatt> armel vars needs a major overhaul
<Sarvatt> but I have no clue what exactly they'd want
<tjaalton> aiui it's a serverside package?
<bryceh> well, I suppose people can always just ask for it if they need it.  Deleting.
<Sarvatt> ppc64 would be the only one they'd ask for it on if they even care (between that and powerpc)
<bryceh> ok changes pushed
<Sarvatt> the arm guys bypass the metapackages because they dont want to pull in all that crap that'll never get used on arm though
<tjaalton> yeah
<jcristau> i suspect arm should just pull in fbdev
<tjaalton> and -dove, I hear
<bryceh> jcristau, yeah I prompted the arm guys to give me a list of the drivers they care about a while back, but they just seemed confused
<jcristau> lool said nobody worked on dove in years
<tjaalton> which is just another framebuffer driver i guess
<tjaalton> jcristau: heh, ok, they still use it though
<jcristau> ok
<Sarvatt> bryceh: me too, every time I hear complaining about it :P
<bryceh> arm == fun
<bryceh> ok, speaking of fun, need to deal with a busted main water line.  be back in a bit
<tjaalton> before;  40 files changed, 19020 insertions(+), 16611 deletions(-)
<tjaalton> current; 40 files changed, 10395 insertions(+), 7324 deletions(-)
<tjaalton> been splitting the diff between sis and winischofers sisfree..
<tjaalton> still some way to go :P
<Sarvatt> I spent a week doing that before saying screw it
<tjaalton> hehe
<Sarvatt> well trying to forward port the sis751 driver to the current days
<tjaalton> well, I won't go all the way, just so that the diff is easier to read
<tjaalton> just reorganizing the functions in sis_driver.c helped a lot
<tjaalton> the premium and intel patches on top of sisfree are a lot easier to review
<tjaalton> and airlied said it would probably be ok to just start from there and clean up the driver, but this way at least some of the history is preserved
<bryceh> ok water ON
<tjaalton> *flushhhh*
<cnd> bryceh, do you remember if you pulled my latest synaptics change?
 * cnd is checking lp
<lool> Sarvatt, bryceh: Ah since you ask, there seems to be renewed interest for an imx51 fb driver which apparently does improve performance; it's another fork of fbdev
<lool> But I don't think we have anything current in archive
<cnd> bryceh, http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-synaptics.git;a=commitdiff;h=bdec4bb6bb291cd893015ff1496b687e484d8e01;hp=37d215c7e1cb11aadf7f3b528296695b84c794b9
<cnd> I was hoping it would get in before beta 1, but if it's too late it can wait
<cnd> I think there was something else I was meaning to get pushed too, let me try to find it
<cnd> bryceh, ahh yes, server: http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blobdiff;f=debian/changelog;h=21d73c51bdce83b440ce91d0ad48827c6cac27dc;hp=95f3efc7f801f291875a721122e6d9054f7391da;hb=debf2e97639978400e3643d0dbeecbf1a8194c3c;hpb=6995430054b22d636694b16316e88d7dc0e5cf33
<bryceh> cnd, ok is that first one for the mini v touchpad issue?
<cnd> no, I haven't got to that yet
<cnd> it's just a general MT fix for synaptics semi-mt trackpads of all sorts
<cnd> neither of these fixes *must* go in for beta 1
<bryceh> lool, ok too late for natty though (at least, for beta).
<cnd> but it would be nice :)
<bryceh> ok well synaptics is minor, I doubt pushing that in would be a problem
<cnd> bryceh, I hope to have a solution for the dell mini trackpads for beta 2
<cnd> it's been sidetracked by other issues
<bryceh> that git commit is rather lengthy, although most of that seems just patch goo
<cnd> yeah, it mostly is
<bryceh> ok, builds fine.  have you tested this change on much hardware?
<cnd> it's been sitting in our utouch ppa for about a week or two
<cnd> and there's at least a handful of us using that
<cnd> I have such a device
<cnd> bryceh, I can get you a cleaner patch if you would like to review it
<Sarvatt> hrm vblank_mode=0 glxgears triggers a steady stream of [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 69936, at 69936], missed IRQ? on sandybridge 100% of the time with mesa 7.10.1
<cnd> bryceh, http://paste.ubuntu.com/585039/
<bryceh> cnd, ahh much nicer
<bryceh> was trying to eyeball what had changed about the case statements
<cnd> yeah
<cnd> it gets tricky with the patches
<bryceh> ok, well if you've been running it on some hardware I'll trust it's not got obvious regressions
<bryceh> keep an eye on the bug tracker the next couple days but I'll go ahead and push it
<cnd> ok
<cnd> the xserver one, maybe we want to push that soon after beta 1
<cnd> so it can sit in the archive a while
<cnd> just to be sure
<bryceh> -synaptics pushed
<cnd> it has a higher potential for regression
<bryceh> cnd, yeah sounds like a good plan, I was thinking along the same lines
<cnd> though it also has been in testing in our team for about two weeks
<bryceh> cnd, I *might* have another xserver patch going in today; if so I will slip this in with that
<lool> bryceh: Yup; just mentioning it because we were on the topic of xorg drivers for ARM
<bryceh> lool, right
<lool> bryceh: I didn't even run it, but I'm on #EFIKAMX, and there was a lot of rejoicing when they managed to improve some 2D pathes
<cnd> bryceh, ok
<cnd> thanks!
<bryceh> lool, I talked about this with Tobin (who had brought the topic up of why so much X stuff rebuilds when arm images are being cooked), and slangasek, and I showed them the list of drivers we build for armel, but I gather it's outside their area of expertise.  You probably would have the strongest clueage here
<bryceh> lool, http://paste.ubuntu.com/585049/ is what we're carrying for armel
<bryceh> lool, I think most of those drivers are way obsolete in general, and particularly are irrelevant for arm, but don't want to remove stuff without someone conversant in arm video bits giving some direction
<bryceh> lool, possibly beta-eve is not the right time to make changes though :-)  But would be good to know what we could try dropping for post beta or even post-natty
<lool> bryceh: This is correct; I would keep only fbdev; I don't even think vesa is relevant
<lool> bryceh: Technically, dove has a PCI bus
<lool> bryceh: So one could build these
<lool> Err use these
<bryceh> lool, I know some of these drivers are used for virtualization (-cirrus) or for specialty devices (-sisusb is used for some usb video cases).  Are those potentially of any value on arm?
<lool> bryceh: Given that these drivers are very rarely used, that ARM boards rarely have a PCI bus, and that even when they do you usually have embedded graphics which you want to use, I think it's reasonnable to propose dropping them
<lool> bryceh: For virtualization, qemu emulates real hardware: either OMAP fb which has special packages in the archive AFAIK, or a regular fb (as in the case of versatile/vexpress); we currently lack a PCI bus for our emulated boards, except the frankenstein versatile which we should drop; I could check whether it can use cirrus
<lool> I'd be surprized if that's the case though
<bryceh> lool, ok sounds like a plan.  Is there a mailing list that would be appropriate to propose this on?
<bryceh> lool, or would it be better to just drop stuff post-beta and see if anyone raises issues?
<lool> bryceh: debian-arm is very on topic for this, but then Debian might request to keep them as they theoritically oculd be used on some boards
<lool> (back in 2min)
<jcristau> we could keep building the drivers, but not have xserver-xorg-video-all depend on them
<bryceh> jcristau, yeah that's sort of what I'm thinking
<bryceh> so folks could still manually install them if needed
<jcristau> right
<bryceh> and bubble up bug reports if/when it's worth re-adding them
<bryceh> lool, jcristau, ok thanks.  I'll post to debian-arm and follow up post-beta with some changes
<lool> back
<lool> jcristau: That's sensible in any case; I thought that was the case already
<jcristau> it's freaking awesome.  xserver-xorg-video-all on armel depends on a lot of useless drivers, but not on omapfb or glamo
<lool> I actually recall dropping drivers on armel in Ubuntu a while ago hmm
<lool> ah no, it was on lpia
<lool> (or rather lpihaha)
<bryceh> heh
<lool> bryceh: One thing you need to be aware of is that the ARM drivers also often lack autodetection in the server
<bryceh> mm
<lool> bryceh: That is, if you don't have xorg.conf, the right drivers might not get selected
<lool> there was some work in Ubuntu specific patches a while ago, but I'm not sure how far it went
<bryceh> lool, due to lack-o-pci-bus ?
<jcristau> yeah autodetection is only there for pci and sbus
<lool> bryceh: That's right
<bryceh> lool, yeah I remember chatting with ncommander about that; thought he'd come up with something workable?
<lool> there's debian/patches/111_armel-drv-fallbacks.patch
<lool> it seems to poke /sys and select between imx, dovefb, omapfb and fbdev
 * bryceh nods
<lool> I suspect the fbdev fallback is missing, and I'm not sure the two OMAP drivers are tried, but that seems good enough
<bryceh> looks like that is enabled in the xserver too... I take it it doesn't work universally on arm?
<lool> bryceh: Sorry, I don't understand what you mean
<lool> debian/patches/111_armel-drv-fallbacks.patch is in xorg-server
<bryceh> lool, sorry, I mean I take it that it doesn't provide automatic detection in all cases on arm?
<jcristau> lool: fbdev is added as a fallback on all archs already
<jcristau> well all linux archs
<lool> jcristau: I fear it's patching out the fallback
<lool> http://paste.debian.net/111883/
<jcristau> oh, crap, yeah.
<lool> by default there's matches[i++] = xnfstrdup("fbdev");
<lool> but it's #else-d out
<lool> and only in the else statement
<jcristau> right, sorry, i missed that on first read
<lool> bryceh: The default is fbdev, which is sensible on ARM
<lool> bryceh: So it's not that bad
<lool> the only issue I see here is that there might not be a fbdev fallback when you're expected to have the optimized driver
<jcristau> http://paste.debian.net/111885/ then?
<lool> bryceh: After some grep-ing, I confirm that there is proper OMAP DSS emulation, but I couldn't confirm for versatile which has PCI
<lool> jcristau: looks good
<lool> bryceh: Ah found it, so no, it's not using PCI (cirrus or whatever), but a specific LCD controller
<lool> bryceh: So I'm not aware of anybody using PCI drivers on ARM right now  :-0
<bryceh> lool, ok
<RAOF> Sarvatt, tjaalton: For what it's worth, nva? accel isn't quirked off in f15.
<tjaalton> RAOF: they have two months until the release, so plenty of time to disable it again..
<RAOF> This is true.
<tjaalton> and people who might crack it during that time ;)
<RAOF> Also true :)
<tjaalton> :)
<bryceh> jcristau, btw thanks for the patch to patch 111.  it looks suitable to me.  lool any reservations to having that change to patch 111?
<bryceh> ok, well I'll queue it for post-beta-1
<Sarvatt> ah hah, I can reproduce https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/739801 and it is specific to mesa 7.10.1
<ubot4`> Launchpad bug 739801 in xserver-xorg-video-intel (Ubuntu) "[sandybridge-gt1] GPU lockup (IPEHR: 0x02000004) (affects: 1) (heat: 8)" [High,New]
<Sarvatt> that apport hook is firing way more than it should, get crash dumps in /var/crash every 4 seconds or so while its playing
<bryceh> sweet
<lool> bryceh: Nope, seems fine; thanks
<Sarvatt> not even really hung, things are fine once you kill firefox/chromium
<lool> bryceh: thanks a lot for caring for ARM  :-)
 * lool waves and goes afk
<popey> bryceh: just fyi, i tested bug 630203 on natty, it's current expired but you asked for more info, so i added it
<ubot4`> Launchpad bug 630203 in xkeyboard-config (Ubuntu) "Macintosh keyboard layout is wrong (affects: 2) (heat: 12)" [Undecided,Expired] https://launchpad.net/bugs/630203
<bryceh> popey, ok thanks
<popey> bryceh: also, dunno if it's related but bug 742120
<ubot4`> Launchpad bug 742120 in gnome-control-center (Ubuntu) "Square blocks where text should be (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/742120
<popey> almost certainly not, but i got to it trying to fix the kb layout
<Sentynel> hi guys, anybody know if there are issues building the (official) nvidia driver modules with the gold linker? I'm getting some odd issues with X not starting newer kernel versions and I was wondering if it might have started when I switched to gold
#ubuntu-x 2011-03-25
<RAOF> Not that I'm aware of; we use the gold linker by default and nvidia seems to run, mostly :)
<Sentynel> bollocks, there goes *that* theory
<Sentynel> soo, any other ideas why my system won't start with a kernel version later than 2.6.35-24?
<Sentynel> in anything later than that it shows the kubuntu boot screen, then goes to a plain blue screen and locks up.
<jcristau> RAOF: gold by default?
<bjsnider> Sentynel, did you try to boot the offending kernels without the blob? did you check the logs?
<RAOF> jcristau: I think so?
<Sentynel> bjsnider: it boots fine on nouveau
<Sentynel> I've looked at the logs and not found anything especially illuminating, but I may not have been looking in the right places
<jcristau> i think debian still has ld -> ld.bfd at least.  maybe doko made the switch in U.
<Sentynel> gold is optional in ubuntu
<Sentynel> binutils-gold package switches the symlink to gold
<RAOF> Yeah.  After investigtion, binutils ships both bfd and gold, but ld points to ld.bfd.  We've got some of the gold DSO linking stuff, though, which was what confused me.
<Sentynel> hi again guys, quick update before I go to bed
<Sentynel> gold *is* the problem
<Sentynel> switched the symlink back and had dkms rebuild the module and lo and behold it booted fine
<RAOF> Hurray!
<RAOF> Perhaps another interesting test would be to rebuild the *kernel* with gold (if you haven't already tried that); it would not blow my socks off to discover that gold and bfd aren't 100% interoperable :)
<Sentynel> I've heard somewhere already that gold won't successfully link kernels
<Sentynel> which is probably what twigged me to wonder if that was the issue here
<RAOF> Well, then.  Trying to link kernel modules with it seems like asking for trouble :).
<Sentynel> apparently so
<Sentynel> didn't even cross my mind before
<Sentynel> but I was discussing gold the other day, and accidentally tried to boot a broken kernel version this evening
<Sentynel> ach, well, I know what the issue is now, I can turn gold on and off as needed
<Sentynel> cheers for the help guys
<ricotz> RAOF, hello
<ricotz> RAOF, is it still possible to update libxfixes in natty to 4:5.0-1?
<tjaalton> why do you need it?
<ricotz> gnome-shell seems to need it
<tjaalton> i thought g-s had plenty of needs that can't be fulfilled in natty
<ricotz> i am not sure about the consequence of updating xfixes in last minute
<ricotz> tjaalton, actually this is the first besides nm 0.9
<tjaalton> file a FFE and we'll see
<ricotz> tjaalton, hmm, might be the best
<RAOF> ricotz: What does gnome-shell use in the new libxfixes?
<ricotz> RAOF, i havent looked into it yet, fredp wrote it is needed for "pointer barriers"
 * RAOF can only think of pointer-barriers, but that's not in a released X server.  Maybe there are older changes I've forgotten, though :)
<RAOF> I hope they don't expect to *use* them; those patches weren't in 1.10 :).  I'm not even sure they're in master, actually.
<ricotz> ok, i will see how it works without the new version
<RAOF> At least you won't lose any functionality by patching that out :)
<RAOF> ricotz: Pointer barriers *haven't* been implemented on xserver master; if they're using them in gnome-shell, then either (a) redhat is shipping a server which supports protocol upstream doesn't or (b) they're not actually testing it :)
<ricotz> RAOF, ok, thank you
<RAOF> s/redhat/fedora/ to be strictly accurate, I guess :)
<bjsnider> ricotz, is the gnome 3 ppa installable and usable right now in natty? some of the packages failed to build
<Sarvatt> ricotz: want me to put new fixesproto and libXfixes in xorg-edgers to copy over or anything?
<ricotz> bjsnider, it is usable with care ;), i am using gnome-shell and its needed deps, using the whole stack caused me some trouble some while a ago and reverting was a pain ;)
<ricotz> Sarvatt, upstream said it isnt really needed, i think it is ok for now
<ricotz> actually i was excepting to have it with edgers already :P
<Sarvatt> argh ok, full screen flash on sandybridge in natty doesn't work, with xorg-edgers it works. just upgrading libdrm and intel on natty it doesn't work, just libdrm and mesa doesn't work. nothing really changed in xserver 1.10 branch. if libdrm + intel + mesa doesn't work next the only other possibility is pixman
<Sarvatt> oh wait, hello mr. ia32-libs
<Sarvatt> containing a 24 week old mesa
<mdeslaur> die.ia32libs.die.die.die
<Sarvatt> 64 bit flash plugin is fine, all signs point to ia32-libs
<ricotz> Sarvatt, yeah, the ia32-libs package should go
<ricotz> the multiarch transition might be usable soon
<Sarvatt> we *seriously* need that updated in natty, I'm scared to think how many bugs are root caused by this with how much mesa has changed
<ricotz> Sarvatt, i see
<Sarvatt> there is a mesa 7.9 git checkout in our ia32-libs currently
<ricotz> ok
<Sarvatt> no r600g change, no TLS fixes, no functional sandybridge 3D support
<Sarvatt> we disabled DRI completely on sandybridge in maverick because it was so bad in maverick's mesa thats in ia32-libs :(
<ricotz> Sarvatt, i have uploaded new packages and removed the sanity check, i hope this works
<Sarvatt> ricotz: oh I'm sorry man, I meant ia32-libs in natty needed to be updated, the ones in xorg-edgers actually work because you've updated them!
<ricotz> Sarvatt, actually the natty one failed everytime
<ricotz> bjsnider, any luck with gnome3? ;)
<Sarvatt> ia32-libs 20090808ubuntu9+natty~xorgedgers3 is in the PPA
<ricotz> yes :(
<Sarvatt> lets see, its easy enough to add edgers and just downgrade ia32-libs to natty to be sure
<Sarvatt> ah that one was built on 14-Nov-2010
<ricotz> grrr
<Sarvatt> ricotz: xorg-edgers with natty's old ia32-libs = gpu hung, xorg-edgers with the november ia32-libs = fine
<ricotz> Sarvatt, ok, still it's old :/
<Sarvatt> yep but the 7.10 and newer libdrm in there is enough to "work" at least to verify its the problem
<ricotz> alright
<bryceh> kees, got a minute?  ia32-libs question
<bryceh> kees, or possibly help needed
<Sarvatt> Need to get 854 MB of source archives.  -- <3 ia32-libs..
<Sarvatt> oh bah, was still using the maverick wine ppa sources on this machine so it grabbed it from there
<kees> bryceh: sorry, am on holiday until wed. but I can look at it more then if you need.
<bryceh> kees, ah
<bryceh> kees, ok is there someone else we can talk to about ia32-libs in the meantime?
<Sarvatt> eww, so you cant update ia32-libs unless everything it pulls in builds properly? looks like the isdnutils ftbs from a few weeks ago is holding it up for starters
<bryceh> Sarvatt, wow, there's a ton of X packages in ia32-libs
<bryceh> jeez this is horrible
<bryceh> this makes me want to have the apport hook redirect all amd64 X bugs to ia32-libs :-/
<ricotz> Sarvatt, yeah, pango is the current reason, which is already multiarch patched
<bryceh> Sarvatt, I've emailed scott richie for advice
<bryceh> xorg, udev, xcb-util, xft, svgalib, libx*, mesa, dbus, even a copy of hal
<Sarvatt> yeah this is why I dont use amd64 on machines I actually use day to day :P
<bryceh> ditto
<bryceh> I think maybe I am going to try to craft some way to detect ia32-libs presence in apport and kick out bug reports
<bryceh> Sarvatt, do you think checking if ia32-libs is installed is the best way to identify this situation?
<Sarvatt> nope, we'd need to know if they were doing something with the 32 bit libs.. google-earth, wine, 32 bit flash plugin..
<bryceh> Sarvatt, like, I wonder if bugs like lp #738600 are also caused by ia32-libs
<ubot4`> Launchpad bug 738600 in nvidia-graphics-drivers (Ubuntu) "flash 10.2 plugin crashes when leaving full-screen with nvidia 270.30 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/738600
<bryceh> Sarvatt, is there a way that can be detected?
<Sarvatt> "Actually that might not be relevant - I get it with nvidia 260.19.44 as well, where flash doesn't crash." comments like that really throw off the bug, 260.19.44 was installed from nvidia.com most likely and they dont have glx in the first place..
<bryceh> true
<bryceh> 740982 and 740462 are also x86_64 with -nvidia
<bryceh> 737765 too
<bryceh> Sarvatt, I guess the question is more about can we even support having multiple versions of mesa in the release
<bryceh> I think no... too much possibility of uncertain stability and hard-to-diagnose client/server issues
<kees> bryceh: yokozar is the best for ia32-libs. but the horror of ia32-libs is why we're pushing mutliarch so hard. ia32-libs will go away
<mdeslaur> ia32-libs eats babies
<jcristau> babies, kittens, anything cute.
<mdeslaur> hehe
<bryceh> okie doke
<seb128> bryceh, hey, I will not play pingpong on bug #737891 but I'm not convinced you are right
<ubot4`> Launchpad bug 737891 in gnome-control-center (Ubuntu) "gnome-display-properties unable to correctly enable monitors connected to VGA (affects: 1) (heat: 8)" [Low,Confirmed] https://launchpad.net/bugs/737891
<seb128> for one thing the issue is hardware specific and the client side has nothing hardware specific
<seb128> it wouldn't be the first time the xrandr command and the capplet use the xorg apis differently and hit different issues
<bryceh> seb128, sure but how is that an X issue?
<bryceh> seb128, I neither like it when you ping pong bugs back to us without sufficient reason
<bryceh> bbl
<seb128> bryceh, well my reasoning is simple
<seb128> - GNOME didn't change this cycle and the issue is new in natty
<seb128> - the issue is hardware specific
<seb128> both arguments suggest it's not a bug in the GNOME side
<seb128> but I could be wrong, hard to say without having the hardware and debug the issue
<seb128> it could also being something in the driver which doesn't like the way the calls are done from the GNOME capplet
<kklimonda> hmm.. gnome-shell crashes a lot inside libnvidia-glcore.so.270.30..
#ubuntu-x 2011-03-26
<bjsnider> Sarvatt, why doe sit appear that i have kms on natty with the blob?
#ubuntu-x 2011-03-27
<ripps> Is it possible to setup ubuntu to not load nouveou for nvidia gt240 cards. There's a bug that freezes systems right now.
#ubuntu-x 2012-03-19
<Sarvatt> bryceh: ok failsafe X not working is because of xdiagnose
<Sarvatt> aka downgrading to xdiagnose 1.6 from oneiric makes failsafe work again
<bryceh> erf.  oh?
<bryceh> weird.
<bryceh> ok thanks
<Sarvatt> change the init scripts?
<bryceh> had to be
<bryceh> I'll have to review.  I did do some cleanups
<Sarvatt> i'm going through it all now, just tested the downgrade to be sure and that was it
<Sarvatt> bryceh: the explicit vt7 
<bryceh> ah
<Sarvatt> thats the only thing remotely different
<Sarvatt> http://paste.ubuntu.com/891040/
<Sarvatt> testing that out now
<bryceh> yeah and that could do it
<bryceh> wonder why I added it?
<Sarvatt> bryceh: yep that works, failsafe X is on vt2
<bryceh> alright thanks
<bryceh> I *think* I might have added that to address some other problem...  digging...
<bryceh> aha
<bryceh>   Force vt7 when launching Failsafe-X.
<bryceh>   
<bryceh>   In testing on Precise, it appears when lightdm doesn't start, X will
<bryceh>   choose to start on vt1 by default, which ain't gonna work.
<bryceh> alright, so I'll re-test this on my hardware and upload new xdiagnose today or tomorrow
<FernandoMiguel> evening
<cnd> RAOF, ping
<RAOF> cnd: Pong.
<cnd> RAOF, so I just pushed the xorg-gtest stuff
<cnd> a couple minor fixes and changes from a review from stephen
 * FernandoMiguel runs
<RAOF> Cool.
<cnd> RAOF, the question now is do we try to push it into precise?
<FernandoMiguel> ahhaha
<cnd> there's a dependency on xorg-macros 1.17
<RAOF> Hm.
<cnd> we either need to update in precise
<cnd> or remove it
<RAOF> If it weren't for that, I'd unreservedly say yes.
<cnd> RAOF, we could also distro patch out the need for xorg-macros 1.17
<bryceh> cnd, what needs it?
<Sarvatt> or just FFE xutils-dev, its already in debian and is very low risk
<cnd> bryceh, it depends on xorg-macros for proper distcheck
<cnd> it doesn't affect the real meat and potatoes of xorg-gtest
<RAOF> The only real concern with the new xorg-macros would be build failures, right?
<cnd> yeah
<cnd> there's near 0 concerns though
<cnd> let me double check that statement :)
<Sarvatt> yeah and there are none, i've built just about everything against the new macros, it's just excessively chatty with warnings now but not that big a deal :P
<cnd> Sarvatt, what version of the macros do we have in ubuntu?
<Sarvatt> 1.15.something
<cnd> xutils-dev version doesn't match the upstream macros version
<cnd> hmmm...
<cnd> I don't know much about what has changed from 1.15 to 1.16.2...
<Sarvatt> 7.7~1 has 1.17 in it
<cnd> Sarvatt, why is it ~1?
<Sarvatt> 1.16 was mostly excessively verbose warnings by default :)
<Sarvatt> because 7.7 katamari isn't released
<Sarvatt> but the warnings were cut back some in 1.16.2
<cnd> oh, it's the katamari version
<Sarvatt> yeah
<cnd> RAOF, bryceh, Sarvatt: would we be updating to the 7.7 katamari for precise anyways?
<cnd> I don't know what the release schedule is
<cnd> "X11R7.7 development is underway for release in the first half of 2012."
<RAOF> I don't think we'd bother?
<cnd> http://www.x.org/wiki/Releases/7.7
<Sarvatt> nope its too late, most of the katamari releases weren't important though, things like 3 build system changes only for lots of the new lib releases
<cnd> that page is way out of date though :)
<cnd> ok
<bryceh> we usually don't bother
<bryceh> fwiw, pulling in the new xorg-macros 1.17 is fine with me
<bryceh> as pointed out above, is likely very low risk.  If it helps xorg-gtest, great.
<Sarvatt> or xserver 1.12 video abi changes only (that we arent shipping) for lots of the video drivers
<RAOF> I'm also happy to pull in xorg-macros 1.17.  We should do a test-rebuild of everything, though.
<cnd> RAOF: could we get that done before the beta 2 freeze on thursday?
<RAOF> cnd: Oh, I'd do a post-hoc test rebuild.
<bryceh> historically the final katamari release has tended to come either after we release or well into when we're hard frozen.
<cnd> RAOF, ok
<RAOF> cnd: Upload now, rebuild later :).  We don't expect any problems.
<cnd> Sarvatt, do you think we should add xorg-macros into the current xutils-dev, or just sync 7.7~1 from debian?
<cnd> what has changed between 7.6+6 to 7.7~1?
<cnd> oh, we're up to 7.6+10 now :)
<Sarvatt> cnd: whichever you feel more comfortable with, i dont think it'd be good to go out of sync with xutils-dev versions though since the only thing useful out of it is macros
<cnd> Sarvatt, I don't really know much about the xorg package
<Sarvatt> http://anonscm.debian.org/gitweb/?p=pkg-xorg/app/xutils-dev.git
<cnd> so I need some guidance :)
<cnd> Sarvatt, oh, it's not even ~1 anymore
<cnd> it's -1
<bryceh> can't risk breaking imake!
<cnd> wait, nm
<cnd> the tag is wrong
<cnd> ok, so it seems like the best course of action is to sync from debian unstable
<cnd> at least it's not from experimental :)
<bryceh> xutils-dev is just utils for building the X packages, so as long as raof's rebuild goes fine, that's really all we need it for.  I'd just sync the debian package.  Keep it simple.
<Sarvatt> guess you cant ~ in the tag
<cnd> last question is: do we need to file an FFe for it?
<cnd> ostensibly, it's just to fix a big bug in xorg-gtest :)
<RAOF> I think so, yes.
<bryceh> it can't hurt
<cnd> but it does seem like it would be good to have an FFe for the xorg package
<Sarvatt> yep requestsync -d unstable -e xutils-dev
<bryceh> good channel to communicate the whyfor of needing to rebuild the X archive
<cnd> I'll file an ffe for it
<Sarvatt> Explanation of FeatureFreeze exception:
<Sarvatt> util-macros 1.17.0 is needed for an updated xorg-gtest which is used for
<Sarvatt> unit testing X. The changes in this package are very low impact, util-macros
<Sarvatt> is required by most X packages and the only major change that is non-opt-in
<Sarvatt> is increasing the verbosity of GCC warnings during the builds.
<Sarvatt> that sound ok? i'll just hit submit if someone with upload privileges can ack it
<bryceh> sounds good to me
<RAOF> Yup.
<bryceh> maybe mention, "To be 100% safe, we will also trigger a rebuild of all potentially affected packages in the X stack."
<Sarvatt> https://bugs.launchpad.net/bugs/959791
<ubottu> Launchpad bug 959791 in xutils-dev (Ubuntu) "FFe: Sync xutils-dev 1:7.7~1 (main) from Debian unstable (main)" [Wishlist,New]
<bryceh> oh, +" and follow up on any issues that arise."
<Sarvatt> k editing it
<cnd> Sarvatt, I was in the middle of filing it, but I'm glad you're taking it :)
<cnd> if anything, it will keep ScottK off my back for perceptions of too many FFe requests made by the touch team :)
<cnd> RAOF, do you know a release team member who would be able to review it right away?
<cnd> some of the FFes can sit for a few days, and I don't want to leave this for after beta 2 freeze
<bryceh> maybe ping slangasek?
<cnd> ok
<eruditehermit> hey
<eruditehermit> does anyone here have experience with fglrx?
<bryceh> Sarvatt, ack'd
<Sarvatt> bryceh: thanks a ton for that, was just about to ask
<Sarvatt> cnd: sorry for stepping on toes, had it all done before seeing ya say you would do it and figured it'd save time :P
<cnd> Sarvatt, np :)
<Sarvatt> have been planning on filing that for the past week
<cnd> I'm surprised someone else was willing to file an FFe :)
<cnd> bryceh, if you clicked the "this affects me too" button, I think it's the wrong thing to do for an FFe
<cnd> the janitor bot moves it to confirmed
<bryceh> ah
<cnd> and the process documentation says it needs to be in the new state
<cnd> the release team has probably realized that by now
<Sarvatt> cnd: hmm
<cnd> but I don't like leaving things to chance
<Sarvatt> so when i file bugs with requestsync without upload permission, its in a new state and a core-dev has to ack it by setting it confirmed
<cnd> Sarvatt, that's a different process from FFes I think
<Sarvatt> but i guess this ones different because its in the FFe stage, after THAT got acked it'd unsubscribe release team and they'd subscribe sponsors and go through that
<cnd> https://wiki.ubuntu.com/FreezeExceptionProcess#General_Instructions
<cnd> it says if it's not in the new state, the release team may not see it
<cnd> I *think* the release team moves it to confirmed
<cnd> in which case, their reports may not show a bug that has already been moved to confirmed
<Sarvatt> sounds right
<Sarvatt> eruditehermit: http://paste.ubuntu.com/891499/
<eruditehermit> Sarvatt, what does that do?
<Sarvatt> just add your switcheroo stuff you want to do to it on resume to disable the gpu
<eruditehermit> Sarvatt, hmm, I already have a script that does that
<eruditehermit> Sarvatt, the issue is that it causes my system to be unresponsive for 20 seconds
<Sarvatt> ah gotcha, no clue about that :(
<eruditehermit> and the fans start whirring uncontrollably during this time
<eruditehermit> this is annoying when it happens in public
<eruditehermit> lol
<eruditehermit> ideally, switcheroo would save the state before suspend
<eruditehermit> or not report incorrect state
<eruditehermit> Sarvatt, also my fglrx works with hybrid gfx, but when I want to switch back to intel, it doesn't switch where it looks for libGL
<eruditehermit> is there an updated ubuntu package version that works with hybrid?
<eruditehermit> you mentioned someone was working on that?
<Sarvatt> I have absolutely no clue at all on the status of it outside of tseliot saying he was working on those scripts not long ago, he's the maintainer of it and its about 2 am his time now so cant ask
#ubuntu-x 2012-03-20
<cnd> RAOF, I'm about to upload xorg-gtest 0.2.0 to precise (\o/)
<RAOF> Wooo!
<cnd> I now have no reservations about the MIR
<RAOF> I'll address the final gtest MIR comment today.
<cnd> RAOF, oh, I didn't notice any MIR comments for gtest
<cnd> RAOF, do you have the bug #?
<RAOF> https://bugs.launchpad.net/ubuntu/+source/gtest/+bug/949575
<ubottu> Launchpad bug 949575 in gtest (Ubuntu) "[MIR] gtest" [Undecided,Incomplete]
<RAOF> Just to run the tests during the build.
<cnd> doh, I need to change libxorg-gtest-dev from arch any to arch all
<Sarvatt> multiarch certainly made local testing annoying, purging all my humble bundle games every time i want to test local libdrm/mesa builds without using a ppa :)
<Sarvatt> since i dont have :i386 versions built too
 * Sarvatt starts not caring about making .deb's of upstream crap he tests
 * RAOF just builds i386 versions, too.
<Sarvatt> oh thats a blast with mesa on laptops
<Sarvatt> would be nicer if we didn't support 8 and 16 bit versions of osmesa to cut the build time in half though :)
<cnd> RAOF, ok, finally got xorg-gtest uploaded after needing a few more changes
<RAOF> Wootness.
<tjaalton> hmm, want an intuos5S, the intuos4L is too big
<tjaalton> driver support missing, will add it
<Sarvatt> bryceh: i'm so confused about https://launchpad.net/ubuntu/+source/mesa/7.11-0ubuntu3.1 -- you added an intel patch instead of the nouveau fix? :P
<Sarvatt> bryceh, RAOF: we have to be super careful with intel cherry-picks in mesa now, the symlinks are dereferenced for the tarballs so when we add a patch touching src/mesa/drivers/dri/intel/* it has to be duplicated out to the other places like src/mesa/drivers/dri/i965
<Prf_Jakob> Sarvatt: symlink derefes sounds like a bug.
<Prf_Jakob> Sarvatt: I'll do the release today btw.
<Prf_Jakob> As soon as I get a review on a patch.
<tjaalton> it's different in 8.0
<Prf_Jakob> Ah ok
<tjaalton> i guess the tarball has the same symlinks
<tjaalton> whereas 7.11 didn't, so we had to do tricks in order to build a source package from git
<tjaalton> since dpkg-source refuses to work if a real file changed to a symlink
<ricotz> tjaalton, hi
<tjaalton> ricotz: yo
<ricotz> tjaalton, the #debian-gnome guy really hoping for libwacom soon ;) they are already doing gnome 3.3/3.4
<tjaalton> ricotz: and ready to sponsor it?
<ricotz> yeah, mbiebl would upload it
<bryceh> Sarvatt, actually, looks like I got two bugs transposed.
<tjaalton> ricotz: so you filed the ITP?
<ricotz> tjaalton, you want to join #debian-gnome
<tjaalton> oh I do? :)
<ricotz> tjaalton, no, i havent
<tjaalton> what's 659700 then
<Sarvatt> bryceh: i'm in the process of working up a SRU for https://launchpad.net/~sarvatt/+archive/sru6 , is it ok if I just remove it from this one? this one will be verified really fast even though its large, its affecting every ivybridge system QA is running tests against
<tjaalton> oh it was me
<tjaalton> hehe
<ricotz> ;)
<bryceh> Sarvatt, that's fine
<Sarvatt> bryceh: that patch you added for src/mesa/drivers/dri/intel needs to be duplicated into src/mesa/drivers/dri/i965 and src/mesa/drivers/dri/i915 if appropriate to get used though
<Sarvatt> because of that symlink problem in 7.11
<bryceh> Sarvatt, right, but I'm not sure the patch should be sru'd
<bryceh> Sarvatt, it's for 757906, whose oneiric task is set to wontfix
<bryceh> mm, think maybe it shouldn't have been set to wontfix though.
<Sarvatt> hmm our mesa debs are .gz
<Sarvatt> we used lzma for 7.11
<Sarvatt>         dh_builddeb -s -- -Zlzma
<Sarvatt> vs
<Sarvatt>         dh_builddeb $(foreach pkg,$(dbgpkg),-p$(pkg)) -- -Zxz
<Sarvatt>         dh_builddeb $(foreach pkg,$(otherpkg),-p$(pkg))
<Sarvatt> that might explain the lack of size difference even though all the dri1 stuff was dropped back when i compared it
<Sarvatt> -rw-r--r-- 1 sarvatt sarvatt 2.9M Mar 20 15:46 data.tar.xz
<Sarvatt> -rw-r--r--  1 sarvatt sarvatt 5.5M Mar 20 15:28 data.tar.gz
<Sarvatt> thats a huge chunk of livecd space
<Sarvatt> just for libgl1-mesa-dri
<Sarvatt> -rw-r--r-- 1 sarvatt sarvatt 2.9M Mar 20 15:48 data.tar.lzma
<Sarvatt> so lzma that doesnt need a pre-depends diff for every package, or xz which does? :P
<albert23> does deb compression matter on a live cd, as the package is installed?
<Sarvatt> good point, dont think it does outside of alternate, i've just always gone under the impression that the compressed deb size is how much approximately is going to be used there but that doesn't make sense :)
<bryceh> should we be thinking about pulling in the libX11 1.5 release with keith's fix for those xcb sync bugs?
<tjaalton> sure, better than a beta
<tjaalton> or rc
<RAOF> Yeah, probably a good idea.
<bryceh> would likely make seb128 happy
<seb128> \o/
<seb128> that would be great
<seb128> would that fix all the XAlloc assert bugs?
<seb128> _XAllocID
<bryceh> seb128, it may; it's not widely tested yet tho afaict
<FernandoMiguel> OlÃ¡
<bryceh> seb128, technically I think the bugs are caused by client apps that are using libxcb in non-threadsafe ways
<mlankhorst> probably
<bryceh> seb128, libxcb is advertised as a single-threaded lib, so when multi-threaded clients use it, they have to be careful.
<bryceh> seb128, so I'm not sure if keith's patch is a true fix or may be just papering over bad client coding.
<bryceh> but... if it stops the asserts...
<seb128> bryceh, I doubt any "client" use xcb
<seb128> but maybe a gtk or cairo bug...
<jcristau> err
<bryceh> seb128, well, they do via libx11
<seb128> like "use it directly"
<bryceh> ah, right
<seb128> bryceh, they use gtk,cairo
<jcristau> using libxcb in a multi-threaded app is very much ok.
<RAOF> xcb is lovingly threadsafe, what with all the cookies and all.
<bryceh> seb128, also fwiw where we've seen this in other apps (there was one in apport a few weeks back), the issue was able to be resolved in the client itself.
<RAOF> Doesn't Keith's patch fix a deadlock in libx11?  I'm not sure that's hugely likely to fix the XAllocID asserts.  But it might, things are madness.
<jcristau> RAOF: it does.
<jcristau> (only fix a deadlock)
<RAOF> Which is certainly a fix we want; deadlocking apps isn't exactly brilliant behaviour :)
<bryceh> ok, so seb128 go back to being sad
<seb128> :-(
<mlankhorst> :-o
<jcristau> does seb128 have a reproducer for his bug?
<bryceh> bug #950222
<ubottu> Launchpad bug 950222 in libx11 (Ubuntu) "eog crashed with SIGABRT in __assert_fail_base()" [Medium,New] https://launchpad.net/bugs/950222
<jcristau> closed worksforme :)
<seb128> jcristau, no, we just get hundred of XAllocID assert in random GNOME component and I've no clue what info would be useful since they seem random, no user come with a way to trigger them
<seb128> jcristau, bug #905686
<ubottu> Launchpad bug 905686 in libx11 (Ubuntu) "nautilus assert failure: nautilus: ../../src/xcb_io.c:528: _XAllocID: Assertion `ret != inval_id' failed." [High,Triaged] https://launchpad.net/bugs/905686
<seb128> bug #507062
<ubottu> Launchpad bug 507062 in libx11 (Ubuntu Lucid) "synaptic assert failure: synaptic: ../../src/xcb_io.c:385: _XAllocID: Assertion `ret != inval_id' failed." [High,Triaged] https://launchpad.net/bugs/507062
<seb128> jcristau, so bug got so dupped you can't open them without getting launchpad to timeout half the time
<tjaalton> there was one bug that looked similar which was a flaw in glib
<tjaalton> fixed last fall i think
<jcristau> it's breaking single threaded apps?
<jcristau> looks like https://launchpadlibrarian.net/37855577/ThreadStacktrace.txt only has 1 thread
<bryceh> seb128, I think a lot of those shouldn't have been all duped together.  Just because they trigger the same assert doesn't mean it's the same bug.
<seb128> bryceh, I would be glad to have any clue how to figure that, what to do with them
<bryceh> seb128, well what I do is look in libx11:src/xcb_io.c and grep for the assertion that the bug hit.
<bryceh> seb128, often times the XCB guys have left comments explaining what the assertion means
<bryceh> seb128, and for many of these bugs, that reveals a coding error somewhere in the client
<bryceh> jcristau and RAOF said above that xcb works fine in multithreaded apps, but from all the bugs you and I have seen where xcb assertions get tripped, it seems very sensitive to threading issues in clients.
<jcristau> these asserts are in xlib
<jcristau> not xcb
<bryceh>  __assert_fail_base (fmt=0xb75b1698 <Address 0xb75b1698 out of bounds>, assertion=0x76ad79 "ret != inval_id", file=0x76acea "../../src/xcb_io.c", line=528, function=0x76adfe "_XAllocID") at assert.c:94
<bryceh> jcristau, xcb_io.c is not xcb?
<jcristau> that's in xlib
<bryceh> jcristau, yes, in libx11:src/xcb_io.c like I said
<seb128> those XAllocID assert a probably the number 1 bug we get through desktop
<seb128> and I've no clue what's the issue or how to debug it
<seb128> and it's clients apps all being buggy, or gtk, or x11 or whatever
<bryceh> seb128, do you see the issue as being random, or do you know of reliable ways to reproduce it?
<bryceh> it/them?
<RAOF> Whoopsie doesn't yet have any ability to do fancy client stuff yet, does it?
<seb128> bryceh, random, I never hit those bugs
<bryceh> seb128, I've hit one once, but never reproduced.
<Sarvatt> they're all drawing theme stuff after an app crash while using murrine or clearlooks from a quick look at the bug reports across the other distros
<bryceh> seb128, that particular instance I believe was when I was in the middle of upgrading stuff, and wondered if it might have been due to an underlying library getting changed out.
<Sarvatt> maybe we only notice it more because of ambiance? :)
<seb128> Sarvatt, could be
<seb128> then you have bugs like bug #948089
<ubottu> Launchpad bug 948089 in gnome-settings-daemon (Ubuntu) "gnome-settings-daemon crashed with SIGABRT in __assert_fail_base()" [Low,New] https://launchpad.net/bugs/948089
<seb128> assert !xcb_xlib_threads_sequence_lost
<seb128> I'm pretty sure that one happens when the session doesn't close properly
<seb128> i.e gnome-session or xorg segfault
<seb128> I wonder if the XAllocID one is a similar red herring
<RAOF> Entirely possible.
<seb128> bryceh, RAOF: what about bug #926379
<ubottu> Launchpad bug 926379 in mesa (Ubuntu) "compiz crashed with SIGSEGV in intel_miptree_release()" [Critical,Triaged] https://launchpad.net/bugs/926379
<seb128> that got enough dups that launchpad timeout to open it
<bryceh> seb128, it's unrelated to the assert bugs.  There's a patch to add logging, which has been run and given, so waiting on upstream for a fix
<bryceh> seb128, a few more folks testing that and providing logs might help
<seb128> bryceh, yeah, I know it's not related to the assert, but that one is concerning because it keeps collecting dups every day on unity
<seb128> ok
<seb128> so "needs info"
<seb128> that seemed like something we should tackle for beta2
<bryceh> yeah
<bryceh> seb128, I guess the thing blocking it currently is that it's hard to reproduce synthetically
<bryceh> or I should say, developers haven't reproduced it synthetically
<RAOF> None of us have been able to reproduce it, have we?
<Sarvatt> never
<RAOF> Because this would sound like a job for apitraceâ¢, even though the actual windows would be blank.
<Sarvatt> oh the mesa bug
<RAOF> Yeah, the mesa bug.
<Sarvatt> sorry, i just popped back on for a minute and thought people were talking about the _XAllocID assert
<RAOF> Nope :)
<bryceh> Sarvatt, seb128 advanced the topic ;-)
<Sarvatt> tjaalton said he hit that one
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=46739
<ubottu> Freedesktop bug 46739 in Drivers/DRI/i965 "[snb-m-gt2+] compiz crashed with SIGSEGV in intel_miptree_release()" [Critical,New: ]
<cnd> bryceh, I was promised warmer weather this time of year... :(
<Sarvatt> cnd: lets trade, too freaking hot
<cnd> Sarvatt, fine by me :)
<cnd> Sarvatt, what have your highs been?
<Sarvatt> 87 yesterday
<cnd> wow
<Sarvatt> 75 or 80 today, im not sure
<cnd> Sarvatt, you've seen the temperature map of the US, right?
<Sarvatt> i'm jealous every time i look at the portland weather in the indicator
<Sarvatt> rain rain rain rain rain snow snow rain snow rain snow, highs in the 40's :P
<cnd> I hope you're not serious...
<Sarvatt> 100%
<bryceh> cnd, heh who promised you nice weather in Portland in March?
<cnd> bryceh, no one promised nice weather, but this is awful
<cnd> this would be understandable in january
<bryceh> cnd, yep.  March is the worst in portland
<cnd> but not in spring
<cnd> and I'm fine with the rain
<cnd> it's just these frigid temperatures
<Sarvatt> cnd: where did you move from?
<cnd> Sarvatt, columbus, oh
<bryceh> the snow is a bit unusual, but depressing rain is all about March in portland
<cnd> meh, rain is fine
<cnd> if it were in the 50s or 60s I'd have no complaints
<bryceh> s/depressing/depressing and cold/
<bryceh> in grade school and middle school I used to have to walk to piano lessons and home in this weather (~2 miles).
<bryceh> builds character (and makes you want to own a car)
<cnd> heh
<bryceh> cnd, it'll turn around come april.  We probably won't get "nice" days until May tho
<cnd> cool
<cnd> well, we're not too far from april :)
<bryceh> yep
<bryceh> in May, this thing people call  "the Sun" sometimes shows up.  Usually high up in the sky.  Keep an eye out for it.
<Sarvatt> my office is like 15 degrees warmer than the rest of the house and hot even with the ac blasting, thats why i'm jealous :)
<bryceh> Sarvatt, I can turn every computer on in my office right now, and not get roasted out
<bryceh> I can even put on t he projectors, but then I do need to crack a window
 * RAOF drops off his car for a service.
#ubuntu-x 2012-03-21
<apw> bryceh, you had an apt-repository-purge script i think ... did that make it into the distro as someting in the end?
<bryceh> apw, ppa-purge what you're thinking about?  yes, it's in the archive
<apw> bryceh, ahh i was looking for apt-repository-purge and failing ... thanks
<apw> bryceh, that patch just went out to kernel-team@ for approval
<apw> bryceh, if you have some solid examples of use cases then you might reply with them
<Sarvatt> apw: have you not seen http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=da0df92b57311aa1b26a2a90599ed16e1e968b90 ? thats going in 3.4
<Sarvatt> pull request went out today for it
<apw> Sarvatt, bah 30s ago wuld have been better ... 
<Sarvatt> sorry, i just saw it a few minutes ago in the drm pull request 
<apw> Sarvatt, heh not your fault, just annoying, i had _literally_ just hit return on the send
<Sarvatt> wow it actually straight up applies to 3.2 too, amazed
<bryceh> mesa 8.0.1's out
<jcristau> 8.0.2
<tjaalton> you mean .2?
<jcristau> cock-up in the first mail
<bryceh> haha, right
<tjaalton> heh
<Sarvatt> RAOF: any idea why all my color profiles disappeared after the last days worth of updates? :P
<Sarvatt> ah ok looks like the settings just got changed and it was not obvious that i needed to add profile and pick the old one, thought adding a profile would make me recalibrate
<Sarvatt> crazy how annoying the default color profile is on this macbook air when you get used to it being set up right :)
<RAOF> Sarvatt: That's true for *all* displays, apparently.
<RAOF> All laptop displays, at least.
<RAOF> Super high colour temperature!
<Sarvatt> libxaw doesn't build with new util-macros btw (see #debian-x)
<Sarvatt> --disable-selective-werror fixes it though
<tjaalton> filed FFe for wacom 0.14.0
<tjaalton> cnd: hey, so is wacom multitouch supported by the utouch stuff or what's it called?
<Sarvatt> tjaalton: very much doubt it, it does its own gestures inside the driver i thought?
<cnd> tjaalton, which stuff?
<cnd> the X wacom driver is not supported by utouch
<tjaalton> meh
<tjaalton> :)
<cnd> the wacom products could be supported if you use evdev
<tjaalton> intuos5 S would be soo cool..
<tjaalton> Sarvatt: windows/mac yes
<Sarvatt> dont you already have an intuos 4?
<cnd> Chris Bagwell mentioned on linux-input that he is interested in bringing XI 2.2 multitouch support to X wacom
<tjaalton> yeah but it's the large one, too large
<cnd> when that happens, utouch should have no problems supporting it
<Sarvatt> whoa first person i've ever heard complain about having too large a wacom tablet :)
<tjaalton> hmm I'm not on that list, should subscribe i guess
<tjaalton> Sarvatt: S would fit next to my slim thinkpad kbd, 4L is high up on the shelf :)
<Sarvatt> i've got an intuos 4 6x8
<Sarvatt> 4x5 was too small, went through 2 of those in the past
<tjaalton> and I don't really use it for art, or anything for that matter
<tjaalton> original idea was to use it for photo management, but it's too big for that
<Sarvatt> probably be served just as well by a cheap bamboo, not like you need the extra pressure levels in that case :)
<RAOF> cnd: Hey, what's currently meant to be working on the unity gesture front?
<cnd> RAOF, nothing :)
<Sarvatt> 4 finger ones!
<cnd> but, I'm about to upload utouch-grail and utouch-frame and utouch-geis
<Sarvatt> when they work
<cnd> that should make the 4 stuff work properly
<RAOF> Ok.  That makes sense of why the magic touchpad isn't doing anything :)
<cnd> and then we will probably land the 3 touch window gestures soon after beta 2 releases
<Sarvatt> hmm its actually different now than it was a week ago, 4 finger swipe in any direction unhides the launcher
<cnd> Sarvatt, none of that code should have changed...
<RAOF> Sarvatt: Not in precise at the moment :)
<cnd> but there's a lot broken in precise right now
<cnd> however, we have glorious regression tests :)
<Sarvatt> RAOF: works on my bcm5974 with synaptics :)
<Sarvatt> oh hey i got the dash that time
<cnd> taps are reallly really broken in precise
<cnd> they've been a big focus of our work
<Sarvatt> cnd: is it intentional clickpad being turned on forces tap to click on too?
<cnd> Sarvatt, no, that is handled by gnome-settings-daemon
<cnd> depending on your trackpad settings
<tjaalton> Sarvatt: well, I have an aiptek/waltop if I want to use a crappy device.. :)
<RAOF> Sarvatt: Fails on my magic touchpad with synaptics â¹
<Sarvatt> cnd: oh nevermind, whatever that was got fixed apparently. enabling clickpad with synclient ClickPad=1 always turned on tap to click and ignored g-s-d
<cnd> Sarvatt, hmmm, that may have happened in earlier patches
<cnd> but shouldn't now
<Sarvatt> cnd: nice, you made 2 finger press do a right click now?
<cnd> Sarvatt, yes, though it was whot who really did it
<Sarvatt> with clickpad enabled
<Sarvatt> cool!
<Sarvatt> only problem is, you have to hold the press or it closes the context menu :)
<cnd> so upstream now has full clickpad support, and we have it from upstream
<cnd> Sarvatt, you can to a "click"
<cnd> i.e. don't hold it down
<cnd> the menu should stay up
<Sarvatt> cnd: oh i see the issue
<Sarvatt> if you 2 finger press
<cnd> if it disappears immediately, then wait for the next synaptics update :)
<Sarvatt> then lift both fingers
<Sarvatt> the menu disappears
<Sarvatt> if you lift 1 finger its fine
<Sarvatt> actually what the heck, its not following any patterns, sometimes it works sometimes it closes immediately
<Sarvatt> 2 finger press then lift 1 finger always leaves the menu up, sometimes 2 finger press then lifting both fingers closes it immediately
<Sarvatt> maybe this has something to do with the thousands of Warning: failed to get previous touch value i have in ~/.xsession-errors
<cnd> Sarvatt, you're hitting a bug I just fixed
<Sarvatt> woohoo, best kind of bug :)
<cnd> wait for the synaptics that is building in the archive to finish :)
<Sarvatt> starting the PPU process, whee
<Sarvatt> have to dig out every single X package to add to the wiki
<broder> Sarvatt: new packageset?
<Sarvatt> yeah going to ask for an X package set
<bryceh> Sarvatt, http://paste.ubuntu.com/894450/
<Sarvatt> bryceh: ohh nice, thank you for that!
<Sarvatt> there's a bunch missing but thats a good start, i was gonna pilfer your versions-current report
<bryceh> better to use the arsenal script -  ./ls-team-subscribed-packages.py -t ubuntu-x-swat | pastebinit
<bryceh> Sarvatt, for missing stuff, sub ubuntu-x-swat if we're maintaining it
<Sarvatt> ah cool was just about to ask that
<Sarvatt> the mail subscriptions?
<Sarvatt> http://sarvatt.com/weston.png
<bryceh> lemme doublecheck
<bryceh> yes, that's right.  And set it for all mail not just open/close
<Sarvatt> bryceh: would ya mind copying https://wiki.ubuntu.com/Sarvatt/MOTUApplication to https://wiki.ubuntu.com/Sarvatt/DeveloperApplication-PPU ? Sorry for not acting when you spent all that time giving me an endorsement before
<bryceh> sure thing
<Sarvatt> appreciate it, no rush or anything because this will take a few weeks at least
<bryceh> Sarvatt, weird, I thought you were core-dev now?
<Sarvatt> bryceh: nope only ubuntu member here!
<bryceh> there we go
<Sarvatt> going through that ordeal selling myself to a group of people really weirded me out, not looking forward to doing it again but it needs to get done, i bug you guys too much :)
<bryceh> yeah I remember it being stressful when I went through it
#ubuntu-x 2012-03-22
<Sarvatt> cnd: seing lots of bugs crashing in NewInputDeviceRequest that are very obviously something frankenserver specific, are you absolutely sure backporting the input options stuff and really using the 1.12 input abi isnt the way to go?
<cnd> Sarvatt, I know there are bugs out there, but I haven't had any time to look at them yet :(
<cnd> so I don't have a good answer
<bryceh> list 'o crashes:  https://bugs.launchpad.net/ubuntu/+source/xorg-server?field.tag=precise&field.tags_combinator=ALL
<bryceh> list Sarvatt said, most of these are crashing in or through input-related functionality
<Sarvatt> things like invalid evdev options crashing the server
<Sarvatt> and they work with 1.12, wasting whot's time forwarding them upstream :)
<cnd> Sarvatt, do you have a list of them handy?
<cnd> even just a couple
<Sarvatt> give me a few to look it up, i lost the tabs i had open for a few weeks meaning to mention it
<bryceh> 931397 
<bryceh> 939023 maybe too
<bryceh> cnd, I can repro both of those
<Sarvatt> bryceh: thank you, the second one specifically
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=46588
<ubottu> Freedesktop bug 46588 in Input/evdev "evdev segfaults when Options are enabled" [Major,Needinfo: ]
<Sarvatt> that was the one i was trying to dig up
<cnd> bug 939023 is more important
<ubottu> Launchpad bug 939023 in xserver-xorg-input-evdev (Ubuntu) "X server crashes when evdev is enabled" [High,Triaged] https://launchpad.net/bugs/939023
<cnd> the only bug I was aware of was 931397
<cnd> which was a low priority because disabling auto add of devices doesn't seem to have a valid use case
<cnd> I was chatting with the bug reporter
<cnd> and he said he was following some instructions somewhere
<cnd> something to do with hybrid graphics, but auto add of devices is only for input devices, IIUC
<cnd> anyways, I will try to get to those bugs soonish
<cnd> but if anyone can lend a hand, I would very much appreciate it
<bryceh> cnd, what sort of help is needed?
<cnd> bryceh, fixing the bug?
<cnd> I don't know what's wrong yet
<Sarvatt> cnd: would just plain doing an actual input abi backport from 1.12 at all be an option?
<cnd> Sarvatt, we have an input abi backport
<cnd> the problem is that there is an option abi backport
<Sarvatt> yeah but its not compatible, things built against 1.12 dont work because of the options
<cnd> well, there could be
<cnd> the problem is that the options abi isn't contained to input drivers
<cnd> it's possible that other drivers, like video drivers, would use the abi
<Sarvatt> ohhh, didn't know that
<cnd> if a proprietary driver did that, we would be incompatible with the upstream 1.11 video abi
<cnd> so we really need to figure out why it's crashing
<RAOF> Which would be *awesome fun*
<cnd> and fix it
<cnd> it probably wouldn't be difficult to figure out what's wrong
<cnd> firing up the server under gdb
<cnd> I'm just lacking for time :(
<Sarvatt> cnd: It could be worse than coding style changes breaking everything, drivers could be in the server :)
 * Sarvatt is so glad that idea stalled
<bryceh> Sarvatt, maybe only stalled until next UDS?
<bryceh> er, XDC
<tjaalton> having the drivers in the server would make backports much easier, that's for sure :)
<tjaalton> green light for wacom 0.14
<tjaalton> so mesa 8.0.2?
<tjaalton> Sarvatt: did you test the new mesa? maybe I'll hold off on uploading it until you're back online..
<apw> bryceh, did you see my updated edid patched kernels, with the latest upstream contribution
<tjaalton> Sarvatt: were we supposed to get the newer libdrm?
<tjaalton> for precise
<tjaalton> intel-gpu-tools could be synced
<Sarvatt> i gave up on it at feature freeze because it wasnt in debian and nothing needed it, we'd have to revert efd6e81e2ba112105457887ae18a58dfa4bbc8ef and 82c6938d232327233caac743a07639ac91bceb7e or else plymouth would be busted
<tjaalton> ah, ok
<Sarvatt> no response on the plymouth bug i filed asking for backporting the year old commit to make drm backends optional
<tjaalton> oh, libxcb
<jcristau> Sarvatt: that's been fixed upstream in plymouth for a while
<Sarvatt> jcristau: yea our plymouth is just ancient
<jcristau> and there was finally a plymouth release recently
<Sarvatt> definitely not going to be updated until 12.10, plymouth is too fragile :)
<tjaalton> synced libxcb 1.8.1
<Sarvatt> 0.8.2-2ubuntu28, its the new initramfs-tools
<Sarvatt> 2 year old release with lots of backports because noone wants to break it :P
<tjaalton> there's a bug against MoM to show the age of the merge
<tjaalton> there are/were lot of those that noone wanted to touch..
<tjaalton> I merged nss & nspr with 4+ years of accumulated diff
<tjaalton> turns out the diff was very small, just the history was messy
<tjaalton> but the plumbing components _are_ harder..
<tjaalton> Sarvatt: x-x-v-vmware, syncable?
<Sarvatt> tjaalton: yes but no point
<Sarvatt> only xserver 1.12 changes past what we have
<Sarvatt> well i better test build to make sure :)
<tjaalton> yeah but the version number is ugly :)
<tjaalton> vmmouse too
<Sarvatt> vmware builds and is only bug fixes past what we have, ship it! :)
 * Sarvatt grumbles about util-macros verboseness
<Sarvatt> xf86-video-vmware hates -Wredundant-decls
<Prf_Jakob> Sarvatt: sorry...
<Sarvatt> nothing to be sorry about, the newer macros are noisy on absolutely everything :)
<Prf_Jakob> Oh I released 8.0.2 yesteraday.
<Sarvatt> http://paste.ubuntu.com/895321/ is my favorite example
<Sarvatt> Prf_Jakob: yeah we saw, already in ubuntu \o/ thanks for that
<Prf_Jakob> Sarvatt: np
<Prf_Jakob> also \o/
<jcristau> btw, *poke* about merging src:xorg :)
<bryceh> apw, yeah do you need me to re-test?  I've got a few other bugs I'm backed up on (and am piloting today) but can squeeze in time if its urgent
<tjaalton> jcristau: yup
<bryceh> apw, oh wow this patch is quite a bit different isn't it
<tjaalton> umm, what about -intel?
<tjaalton> we're one release behind
<bryceh> tjaalton, what's in it?
<tjaalton> bryceh: no idea, but it's part of the Q1 release?
<apw> bryceh, quite different and yet not really, it works ish for me, but to propose it for P i would like a valid test like your 'fixed my config test you reported' would be good
<bryceh> are we frozen now?  too late for a merge?
<bryceh> apw, on it
<tjaalton> not frozen until 3-4h from now
<bryceh> tjaalton, plenty of time!  ;-)
<tjaalton> bryceh: my thoughts exactly! :)
<tjaalton> i'll merge xorg
<tjaalton> that one _is_ important
<tjaalton> intel is mostly sna changes i guess
<bryceh> yeah the ddx has gotten pretty tame
<tjaalton> ah no, 2.17.0 is the 12.02 release component
<bryceh> heh http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=3640a0d4cb9e0f115fda9ea36212670f6ccafb22
<tjaalton> hah
<Sarvatt> got intel merged locally and testing it out now
<Sarvatt> just incase someone gives the go-ahead :)
<tjaalton> git log --oneline 2.17.0..2.18.0 |grep -v " sna", could filter even more
<bryceh> tjaalton, grep -v glamor ?
<tjaalton> bryceh: yeah that too
<bryceh> looks like there's a few uxa bits that might be worthwhile but a lot of the remainder here feels code refactory
<bryceh> if worse came to worse we could probably just cherrypick out the uxa bits that look useful
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel?field.tag=precise&field.tags_combinator=ALL
<bryceh> pretty much all our open bugs for precise look like drm / kms type issues.
<bryceh> tjaalton, guess an argument could be made "ain't broke, don't fix"
<Sarvatt> see any bugs with intel_uxa_prepare_access: bo map failed: No space left on device in xorg.0.log?
<Sarvatt> i've hit that before but i dont see any bugs, argh :)
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/539898
<ubottu> Launchpad bug 539898 in xserver-xorg-video-intel (Ubuntu) "[i965gm] X server crash with KDE SC 4.4 compositing" [Undecided,New]
<bryceh> wait no, that's bo map failed
<bryceh> hmm, same thing with #468923
<bryceh> stupid launchpad search
<Sarvatt> thats too old to possibly be relevant i'd imagine
<bryceh> yeah karmic
<bryceh> not spotting anything in precise offhand
<tjaalton> bryceh: ok then :)
<tjaalton> xorg merge uploaded
<tjaalton> i'll discuss -qxl sync with hallyn tomorrow
<Sarvatt> ah i see
<Sarvatt> it happens under OOM conditions, and people file the bugs against the kernel
<Sarvatt> so no xorg.0.log
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/891300 is one that needs http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=5b5cd6780ef7cae8f49d71d7c8532597291402d8
<ubottu> Launchpad bug 891300 in linux (Ubuntu) "drm i915_gem_crate_mmap_offset *ERROR*failed to allocate offset for bo 0" [Medium,Confirmed]
<bryceh> cherrypickable?
<bryceh> apw, this edid patch totally rocks :-)
<apw> bryceh, cool ... its a direct cherry of upsteams merge, so it also makes sense to use i
<apw> it
<bryceh> apw, will shoot an email back with results
<apw> bryceh, and for UDS-Q we need to start thinking abnout some userspace for it
<apw> bryceh, sounds good
<LLStarks> this isn't good. i'm getting a lot of cursor death with the precise input drivers. cursor will get stuck in the grab mode and can't release to click on anything else.
<LLStarks> any way to unstick other than a sysreq k?
<tjaalton> "input drivers".. which ones?
<Sarvatt> bryceh: huzzah https://bugs.freedesktop.org/attachment.cgi?id=58726
<Sarvatt> fixes the intel_miptree_release segfaults
<tjaalton> phew
<Sarvatt> great, cant even load https://bugs.launchpad.net/ubuntu/+source/unity/+bug/926379
<ubottu> Launchpad bug 926379 in mesa (Ubuntu) "compiz crashed with SIGSEGV in intel_miptree_release()" [Critical,Triaged]
<LLStarks> tjaalton: i've observed it starting with -mouse
<LLStarks> and persists with -synaptics
<tjaalton> LLStarks: you most certainly aren't using mouse
<LLStarks> what's the default for usb mice then, -evdev?
<tjaalton> yes
<LLStarks> that's what i meant
<LLStarks> trying to find a goodway to reproduce on command
<tjaalton> what do you mean by "grab mode"?
<tjaalton> some app has the focus and won't let go?
<tjaalton> Sarvatt: should we push another mesa with that commit?
<Sarvatt> for sure
<Sarvatt> i've been trying to interact with that bug for 10 minutes now, about to give up
<Sarvatt> want me to push it?
<tjaalton> either way is fine
<tjaalton> you found it, maybe best if you commit it :)
<Sarvatt> okie pushed
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=46303
<tjaalton> uploaded
<ubottu> Freedesktop bug 46303 in Drivers/DRI/i965 "[SNB] segfault in intel_miptree_release()" [Normal,Assigned: ]
<LLStarks> tjaalton: pretty much, but moreso its a problem of the window drag mode can't be released
<LLStarks> so, i get the fist icon and can't click anything
<LLStarks> keyboard works
<tjaalton> LLStarks: first icon?
<LLStarks> fist
<LLStarks> the grab icon
<tjaalton> oh fist, hehe
<tjaalton> this is with unity?
<LLStarks> shell
<tjaalton> right, well I'd say it's a bug there then
<LLStarks> don't use unity long enough to encounter i
<LLStarks> *it
<LLStarks> not sure what packages to file against
<tjaalton> gnome-shell?
<LLStarks> yeah
<tjaalton> that then :)
<LLStarks> ok
<LLStarks> thanks
<tjaalton> i could be wrong, but that's where to look for possible dupes
<chandler> Hello folks. I just updated to the most recent xserver-xorg-video-vmware (12.0.1) in precise, and it looks like XA is not enabled in this version of the package. Was this disabled for some reason, or should I file a bug? (Or none of the above?)
<bryceh> chandler, looks like -vmware got sync'd from debian, which dropped Robert's change to enable XA in the build, from 1:11.99.901-0ubuntu1 
<bryceh> chandler, so yes, please file a bug report, and assign to the canonical-x team if you could.
<Sarvatt> ah heck, sorry about that! bryceh would you be able to help me out with uploading the merge? i'll get it all ready
<Sarvatt> if we dont get reenabled in beta 2 there won't be 3D accelerated unity on the image, thats a pretty big feature to miss by mistake
<bryceh> Sarvatt, sure thing
<Sarvatt> (in vmware)
<bryceh> do we have -vmware in git?
<Sarvatt> yup
<Sarvatt> http://anonscm.debian.org/gitweb/?p=pkg-xorg/driver/xserver-xorg-video-vmware.git;a=summary
<Sarvatt> i'm just updating it now
<bryceh> cool
<Sarvatt> i didnt realize xatracker was disabled in debian but it makes sense because its in experimental still
<tjaalton> right, missed that
<Sarvatt> tjaalton: oh you're around still? ok if I push it UNRELEASED and you do the close/upload since thats so much easier? :)
<chandler> I created a bug report, but I can't assign it: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vmware/+bug/962599
<ubottu> Launchpad bug 962599 in xserver-xorg-video-vmware (Ubuntu) "xserver-xorg-video-vmware 12.0.1-1 disables 3D acceleration passthrough via XA (precise)" [Undecided,New]
<Sarvatt> chandler: thanks for that!
<Sarvatt> was just about to do that to add it to the changelog
<Sarvatt> well i'll just get it ready for sponsorship then, its late there :)
<Sarvatt> bryceh: http://kernel.ubuntu.com/~sarvatt/merges/vmware/ and its in git
<Sarvatt> bryceh: scratch that!!
<tjaalton> yeah still here
<Sarvatt> test building now
<Sarvatt> just pushed another change
<bryceh> pulling
<bryceh> 3df8bb3e ?
<Sarvatt> ok http://kernel.ubuntu.com/~sarvatt/merges/vmware/ is up to date and has a build log, so is git
<Sarvatt> bryceh: yep
<Sarvatt> tjaalton: i even test built it before, but the schroot i used wasn't clean, had libxatracker-dev installed already :( sorry about that
<bryceh> Sarvatt, uploaded
<Sarvatt> bryceh: thanks a million! that would have really sucked, glad chandler caught it :)
<bryceh> chandler, if you wouldn't mind please do an update in a couple hours (once it's done building and distributed to your mirror), install version 12.0.1-1ubuntu1, and verify it fixes the issue you saw
<bryceh> Sarvatt, yeah totally.  thanks chandler 
<chandler> Sure, of course.
<tjaalton> Sarvatt: heh, no worries.. sorry for not noticing that change myself
#ubuntu-x 2012-03-23
<chandler> bryceh: It's definitely fixed.
<bryceh> chandler, excellent, thanks.
<chandler> Is there anything I should mark on the bug report?
<bryceh> chandler, hmm, it should have closed automatically; what was the bug # again?
<chandler> It did get closed; it's 962599.
<bryceh> great
<ricotz> bjsnider, hi
<ricotz> bjsnider, could you push 295.33 to precise in xup ppa too in the meantime?
<johanbr> cnd, thank you for the clickpad support! just a question - is there a way to enable middle click?
<cnd> johanbr, meaning?
<johanbr> I was previously using an unofficial patch that sent a middle click when you clicked the lower middle of the touchpad (between left button area and right button area)
<cnd> ahh, yes, you can enable that
<cnd> you need to modify the soft button areas
<cnd> synclient is the easiest tool to use
<johanbr> ahh, alright, I'll have a look at that
<johanbr> thank you again!
<cnd> johanbr, synclient MiddleButtonArea*
<johanbr> right :)
<bjsnider> ricotz, yes i can
<Sarvatt> bjsnider: thank you for that, tseliot wont upload it until monday and people using proprietary drivers freak out if a day goes by without an update in the distro :)
<bjsnider> they probably aren't using x-updates though
<bjsnider> in precise that is
<Sarvatt> i got 2 emails already and said it should be in the distro on monday
<Sarvatt> (asking for it in x-updates)
<bjsnider> lol
<Sarvatt> lol indeed
#ubuntu-x 2012-03-24
<bjsnider> odd to use both an unstable distro and a ppa
<bjsnider> but they knows what they likes i guess
<Sarvatt> well its not as big a deal for fglrx because the stuff from amd.com works fine if you build debs, no options on nvidia :)
<Sarvatt> outside of learning how to package it yourself
<Sarvatt> and 295.20 is severely busted with gnome-shell
<Sarvatt> all fixed up in .33
<bjsnider> ok, sent in driver and nvidia-settings
<Sarvatt> bjsnider: if its a pain in the butt just dont bother, it'll most likely be up on monday
<bjsnider> from the looks of the build farm it will be built very quickly
<Sarvatt> holy crap, never seen the queue that empty
<Sarvatt> must not have been any kernel SRU's this week
<Sarvatt> they pull off the buildds to do SRU testing and the queues build up all the time :(
<bjsnider> it was backed up hours last night though
<cnd> bryceh, just to note, I'm ok with this weather :)
<cnd> btw, I may have a fix for bug 931397
<ubottu> Launchpad bug 931397 in xorg-server (Ubuntu Precise) "Xorg crashes with AutoAddDevices "false"" [High,Confirmed] https://launchpad.net/bugs/931397
<cnd> I found a couple input commits that use the new input option abi
<bryceh> cnd, told ya it'd turn around ;-)  the ball in the sky's only temporary though
<cnd> which bit us because the old input option abi had no type safety /o\
<bryceh> cnd, awesome!
<bryceh> cnd, aha, yeah we were wondering if something like that could be the case
<cnd> everything is passed around as opaque pointers for no good reason
<cnd> and then casted to the appropriate type inside the functions
<cnd> and the real issue, IIUC, is that the new abi is based on the general xf86Option abi
<cnd> rather than an input-specific option api
<cnd> so upstream just switched to using the general option api
 * bryceh nods
<cnd> if they had added or modified the option api, it might have been caught easier
<cnd> at least things will be better in the future :)
<bryceh> cnd, totally.  Any chance this might solve some of our other xserver bugs in precise?
<cnd> dunno?
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xorg-server?field.tag=precise&field.tags_combinator=ALL
<cnd> this particular bug only manifests at start up
<cnd> at device initialization time
<cnd> specifically master and Xtest device init time
<bryceh> well, once you have a solid patch lemme know and I can troll around a bit for bugs
<Sarvatt> cnd: thats freaking awesome, i've been going over the changes between the two abis trying to figure out what changed to make it work in 1.12 and not in ours and drawing frigging blanks
<cnd> need to revert these two commits in our packaging branch:
<cnd> 7ee1621364d2b6230bb1c02bbdb5b6abb74ad2ff.
<cnd> 4b7dd4523c11ef4952b78e4164b2fa7b34588867.
<cnd> bryceh, this could be related: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/946028
<ubottu> Launchpad bug 946028 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT "free(): invalid pointer" from xf86optionListFree" [High,Confirmed]
<bryceh> ok
<Sarvatt> oh no wonder i had no luck, i was looking for differences in NewInputDeviceRequest from hw/xfree86/common/xf86Xinput.c compared to our patched server
<Sarvatt> and am a dunce :)
<cnd> bryceh, what do you think we should do with this fix?
<cnd> I think it's a candidate for beta 2 freeze exception
<bryceh> I do too
<bryceh> cnd, is it literally just reverting those two commits?  or is any additional code needed?
<bryceh> if it's just reverts I think getting it in asap is the way to go
<cnd> just reverting those commits for this particular bug
<cnd> I can't guarantee there are no other issues lurking elsewhere though
<bryceh> otherwise, we might want to stick it in a ppa for extra testing first
<cnd> I think it's an obvious fix
<bryceh> cnd, ok
<cnd> one would hope that things couldn't get worse
<cnd> but we're dealing with type-unsafe pointer passing
<cnd> so it's possible that we fix one bug but expose a worse one
<bryceh> cnd, well the AutoAddDevices bug I'm actually not too concerned with as it's a really minor corner case
<cnd> bryceh, I'm not exactly sure why the autoadddevices option causes the bug though
<cnd> it may be that there are multiple ways to trigger it
<cnd> multiple conf file options
<Sarvatt> cnd: people wont be using xorg.conf's breaking things with the beta for the most part i wouldn't imagine, directly after beta 2 releases sounds good to me personally
<bryceh> cnd, but I think it's exposing a deeper problem, and I think you may have a hook into it.  I have a hope that if we can address what causes the xorg.conf problem it might shed light on some of the other SIGABRT bugs we've been getting lately
<bryceh> post-beta2 sounds like a good plan to me too
<cnd> I guess my main question is: why does it *only* appear when the option is used
<cnd> because the core and xtest devices are always created
<cnd> which is where this bug hits
<Sarvatt> then again, there will be respins up until monday probably
<Sarvatt> so maybe it would be ok to get it in, it is a good fix :)
<bryceh> yeah commit reverts generally tend to be unlikely to  cause regressions, sort of by definition :-)
<cnd> hmm... well, I'm testing it more
<cnd> and now my kb won't work :)
<cnd> oh right
<cnd> I have autoadddevices = false
<cnd> imagine that, it works after commenting that out :)
<bryceh> hehe
<Sarvatt> cnd: you're probably the only one who can judge how risky it is, from what i gathered from #ubuntu-desktop talk earlier it should be ok if you deem it really important before monday :)
<cnd> ok, I've committed the changes to the repo
<cnd> let me try to reason why it wasn't occurring during normal startup
<Sarvatt> i've got it building to test on all my machines just to make sure it doesn't screw up
<cnd> ok, I think I see what's going on
<cnd> if you don't have AutoAddDevices turned on, the server will instantiate core devices at startup
<cnd> oops, I mean it will instantiate a built-in default
<cnd> the core devices are always created
<cnd> but the issue is the built-in default
<cnd> the built-in default mouse driver is noted saved in xf86ConfigLayout.inputs
<cnd> then in InitInput, any saved devices are turned into real devices by creating xf86 input options
<cnd> and that's where we were using the wrong abi
<cnd> however, if we are instantiating devices normally, through hotplug, the built-in default isn't set up, and isn't created in InitInput
<cnd> it's created through some other mechanism that is probably *not* broken
<cnd> I think this would also apply to anyone who is specifying devices manually in xorg.conf
<cnd> are there any use cases for that?
<cnd> if not, then I propose leaving this till after beta 2
<cnd> bryceh, Sarvatt ^^?
<bryceh> cnd, yes leave to post-beta2
<bryceh> but yeah I think some of our bugs may well be from people specifying devices manually.  I'd have to review them to be sure though.
 * bryceh -> EOD
<cnd> bug 954745 is a dupe
<ubottu> Launchpad bug 931397 in xorg-server (Ubuntu Precise) "duplicate for #954745 Xorg crashes with AutoAddDevices "false"" [High,Fix committed] https://launchpad.net/bugs/931397
<FernandoMiguel> Boa noite
<Sarvatt> cnd: looks like its absolutely only for people manually using an xorg.conf to me, noone testing a beta 2 livecd or new install there will hit it, upgraders will still hit the same bug they've always had, uploading the day beta 2 releases would be just as good without the hassle IMO
<Sarvatt> in the same vein it wont affect autoconfig everyone using the livecd is using so its just as good to go in now though :)
<Sarvatt> its just, are the beta 2 livecds final now? i'm not sure how locked down things really are
<Sarvatt> the first thing someone installing mythubuntu beta 2 is going to try to do is configure their remote via xorg.conf
<FernandoMiguel> nite
<Sarvatt> -rw------- 1 sarvatt sarvatt 75M Mar 24 16:13 /home/sarvatt/.xsession-errors oh fun
<Sarvatt> almost all grail warnings
<Sarvatt> GRAIL WARNING (v3/gesture.cpp:CheckOwned:290): failed to get touch 100 from frame, gesture 1199 marked as not owned
<Sarvatt> GRAIL WARNING (v3/slice.cpp:GetValues:199): failed to get touch from frame
<Sarvatt> GRAIL WARNING (v3/slice.cpp:GetValues:199): failed to get touch from frame
<Sarvatt> GRAIL WARNING (v3/slice.cpp:GetValues:230): failed to get touch from frame
<Sarvatt> GRAIL WARNING (v3/slice.cpp:GetValues:230): failed to get touch from frame
<Sarvatt> GRAIL WARNING (v3/slice.cpp:CheckGestureEnd:392): failed to get touch from frame by id
<Sarvatt> GRAIL WARNING (v3/slice.cpp:CheckGestureEnd:392): failed to get touch from frame by id
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/utouch-grail/+bug/964135
<ubottu> Launchpad bug 964135 in utouch-grail (Ubuntu) "Grail warnings are excessively verbose in ~/.xsession-errors" [Undecided,New]
#ubuntu-x 2012-03-25
<Sarvatt> pheeeew, so many X bugs about the unity-3D issue. vanvugt rocks for duplicating so many of these already
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/963633 https://bugs.launchpad.net/unity/+bug/963093 https://bugs.launchpad.net/oem-priority/+bug/949296 covers the vast majority of X bugs in the past week
<ubottu> Launchpad bug 963633 in unity (Ubuntu Precise) "Unity 5.8: Login to blank screen (all black or just wallpaper)" [Critical,Confirmed]
<ubottu> Launchpad bug 963093 in unity (Ubuntu Precise) "Unity 5.8: Flickering and corruption on Unity UI elements" [Critical,Confirmed]
<ubottu> Launchpad bug 949296 in gnome-settings-daemon "gnome-settings-daemon always prevents suspend when proprietary nvidia drivers are used." [Medium,In progress]
<Sarvatt> Darxus: err, your bug is with the nvidia blob, you need to use nvidia-settings to change resolutions I believe not the gnome display settings dialog?
<Sarvatt> Darxus: i think you got caught in some bug bot wars reassigning things automatically :P
<bjsnider> both can change resolutions
<Sarvatt> not refresh rate though apparently, thats what i meant
<Sarvatt> well his bug was that the gnome one shows it as an unknown monitor
<bjsnider> it does do that
<Darxus> Sarvatt: I was also seeing it with nouveau.
<Darxus> Sarvatt: And I don't see it with nouveau when I boot back to oneric.
<Darxus> Sarvatt: My problem, I believe, is that my monitor is not being detected properly.  With either driver.  
<RAOF> cnd: Whom do I have to bribe with beer to get 3-finger-tap-as-middle-click working again?
<Sarvatt> RAOF: thought that was disabled intentionally to never return?
<Sarvatt> interferes with gestures?
<johanbr> synclient ClickFinger3=2 doesn't help?
<Sarvatt> maybe if you ClickPad=0 first
<Sarvatt> (me is just guessing he's referring to his magic trackpad)
<johanbr> Speaking of multi-finger things, what's the likely culprit if geistest says "error subscribing to gestures"?  some daemon not running?
<johanbr> RAOF, I just discovered tapping at the top right gives me middle click, I don't know if that's an acceptable substitute
<RAOF> FREAKY!
<RAOF> Bah.  Heaven forfend that the kernel could dump some sort of state to disc before hard-freezing.
<bjsnider> has that ever been discussed?
<bjsnider> it would seem like a good idea
<bjsnider> kind of obvious
<RAOF> The obvious trouble is: when you've hard-locked, you're broken.
<bjsnider> the windows kernel does that
<cnd> Sarvatt, RAOF, it's disabled by default, but you can enable it with synclient TapButton3=2
<cnd> you don't need to disable clickpad support
<RAOF> Cool.
<cnd> johanbr, it's probably attempting to subscribe on the root window
<cnd> but only one utouch client can subscribe to a window at the same time
<cnd> and if you're running unity, then unity already has a subscription
<johanbr> cnd, ahh... 
<cnd> so you want to use geistest with the -w option to specify a different window
<cnd> bjsnider, there have been many attempts over the years to save state to disk when a kernel oopses
<cnd> many of them are even in the mainline tree I think
<cnd> one or two may be compiled into the ubuntu kernel
<cnd> but they require manual setup
<johanbr> I think I've seen a kernel patch that writes some state to nvram...
<cnd> and sometimes are hardware and environment specific
<cnd> cking actually added a patch to save a limited backtrace hash to the hw clock
<cnd> since the hw clock is maintained across boots
<Sarvatt> oh god that patch was so screwy
<johanbr> oh, that's probably what I'm thinking of
<cnd> Sarvatt, yeah, it's a really interesting piece of debug work
<cnd> cking does crazy stuff
<Sarvatt> it screwed up your time, completely breaking vblank timestamps next boot :)
<cnd> like outputting console over speakers using binary code, and using a mic from another computer to turn it back into a visual console
<cnd> or flashing your caps lock leds to diagnose suspend/resume problems
<RAOF> Now *that's* an awesome hack.
<cnd> RAOF, http://smackerelofopinion.blogspot.com/2011/08/debugging-s3-suspendresume-using.html
<RAOF> Yeah, I know it.
<cnd> anyways, it's still my sunday, so I'm going to stop chatting on irc and go play video games :)
<RAOF> Excellent plan!
<Sarvatt> on a tales of graces f break here :)
<johanbr> Hmm, geistest refuses to register anything, though... I wonder if that's because I'm using a clickpad
#ubuntu-x 2013-03-18
<Sarvatt> mlankhorst: nope thats too recent, armhf has been broken over a month
<Sarvatt> plus the patch is from our packages :)
<mlankhorst> Sarvatt: it's the patch we used for fixing up 9.1 branch :P
<mlankhorst> ah well lets see if I can build mesa on panda without running into oom killer
<RAOF> Hah!
<mlankhorst> over nfs, no less!
<tjaalton> hmm, some kernel regression on intel
<tjaalton> in -13
<mlankhorst> awesome
<mlankhorst> oh indeed mesa is a different error
<mlankhorst> what do we need from mesa on arm though? I can only imagine softpipe being useful in it's current state
<mlankhorst> maybe once robclark's free arduino driver works that would change
<ogra_> swrat has always worked ... just urlta slow
<ogra_> *swrast
<ogra_> bah
<ogra_> *ultra
<mlankhorst> I know but is there any point building anything but swrast?
<ogra_> theoretically llvmpipe ... but last time i tried it was unusable
<ogra_> no idea if there were any improvements since quantal
<mlankhorst> llvmpipe in general, or llvmpipe on arm?
<ogra_> on arm indeed
<mlankhorst> I don't know, lets see..
<ogra_> my x86 machines have proper drivers :)
<ogra_> (most of my arm ones too ... but most of them arent distributable ...)
<mlankhorst> nothing arm specific in llvmpipe
<mlankhorst> so it would have to be in llvm-3.2
<ogra_> then i doubt it makes sense to have it right now ...
<ogra_> after all most of the arm world will likely be Mir'ed andyway and use android drivers soon
<ogra_> i think we'll only keep the tegra3 binary stuff around in the long term ... for desktop reference images on the nexus7
<ogra_> (FSVO long term .... read that as  until 14.04)
<mlankhorst> I want to be able to run without blobs, even if the result may not be as performant
<ogra_> as performant ... heh
<ogra_> usually its unusable ... 
<ogra_> (like an animated slideshow)
 * mlankhorst had to disable smp because it kept bugging :/
<ogra_> on your panda ?
<mlankhorst> yeah
<mlankhorst> black screen, then everything gone
<ogra_> hmm, what release ?
<mlankhorst> precise
<ogra_> hmm, havent seen such issues on mine with precise
<mlankhorst> do you have the ti-omap ppa enabled?
<ogra_> ugh, no
<ogra_> using the in archive stuff indeed
<ogra_> the ppa is only intresting for video codecs ... 
<ogra_> which we cant have in the archive due to incompatible gstreamer patches
<mlankhorst> :D
<mlankhorst> it enables some other stuff like bluetooth support iirc
<ogra_> well, it also ships a TI kernel that might have breakage we dont know about 
<ogra_> (like SMP perhaps ?)
<mlankhorst> probably
<mlankhorst> could also be the powervr drivers
<ogra_> well, panda desktop is on the way to be out to death anyway ...
<ogra_> s/out/put/
<mlankhorst> yeah but as long as it's alive it's useful for testing mechanics on arm
<mlankhorst> tjaalton: hah my fix worked
<mlankhorst> http://paste.ubuntu.com/5624961/
<mlankhorst> fixes building on armhf
<mlankhorst> no idea about armel
<mlankhorst> do we still support that?
<mlankhorst> dh_install: libgl1-mesa-dri missing files (dri/usr/lib/arm-linux-gnueabihf/libllvmradeon*.so), aborting
<mlankhorst> oops, almost :)
<ogra_> mlankhorst, nexus7 is better for testing mechanics
<mlankhorst> except I leave my panda on 24/7 ;)
<ogra_> pandas are great as builders ... but due to the driver situation we'll drop them soon
<ogra_> for UI testing the nvidia stuff simply works better and causes way less maintenance
<mlankhorst> yeah but the wired network is nice, I keep all my stuff on nfs
<mlankhorst> and doing that over wireless is crazy
<ogra_> yeah, true 
 * ogra_ would love to see us supporting chromebooks ... but there the driver situation is even worse ... 
<ogra_> you would have USB 3.0 though 
<ogra_> so it pfferse some decent disk throuoghput ...
<ogra_> *offers
<mlankhorst> ok armhf built..
<mlankhorst> raring no longer supports armel right?
<ogra_> support was dropped in precise
<ogra_> ( we still left it building alongside but it wasnt an official arch ... with quantal the archive completely vanished)
<mlankhorst> looks like quantal still had some.. https://launchpad.net/ubuntu/quantal/armel
<mlankhorst> raring otoh 0
<mlankhorst> ah well I'm not going to worry about ftbfs then, I'll just disable building llvm-3.2 and mesa renamed for armel if it hapens
<ogra_> yeah, just ignore it 
<ogra_> we dont encourage anyone to ever use armel :)
<mlankhorst> but andwoooidddd
<tjaalton> mlankhorst: yeah, sounds like a valid fix..
<ogra_> what about android ? :)
<mlankhorst> tjaalton: yeah I should probably figure out why st_gl_api_create is in libmesagallium, but meh!
<mlankhorst> oh fun, I get to run piglit again 6x
<fexilal> Greetings
<fexilal> are the nvidia 310 series drivers going to be included soon?
<bjsnider> included in what
<fexilal> in ubuntu-x-swat
<mlankhorst> isn't it already in the archive though?
<fexilal> nope, the latest version in the archive (that I can find) is 304.84
<bjsnider> fexilal, search for nvidia-experimental-310
<bjsnider> you have to have hardware that is not too old
<bjsnider> no support for hardware before the geforce 8
#ubuntu-x 2013-03-19
<mlankhorst> raof ping?
<RAOF> raof pong?
<mlankhorst> piglit no longer works nicely on my system and seems to be hanging on nouveau, which makes mre verification for mesa 9.0.3 hard
<mlankhorst> however there have been 0 nouveau related commits between 9.0.2 and 9.0.3, so is it ok if i skip piglit for nouveau?
<RAOF> Uuuuum.
<RAOF> Can we get someone else to try piglitting nouveau?
<mlankhorst> doubtful
<RAOF> I'm not entirely sure âour test suite no longer runs on $HARDWARE, but I'm pretty sure that's an unrelated failureâ is a good standard for MRE :)
<mlankhorst> RAOF: it no longer runs on 9.0.2 either :P
<RAOF> mlankhorst: You're not filling me with confidence :)
<mlankhorst> RAOF: I'm going to need a time machine for this one, from the dmesg output it feels like I'm hitting a kernel regression
 * RAOF <shudders>
<mlankhorst> I'm running with some crack kernel though
<RAOF> Maybe running piglit on the stack that we're trying to test would be appropriate? âº
<tjaalton> yeah.. :)
<mlankhorst> but but hybriddddd
 * mlankhorst tries
<mlankhorst> g
<mlankhorst> [  137.761860] [drm] nouveau 0000:01:00.0: PFIFO_CACHE_ERROR - Ch 4/3 Mthd 0x1b04 Data 0x20211000
<mlankhorst> [  137.761949] [drm] nouveau 0000:01:00.0: Unexpected pageflip in channel 4.
<mlankhorst> ugh
<mlankhorst> removing parallelism seems to help slightly
<mlankhorst> probably that's what I did before
<mlankhorst> yep without running in parallel, it's fine
<mlankhorst> RAOF: ^ solved, doing nouveau tests again now
<bjsnider> any major borkage on intel/raring at the moment?
<bjsnider> snb specifically
<bryce> bjsnider, tghe usual gpu hangs and such - http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-raring-workqueue.svg
<bjsnider> there's a guy over in the other channel having a problem. i'll send him here if he rejoins
<tjaalton> bjsnider: make sure he updates to kernel -13.23 first
<tjaalton> a couple of stable commits reverted in that one compared to .22
<tjaalton> that caused issues
<tjaalton> aka http://lists.freedesktop.org/archives/intel-gfx/2013-March/025767.html
#ubuntu-x 2013-03-20
<mlankhorst> morning
<RAOF> mlankhorst: Good morning.
<Sarvatt> RAOF, mlankhorst: good morning you crazy time zone people guys :)
<mlankhorst> hah!
<swelogan>  Hi, new here. I have some problems with my touchscreen. I get data from ttyS4 and when i run Calib. I can here "beeb" sound when i touch the point. But when i am finish it says: Base Point Data: 3968 128. And then "Can't find a touch screen"
#ubuntu-x 2013-03-21
<mlankhorst> morning
#ubuntu-x 2013-03-22
<hyperair> Sarvatt: ping
<hyperair> Sarvatt: regarding that hardware enablement pack... have you tried dist-upgrading a machine with -lts-quantal from precise to quantal?
<hyperair> there aren't any -lts-quantal packages on quantal, and the upgrader doesn't shift things back to the core packages.
<tjaalton> there should be conflicts in place?
<tjaalton> mlankhorst: ^
<tjaalton> though he's off today
<mlankhorst> it's not supported
<mlankhorst> end of story :P
#ubuntu-x 2014-03-17
<mlankhorst> check power draw I guess
#ubuntu-x 2014-03-18
<nerochiaro> hi everyone, i'm trying to get a magic touchpad device to work with ubuntu, and while unity seems to recognize 3- and 4-finger touches it seems to ignore any other gesture. any pointers where to start looking ?
<RAOF> nerochiaro: What other gestures are you trying? IIRC those are pretty much the set of supported ones.
<nerochiaro> RAOF: isn't there a 3finger swipe to switch windows or workspaces ?
<RAOF> I don't think so?
<RAOF> You *used* to be able to use 3-fingers to move windows around, but I think that gesture got dropped.
<RAOF> Too few people have touchpads capable of tracking more than one finger :(
<mlankhorst> I really?
<nerochiaro> RAOF: i see. and is there any test app i can use to verify that other multitouch events are actually recognized and sent to windows ?
<RAOF> nerochiaro: âxinput test-xi2â will show all the touches X sees (as different valuators)
<nerochiaro> RAOF: i dont' seem to be getting any event for 2 finger gestures. 3 or more generate TouchUpdate events
<RAOF> Hm. 2 fingers might be translated into scroll events, I forget.
<nerochiaro> RAOF: and 2 finger pinch is what i really need to test
<nerochiaro> RAOF: doesn't seem like the case, or at least windows with scroll bars don't seem to react to them
<nerochiaro> and xinput doesn't show them as scroll neither
<Prf_Jakob> Is bug 1293384 a known bug?
<ubottu> bug 1293384 in Compiz "Compiz CPU usage dramatically increased in Ubuntu 14.04" [Undecided,New] https://launchpad.net/bugs/1293384
<tjaalton> guess so
<tjaalton> maybe try #ubuntu-unity?
<mlankhorst> Prf_Jakob: haven't heard of it, but it could be due to unity blur effects
<Prf_Jakob> Okay thanks
<tjaalton> right
<tjaalton> it should be possible to drop some effects for such cases
#ubuntu-x 2014-03-19
<shadeslayer_> I seem to have alot of corruption with X + i965
<shadeslayer_> on Trusty
<shadeslayer_> http://wstaw.org/m/2014/03/19/plasma-desktopkh2108.png & http://wstaw.org/m/2014/03/19/plasma-desktopUR2108.png
<Sarvatt> mesa bug with kde, just saw that reported upstream yesterday.. lessee if i can find a bug number
<shadeslayer_> thx
<Sarvatt> darn, they just reported it in irc and didn't file a bug.. any chance you could run ubuntu-bug xserver-xorg-video-intel and attach the screenshots?
<shadeslayer_> sure
<shadeslayer_> Sarvatt: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1294666
<ubottu> Launchpad bug 1294666 in xserver-xorg-video-intel (Ubuntu) "Multiple graphical artifacts in KDE with i915 driver" [Undecided,New]
<shadeslayer_> weird that it didn't attach lscpi output
<Sarvatt> shadeslayer_: huh, thats odd.. can you try apport-collect -p xorg 1294666 ?
<tjaalton> just install xdiagnose first
<Sarvatt> oh!
<tjaalton> kubuntu doesn't, since it has a gtk gui
<Sarvatt> so xdiagnose isnt seeded in kubuntu?
<tjaalton> no
<Sarvatt> yuck
<shadeslayer_> okay
<shadeslayer_> Sarvatt: enospace :(
<Sarvatt> shadeslayer_: /var/log/Xorg.0.log /var/log/kern.log and the output of dpkg -l should be enough if you want to attach it manually
<shadeslayer_> Sarvatt: sending via apport
<Dandel> ricotz: how hard would it be to push a single package into the ubuntu-xorg edgers repo? ( to satisfy a build dependency change in piglit )
<Dandel> I figure that it probably would be safe to update the package opencl-headers and then add the ocl-icd package to precise. This is to enable the OpenCL Driver support for amd and nvidia on precise, and also enable building the OpenCL tests on piglit.
<ricotz> Dandel, to be more specific, you are talking about backporting khronos-opencl-headers?
<Dandel> ricotz: the headers and the package ocl-icd
<Dandel> to be exact, the two packages that need backporting are... ocl-icd-libopencl1 and ocl-icd-libopencl1-dev
<Dandel> and the opencl headers can be just copied over from the latest
<ricotz> i see, "ocl-icd" is the source package
<Dandel> version 2.1.3 and 2.0.2 build without any faults if you provide an opencl 1.2 header package
<Dandel> the only changes to piglit would be to set PIGLIT_BUILD_CL_TESTS to true and to make sure it depends on whatever package provides libOpenCL.so 
<ricotz> Dandel, i might take a look
<Dandel> mesa 10.0 ( and up ) has an opencl ICD ( requries --enable-opencl-icd )
<mlankhorst> yeah but it's disabled in ubuntu
<mlankhorst> reverted in commit 0a7a1c90922c962af7876f5f47802b43665bb446
<mlankhorst> it required some stuff not in main
<Dandel> I know that the OpenCL Support in mesa is relatively new ( the icd support was added around august of last year )
<Dandel> I do believe that it probably would not hurt to enable the opencl layer in general seeing as how the proprietary drivers have opencl and there is alternative ( cpu-based ) implementations that can make use of the features.
<Dandel> I know that one of the implementations ( http://portablecl.org/ ) just requires that the computer have llvm 3.2 or newer
#ubuntu-x 2014-03-20
<ara_> Hello! Anybody with experience with xinput? qengho is working in trying to make Chromium touch friendly, and he is finding impossible to get 2-finger pinch working in a multitouch touchpad
<qengho> Hi all. I'm interested in making an app support pinch gestures, and it works on direct-mode touch devices like touch screens, but on dependent-mode touch devices like touch pads, I don't see a way to get touch events for two-finger gestures. I *think* this is some ancient scroll-support hack in the way. Is there a way to get xinput2 two-finger touch events out of a touchpad?    /ping ara
<ara_> tseliot: any ideas?
<tseliot> ara_: you might want to talk to RAOF about that
<tseliot> not really my field
<ara_> qengho: you "may" overlap a bit with RAOF later today
<ara_> qengho: maybe you can sending an email CC'ing me just in case we don't overlap in time?
<qengho> On it.
<tjaalton> phoronix keeps on giving http://www.phoronix.com/scan.php?page=news_item&px=MTYzNzQ
<mlankhorst> rofl
#ubuntu-x 2014-03-21
<qengho> RAOF: Hi, we're trading email about touchpads and XI2 touch events.  IRC may be quicker.
<RAOF> qengho: Sure.
<qengho> RAOF: I really want your nick to be ROUS, every time I read it.
<RAOF> qengho: If it makes you feel any better, it stands for Running Around On Fire.
 * RAOF 's cooperteam.net domain name may suggest the origin of that for the owner of sufficiently exotic trivia :)
<qengho> That does comfort me.
<qengho> RAOF: I don't know the trivia, but sounds like some racing mishap.
<RAOF> qengho: So the problem is indeed that synaptics isn't giving you two-finger touches, and is instead returning scroll events?
<RAOF> ie: evdev worked?
<qengho> RAOF: Right.
<RAOF> So, this is where input becomes terrible.
<qengho> I can paste the events it *does* show, if you'd like.
<RAOF> For evdev, or synaptics (or, I guess, both :))
<RAOF> Yeah, the events might be interesting.
<qengho> Er, I don't know what "synaptics" means.
<RAOF> Oh, the synaptics driver.
<RAOF> ie: before you deleted the âload synaptics for touchpadsâ xorg configuration.
<RAOF> But, in general - Peter Hutterer is the maintainer of synaptics, and would prefer very much to do gestures in-driver. Because you can't assume that clients will handle them, and sending both raw touches and synthesised scroll events becomes awkward.
<RAOF> I'm not _entirely_ sure that we can't do that sensibly, though. I'd like to try anyway :)
<qengho> RAOF: http://pastebin.ubuntu.com/7128187/     Unmodified xorg config, two-finger pinch.
<qengho> I'll have to go away and fabricate the other one.
<qengho> Modified to have no synaptics driver, I mean as other.
<RAOF> Right.
<qengho> Right, you need it? 
<RAOF> I'd be interested to see it, but I could also get the same thing by charging some batteries, pairing my magic touchpad, and seeing whether it still panics my kernel.
<RAOF> And in that log you're seeing all the events on valuators 2 and 3, which are v. scroll and h. scroll respectively.
<qengho> Oh, I had that same problem, kernel panic.  Thinkpad?
<RAOF> System76
<RAOF> I think it's a bug in hid-magicmouse.
<qengho> Huh. I'm on a Darter.
<RAOF> Galago here.
<qengho> ...now.
<qengho> Back in 5min.
<qengho> ROUS: Well.  Commenting everything out isn't right. Builtin trackpad doesn't do anything.
 * qengho restarts X.
<qengho> RAOF: I'm realizing I don't really know what you wish me to change.
<RAOF> qengho: Oh. I wanted you to delete /usr/share/X11/xorg.conf.d/50-synaptics.conf and restart X; that'll switch your touchpad to using evdev, which definitely won't eat events to synthesise other events.
<qengho> RAOF: I didn't delete, but I added "#### " to the start of every line.  That made neither builtin nor APPL bluetooth pad work.
<RAOF> Hm, that shouldn't happen.
<qengho> RAOF, right now, I added a new section that tries to match the device and assign it Driver evdev before the first one assigns synaptics.  I don't think it's doing what I expected. Perhaps it's not matching.
<RAOF> Yeah, you'd need to do the matching *after* the synaptics one.
<RAOF> (/var/log/Xorg.0.log should show you which driver is getting loaded)
<qengho> I did it there too. I'm thorough.
<RAOF> I'm surprised that commenting out 50-synaptics.conf didn't work; evdev should still match in that case. Maybe could you throw me your Xorg.0.log at some point?
<qengho> Comment all, get log?
<RAOF> Yeah, thanks.
<Sarvatt> you're going to need to force it to evdev for it to work, synaptics wont work unless its a non synaptics touchpad that works with it like a macbook one, seems like a lost cause
<qengho> RAOF: log, conf lacks 50-synaptics.  http://pastebin.ubuntu.com/7128307/
<RAOF> Sarvatt: I think synaptics doesn't report TouchBegin/.../TouchEnd for two-fingers, right?
<qengho> At three, it magically wakes up and starts reporting. It decided it wasn't a scroll request.
<RAOF> Right.
<RAOF> My magic touchpad agrees.
<RAOF> qengho: So, the answer is - ugliness.
<RAOF> I think for the moment you get to assume that you won't get two-finger touch data on touchpads, and give up on getting pinch & such to work :(
<qengho> Is the long answer, kill kill kill the old scroll hack and make every client xi2-aware?
<RAOF> Well, and also the _new_ scroll hack.
<qengho> Oh. I didn't know there was a new one.
<RAOF> Yeah, rather than translating to buttons we translate to scroll axes - which is why you can get smooth scrolling support.
<qengho> So. .....so! I kind of reckon that a UDS immediately after 14.04 is a perfect point to propose this.
<RAOF> But this needs core input support - we can't send both synthesised scroll events and touch events, because clients won't be expecting it.
<RAOF> Can I interest you in getting this to work on Mir instead? :)
<RAOF> Hm. Maybe it wouldn't be _so_ terrible in X.
<qengho> I don't know anything about mir. I'm some browser guy
<RAOF> I think the answer is that it should actually just work in Mir - check out racarr's Chromium-on-Mir work.
<qengho> I keep meaning to merge that and get it into upstream.
<qengho> And, that's good news.
<RAOF> I should _keep_ it working on Mir, too.
<RAOF> :)
<RAOF> Hey! It looks like magic trackpads no longer panic my kernel. Bitchn'!
<qengho> I'm taking credit for that.
<qengho> RAOF: Okay. So, 1a) give up on synaptics pinch. 1b) break the bad news to ara and manager-y people.  2) get mir patches into chromium, first local, then upstream. 3) something about future driver or clients or something that I don't understand and will leave to you.
<qengho> RAOF: thanks for your time.
<RAOF> qengho: No problem!
<qengho> Summary in email to ara.
<RAOF> Which I will be receiving shortly, I guess? :)
<qengho> Now, I must go fall unconscious and hallucinate for 8 hours.
<qengho> Strange we think that's normal.
<qengho> Laters.
<RAOF> Sleep well!
<RAOF> Hey! Looks like Chrome managed to wedge i915 pretty good.
<mlankhorst> RAOF: known bug i think
#ubuntu-x 2015-03-16
<furkan> mlankhorst: i'm terribly sorry if this is a noob question, but i added the x-staging ppa using add-apt-repository, and also by manually editing sources.list, but it never shows up when i do apt-get update and it can't locate xorg-server-lts-vivid even though you've already put it up
<furkan> i also added "deb http://ca.archive.ubuntu.com/ubuntu/ trusty-proposed main restricted multiverse universe" to my sources.list since it's listed as a dependency for the x staging ppa
<furkan> just wondering if there's something that i'm overlooking...
<furkan> mlankhorst: is it a mistake that it's called xorg-server-lts-vivid, instead of xserver-xorg-lts-vivid?
<furkan> not that i'm blaming my problem on the package name, but just noticed the different naming scheme
<mlankhorst> no idea.
<mlankhorst> probably in error :P
<mlankhorst> xorg-server-lts-vivid is the source name at least
<mlankhorst> furkan: no it's still correct, you're confusing names..
<furkan> mlankhorst: have you installed it yourself on trusty?
<furkan> when i do an apt-cache search for lts-vivid, nothing shows up
<mlankhorst> not yet..
<mlankhorst> I only just uploaded it
<mlankhorst> it's in x-staging and not in -proposed for a reason..
<furkan> lol yeah i noticed, didn't mean to badger you, was just confused why i couldn't see the packages
<furkan> i checked to make sure the amd64 packages were built, but it looks like they are so that's not the issue
<mlankhorst> fwiw I do see a xserver-xorg-lts-vivid..
<furkan> ah
<furkan> i removed it and added it back, for like the 3rd time, and now i can see the packages *facepalm*
<mlankhorst> yeah
<mlankhorst> it wants to upgrade if I install xserver-xorg-lts-vivid libgl1-mesa-glx-lts-vivid:i386..
<mlankhorst> .. I'm actually crazy enough to test..
<furkan> mlankhorst: me too, i'm almost done installing
<furkan> if you don't hear back from me in a couple of minutes it means i'm in a recovery console reverting everything :P
<mlankhorst> it works..
<furkan> yeah, survived the reboot test here too
<furkan> thanks for putting it up :)
<furkan> so far i'm not seeing any corrupted characters like i was before... so i hope that means it's settled
#ubuntu-x 2015-03-17
<alkisg> Hi, when I boot an office PC the USB mouse doesn't work. It does show up in lsusb and it *does work* if I unplug and re-plug it, so I'm thinking it might be a xorg issue. Any troubleshooting tips? Ubuntu 14.04, 64 bit, i5 system, microsoft mouse. The mouse works fine in windows as well.
<tjaalton> input issues are kernel bugs
<tjaalton> try evtest, if you don't see events then that's a kernel bug for sure
<tjaalton> or bios
<alkisg> xev didn't produce events
<tjaalton> or hw
<alkisg> I'll try evtest, thanks
<alkisg> Yup, evtest doesn't list the mouse as an input device even though lsusb does show it. After unplug/re-plug it works. I'll check with #ubuntu-kernel
<smallfoot-> Why does X.Org Server run as root?
<smallfoot-> Why does not X.Org server run without root privileges?
<smallfoot-> When will CVE-2015-180[2,3,4] get patched? http://lists.freedesktop.org/archives/xorg/2015-March/057236.html
<furkan> smallfoot-: you might find this informative/useful https://wiki.ubuntu.com/X/Rootless
<smallfoot-> thanks furkan 
<smallfoot-> furkan, last edited 2010 lol
<furkan> smallfoot-: yeah a lot of those help pages are pretty old, but i think that one is still accurate RE: the non-free drivers not supporting KMS
<furkan> *wiki pages, rather
<smallfoot-> but I heard that Fedora runs X without root
<smallfoot-> at least with the drivers that support it
<smallfoot-> I wish Ubuntu did too
<tjaalton> no it doesn't
<tjaalton> not by default anyway
<tjaalton> https://bugzilla.redhat.com/show_bug.cgi?id=1078902 still open
<ubottu> bugzilla.redhat.com bug 1078902 in Changes Tracking "Xorg without root rights" [Unspecified,New]
<smallfoot-> Oh, I thought it was already fixed
<smallfoot-> Is there any similar bug filed against Ubuntu on Launchpad?
#ubuntu-x 2015-03-19
<mck182> hello, I was sent here with a strange problem with *buntu since about 13.10 (currently I'm running 15.04latest) - when I switch to tty1, my whole screen turns just red after about 5 seconds and stays red, it's not frozen but just red (and thus unusable), switching to vt7 and back fixes it...for 5 seconds
<mck182> first of all is this a good channel to ask about this and second, any ideas what that might be about? :)
<tjaalton> mck182: what driver/hw?
#ubuntu-x 2015-03-22
<ricotz> mlankhorst, hi :), the conflicts/provides of libgbm1-lts-utopic and libgbm1-lts-utopic-dbg are *empty*
<ricotz> looking at 10.3.2-0ubuntu1~trusty2
<ricotz> http://paste.debian.net/plain/162581
<mlankhorst> that's fine
<mlankhorst> ricotz: try that and see what happens..
<mlankhorst> really
<mlankhorst> if you tried it you would know why I did that
<ricotz> mlankhorst, ah sorry, and I tried it after
<mlankhorst> yeah, removing most of desktop was not a great idea. :)
<ricotz> mlankhorst, have you checked some rdepends of libgdm-dev by any chance? like libcogl-dev
<mlankhorst> no idea
<mlankhorst> probably works
<mlankhorst> just use the unrenamed -dev packages, you just won't see the new symbols
<ricotz> mlankhorst, right, but if you decide to "develop" on trusty HWE you are not able to install it
<ricotz> loosen the mesa deps of clutter/cogl helps a bit but gbm is a problem
<ricotz> mlankhorst, I am going to try to workaround it somehow
<mlankhorst> you can install the unrenamed -dev packages from -proposed
<ricotz> mlankhorst, will test this, thanks
#ubuntu-x 2016-03-21
<tseliot> ricotz, mamarley: I have 364.12 already packaged. Are you interested? http://www.nvidia.com/download/driverResults.aspx/100577/en-us
<ricotz> tseliot, yes, is the wayland support working?
<tseliot> ricotz: I enabled that but I haven't had the chance to test it yet
<tseliot> (it's disabled by default)
<ricotz> tseliot, sudo cat /sys/module/nvidia_drm/parameters/modeset ?
<ricotz> tseliot, could you put your package somewhere?
<tseliot> just the debs or the sources too?
<ricotz> the source of course
<ricotz> people.ubuntu.com or so
<tseliot> I can do that
<ricotz> thanks!
<ricotz> tseliot, I assume vulkan is working fine though?
<tseliot> it should (the code is there). I haven't tested that though. 
<tseliot> sudo cat /sys/module/nvidia_drm/parameters/modeset
<tseliot> N
<tseliot> I have a udev rule that passes modeset=1
<ricotz> tseliot, I see, was about to ask that
<tseliot> ricotz: oh, wait, I actually packaged a private pre-release. 364.12 is newer. I'll update to that
<ricotz> tseliot, let me know when abd where I can grab the package
<ricotz> ah ok
<ricotz> just push the debian.diff.gz then
<tseliot> no tarball?
<ricotz> I can grab the *.run's too if you don't have it yet
<ricotz> tseliot, better use http://us.download.nvidia.com/XFree86/Linux-x86_64/364.12/NVIDIA-Linux-x86_64-364.12-no-compat32.run
<tseliot> yes, that wasn't available when I packaged it
<tseliot> I'll do it now
<tseliot> debian/rules get-orig-source FTW!
<mamarley> Ooh, where is the package?  (I actually checked to see if there were any NVIDIA updates available this morning but didn't see that one.)
<mamarley> And DRM-style KMS support too!  I wonder if this means we can finally have a proper accelerated high-resolution console...
<tseliot> I'm trying to upload that but ssh is giving me all sorts of troubles...
 * mamarley slaps tseliot's ssh around a bit with a large trout.
<tseliot> :D
<mamarley> tseliot: Did you package nvidia-settings 362 as well, or should I do that?
<tseliot> mamarley: no, I didn't
<mamarley> OK, I will do it then.
 * tseliot reboots
<mamarley> jcastro: Did you hear that the latest NVIDIA driver (364.12) supports DRM KMS, Vulkan, and apparently native PRIME too?
<jcastro> mamarley: yes, it sounds awesome.
<jcastro> mamarley: And this morning my PSU went bye bye, so I have to RMA it, etc.
<jcastro> I am stuck on laptops for a while
<ricotz> mamarley, jcastro, hey :)
<mamarley> Hi :)
 * ricotz reboots
<mamarley> tseliot: Any luck with the upload?  If not, you could just post the debian.tar.gz somewhere and one of us could upload it.
<tseliot> mamarley: err, no, I can't access any of the canonical systems at the moment. I'm trying to solve the problem first
<mamarley> OK
<tseliot> mamarley, ricotz: my ssh connection is ok now. I'm uploading here (it should take a few minutes) http://people.canonical.com/~amilone/nvidia/
<mamarley> Yay!  nvidia-settings gave me a bit of trouble.  They changed how their binaries get stripped, which caused an FTBFS.  I had to rejigger a couple of patches.  Almost done...
<tseliot> :/
<mamarley> ricotz: What difference do we have on 361 between Wily and Xenial?  It is just the EGL alternatives, right?
<ricotz> mamarley, I think so
<mamarley> Cool, thanks!
<ricotz> tseliot, first no transitional packages for the ppa ;)
<mamarley> ricotz: I can handle that. :)
<ricotz> tseliot, nvidia_drm must be loaded first to respect the modeset=1 arg otherwise nvidia_modeset will auto-load it as dependency?
<ricotz> tseliot, please add libwayland-dev to the build-dep instead of ignoring shlibs-dep, what happened to "#NVIDIAEXTENSION#/libglx.so.#VERSION# #NVIDIAEXTENSION#/libglx.so"
<ricotz> I am calling it a day
<tseliot> ricotz: I'll do it tomorrow
<soee> http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-364.12-Linux
<soee> :)
 * mamarley slaps soee around a bit with a large trout.
 * soee :)
<mamarley> soee: If you dare, https://launchpad.net/~mamarley/+archive/ubuntu/staging
<soee> always :)
<soee> uhmm... 
<soee> BÅÄd:21 https://launchpad.net/~mamarley/+archive/ubuntu/staging xenial Release
<soee>   404  Not Found
<soee> ah lol i used whole link ....
<mamarley> WfM
<soee> hmm http://paste.ubuntu.com/15468244/
<soee> it doesn show driver to update
<mamarley> soee: You must manually install new major versions; they don't automatically upgrade.
<soee> ah i have to remove old one first probably
<mamarley> If you request the new one to be installed, the old one will be uninstalled automagically.
<soee> yup
<soee> reboot
<soee> mamarley: +1 http://wstaw.org/m/2016/03/21/Screenshot_20160321_231804.png
#ubuntu-x 2016-03-22
<tjaalton> regression fixes for xserver pushed to ppa:canonical-x/x-staging, please test
<tjaalton> we're in beta freeze, so 1.18.2 will have to wait until next week
<tjaalton> mesa as well
<tseliot> ricotz: so, to answer your question: yes, nvidia-drm depends on nvidia-modeset
<jjjoooeee> tjaalton: would https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1555434 be included in the "regression fixes"?  
<ubottu> Launchpad bug 1555434 in linux (Ubuntu) "Black screen/system lockup on 4.4.0-11" [Medium,Confirmed]
<tseliot> ricotz: and nothing else loads nvidia-drm, so we load it manually (udev rule) after nvidia-modeset
<tjaalton> jjjoooeee: if you mean the staging upload, why not just try it?
<ricotz> tseliot, it is the other way around
<tseliot> ricotz: you said that nvidia-modeset depends on nvidia-drm but it's the other way around
<tseliot> don't ask me why
<tseliot> ;)
<ricotz> nvidia_uvm            688128  0
<ricotz> nvidia_drm             45056  2
<ricotz> nvidia_modeset        753664  8 nvidia_drm
<ricotz> nvidia              10268672  139 nvidia_modeset,nvidia_uvm
<tseliot> ricotz: http://pastebin.ubuntu.com/15472463/
<ricotz> huh, I see
<tseliot> I'm rebuilding with that build-dep, (I didn't care about wayland when I first built the packages)
<ricotz> tseliot, and drop the transitions
<ricotz> tseliot, and you know my opinion about the changelog! :)
<tseliot> ricotz: oh, right, I keep forgetting about that. What should be in the changelog? Stuff from the xenial 361 release?
<ricotz> (remember it is still a beta release)
<ricotz> tseliot, the whole changelog from the base package
<tseliot> which base package? I based mine on what we currently have in xenial
<ricotz> so this would be 361 here (which already dropped it too :\)
<tseliot> ok, I can do that
<ricotz> tseliot, you are not rewriting the whole packaging out of thin air, so keep the changelog from the previous releases
<tseliot> ricotz: they are all git branches, usually based on the latest driver in our Ubuntu development release
<ricotz> tseliot, the changelog is still the user-visible part of the package, and should be preserved imo
<ricotz> might be good to removed obsolete files too e.g. dkms.conf
 * ricotz is going to have some late lunch
<tseliot> ricotz: I can do that. The reason why I don't change those things is that it makes it easier for me to cherry-pick fixes from one branch to the other.
<ricotz> tseliot, thanks!
<mamarley> tseliot: I'm pretty sure you have upload rights to the PPA too, so as far as I am concerned you can just upload straight there if you want.
<tseliot> mamarley: ok :)
<mamarley> And I also have nvidia-settings 364 packages ready in ppa:mamarley/staging.  Unlike the last few releases, this one actually has some changes.
<tseliot> good
<tseliot> I think I'll rebase on your work when the time comes for Xenial (SRU, I suppose)
 * mamarley already has several users contacting him asking for fresh NVIDIA crack ;).  That and complaining about the APT 1.2.7 changes that cause the PPA to throw a warning about insufficient signing.
<tseliot> :)
<tseliot> all right, uploading for xenial. The upload for trusty should be much quicker
<ricotz> tseliot, and wily ;)
<tseliot> ricotz: ok
<ricotz> thanks
<jjjoooeee> tjaalton: will do, thanks
<mamarley> tseliot: Don't forget to get rid of the EGL alternatives for Trusty and Wily. :)
<tseliot> mamarley: good point
<mamarley> Also, should I go ahead and copy nvidia-settings to the main PPA?
<tseliot> mamarley: if it works, then why not?
<mamarley> No reason in particular.  I just wanted to get approval first.
<tseliot> I've just uploaded for wily and trusty
<tseliot> no EGL
 * tseliot -> EOD
#ubuntu-x 2016-03-23
<darkxst>  I played with the KMS modesetting in the new nvidia drivers today, couldn't get plymouth to work, but it should in theory since I got a DRM DUMB BUFFER working after boot
<darkxst> and non-root Xorg seems happy enough but mutter segfaults creating the cogl framebuffer
<mamarley> It doesn't support fbdev, which is probably why Plymouth doesn't work?
<darkxst> mamarley, plymouth doesnt use fbdev
<mamarley> Ah, OK.  I don't use Plymouth, so I was only guessing.
<darkxst> but apart from that, the ABI verison of the drm module is causing problems (i.e. there is a modprobe ndivia_drm modeset=1, that fails)
<darkxst> and also (probably unrelated) nvidia-persistanced is broken on my system due to user permissions, it seems to think that the nvidia-persistentd user is ID 133, when in acutal fact its 151 or something
<mamarley> Sounds like your installation is screwed up somehow.
<ricotz> darkxst, just for completeness you are using the 364 ppa packages, not installed it yourself?
<darkxst> ricotz, yes ppa packages
<darkxst> systemd-udev calls "modprobe nvidia_drm", but locally only "modprobe nvidia_364_drm" works
<darkxst> I hacked around that with symlinks (and copying modules into initramfs) was able to get to the point of running and also (probably unrelated) nvidia-persistanced is broken on my system due to user permissions, it seems to think that the nvidia-persistentd user is ID 133, when in acutal fact its 151 or something
<darkxst> bad paste
<darkxst> running https://github.com/dvdhrm/docs/tree/master/drm-howto
<darkxst> that works (and is almost identical to how plymouth works)
<darkxst> plymouth passed the drmGetCap call (same as example above)
<darkxst> but then failed trying to setup the connectors and/or crtc's
<darkxst> anyway I will play around more with the plymouth side of things after beta-2, but can you guys  look at loading the nvidia-drm into initramfs and fixing the modprobe error?
<darkxst> this: Mar 23 10:41:07 duhast systemd-udevd[475]: Process '/sbin/modprobe nvidia-drm modeset=1' failed with exit code 1.
<mamarley> tseliot: ^
<tseliot> darkxst: where did you see that modprobe nvidia_drm modeset=1 fails?
<darkxst> tseliot, with 364 drivers and kernel param nvidia-drm.modeset=1 
<darkxst> but I also get the same if I rmmod and the try to modprobe
<tseliot> darkxst: it works fine here (on 16.04)
<tseliot> even if I modprobe manually
<tseliot> darkxst: what's the error when you modprobe the module?
<darkxst> tseliot, I can't try again right now, but pretty sure it was "can't find nvidia_drm module" or similar
<darkxst> then It work with `modprobe nvidia_364_drm`
<tseliot> darkxst: ok, I can see that the alias for nvidia-drm is missing
<tseliot> that should be the problem
<tseliot> (nvidia-modeset has an alias)
<darkxst> tseliot, then they need to be in the initramfs
<tseliot> darkxst: yes, the aliases will be there. All but nvidia-drm are
<tseliot> I'll fix that
<darkxst> tseliot, no the modules, so plymouth can get them
<tseliot> I'm not sure why things work here though
<tseliot> darkxst: we don't do that in Ubuntu. You can add them manually if you like
<tseliot> tjaalton: ^ do we do that with intel?
<darkxst> tseliot, I think all the other drm drivers are in the initramfs
<tseliot> (I could be wrong)
<darkxst> nvidia-drm isn't because its like a day old
<tjaalton> yep
<tseliot> oh, ok then
<tseliot> I'll fix that up
<darkxst> tseliot, ok, thanks!
<ricotz> tseliot, watch out for hyphen vs underscore
<tseliot> ricotz: yes, I know
<ricotz> tseliot, what I meant is "alias nvidia-modeset $(PKG_module)-modeset" or "alias nvidia-modeset $(PKG_module)_modeset" ?
<ricotz> so the existing hyphens seem wrong :\
<tseliot> ricotz: I see what you mean. I really don't remember why things are the way they are (it's been a while). I can certainly look into that
<tjaalton> scr
<tjaalton> bah
#ubuntu-x 2016-03-24
<mamarley> tseliot: I was just looking at log files and I found that I have the same problem as darkxst with nvidia-drm not loading.
<mamarley> Or, not loading with modeset=1.  It does load automatically later.
<mamarley> I can also see that modinfo doesn't work for any of the alias module names. (module not found)
<tseliot> mamarley: yes, I'll have a look at that
<mamarley> I was actually going to see if I could fix it myself.  I don't know how to get modules to be included in the initramfs though.
<mamarley> I fail to see how the "alias nvidia nvidia_364" doesn't work though, since "modinfo nvidia_364" does work.
<mamarley> It is almost like the aliases are being ignored entirely.  I can't see why.
<ricotz> mamarley, tseliot, added/tweaked aliases locally (using underscores only)
<tseliot> ricotz: ok. BTW I'm working on nvidia right now
<ricotz> tseliot, I was counting on that ;)
<tseliot> mamarley: "automatically" means maybe the driver loads that module?
<tseliot> tjaalton: I don't see the kms drivers in the initramfs. They are not built as modules, so I suppose there is nothing to include
<tjaalton> tseliot: huh? i915.ko etc
<tjaalton> /usr/share/initramfs-tools/hooks/framebuffer copies them
<tseliot> tjaalton: yes, I will have to write a hook for nvidia. I simply could not file the files in the initramfs
<mamarley> tseliot: Yes, I think nvidia-drm is getting loaded automatically by either nvidia-modeset or nvidia and that is why the driver works even though the modprobe in the udev configuration fails.
<tseliot> whatever it is, I'll fix it all ;)
<mamarley> Thanks :)
<tseliot> tjaalton: I extracted the initramfs and I used find to get a list of the .ko files: http://paste.ubuntu.com/15486764/
<tseliot> this is what puzzles me
<tjaalton> you're on trusty still..
<tjaalton> check if it has that hook
<tseliot> yes
<tseliot> and yes, the hook is there
<tjaalton> dunno then
<tseliot> are you sure that we do that even on systems that are not encrypted?
<tjaalton> yes
<tjaalton> http://sprunge.us/JUfW
<tseliot>     - Restore the framebuffer hook and script, copying KMS and other
<tseliot>       framebuffer drivers into the initramfs, but make them optional; you
<tseliot>       need to set FRAMEBUFFER=y for these to be included.
<tseliot> tjaalton: ^ Do you have FRAMEBUFFER=y in grub or is your system encrypted?
<tjaalton> FRAMEBUFFER where?
<tjaalton> this one isn't encrypted
<tseliot> well, actually not grub, somewhere in /etc/initramfs-tools/conf.d/
<tjaalton> no
<tjaalton> grep gives no hits
<tjaalton> where did you get that text?
<tseliot> from the changelog of the initramfs-tool package
<tseliot> *tools
<tseliot> if you add FRAMEBUFFER=y, plymouth will start much earlier in the boot process
<tjaalton> add where?
<tjaalton> upgrade to xenial already
<tjaalton> :)
<tseliot> /etc/initramfs-tools/conf.d/splash
<tjaalton> don't have that
<tjaalton> you're on an obsolete distro ;)
<tseliot> yes, well, echo FRAMEBUFFER=y > /etc/initramfs-tools/conf.d/splash
<tjaalton> my initrd already has all the modules
<tjaalton> the hook does not check for that option
<tseliot> I'm trying to understand why we don't have the modules on trusty
<tjaalton> just ask apw?
<tseliot> yes, that's why I'm confusedf
<tseliot> *confused
<tseliot> yes, I'll try that
<apw> splash is only needed in the initramfs if you have encrypted things to open to get to root
<tjaalton> oh you're here :)
<apw> so we don't include that lot unless you have crypt thing on there
<tseliot> which is what I suggested before
<tseliot> apw: but how about the single drm drivers?
<tseliot> I don't have them in trusty, but tjaalton does in xenial
<tjaalton> my initrd has all of them, this is a fairly recent install
 * tseliot -> lunch
<apw> tjaalton, it is dependant on you needing them
<apw> so encrypted root, or actually iirc stypidly having crypttools installed at all
<tjaalton> nope, neither
<apw> tseliot, ^
<apw> well something is triggering them being in there, it is not a normal situation
<apw> basically any hook which needs them sets that FRAMEBUFFER thing and that triggers it
<apw> iirc
<apw> so look at your hooks and one will be asking for it
<apw> or it is broken, which is also possible
<tjaalton> i have a fresh server vm, and it has them too :)
<tjaalton> so maybe it's a bug then
<mamarley> Does the nvidia-modeset module need to be loaded for DRM KMS to work or just nvidia-drm?
<apw> tjaalton, could be, could you file a bug against initramfs-tools for me, and tell me the number
<tseliot> mamarley: both, as KMS stands for kernel mode setting, so nvidia-modeset is definitely needed
<mamarley> That's what I thought.
<tseliot> apw: thanks, that's what I thought
<tseliot> tjaalton: so, yes, that does look like a bug:
<tseliot>   * mkinitramfs: Allow scripts to specify OPTION=VAR, and unless VAR is
<tseliot>     set to something other than "n", the script will not be included.
<tseliot> the framebuffer hook has OPTION=FRAMEBUFFER
<tseliot> so, if OPTION=FRAMEBUFFER is ignored, and the script is included regardless of that, it's a bug
<tseliot> darkxst: are you using an encrypted system?
<tseliot> if not, fixing the aliases should do it
<tseliot> I am certainly going to add an initramfs hook for encrypted systems though
 * tseliot building the driver with the correct aliases first...
<tseliot> ricotz, mamarley: the aliases seem to work fine now: http://pastebin.ubuntu.com/15488195/
<tseliot> modinfo doesn't seem to resolve the aliases but I think we are fine as long as modprobe does ;)
<mamarley> tseliot: Cool, thanks!
<tseliot> so the last step will be a hook for encrypted systems. Then things should be fine. I'm not sure about nvidia-persistence though
<ricotz> tseliot, is this working for you now? "sudo cat /sys/module/nvidia_drm/parameters/modeset"
<mamarley> tseliot: Maybe also have it obey that override that apw mentioned?
<tseliot> ricotz: I still get "N", but I don't see any errors in journactl
<ricotz> tseliot, mhh, I see
<tseliot> mamarley: yes, I could have to look at initramfs-tools
<apw> tseliot, or get a bug filed on it and shove it at me
<apw> sounds like something i would have screwed up in my merge with debian if anything
<tseliot> apw: yes, that would be much better (for me) ;)
<apw> tseliot, shove what you have in a bug, and tell me the number and i'll put it on my todo
<apw> its making peoples initramfs' large and slwo, so i want to wack it
<mamarley> tseliot: Sorry, I didn't mean for you to fix the initramfs-tools bug, I just meant to make it so when that bug gets fixed that the flag there will affect the nvidia modules too.
<tseliot> apw: sure, thanks. I'm updating my xenial installation right now, so that I can use ubuntu-bug to file the report, just in case
<apw> tseliot, ack thanks
<tseliot> mamarley: I'm all for solutions that don't involve me doing the work :P
 * mamarley too :)
<mamarley> I just confirmed that manually loading the nvidia_drm module with modeset=1 results in "sudo cat /sys/module/nvidia_drm/parameters/modeset" returning Y.
<tseliot> mamarley: ok, so maybe the udev rule should try to remove the module first (as per the nvidia docs)
<mamarley> I'm not sure why it would be loaded at all at that point.  Unless udev loads it automagically...
<tseliot> mamarley: ok maybe their X driver?
<mamarley> Would something in /etc/modprobe.d/ that says "options nvidia_drm modeset=1" work by any chance?
<mamarley> Would the X driver have started by that point?  I was under the impression that the udev thing happened earlier than X starting.
<mamarley> Also, I would think if X is running, "modprobe -r"ing the module would fail anyway.
<tseliot> it's worth a shot
<mamarley> I can try that on my laptop real quick, just a sec...
<tseliot> and yes modprobe -r failed for me above ^
<tseliot> udev starts earlier than X though
<tseliot> just guessing. I have no idea what else could be pulling that in
<mamarley> tseliot: That ("options nvidia_drm modeset=1") appeared to work. :)
<tseliot> mamarley: wouldn't that be nvidia-drm though? (to match the alias)
<mamarley> I actually put four different lines though, with and without the 364 and -s and _s, because of the alias madness.
<tseliot> :)
<tseliot> I'll test it here too
<mamarley> Hmm, will that work if the module is in initramfs too?
<tseliot> well, the aliases are in the initramfs
<mamarley> OK, it should work fine then.  I stuck my options in the same file as the aliases.
<tseliot> and the actual module name would be nvidia_364_drm, whereas nvidia_drm shouldn't exist
 * tseliot rebuilding and testing...
<mamarley> I understand; I just wanted to cover all the bases since I am not running the version with the fixed aliases yet.
<tseliot> right
<tseliot> I think I'll work on the hook tomorrow, as it's EOD for me
<mamarley> Explosive Ordnance Disposal? ;P
<tseliot> hehe
<tseliot> in addition to being almost guitar o'clock
<tseliot> apw: LP: #1561643
<ubottu> Launchpad bug 1561643 in initramfs-tools (Ubuntu) "initramfs-tools ignores the FRAMEBUFFER option" [High,Confirmed] https://launchpad.net/bugs/1561643
<tseliot> mamarley: nvidia-drm options didn't work here. I'll mess with it again tomorrow
 * tseliot -> off
<mamarley> tseliot: OK.  It actually didn't work setting options on the alias for me either.
<mamarley> I think I have to set options with the full module name.
<tseliot> yes, that would be easy to do
<mamarley> Yeah, that works.
<furkan> anybody know why I would be getting this error? first time i'm seeing it:
<furkan> furkan@furkan-pc:~$ Xorg -version
<furkan> /usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server
<furkan> also, tjaalton: MrCooper wrote a patch for the cursor bug https://bugs.freedesktop.org/show_bug.cgi?id=94560#c16
<ubottu> Freedesktop bug 94560 in Server/General "[regression, bisected] Xorg 1.18.2 stray cursor appears when some applications are launched maximized on rotated display" [Normal,New]
<darkxst> tseliot, no my system is not encrypted
#ubuntu-x 2016-03-25
<tjaalton> furkan: ah, that's nice. i'll add it after easter
<tseliot> darkxst: ok, thanks
<darkxst> tseliot, np, let me know if you need testing of updated packages (though I am stuck on intel only laptop for easter break)
<tseliot> darkxst: sure, thanks
<darkxst> I'll dig into plymouth a bit more when I get back, 99.9% sure it should work, so either an issue with intialization of DRM or a bug in plymouth
<tseliot> ricotz, mamarley: now I do get cat /sys/module/nvidia_drm/parameters/modeset -> Y . The only problem is that all I can see is a black screen. Something must have broken hybrid graphics
<darkxst> tseliot what DE? 
<tseliot> darkxst: I always use unity
<darkxst> I've not tried that yet, but probably best to leave the modeset option out by default
<darkxst> for now
<mamarley> Hmm, maybe the new DRM KMS implementation is incompatible with the existing PRIME implementation.  I haven't tried it with an optimus system though.
<darkxst> mutter segfaults also nothing to do with PRIME
<tseliot> it's certainly incompatible with SLI. Who knows what else that breaks. I'll report that to nvidia
<tseliot> darkxst: mutter with Wayland?
<darkxst> tseliot, no there is no code for that yet
<darkxst> mutter on X11
<tseliot> as that would need some patches that NVIDIA published
<tseliot> oh
<tseliot> hmm...
<darkxst> tseliot, it could also be GNOME bug, but dont force the kernel option on until things are working
<darkxst> just fix alias, and preloading of initramfs
<tseliot> I won't. I'm changing it back
<tseliot> :/
<tseliot> the thing is I only have a hybrid system with nvidia. No (functioning) nvidia-only system.
<darkxst> and I only have a nvidia-only system (no hybrid)
<darkxst> and its my main development machine so a huge pain when I have to reboot
<tseliot> heh, no nvidia or any kind of testing on my workstation. I even run trusty here.
<tseliot> the testing boxes run xenial or whatever else I need
<ricotz> tseliot, I see, please at least paste a debdiff
<ricotz> darkxst, heh, same here, nvidia-only dev-machine ;)
<ricotz> xenial + some ppas is where the fun begins
<tseliot> ricotz: I can probably do better than that. I'll remove the modeset=1 argument from the udev rule, and keep it in the modprobe file, set to 0. This way it's easy change it back to 1 for testing
<mamarley> I actually have a system that supports Optimus, but it has a hardware mux and I leave it in NVIDIA-only mode because I hate tearing.
<ricotz> tseliot, alright, then push it that way
<tseliot> good old multiplexers :)
<tseliot> ok, good
<ricotz> tseliot, don't sit too long on such fixes ;)
<darkxst> ricotz, I just run "devel" + staging on my dev machine, doesnt break often 
<mamarley> If I understand things correctly, the DRM KMS support will eventually allow for "proper" Optimus (rendering only the game/whatever on the NVIDIA card and supporting vsync).
<ricotz> darkxst, I better don't tell what I am pulling in here
<darkxst> hmm, hardware multiplexers don't work with prime
<darkxst> ricotz, don't worry we all know!
<darkxst> you have a system of git snapshots ;)
<ricotz> it isn't that worse ;P
<tseliot> mamarley: yes, that and probably SLI too. And yes, tearing should go away, that will need kernel patches too.
 * tseliot finally working on the initramfs hook
<tseliot> ok, done. Rebuilding and testing now
<tseliot> well, after lunch...
 * tseliot -> lunch
<tseliot> ricotz, mamarley: I have the initramfs hook and all the fixes here. I am going to upload all that to the PPA
<tseliot> it works fine (with modesetting disabled) here
<tseliot> uploaded
<tseliot> the instructions on how to enable modesetting are in the changelog
<tseliot> darkxst: ^
<mamarley> tseliot: Cool, thanks!
<tseliot> also, I am going to be off next week
 * tseliot EOW \o/
#ubuntu-x 2017-03-20
<alkisg> So, about the ghost monitor issues, upstream is telling me to test a commit: https://bugs.freedesktop.org/show_bug.cgi?id=100267#c2
<ubottu> Freedesktop bug 100267 in DRM/Intel "Ghost eDP-1 monitor on skylake with kernel >= 4.8" [Normal,Needinfo]
<alkisg> Am I supposed to follow https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel? What would I use for the kernel source, apt-get? Some git?
<tjaalton> no, use mainline ppa
<tjaalton> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<tjaalton> just grab latest drm-tip deb
<alkisg> Ah, cool!
<alkisg> Thank you tjaalton :)
 * alkisg ignores all those warnings, W: Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1_01.bin for module i915
<alkisg> Yup, so simple, problem solved :D
#ubuntu-x 2017-03-21
<alkisg> I've been testing 16 bpp depth with the modesetting driver, and it has issues everywhere that I tested it: intel => crash, vboxvideo (vbox) and virtio (kvm) => corrupted double image, cirrus (kvm) => corrupted small image etc
<alkisg> But there's something I don't understand. Ubuntu 16.04.1 and 16.04.2 have the same modesetting driver, right?
<alkisg> So, why e.g.  `kvm -vga cirrus -ctrl-grab -m 1024 -cdrom ubuntu-mate-16.04.1-desktop-i386.iso` works, while 16.04.2 has issues?
<alkisg> Hey, it's Xorg 1.18.3 vs 1.18.4, let me test if that's to blame....
<alkisg> So, I've booted with ubuntu-mate-16.04.2-desktop-i386.iso which does have the 16 bpp issue, then I downgraded from xserver-xorg-hwe-16.04 (1.18.4) to xserver-xorg (1.18.3), and it still has the issue. What does that prove, that the issue is in the cirrus driver and not in the modesetting driver?!
<alkisg> (while 16.04.1 with xserver-xorg (1.18.3) does not have the issue)
<alkisg> (unless installing a different xorg requires a reboot too, not just a xinit...)
<alkisg> Sorry my bad, I didn't notice that the xserver-xorg-core version was unrelated to the xserver-xorg-* stack. By installing xserver-xorg-core=1.18.3, the problem disappeared
<alkisg> So I believe that the regression happened somewhere between 1.18.3 and 1.18.4. Testing more...
<alkisg> I filed this one: https://bugs.freedesktop.org/show_bug.cgi?id=100295
<ubottu> Freedesktop bug 100295 in Driver/modesetting "Regression in 16bpp between 1.18.3 and 1.18.4" [Normal,New]
<alkisg> What real hardware can I test, that would use the modesetting driver? Except for intel, which crashed and I've already reported that?
<tjaalton> whatever you have
<alkisg> tjaalton: I can specify "Driver modeset" in xorg.conf in e.g. a radeon laptop that I have here?
<tjaalton> yes
<alkisg> ty, testing...
<alkisg> I updated the bug report with the results of the real hardware test, which are similar.
 * alkisg checks if he can find any recent commits that could have caused this...
<tjaalton> there aren't too many between 1.18.3..1.18.4
<tjaalton> bisect
<tjaalton> or just try reverting a commit at a time that touches modesetting
<tjaalton> 62 commits in 1.18.4
<tjaalton> 11 on modesetting
<alkisg> tjaalton: I'm a little lost between apt source and upstream git, is it possible to git/bzr clone and bisect something from launchpad instead? E.g. is there a bzr branch of xserver-xorg-hwe-16.04 in launchpad?
<tjaalton> no
<alkisg> I'm seeing this: https://cgit.freedesktop.org/xorg/xserver/log/hw/xfree86/drivers/modesetting, and I can't find out which commit maps to the 1.18.3 release
<tjaalton> git clone upstream, git log xorg-server-1.18.3..xorg-server-1.18.4
<tjaalton> then start reverting the commits that touch modesetting, starting from the latest
<alkisg> ty, trying...
<tjaalton> next git format-patch -1 <sha>, drop the patch in debian/patches and add to series. build a package
<tjaalton> it's probably f091528457cc62f modesetting: Implement 32->24 bpp conversion in shadow update
<alkisg> Yup, that was the one
<alkisg> Thank you Timo, commenting on the report...
<alkisg> tjaalton: eh, it's also the one that's causing the broadwell crash on 16bpp :D
<tjaalton> figured
#ubuntu-x 2017-03-22
<alkisg> What's the xorg.conf equivalent of `xrandr --output HDMI-1 --same-as DP-1`? I see "RightOf", "AboveOf" but I don't see "SameAs" in `man xorg.conf`...
<tjaalton> dunno
<tjaalton> but there's a patch for the 16bpp mode, though it doesn't fix the intel fail
<tjaalton> on xorg-devel@
<tjaalton> https://patchwork.freedesktop.org/patch/145420/
<alkisg> Ty! Let me check...
<MustaKrakish> ubuntu 16.04.2 Xorg 1:7.7+13ubuntu3 uses 100% CPU and running an strace on Xorg PID locked my machine up. VGA is Intel gen 4
<MustaKrakish> any ideas?
<michael-vb> alkisg: just happened to see this on xorg-devel, wondered if it is of interest:
<michael-vb> https://lists.x.org/archives/xorg-devel/2017-March/053133.html
<alkisg> michael-vb: yes, thank you, tjaalton already gave me that url and he said it fixes the 16bpp mode but not the intel crash
<alkisg> It was a busy day today so I didn't have a chance to try it
#ubuntu-x 2017-03-23
 * alkisg tested that https://lists.x.org/archives/xorg-devel/2017-March/053133.html patch, but didn't see any improvement at all...
<tjaalton> report to the bug
<alkisg> I'm using -depth 16 though, I hope I don't need to create a xorg.conf for that
<tjaalton> try
<alkisg> OK, trying
<alkisg> Eh, it indeed works now if using a xorg.conf, but not with -depth
 * alkisg is still waiting for the mailing list activation mail... for 1 hour now...
<tjaalton> check junk mail
<alkisg> I did...
<alkisg> I'll check the intel client too while waiting for the mail
<alkisg> Haha. Incredible! cp modesetting_drv.so.4 modesetting_drv.so => bad. cp modesetting_drv.so.5 modesetting_drv.so => ok
<alkisg> The amazing thing is that a plain "cp" fixes the screen without xorg restart or anything else
<alkisg> What is this, dynamic module loading with inotify?!!
 * alkisg was waiting for the intel client to be free for tests, before reporting back to the -devel list...
#ubuntu-x 2018-03-20
<soee_> Hey, how is the progress witg latest driver for 16.04 ?
<tseliot> mamarley, ricotz: I have just uploaded a first release of nvidia-prime for bionic here. The prime-select script works with the new driver packaging, and doesn't require bbswitch: https://launchpad.net/~albertomilone/+archive/ubuntu/nvidia-glvnd-temp
#ubuntu-x 2018-03-23
<soee_> mamarley: any progress with 16.04 drivers ?
<mamarley> tseliot: ^
<tseliot> soee_: no, I focused on hybrid graphics in 18.04. I'll look into that after Easter, as I'll be off next week
#ubuntu-x 2019-03-18
<tomreyn> Hi. In an attempt to better understand how a given nvidia graphics card can be made to work on Ubuntu, I asked around and came up with this - comments welcome (I may post this to the wiki): https://cryptpad.fr/code/#/2/code/edit/IEsMDKlobVXriW2bCRGBNl07/
<tomreyn> Feel free to edit, too
#ubuntu-x 2019-03-23
<mamarley> ricotz: Sorry for the slowness, but I have 418.56 in the normal place.  Disco, Cosmic, and Bionic have all been rebased on the latest from either you or the main repository, as appropriate.
#ubuntu-x 2019-03-24
<ricotz> mamarley, thanks
