#ubuntu-x 2007-02-05
<Ubugtu> New bug: #83339 in xorg (main) "opengl over remote X (over ssh) crashes X" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83339
<Ubugtu> New bug: #83321 in update-manager (main) "dapper to edgy fails due to x11-common (dup-of: 67996)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83321
<Ubugtu> New bug: #35741 in mesa (main) "Wrong module directory used when loading i915_dri.so ?" [Medium,Rejected]  https://launchpad.net/bugs/35741
<Ubugtu> New bug: #40116 in xserver-xorg-video-cirrus (main) "Thinkpad 600e sound hardware not detected with Ubuntu "Dapper Drake" live CD (Flight 6)" [Medium,Needs info]  https://launchpad.net/bugs/40116
#ubuntu-x 2007-02-06
<Ubugtu> New bug: #34776 in mplayer "mplayer with xv crashes system on specific file" [Medium,Needs info]  https://launchpad.net/bugs/34776
<Ubugtu> New bug: #70382 in xli (universe) "x11-common update breaks because of xli files in /usr/X11R6/bin (dup-of: 67996)" [Medium,Confirmed]  https://launchpad.net/bugs/70382
<Ubugtu> New bug: #71915 in update-manager "subprocess pre-installation script returned error exit status 1 (dup-of: 67996)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/71915
<Ubugtu> New bug: #52192 in Ubuntu "Kubuntu 6.10 max sound volume is too low compared to 5.10 (dup-of: 49824)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/52192
<Ubugtu> New bug: #83571 in xorg (main) "[Feisty]  Middle click fails with no action" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83571
<Ubugtu> New bug: #53216 in linux-source-2.6.15 (restricted) "BUG() report in getnstimeofday: soft lockup" [Undecided,Confirmed]  https://launchpad.net/bugs/53216
#ubuntu-x 2007-02-07
<Ubugtu> New bug: #37691 in xserver-xorg-input-synaptics (main) "Touchpad stops responding" [Medium,Unconfirmed]  https://launchpad.net/bugs/37691
<Ubugtu> New bug: #29009 in xkeyboard-config (main) "No keymap for 'Apple Extended USB Keyboard'" [Wishlist,Confirmed]  https://launchpad.net/bugs/29009
<Ubugtu> New bug: #54347 in xserver-xorg-input-keyboard "Numlock light on switching user is wrong" [Undecided,Unconfirmed]  https://launchpad.net/bugs/54347
<Ubugtu> New bug: #67443 in xorg (main) "Progress bar is invisible" [Medium,Needs info]  https://launchpad.net/bugs/67443
<Ubugtu> New bug: #27204 in xserver-xorg-video-ati (main) "live cd chooses wrong video settings for Radeon 7000" [Medium,Fix released]  https://launchpad.net/bugs/27204
<Ubugtu> New bug: #36316 in discover1-data (main) "New ATI chipset not recognized (PCI 1002:71c4)  [also radeonfb] " [Medium,Confirmed]  https://launchpad.net/bugs/36316
<Ubugtu> New bug: #83704 in linux-restricted-modules-2.6.17 (restricted) "X hangs with NVidia error in kernel.log" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83704
<Ubugtu> New bug: #58019 in linux-restricted-modules-2.6.17 (restricted) "Xorg freezes because of nvidia-driver" [Undecided,Confirmed]  https://launchpad.net/bugs/58019
<Ubugtu> New bug: #83774 in xorg (main) "Xwrapper.config man page does not exist" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83774
<Ubugtu> New bug: #36885 in linux-source-2.6.17 (main) "Asus laptop hangs on TFT/VGA video switch (Fn-F8)" [Medium,Confirmed]  https://launchpad.net/bugs/36885
<Ubugtu> New bug: #49441 in gnome-screensaver (main) "Should not choose GL screensavers when no acceleration is available (dup-of: 33753)" [Undecided,Confirmed]  https://launchpad.net/bugs/49441
<Ubugtu> New bug: #35297 in xserver-xorg-video-ati (main) "no stencil buffer support" [Low,Fix released]  https://launchpad.net/bugs/35297
<Ubugtu> New bug: #26709 in xserver-xorg-video-ati (main) "new xserver-xorg-driver-ati 1:6.5.7-0ubuntu1 driver in dapper causes wrong transparancy with overlays" [Medium,Fix released]  https://launchpad.net/bugs/26709
<Ubugtu> New bug: #27108 in xserver-xorg-driver-ati (main) "Hang on resume from sleep with ati X driver (dup-of: 23545)" [Medium,Rejected]  https://launchpad.net/bugs/27108
<Ubugtu> New bug: #27381 in xserver-xorg-driver-ati (main) "r300 dri breaks suspend/resume (dup-of: 23545)" [Medium,Rejected]  https://launchpad.net/bugs/27381
<Ubugtu> New bug: #27578 in xserver-xorg-video-ati (main) "[r350]  dri not acpitastic (dup-of: 23545)" [Medium,Unconfirmed]  https://launchpad.net/bugs/27578
<Ubugtu> New bug: #40332 in xserver-xorg-video-ati (main) "[dapper]  Thinkpad R52 won't wake from sleep/hibernate" [Medium,Fix released]  https://launchpad.net/bugs/40332
<Ubugtu> New bug: #38345 in xserver-xorg-video-ati (main) "Xv UYVY overlay garbled" [Medium,Unconfirmed]  https://launchpad.net/bugs/38345
<Ubugtu> New bug: #38484 in xserver-xorg-video-ati (main) "Radeon 9200se Gui fails partly" [Medium,Fix released]  https://launchpad.net/bugs/38484
<Ubugtu> New bug: #28007 in xserver-xorg-video-ati (main) "Fullscreen in VMware is distored (breezy, regression from hoary)" [Medium,Fix released]  https://launchpad.net/bugs/28007
<Ubugtu> New bug: #34005 in xserver-xorg-video-ati (main) "Upon upgrade to Xorg7.0, xinerama does not output signal to external monitor" [Medium,Fix released]  https://launchpad.net/bugs/34005
<Ubugtu> New bug: #35408 in xserver-xorg-video-ati (main) "Host locks up tighter than a drum from within X on Dapper Drake!" [Medium,Unconfirmed]  https://launchpad.net/bugs/35408
<Ubugtu> New bug: #26194 in xserver-xorg-video-ati (main) "ATI Mobility M4 crashes/segmentation faults under 1280x1024 resolution" [Medium,Fix released]  https://launchpad.net/bugs/26194
<Ubugtu> New bug: #27845 in xserver-xorg-video-ati (main) "FBMerged Resolution detect problem -Dapper 6.99.99.904" [Medium,Fix released]  https://launchpad.net/bugs/27845
<Ubugtu> New bug: #28171 in xserver-xorg-video-ati (main) "[RV350]  Switching resolution hangs computer on (9600 mobility)" [Medium,Fix released]  https://launchpad.net/bugs/28171
<Ubugtu> New bug: #18969 in xserver-xorg-video-ati (main) "[radeon/r200]  GL apps cause MergedFB display to become mirrored" [Medium,Fix released]  https://launchpad.net/bugs/18969
<Ubugtu> New bug: #21168 in xserver-xorg-video-ati (main) "X (at gdm startup) is garbled (except for mouse pointer)" [Medium,Fix released]  https://launchpad.net/bugs/21168
<Ubugtu> New bug: #24790 in xserver-xorg-video-ati (main) "MergedFB requires displays to be ordered from larger to smaller" [Medium,Needs info]  https://launchpad.net/bugs/24790
<Ubugtu> New bug: #42312 in xserver-xorg-video-ati (main) "Ubuntu 6.06 Beta 2 (install) X display freaky after boot." [Medium,Fix released]  https://launchpad.net/bugs/42312
<Ubugtu> New bug: #40611 in xserver-xorg-video-ati (main) "[Dapper, EXA]  Screen corruption when switching to VT 1 with running glxgears" [Medium,Unconfirmed]  https://launchpad.net/bugs/40611
<Ubugtu> New bug: #18163 in xserver-xorg-video-ati (main) "[mach64]  only starts on odd boots?" [Medium,Fix released]  https://launchpad.net/bugs/18163
<Ubugtu> New bug: #22749 in xserver-xorg-video-ati (main) "[x600]  wavy effect after VT switch" [Medium,Needs info]  https://launchpad.net/bugs/22749
#ubuntu-x 2007-02-08
<Ubugtu> New bug: #38931 in Baltix (main) "add lt keymap to NONLATINMAPS variable in xserver-xorg.config script" [Medium,Unconfirmed]  https://launchpad.net/bugs/38931
<Ubugtu> New bug: #83934 in xserver-xorg-video-nv (main) "1280x1024 resolution on 1680x1050 monitor" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83934
<Ubugtu> New bug: #38996 in xserver-xorg-video-ati "Live CD doesn't boot" [Medium,Unconfirmed]  https://launchpad.net/bugs/38996
<Ubugtu> New bug: #35737 in xserver-xorg-video-ati (main) "Dapper installation shows only blank screen" [Medium,Fix released]  https://launchpad.net/bugs/35737
<Ubugtu> New bug: #31634 in xserver-xorg-video-ati (main) "Driver cannot allocate memory" [Medium,Needs info]  https://launchpad.net/bugs/31634
<Ubugtu> New bug: #29508 in ubuntulooks (main) "Progress bar text is hard to read when progress indicator is halfway through the character" [Wishlist,Confirmed]  https://launchpad.net/bugs/29508
<Ubugtu> New bug: #82958 in xorg (main) "Feisty herd 3 desktop CD cannot install on D3C5105 because graphics are messed up" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82958
<Ubugtu> New bug: #84024 in xorg (main) "Xorg:could not open default cursor font" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84024
<Ubugtu> New bug: #82951 in Debian (main) "Graphics Card Direct rendering disappears" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82951
#ubuntu-x 2007-02-09
<Ubugtu> New bug: #19382 in xorg (main) "X / KDE fails to start" [Medium,Rejected]  https://launchpad.net/bugs/19382
<Ubugtu> New bug: #42347 in kdebase (main) "Cursor speed unaffected by preference-settings" [Medium,Rejected]  https://launchpad.net/bugs/42347
<Ubugtu> New bug: #84158 in xserver-xorg-video-ati (main) "[Feisty Herd 3]  Corrupt screen when switching resolution" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84158
* netjoined: irc.freenode.net -> brown.freenode.net
<Ubugtu> New bug: #84252 in xorg (main) "Crash of graphic system from time to time" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84252
<Ubugtu> New bug: #54295 in xset (main) "remote font path against hpux failes." [Undecided,Unconfirmed]  https://launchpad.net/bugs/54295
#ubuntu-x 2007-02-10
<Ubugtu> New bug: #36596 in xserver-xorg-video-ati "system freeze after clicking task manager trash icon in "pan" newsreader" [High,Needs info]  https://launchpad.net/bugs/36596
<Ubugtu> New bug: #84314 in linux-restricted-modules-2.6.17 (restricted) "Please update nvidia to 1.0-9746" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84314
<Ubugtu> New bug: #84340 in xorg (main) "Upgrade to kernel 2.6.17-11-386 breaks X/NVidia" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84340
<Ubugtu> New bug: #84354 in xserver-xorg-video-ati (main) "radeon in feisty: drm fails at first start, runs at restart X" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84354
<Ubugtu> New bug: #84360 in xorg (main) "Driver Vesa con Nvidia 6100" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84360
<Ubugtu> New bug: #36826 in xserver-xorg-video-ati (main) "Ubuntu freezes after X is killed, when trying to get back to tty7" [Medium,Rejected]  https://launchpad.net/bugs/36826
<Ubugtu> New bug: #33334 in xserver-xgl (universe) "r300 Xgl" [Medium,Rejected]  https://launchpad.net/bugs/33334
<Ubugtu> New bug: #49298 in xorg (main) "Login screen scrambled" [Undecided,Rejected]  https://launchpad.net/bugs/49298
<Ubugtu> New bug: #49349 in xorg (main) "Server occasionally hangs on user logout." [Undecided,Rejected]  https://launchpad.net/bugs/49349
<Ubugtu> New bug: #49996 in xorg (main) "Mouse does not work after kernel upgrade to 2.6.15-25" [Undecided,Confirmed]  https://launchpad.net/bugs/49996
<Ubugtu> New bug: #27846 in xserver-xorg-video-sis (main) "[dapper]  Screen blanks when mouse or keyboard events occur." [High,Needs info]  https://launchpad.net/bugs/27846
<Ubugtu> New bug: #19005 in xkeyboard-config (main) "total support for laptop function keys" [Low,Rejected]  https://launchpad.net/bugs/19005
<Ubugtu> New bug: #26587 in xorg (main) "USB mouse strange behaviour in 2.6.15-6-*" [Low,Rejected]  https://launchpad.net/bugs/26587
<Ubugtu> New bug: #48884 in xorg (main) "Intel 945GM / 950GMA Video Very Slow In Xorg 7.0" [Low,Fix committed]  https://launchpad.net/bugs/48884
<Ubugtu> New bug: #48989 in linux-restricted-modules-2.6.15 (restricted) "Font is blue when going into console mode" [Low,Rejected]  https://launchpad.net/bugs/48989
#ubuntu-x 2007-02-11
<Ubugtu> New bug: #36709 in usplash (main) "usplash corruption on EPIA/TV Out" [Low,Rejected]  https://launchpad.net/bugs/36709
<Ubugtu> New bug: #36923 in xorg (main) "Cannot enable middle-button, Logitech Marble Mouse" [Low,Needs info]  https://launchpad.net/bugs/36923
<Ubugtu> New bug: #81000 in kdelibs (main) "kdeinit crash while away (dup-of: 60288)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81000
<Ubugtu> New bug: #43083 in xserver-xorg-video-i810 (main) "Machine hangs (dup-of: 60288)" [Medium,Unconfirmed]  https://launchpad.net/bugs/43083
<Ubugtu> New bug: #65889 in xscreensaver (main) "The screensaver called "Galaxy" freezes computer. (dup-of: 60288)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/65889
<Ubugtu> New bug: #84464 in xorg (main) "frequent X freezes (6.10, x86_64, nv driver)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84464
<Ubugtu> New bug: #25079 in xorg (main) "Resolution not correct after install on a Toshiba Tecra 8000 laptop" [Medium,Confirmed]  https://launchpad.net/bugs/25079
<Ubugtu> New bug: #37540 in xserver-xorg-video-nv (main) "[nv11]  DPMS not switching off laptop backlight " [Medium,Unconfirmed]  https://launchpad.net/bugs/37540
<Ubugtu> New bug: #49280 in linux-restricted-modules-2.6.15 (restricted) "6.06LTS crashes a few minutes after login" [Undecided,Unconfirmed]  https://launchpad.net/bugs/49280
<Ubugtu> New bug: #55844 in xorg (main) "xorg.conf completely locks machine" [Undecided,Needs info]  https://launchpad.net/bugs/55844
<Ubugtu> New bug: #84557 in xorg (main) "x.org from 6.10 incorrectly detects HorizSync for the Dell Latitude C800 panel" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84557
<Ubugtu> New bug: #84574 in mesa-utils (main) "glx info crashes after nvidia-glx-legacy install" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84574
<Ubugtu> New bug: #41106 in xserver-xorg-video-i810 (main) "Black screen during install after configuring of xserver (on certain intel graphics cards)" [High,Needs info]  https://launchpad.net/bugs/41106
#ubuntu-x 2008-02-04
<ubotu> New bug: #188788 in xorg (main) "[Hardy] X uses vesa driver rather then ati" [Undecided,New] https://launchpad.net/bugs/188788
<ubotu> New bug: #188792 in xserver-xorg-video-ati (main) "Incorrect default resolution with Radeon9200SE and CRT over VGA" [Undecided,New] https://launchpad.net/bugs/188792
<ubotu> New bug: #184715 in xorg (main) "Odd behavior with H193Wk display at 1440x900." [Undecided,New] https://launchpad.net/bugs/184715
<ubotu> New bug: #188787 in wacom-tools (main) "no wacom tablet driver" [Undecided,New] https://launchpad.net/bugs/188787
<ubotu> New bug: #188822 in xserver-xorg-input-evdev (main) "[Gutsy] X crash when evdev used "Dev Phys" instead of device" [Undecided,New] https://launchpad.net/bugs/188822
<ubotu> New bug: #188848 in compiz (main) "[Gusty-Hardy] 3D effects incompatible with some programs (dup-of: 147359)" [Undecided,New] https://launchpad.net/bugs/188848
<ubotu> New bug: #188851 in xorg (main) "keypad doesn't work in gnome" [Undecided,New] https://launchpad.net/bugs/188851
<soren> I have a patch for the vmware video driver.. What's easiest? Send to you guys and you'll apply, upload and forward to Debian? 
<soren> (It simply adds /usr/share/xserver-xorg/pci/vmware.ids)
<bryce> forwarding to debian is easiest
<bryce> we like to sync stuff as much as possible
<soren> Ok. I wasn't sure if you might have access to their git repo or something.
<bryce> timo probably does; I don't
<bryce> night
<soren> 'night :)
<soren> tjaalton: Do you?
<tjaalton> soren: yes (and bryce does too :)
<soren> Haha! Ok :)
<soren> tjaalton: Can I just send the patch to you and you can apply and such?
<tjaalton> soren: sure
<soren> tjaalton: http://people.ubuntu.com/~soren/vmware-pci-ids.diff
<tjaalton> soren: thanks, looks sane
<pwnguin> hmm. wacom appears fixed even though i dont think any packages changed
<soren> Thanks, I guess :)
<ubotu> New bug: #188869 in xorg (main) "[hardy] Xorg crashes on startup" [Undecided,New] https://launchpad.net/bugs/188869
<ubotu> New bug: #188913 in xserver-xorg-driver-ati (main) "X don't run correctly with my ATI Mobility 7000" [Undecided,New] https://launchpad.net/bugs/188913
<ubotu> New bug: #188951 in xorg (main) ""dpkg-reconfigure xserver-xorg" aborts prematurely" [Undecided,New] https://launchpad.net/bugs/188951
<ubotu> New bug: #184348 in xorg (main) "VLC, FileZilla, Kdenlive, aMule" [Undecided,New] https://launchpad.net/bugs/184348
<ubotu> New bug: #188545 in xserver-xorg-driver-i810 (main) "no full screen" [Undecided,New] https://launchpad.net/bugs/188545
<ubotu> New bug: #188975 in linux-restricted-modules-2.6.24 (restricted) "Broadcom bcm4306 rev 3 chipset not working" [Undecided,New] https://launchpad.net/bugs/188975
<ubotu> New bug: #188993 in linux-restricted-modules-2.6.24 (restricted) "No support for Radeon HD 2900 Pro via adapters" [Undecided,New] https://launchpad.net/bugs/188993
<bryce> morning
<ubotu> New bug: #46814 in xorg (main) "Shift+Backspace Kill X" [Medium,Confirmed] https://launchpad.net/bugs/46814
<ubotu> New bug: #96245 in mesa (main) "[via] glxgears and screensavers displaying outside the preview window" [Undecided,New] https://launchpad.net/bugs/96245
<tjaalton> bryce: hey
<tjaalton> bryce: you actually do have commit access to git.d.o :)
<ubotu> New bug: #189042 in linux-restricted-modules-2.6.24 (restricted) "wine crashed with "Error of failed request:  GLXBadContext" fglrx & AIGLX are enabled" [Undecided,New] https://launchpad.net/bugs/189042
<bryce> tjaalton: btw when do plan to switch us back to XAA?
<ubotu> New bug: #189051 in xorg (main) "No Screen Resolutions can be adjusted on Dell 1721" [Undecided,New] https://launchpad.net/bugs/189051
<ubotu> New bug: #189007 in ubuntu "Trackpad scrollbar not working in Hardy Alpha 4 (dup-of: 173411)" [Undecided,New] https://launchpad.net/bugs/189007
<tjaalton> bryce: right, I guess we already decided to go back to XAA, so it's just a matter of doing the actual upload
<tjaalton> on the other hand, I'm now running compiz on my 965GM with "MigrationHeuristic" "greedy", and things seem to work fine
<tjaalton> like no corrupted window shadows, scrolling in firefox is pretty snappy etc
<bryce> really...  huh
<bryce> what is MigrationHeuristic?  is that new?
<tjaalton> man exa
<bryce> ah
<bryce> do you think that'll give a sufficient solution that we won't need to switch back to XAA?
<tjaalton> I'Ãm not sure yet, it might have some other issues
<bdmurray> Is anybody familiar with the framebuffer driver and how usplash uses it?
<bdmurray> tjaalton: you commented on bug 129910 right?
<ubotu> Launchpad bug 129910 in xserver-xorg-video-ati "Blank ttys when using vesafb (vga=xxx)" [Unknown,Fix released] https://launchpad.net/bugs/129910
<tjaalton> bdmurray: argh.. yep :)
<bdmurray> tjaalton: What I'm really curious about is bug 147623 and the source of that problem.  Do the framebuffer drivers only work with certain cards?
<ubotu> Launchpad bug 147623 in usplash "[EM64T + nvidia 8xxx]When booting, screen stays black." [Medium,Confirmed] https://launchpad.net/bugs/147623
<bryce> http://bryceharrington.org/files/screenrez_1.png
<tjaalton> bdmurray: it seems to have issues with 64bit and nvidia..
<tjaalton> bryce: woo, you fixed displayconfig-gtk?
<bryce> tjaalton: actually check the title
<tjaalton> oh is that the gnome capplet?
<bryce> yup
<bdmurray> tjaalton: right, come to find out I have hardware around here where I should be able to recreate it.  Is it an issue with the kernel framebuffer driver?
<tjaalton> bdmurray: we don't use a fb driver by default
<bdmurray> tjaalton: okay, if you have an idea what is going on could you explain it to me?  I'm uncertain as to what is used.
<tjaalton> bdmurray: I'm not too familiar with it.. mjg59 should be able to fill in the details
<bdmurray> tjaalton: okay, thanks!
<tjaalton> bdmurray: I've got a nvidia 8600GT, and could test a 64bit livecd to see if I'm able to reproduce it
<bdmurray> tjaalton: I'll be testing it shortly with an 8300 which I think should have the same results
<tjaalton> bdmurray: yeah, G80-series both
<pwnguin> is it a bug in wacom tools or in xorg if you still need an xorg.conf to use wacom?
<tjaalton> wacom
<tjaalton> although we still don't use input-hotplug by default
<bryce> http://bryceharrington.org/files/screenrez_2.png
<ubotu> New bug: #183502 in xserver-xorg-video-intel (main) "[hardy] Intel graphics (965) slowed down" [Undecided,New] https://launchpad.net/bugs/183502
<tjaalton> hmm, seems that the option for intel makes it use more power..
<tjaalton> bryce: will it change the xorg.conf?
<bryce> tjaalton: no, this one will be xrandr 1.2 based
<bryce> so it will be doing everything on the fly
<tjaalton> bryce: ok, but we'll keep dc-gtk as well?
<bryce> for now, but the goal is to deprecate it
<bryce> it's too broken
<tjaalton> ok
<bryce> but I don't have anything better to use for bulletproof-x mode presently
<bryce> but I might be able to shoehorn DCG to work adequately in that mode since I control the input xorg.conf there
<tjaalton> yep
<seb128> hey bryce
<bryce> hi seb128
<seb128> bryce: about the keyboard issue, Hobbsee has the same bug, she confirmed using xev that she gets the same events
<seb128> bryce: so that's not specific to the layout used
<bryce> I saw that.  but while that rules out one possibility, the other things still need to be tested
<seb128> bryce: downgrading the xserver-xorg-input-xkb package is not trivial because the input methods changed or something and the gutsy version doesn't install on gutsy, would a rebuild on hardy do the trick?
<tjaalton> a rebuild would work
<seb128> bryce: what other things? I use no virtualization
<seb128> I'll try the rebuild and downgrade
<seb128> tjaalton: thanks
<tjaalton> unless the new server _requires_ the newer driver
<tjaalton> I'm not sure
<tjaalton> maybe something to push upstream
<tjaalton> the bug
<tjaalton> whot is pretty responsive
<bryce> well, basically at this point we need to narrow in what is causing the issue, and so far we've only ruled _out_ possibilities
<bryce> tjaalton, yeah maybe pushing it upstream would be good since we don't know what more to do to troubleshoot
<bryce> (unless you have ideas, or unless downgrading shows something illuminating)
<tjaalton> I bet the error goes away with evdev..
<tjaalton> hmm, gravity is online
<tjaalton> ok, bedtime.. night ->
<bryce> http://bryceharrington.org/files/screenrez_3.png
#ubuntu-x 2008-02-05
<ubotu> New bug: #182284 in xserver-xorg-video-intel (main) "no direct rendering after upgrade to hardy" [Undecided,New] https://launchpad.net/bugs/182284
<ubotu> New bug: #187281 in xserver-xorg-video-ati (main) "Graphic problems with ATI" [Undecided,New] https://launchpad.net/bugs/187281
<ubotu> New bug: #189147 in xorg (main) "X display freezes, slowly fades to black (video included)" [Undecided,New] https://launchpad.net/bugs/189147
<ubotu> New bug: #189167 in mesa (main) "Missing glClipPlane support in r300" [Undecided,New] https://launchpad.net/bugs/189167
<ubotu> New bug: #120619 in xorg (main) "[Gutsy] invalid resolution detected resulting in BIG fonts on i915" [Undecided,New] https://launchpad.net/bugs/120619
<Company> hrm, everybody asleep here, too
<Company> i'm wondering who to poke about https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/147846
<ubotu> Launchpad bug 147846 in xserver-xorg-video-ati "resolution out of sync with version 2:1.3.0.0.dfsg-12ubuntu8" [High,Incomplete] 
<tjaalton> Company: do you have a radeon or intel?
<Company> tjaalton: radeon
<Company> tjaalton: (last reply to that bug is mine)
<tjaalton> yes I noticed
<tjaalton> try the driver from http://wiki.ubuntu.com/XorgOnTheEdge
<Company> radeonhd or ati?
<tjaalton> ati
<Company> brb (hopefully ;))
<Company> logging out and back in should be enough to restart X, right?
<tjaalton> perhaps
<tjaalton> I'm not sure what the gdm default is
<Company> i got to see the console in between
<tjaalton> I reckon it didn't help?
<Company> nope
<Company> still the same issue: garbled screen andmanually having to xrandr without seeing a lot
<tjaalton> ok, please open a new bug and attach your logfile and config.
<Company> half of that is easy - i have no config :)
<tjaalton> ok
<Company> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/189198
<ubotu> Launchpad bug 189198 in xserver-xorg-video-ati "r100 video comes up garbled" [Undecided,New] 
<tjaalton> Company: umm, on the other bug you said that resolutions such as 1920x1200 worked right? I'm not sure how 446Xpro is able to do that..
<Company> tjaalton: i can definitely see it
<tjaalton> it's not a widescreen monitor..
<Company> i know
<ubotu> New bug: #189198 in xserver-xorg-video-ati (main) "r100 video comes up garbled" [Undecided,New] https://launchpad.net/bugs/189198
<Company> it looks pretty stretched and is flickering, but the image is vivible
<tjaalton> the log shows that it's using 16x12, and you listed that as working?
<Company> it's using 1600x1024, no?
<Company> i was assuming that it does that, because the other modes work when i xrandr to them
<tjaalton> you listed 1600x1024 as working too
<Company> wait, i did?
<tjaalton> WORKS: 1920x1200, 1600x1200, 1600x1024...
<Company> i messed that up when copy/pasting, i'm sorry
<tjaalton> hmm, indeed it is trying to use 16x10
<Company> yep, 1680x1050 works
<Company> looks ugly, but works
<tjaalton> what if you generate the config? 'dpkg-reconfigure xserver-xorg'
<tjaalton> I meant it's using 1600x1024
<Company> right
<Company> i was just checking what i'd written in the bug
<tjaalton> ah
<Company> can i dpkg-reconfigure while X is running?
<tjaalton> yes
<tjaalton> it doesn't probe or anything
<Company> hrm, the xorg.conf doesn't contain anything important
<Company> just "configured device" for everything and a keyboard layout
<tjaalton> right
<tjaalton> that's enough
<Company> alright
<tjaalton> ..for now
 * Company tries
<Company> same problem
<tjaalton> ok, so you can force the resolution using these instructions: http://wiki.debian.org/XStrikeForce/HowToRandR12
<tjaalton> "forcind a preferred mode"
<Company> yeah, that was pretty much what i was doing - i had set a preferred resolution on gnome login which caused an xrandr to 1280x1024
<tjaalton> it would be cool if you could report this upstream
<Company> but the new gnome stopped auto-xrandr'ing
<Company> what's the preferred irc channel for poking upstream people?
<tjaalton> #xorg-devel
<tjaalton> ask agd5f (some US timezone though..)
<Company> will do
<tjaalton> hmm, actually he's real name is alex deucher, so maybe he's German after all :)
<Company> he works for ati now, so he probably is us-based nonetheless ;)
<tjaalton> true
<Company> gutsy shipped xorg 1.4?
<Company> hrm shouldn't matter, because it was caused by that patch removal
<tjaalton> nope, 1.3
<tjaalton> yes, that patch basically forced the setting, which is equivalent to the PreferredMode
<Company> freedesktop.org 14383
<tjaalton> excellent
<tjaalton> added a comment about the driver version
<Company> i'll try poking agd5f tonight or tomorrow
<tjaalton> ok, cool
<Q-FUNK> http://people.ubuntu.com/~bryce/Uploads/xorg-server_1.4.1~git20080118-1ubuntu3_source.changes
<Q-FUNK> is there a source tarball for this?
<Q-FUNK> I was gonna add bartman's vcons patch and upload to my PPA, but no source tarball found.
<tjaalton> Q-FUNK: I'm about to upload a new merged version
<tjaalton> with your patches
<Q-FUNK> oh
<tjaalton> that version was never uploaded
<Q-FUNK> including the vcons patch attached to 180742 ?
<Q-FUNK> there's a total of 3 patches against x86emu from Bart.  2 are attached to 140051 and 1 to 180742.
<tjaalton> that's not included, the first two are
<Q-FUNK> ok
<Q-FUNK> can you check that third one, before you upload?
<tjaalton> better to test that separately?
<Q-FUNK> hmm ok
<Q-FUNK> I guess I'll make my PPA packages from your current upload.
<Q-FUNK> which version is it?
<tjaalton> the one that'll hit the archive in 10min :)
<tjaalton> 2:1.4.1~git20080131-1ubuntu1
<Q-FUNK> ok :)
<Q-FUNK> how often is the PPA build queue processed, again?
<tjaalton> every 30min/1h or so
<tjaalton> dunno
<Q-FUNK> source was just accepted by PPA, but no binaries yet
<Q-FUNK> ah ok
<tjaalton> bryce: ok, xorg-server uploaded with those patches
<tjaalton> now home ->
<bryce> thanks
<Q-FUNK> tjaalton: kiitos tÃ¤stÃ¤.
<Q-FUNK> one worry less for Hardy
<tjaalton> if it doesn't break anything :)
<tjaalton> bryce: maybe we should take a look at the fedora displayconf tool if dc-g isn't going to cut it anymore? looks like it has accumulated ~150 bugs so far
<bdmurray> bryce: Is there a master bug for touchpad scrolling?
<tjaalton> yep
<tjaalton> bdmurray: ^^ :)
<tjaalton> bug 173411
<ubotu> Launchpad bug 173411 in xorg "[Hardy][Regression] Touchpad vertical scroll does not work" [Medium,Confirmed] https://launchpad.net/bugs/173411
<bdmurray> tjaalton: thanks!
<bryce> tjaalton: really?  I looked at it a couple weeks ago but wasn't that impressed
<ubotu> New bug: #186899 in ubuntu "Scrolbar of my hp dv9646 laptop mouse doesn't work on Hardy (dup-of: 173411)" [Undecided,Triaged] https://launchpad.net/bugs/186899
<tjaalton> bryce: oh ok, what's it called? I'll dig it up to convince myself that it sucks :)
<bryce> system-config-display iirc
<bryce> here are some (early) mockups of what they're working on to gain xrandr support - http://www.gnome.org/~clarkbw/designs/monitor-resolution-settings/
<tjaalton> yeah, that's the one
<bryce> I think the layout that glatzor and mpt put together is a bit more usable.  I do want to have a graphical screen layout tool some day, but I've seen other prototypes I like better
<tjaalton> ok I won't spend any time on that right now
<bryce> so far, grandr's layout tools is the most interesting, however it takes up a lot of space
<tjaalton> but we still need a tool which touches xorg.conf, imho
<bryce> http://fedoraproject.org/wiki/Features/RandrSupport
<bryce> here's a screenshot:  http://www.redhat.com/magazine/014dec05/features/multihead/
<bryce> yes I agree we need something which can manipulate xorg.conf, and I'm a bit uncertain about what to do there
<bryce> there's three use cases I see
<bryce> 1.  bulletproof-x mode (a xrandr gui presumably won't cut it here)
<bryce> 2.  altering the Virtual settings to allow different layouts (but maybe this could simply be a script)
<bryce> 3.  general xorg.conf customization
<bryce> I don't know though --- given my experience seeing how hard it's been for dcg to chase xorg.conf as it's format evolves, this seems like a really hard problem, and these three use cases don't represent as huge of an amount to gain, assuming people will be able to do more using xrandr now
<jcristau> pyxf86config sounds nicer than shell to manipulate xorg.conf
<tjaalton> bryce: speaking of 1., do we want to get a recent -ati snapshot in? I'm tired of those r5xx bugs which fail to load vesa :)
<bryce> tjaalton: yeah probably a good idea; I've sort of lost track of where -ati is at since our last release
<tjaalton> bryce: deep in the snapshot-land :)
<bryce> hrm
<tjaalton> or -jungle
<tjaalton> jcristau: I'll take a look at pyxf86config
<tjaalton> bryce: they do support accelerated 2D for r5xx, and maybe for r6xx too
<bryce> tjaalton: well, I'd like to avoid the situation we were in last time where we were putting out new -ati's right up until freeze...  the vesa issue is minor compared with some bugs we could risk unearthign
<bryce> tr/gn/ng/
<tjaalton> currently r5xx-> can't get X up because of that, so it's not that minor :)
<bryce> tjaalton: maybe ask alex about any release plans for the month?
<tjaalton> yeah, good point
<tjaalton> a coworker has a Thinkpad T-series with a recent ati card on it, so I could try some dailies on it every now and then
<bryce> yes that's a really good idea
<bryce> I think ScislaC may also be open to doing some testing, although usually he focuses on fglrx
<tjaalton> I'd like to personally see a machine failing to boot a livecd, otherwise it's much harder to fix anything
<bryce> I think you might be the only person wishing for that ;-)
<tjaalton> hehe :)
<ubotu> New bug: #189343 in linux-restricted-modules-2.6.24 (restricted) "DRI doesn't work with fglrx 8.01" [Undecided,New] https://launchpad.net/bugs/189343
<ubotu> New bug: #187588 in xorg (main) "[hardy] wrong screen resolution on laptop HP nw8440" [Undecided,Incomplete] https://launchpad.net/bugs/187588
<bryce> tjaalton: I started that page on hardy driver status I mentioned the other day - https://wiki.ubuntu.com/X/Drivers
<bryce> so far just -intel; going to do -fglrx after lunch
<bryce> if you could, please review it and correct any inaccuracies - this is mostly taken from feedback from your testing, so I may have made mistakes in capturing it correctly
<tjaalton> bryce: ok, I'll have a look
<tjaalton> bryce: yep, looks good
<bryce> great
<bryce> on to -fglrx
<tjaalton> for some reason it seems to _require_ forcing 24bit mode on...
<bryce> huh
<bryce> what other issues?  I owe AMD a top 5 bug list, so if you have issues in mind I'll collect 'em
<tjaalton> DRI doesn't work for everyone etc
<tjaalton> look at the l-r-m-2.6.24 bug list
<bryce> ok
<bryce> tjaalton: there doesn't seem to be that many fglrx errors in the lrm-2.6.24 bug list
<bryce> about a dozen
<tjaalton> right, but even more puzzling ones :)
<tjaalton> but the fact is that not that many get past the broken-X phase
<tjaalton> I guess..
<tjaalton> the bug list for 2.6.22 is more impressive
<bryce> could be
<bryce> will many of the 2.6.22 bugs still be relevant though?
<tjaalton> some of them will
<tjaalton> don't know the percentage, but some of them are already running the latest driver(s)
<tjaalton> those could be moved to .24
<bryce> heya tormod
<tormod> hi bryce
<bryce> how things going tormod?
<tormod> fine thanks. trying to not fall sick, flu all over Europe it seems.
<bryce> erf
<tormod> did you see my e-mail reply with another small patch?
<bryce> yes
<bryce> I'll add it in now
<tormod> you can also remove the '/.git.*/' from -i I think, just -i removes all git/svn/etc
<bryce> ok done and pushed :-)
<tormod> my plans (some time) would be to rearrange the script in modules so it can be used as a shell library if needed.
 * bryce nods
<tormod> for instance build binaries, then change a few things for backports, build again (without downloading from git every time)
<bryce> I got completely sidetracked by ubuntu-mobile stuff there around the holidays so haven't had time to work on the driver builder infrastructure more, but if/when I do, it'd be helpful to have the script modularized
<bryce> I did take a shot at adding support for mesa before the holidays, but it never worked
<bryce> I had the changes queued up in my tree (thus my procrastination merging more changes), but I think mesa just may be too complicated for it, so I just tossed that work for now.
<tormod> is the ubuntu mesa maintained in git?
<bryce> no
<bryce> just xorg and xorg-server are in git for ubuntu so far
<tormod> I guess it would be the next candidate.
<bryce> possibly; although it's not a package we tend to do a lot of work on - I think we mostly just sync to debian
<tormod> that's the tendency for all xorg*, luckily
<bryce> right.  xorg and xserver are the two main pieces where we have a significant amount of non-syncable / ubuntu-specific stuff
<bryce> I've thought a bit that maybe one or two of the drivers would be next on the list, but typically what changes we make to drivers gets taken upstream swiftly so we rarely have more than a couple patches against them at a time
<bryce> tormod: hey did you see we got 100% caught up the other day on New bug triage for the major xorg bits? :-)
<bryce> (well major aside from the binary drivers)
<tormod> wow that's great
<bryce> tormod: http://people.ubuntu.com/~bryce/Plots/
<bryce> things have crept up a bit since then but not much ;-)
<tormod> looks good :)
<tormod> and displayconfig-gtk needs some love... any new plans for it?
<bryce> indeed; I've been working on a replacement for it the last couple days
<tormod> link?
<bryce> http://bryceharrington.org/files/screenrez_6.png
<tormod> xrandr-aware I hope?
<bryce> right
<bryce> my code branch is at https://code.launchpad.net/gnome-control-center
<bryce> it won't edit xorg.conf though, so we may still need a solution for that.
<tormod> btw, are we gonna update -ati soon, or wait for Debian (or for 6.8...)?
<bryce> tjaalton and I were just talking about that earlier
<tormod> the support for X1?00 cards would obsolete many vesa bugs...
<bryce> it would be nice to not get stuck in a situation like last time where we were pushing new -ati's up until the last minute before release
<bryce> right
<bryce> I think tjaalton is going to check with alex about release plans in the near future
<bryce> tormod, have you tested against newish -ati snapshots?  How is it doing?
<tormod> well it just got better and better :)
<bryce> heh
<tormod> works well, and I ask people to test it whenever I can in bug reports.
<tormod> I am a little afraid Alex doesn't have a release plan, as in planning wrt time
<ubotu> New bug: #189415 in xorg (main) "[Hardy] X serveur restart randomly with nvidia propriotary driver" [Undecided,Incomplete] https://launchpad.net/bugs/189415
<bryce> hmm
<bryce> since Hardy is an LTS release, it would be a bit uncomfortable shipping an -ati snapshot...
<tormod> it seemed to settle and I was waiting for a release, then he merges atombios, same again, then he adds something else...
<bryce> have you suggested to him that it would be good to put out a release before merging more stuff?
<tormod> it would be better than 6.6.3 I guess ;)
<jcristau> the ati driver tends to have never-ending release candidate series these days
<tormod> hmm no I haven't. I am maybe not the one to tell him. jcristau?
<jcristau> you could just pick whatever goes into F9 :)
<tormod> true enough
#ubuntu-x 2008-02-06
<bryce> I wonder if we should consider pulling radeonhd into main yet?
<ubotu> New bug: #185809 in restricted-manager "[hardy] restricted-manager break xorg when enabling fglrx (dup-of: 188409)" [Undecided,New] https://launchpad.net/bugs/185809
<bryce> I've finished outlining -fglrx status too:  https://wiki.ubuntu.com/X/Drivers
<bryce> please update if anyone spots inaccuracies; I'm going off second hand reports + judgment for many of the reported issues so could easily be mistaken on some details.
<tjaalton> bryce: then radeonhd and ati would be fighting over r5xx-> cards
<tjaalton> I don't know how that would work out
<bryce> yeah
<bryce> well, couldn't we have it in main but not the default?
<bryce> tjaalton: wow check this new tool out:  https://edge.launchpad.net/ubuntu/+upstreamreport
<tjaalton> well, if it's not installed by xserver-xorg-video-all, what's the point in having it in main :)
<tjaalton> s/point in/point of/
<bryce> can't it be installed by -all, but not selected as the default driver in xserver?
<tjaalton> both ati and radeonhd support the same pci-id's (or a subset of them in case of radeonhd), so I'm not sure how the xserver chooses the default then
<tjaalton> maybe the first it finds, which would be ati
<bryce> hmm
<tjaalton> hum, new intel. I'll merge it today
<tjaalton> *-desktop still depends on xresprobe
<tjaalton> bryce: still here?
<Q-FUNK> tjaalton: that CPUID patch did something weird on amd64.  I'm not sure what to make of the build log on my PPA.
<bryce> tjaalton: yup (barely though)
<tjaalton> bryce: ok, now that intel 2.2.1 is close, what should we do with -i810? it's not used by default anyway, everyone is "forced" to -intel
<tjaalton> since the server autoloads intel
<bryce> well, I have a few bugs in on -i810 migration issues that still remain unfixed, so I generally think we have to keep i810 for now
<bryce> I've been hopeful we can deprecate it in time for hardy though, but...
<tjaalton> Q-FUNK: glad that I didn't include it then ;)
<Q-FUNK> tjaalton:  :)
<tjaalton> bryce: ok, do you remember which #'s?
<Q-FUNK> https://launchpad.net/~q-funk/+archive/+builds?build_text=&build_state=failed
<tjaalton> bryce: just to check if they should be fixed or are marked as blockers
<bryce> 114331  135093  147189  157610  16887  131972  and probably others
<tjaalton> hmm, that's a lot :)
<bryce> indeed
<tjaalton> although 16887 seems to be invalid/fixed by now
<bryce> please go ahead and update; I've not had a chance to get them all updated
<tjaalton> ok, I'll forward upstream those that aren't already
<bryce> great
<bryce> ok, going to bed.  cya tomorrow
<tjaalton> bryce: night
<Q-FUNK> did bryce switch to .AU time?
<tjaalton> it's just 2AM in Portland ;)
<Q-FUNK> oh
<Q-FUNK> I thought that he was in UK
<tjaalton> heh
<Q-FUNK> ...and now traveling to AU
<Q-FUNK> this gets confusing :)
<Q-FUNK> hm. i really wonder why that build failed only on amd64.  could there be some 32-bit only code in bartman's patch?
<tjaalton> no idea
<jcristau> Q-FUNK: have you actually read that patch?
<Q-FUNK> jcristau: no, I just applied and tested whether it builds cleanly on all arch.
<jcristau> sigh
<jcristau> maybe you should, then
<Q-FUNK> I notice an ifdef for amd64
<Q-FUNK> right.  a conditional include for 64-bit build.
<Q-FUNK> which apparently fails.
<Q-FUNK> nice bit of ASM there
<Q-FUNK> jcristau: ok.  I see your point.  any suggestion on how to fix this?
<tjaalton> Q-FUNK: bug the writer?
<jcristau> i thought that was obvious, but don't build i386 asm on amd64?
<Q-FUNK> jcristau: this whole construct is an emulator to begin with.  I already find it suspicious that we're trying to make every video and input hardware in the universe appear to X as x86 hardware, in the first place.
<jcristau> Q-FUNK: that's the point of an emulator
<Q-FUNK> sure, it is.  but native code for each architecture, rather than forcing the whole universe to appear as x86 hardware, would seem to be a more productive approach.
<Q-FUNK> it would also be a nice wat to get rid of that dependence on legacy BIOS calls for everything.
<jcristau> the bios is x86 code
<jcristau> so if you're not an i386, you have to emulate that if you want to call into the bios
<Q-FUNK> why should we force non-x86 architectures to play as if they were x86, though?
<jcristau> meh
<jcristau> once again: because you're running bios calls
<Q-FUNK> once again: other architectures don't even have a BIOS.
<jcristau> they do
<jcristau> so if you want to use it to POST the card on !x86, you need an emulator
<tjaalton> bryce: so apart from 147189 none of those bug reports have seen an update during hardy. I'd say it's looking good
<ubotu> New bug: #189579 in xorg-server (main) "xephyr should have a menu entry" [Undecided,New] https://launchpad.net/bugs/189579
<ubotu> New bug: #186999 in restricted-manager "Dell OEM ATI graphics chip not recognised by Restricted Drivers Manager" [Undecided,Invalid] https://launchpad.net/bugs/186999
<ubotu> New bug: #189599 in xorg (main) "[Hardy] Ubuntu does not remember the screen resolution" [Undecided,New] https://launchpad.net/bugs/189599
<tjaalton> oh crap, so the new intel just hangs
<pochu> Is that a new feature? :-)
<tjaalton> I bet
<tjaalton> right, it's already reported on xorg@
<bryce> erf, that's the 2.3 driver?
<tjaalton> no, 2.2.0.90
<tjaalton> which will become 2.2.1
<tjaalton> I'll revert the change that broke it
<jcristau> tjaalton: jbarnes just posted a new patch
<tjaalton> jcristau: oh cool
<tjaalton> jcristau: where exactly?
<tjaalton> can't see it on gitweb or on the list
<jcristau> tjaalton: list
<tjaalton> damn snailmail
<tjaalton> ok got it
<tjaalton> building
<tjaalton> now it doesn't hang, but the output is on the wrong port
<bryce> (hmm not boding well)
<tjaalton> it works after all
<tjaalton> I had to reboot though
<tjaalton> phew
<bryce> cool
<bryce> gotta be more careful with that upload button ;-)
<tjaalton> glad I tried it before leaving
<tjaalton> fix uploaded
<ubotu> New bug: #189666 in linux-restricted-modules-2.6.24 (restricted) "Intel iwl4965 microcode not included in rt restricted modules" [Undecided,New] https://launchpad.net/bugs/189666
<ubotu> New bug: #189690 in mesa (main) "libGLw.so is not provided by a package" [Undecided,New] https://launchpad.net/bugs/189690
<ubotu> New bug: #189692 in xserver-xorg-video-intel (main) "problem with intel card and resolution (dup-of: 189694)" [Undecided,New] https://launchpad.net/bugs/189692
<bryce> hmm, here's a question - will we support upgrades of dual-head systems from Dapper with Xinerama to Hardy with Xrandr?
<tjaalton> heh, sounds like a real nightmare
<bryce> yeah I just flashed on that after closing a dapper-era xinerama upgrade bug.  o_O
<tjaalton> it's just not doable
<bryce> I'm worried that if we're going to advertise working upgrades from Dapper->Gutsy, it's going to bite us on the butt if people expect a Dapper-era xorg.conf to be supported without issue on Hardy
<bryce> I think we're going to need to have the upgrade process move aside their xorg.conf and generate a new one
<bryce> but even that can lead us into problems...
<tjaalton> that's one example why a robust gui configurator would be nice to have
<jcristau> don't people have bullet-pproof-x to[B[B[B
<tjaalton> :)
<bryce> :-P
<jcristau> sorry
<jcristau> ssh lag
<bryce> it made me laugh though ;-)
<soren> How can I see which program stole my input focus?
<bryce> uhhh
<soren> Hm.. No, that can't be it, now that I think about it.
<bryce> hrm, I wrote a test code to re-steal focus and restore it, but I don't know if it's possible to determine what took it to begin with
<soren> X just stopped accepting keyboard input from me.
<bryce> is this in kvm or in general?
<soren> General
<soren> If I do the x2x trick, I can type on my laptop and it shows up, so it's not a focus problem.
<soren> It's just.. Odd.
<bryce> not sure, but there's been a few of those bugs reported
<soren> chvt'ing away from X and back doesn't fix it. That surprised me somewhat.
<bryce> but the keyboard works ok when you're at a vt I take it?
<soren> Yeah, no problems there.
<bryce> bug 184078 is the one I was thinking of
<ubotu> Launchpad bug 184078 in xorg "keyboard stops working until logout" [High,Confirmed] https://launchpad.net/bugs/184078
<bryce> does that match your issue?
<bryce> wow, searching ubuntu for "keyboard stops working" gives 100 hits
<bryce> bug 58884 sounds a bit closer to your symptoms actually
<ubotu> Launchpad bug 58884 in xserver-xorg-input-keyboard "Random keyboard failure in X" [Undecided,Incomplete] https://launchpad.net/bugs/58884
<soren> I can't even ctrl-alt-f1 to get away from X. It completely ignores me.
<bryce> hmm, nope that bug's ancient
<bryce> in fact it looks abandoned.  I'll invalidate it and shoo away the me-too'ers
<tjaalton> I think the issue is new with xserver 1.4
<tjaalton> soren: how often do you see it?
<soren> tjaalton: This is the first time, i think.
<tjaalton> ok
<soren> tjaalton: Er.. Strike the "I think" part. I would certainly have noticed it if it had happened before.
<tjaalton> mouse works normally, you can do stuff with it?
<soren> Sure.
<tjaalton> ok, so the server is not hung :)
<tjaalton> damn
<tjaalton> can you ssh to the box?
<soren> Sure.
<tjaalton> the log might help, or not :)
<soren> That's how I did the x2x thing.
<tjaalton> x2x?
<soren> Yes.
<tjaalton> ah
<soren> It allows you to use one keyboard and one mouse on two different X servers.
<soren> ..it places a window on an edge of your screen and sends events to the remove X server using the XTEST extension.
<tjaalton> neat, haven't seen that before :)
<soren> O_O
<soren> Oh, it's pretty nifty.
<soren> It's default mode of operation is quite boring. You want the -{north,east,south,west} option.
<tjaalton> I need to try that at work
<jcristau> it needs a maintainer ;)
<tjaalton> hehe :)
<bryce> heh, I used x2x for a wonky 2-machine multi-head thingee I did a long time ago
<bryce> I remember it being a bit quirky
<soren> wfm
<tjaalton> bryce: I'll close the libGLw.so bug as wontfix, since it would pull lesstif into main. I believe the security team still doesn't want to support that
<bryce> tjaalton: sounds good
#ubuntu-x 2008-02-07
<ubotu> New bug: #189772 in mesa-utils (main) "[hardy] glxinfo uses 100% CPU" [Undecided,New] https://launchpad.net/bugs/189772
<ubotu> New bug: #150638 in linux-source-2.6.22 "framebuffer mode results in black screen starting with kernel 2.6.22-13-generic (dup-of: 129910)" [Undecided,New] https://launchpad.net/bugs/150638
<ubotu> New bug: #183869 in xorg-server (main) "mouse is not working after upgrading to hardy" [High,Confirmed] https://launchpad.net/bugs/183869
<tjaalton> bryce: whoa, you closed a couple of intel bugs :)
<bryce> :-)
<bryce> tjaalton: halfway to my goal of reducing -intel to <100 bugs
<tjaalton> I guess there are a lot of bugs on drivers which should really be against mesa
<tjaalton> DRI, 3D etc
<bryce> could be
<bryce> it's interesting how much easier it is working on bugs once they're cataloged properly
<tjaalton> right
<bryce> so like today since I'd finished with New, I just focused on bugs marked 'Incomplete'
<bryce> next time I'll focus on the confirmed ones and get them upstreamed
<tjaalton> or ask to try with hardy
<bryce> I did that a lot today
<tjaalton> yeah
<bryce> it was interesting just how large a portion of the bugs were plain old out of date
<bryce> sort of makes me think how unproductive a lot of the bug reporting efforts are - the bug report never gets seen upstream, yet the issue got fixed anyway, so the effort of reporting the bug merely generated work, with no benefit.
<bryce> not really their fault though of course
<tjaalton> I think our documentation should be changed to use 'lspci -nn | grep VGA', which should be enough. -vvnn creates too much noise
<tjaalton> thats partly because there are too many bugs open
<tjaalton> ..still
<tjaalton> so if we only had those that we are certain about, it would be easier to identify new ones and forward upstream
<bryce> yup
<tjaalton> having a release biannually doesn't really help :P
<bryce> in any case, I feel like we're making good progress with them
<bryce> I'd like to get to a point where I can focus on creating fixes more than just managing bug loads
<tjaalton> a reasonable goal indeed :)
<tjaalton> yay, we are below 1600 bugs (1580)
<bryce> nice; where is that totaled?
<tjaalton> https://bugs.edge.launchpad.net/~ubuntu-x-swat/+packagebugs
<tjaalton> that's my start page when triaging
<tjaalton> bbl
<bryce> ah cool
<bryce> looks like most bugs are in lrm
<tjaalton> yeah :/
<tjaalton> ati needs a cleanup as well
<tjaalton> maybe I should put the BTFH hat on and start bashing :P
<bryce> hehe :-)
<tjaalton> bryce: did you notice my comment about the bug list you showed me? only one of them has been tested against the ~latest driver, and the rest should be fixed according to upstream (I actually closed some of them)
<tjaalton> this was about intel vs. i810
<bryce> oh cool, no I missed that
<tjaalton> so it looks like i810 could be dropped IMHO
<bryce> was that this page?  http://people.ubuntu.com/~ogasawara/qa-hardy-list-archive/sort-by-package/current-buglist.html
<tjaalton> 12:04 < bryce> 114331  135093  147189  157610  16887  131972  and probably others
<tjaalton> nope, that :)
<bryce> ahh
<tjaalton> 147189 is the one that seems to be valid now, and I forwared it upstream
<bryce> ok
<bryce> there were some more 8xx ones I looked at in doing the triage today.  I don't remember whether I asked for them to be re-tested or if they looked legit
<bryce> but yeah, I think we're getting close to being ready to deprecate it
<tjaalton> I asked Shaun (147189) to try the latest driver
<tjaalton> since it seems that the past week there has been some changes that should fix issues with i830
<Ng> ooh, new -intel this morning :)
<bryce> heya Ng
<Ng> hey hey :)
<Ng> how evil am I for using EXA, greedy migration and "ExaNoComposite" "false"?
<Ng> seems to make EXA as nippy as XAA
<tjaalton> for me just the greedy stuff is enough (965)
<tjaalton> bryce: we actually toyed with the idea to use EXA only for 965 and use greedy :)
<tjaalton> this was on #ubuntu-desktop yesterday
<bryce> not a bad idea actually
<tjaalton> and XAA for the rest
<tjaalton> I'm not sure if it's doable, but..
<bryce> yeah, I was wondering if that's feasible myself
<bryce> bedtime...  night
<tjaalton> greedy makes it use CPU more, so I haven't tried what happens to the battery lifetime
<tjaalton> night!
<Ng> hmm
<Ng> there's something odd about the new driver
<tjaalton> Ng: oh? describe
<Ng> tjaalton: it's quite hard to describe, but things like the fading in of menus is more like a flicker
<Ng> and it almost seems like colours are made up of 8bit gif dithering
<tjaalton> hmm
<tjaalton> Ng: you had 945?
<Ng> nah this is 855
<tjaalton> ah ok
<Ng> gonna try pulling out those options
<Ng> it's possible my eyes have just gone funny ;)
<Ng> no, that didn't help :/
<Ng> going back to XAA doesn't seem to have helped either
<tjaalton> ok, so it seems like a regression then
<Ng> a pretty hard one to describe, but for example glxgears - the green gear looks like it alternates between light green dots and dark green dots instead of all of the pixels being a uniform green
<Ng> I should still have the old package, I'll give that a try again just to be sure I'm not mad
<tjaalton> hehe
<Ng> nope, definitely not mad :)
<Ng> 2:2.2.0+git20080107-1ubuntu2 is better
<jcristau> should be pretty easy to bisect then
<tjaalton> yes, since that version had all the commits up to ~Jan 31.
<Ng> filed as #189868
<tjaalton> thanks
<tjaalton> looks like the only possible commit which broke this is "Allow non-strict free order for bo_list" a70b59bd44d14e77c9e522dbe225b62a8bcf3050
<Ng> tjaalton: I'd be happy to test a build without that :)
<jcristau> Ng: git-revert a70b59bd; make :)
<tjaalton> Ng: I'll reply to the bug, 'patch -R < foo' should work too :)
<tjaalton> yeah, menus work fine on my 965
<ubotu> New bug: #189863 in linux-restricted-modules-2.6.24 (restricted) "[Hardy]Window borders are not drawn using fglrx" [Undecided,New] https://launchpad.net/bugs/189863
<ubotu> New bug: #189868 in xserver-xorg-video-intel (main) "regression in 2.2.0.90-2ubuntu2 on i855GM" [Undecided,Incomplete] https://launchpad.net/bugs/189868
<Ng> bah, wgetting that git link downoads 30kb of html
<tjaalton> hmm? not here
<Ng> in a browser I get a patch
<tjaalton> 928 bytes
<Ng> this is a patch to i830_memory.c, right?
<tjaalton> yes
<Ng> it's not reverse applying cleanly. just looking at why
<tjaalton> it's not that huge either, so you can just edit by hand if all else fails :)
<Ng> I sure wish patch could tell me why though
 * Ng shrugs. visual inspections suggest I reverted it by hand fine, but the patch still doesn't apply. gonna build it and see what happens ;)
<Ng> tjaalton: nope, still doing it without that patch, afaics
<tjaalton> bah
<tjaalton> Ng: look at the commits since the one 13 days ago, list found here http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=shortlog;h=xf86-video-intel-2.2-branch
<tjaalton> and apply one at a time on top of the working driver
<tjaalton> but I guess you don't have the sources anymore?
<tjaalton> you can find it here: http://users.tkk.fi/~tjaalton/dpkg
<Ng> cool, ta
<seb128> is there a known bug about middle click events being duplicates sometimes on hardy?
<tjaalton> I don't remember seeing one
<ubotu> New bug: #189969 in xserver-xorg-video-intel (main) "Newest revision (2.2.0.90-2ubuntu2) leaves garbage on screen" [Undecided,New] https://launchpad.net/bugs/189969
<Ng> interesting
<Ng> that's 855
<Ng> it's very distressing how many variants there are of each model. I've never seen anything remotely like that bug ;/
<tjaalton> could be the same commit that causes the breakage
<tjaalton> Ng: even more important for you to find out which commit broke it :)
<Ng> tjaalton: yeah, I'll try and work through the patches this weekend
<tjaalton> hmm, I could forward it upstream in the meantime
<tjaalton> done
<Ng> cool, thanks
<ubotu> New bug: #36625 in linux-restricted-modules-2.6.24 (restricted) "can't remove nvidia-glx" [Medium,Confirmed] https://launchpad.net/bugs/36625
<ubotu> New bug: #22297 in linux-restricted-modules-2.6.22 "no icon for nvidia settings in gnome menu (dup-of: 44897)" [Undecided,New] https://launchpad.net/bugs/22297
<tjaalton> \o/ the only remaining bug regarding i830 is fixed with 2.2.0.90
<tjaalton> so now we only have the regression with 855 :)
<bryce> whoohoo
<tjaalton> so, we could drop -i810 with 2.2.1 final
<tjaalton> I don't think it's of much value anymore, unless someone really insists on using xinerama
<tjaalton> going through lrm bugs btw.. man, there are plenty
<bryce> yeah
<bryce> when I was looking at fglrx the other day, I just searched on "fglrx" so I could focus on just that subset
<tjaalton> the good thing is that many bugs are marked against many lrm versions, so it's trivial to mark wontfix the old ones 
<bryce> yup
<tjaalton> bug 36625 might have the information needed to finally fix the nvidia/fglrx uninstall issues..
<ubotu> Launchpad bug 36625 in linux-restricted-modules-2.6.24 "can't remove nvidia-glx" [Medium,Confirmed] https://launchpad.net/bugs/36625
<tjaalton> (bumped the version, was against 2.6.17)
<tjaalton> seems like if mesa has been updated or tried another revision of the driver, this could happen
<ubotu> New bug: #190004 in xf86-input-evtouch (universe) "Please merge xf86-input-evdev 0.8.7-3 (universe) from debian unstable (main)" [Undecided,In progress] https://launchpad.net/bugs/190004
<ubotu> New bug: #54335 in linux-restricted-modules-2.6.24 (restricted) "fglrx should contain install instructions" [Low,Confirmed] https://launchpad.net/bugs/54335
<ubotu> New bug: #54966 in linux-restricted-modules-2.6.17 (restricted) "nvidia-glx boasts unnecessary dependencies" [Undecided,Won't fix] https://launchpad.net/bugs/54966
<bryce> yeah
<bryce> after FF I want to really hammer on some bugs - hopefully I'll have this xrandr gui done by then!
<bryce> there's been a lot of people coming to us about keyboard and mouse problems...  makes me think we need to look into that more seriously
<ubotu> New bug: #22255 in linux-restricted-modules-2.6.17 (restricted) "Potential deadlock when the connection to the AP is lost?" [Medium,Invalid] https://launchpad.net/bugs/22255
<tjaalton> we should switch to input-hotplug (=evdev).. :)
<tjaalton> ie. waiting for gravity
<ubotu> New bug: #48276 in linux-restricted-modules-2.6.24 (restricted) "iwlist can make network tools unusable when it crash" [Medium,Incomplete] https://launchpad.net/bugs/48276
<ubotu> New bug: #158317 in compiz (main) "Random screen flicker on Dell Inspiron 9400 (dup-of: 164589)" [Undecided,New] https://launchpad.net/bugs/158317
<ubotu> New bug: #160747 in linux-source-2.6.20 (main) "Random black frames (screen flickering) #7.10 (dup-of: 164589)" [Undecided,New] https://launchpad.net/bugs/160747
<ubotu> New bug: #34017 in linux-restricted-modules-2.6.24 (restricted) "Include nvidia-settings and nvidia-xconfig" [Wishlist,Fix released] https://launchpad.net/bugs/34017
<ubotu> New bug: #39082 in linux-restricted-modules-2.6.15 (restricted) "nVidia driver in dapper API mismatch" [Medium,Invalid] https://launchpad.net/bugs/39082
<ubotu> New bug: #126251 in linux-restricted-modules-2.6.22 "nvidia-settings menu item missing (dup-of: 44897)" [Undecided,Confirmed] https://launchpad.net/bugs/126251
<ubotu> New bug: #149204 in linux-restricted-modules-2.6.22 "[gutsy] Xorg crashed with SIGSEGV" [Medium,New] https://launchpad.net/bugs/149204
#ubuntu-x 2008-02-08
<ubotu> New bug: #46685 in wvdial (main) "wvdial upgrade causes system crash with ltmodem (dup-of: 41991)" [High,Confirmed] https://launchpad.net/bugs/46685
<bryce> bugz bugz bugz
<tjaalton> almost got them below 1500 ;)
<tjaalton> hrm, the latest lrm doesn't have the latest nvidi&nvidia-legacy drivers in it.. will fix
<tjaalton> hmm, stevenk patched the server
<Q-FUNK> ok, it seems that Bart's revised patch works for Bug #180742
<ubotu> Launchpad bug 180742 in xorg-server "xf86-video-amd: switching to a vcons fails" [Unknown,Confirmed] https://launchpad.net/bugs/180742
<ubotu> New bug: #190153 in xserver-xorg-video-intel (main) "latest update to the intel driver fails suspend" [Undecided,New] https://launchpad.net/bugs/190153
<Ng> woo, another 855 report
<tjaalton> intel loves you
<Ng> I get the feeling that they really don't ;)
<ubotu> New bug: #190198 in xorg (main) "Hardy 4 does not recognize screen on Asus G1S" [Undecided,New] https://launchpad.net/bugs/190198
<ubotu> New bug: #190215 in xorg (main) "RECENT UPDATE has now made Xorg unstable" [Undecided,New] https://launchpad.net/bugs/190215
<bryce> tjaalton: stevenk talked to me about that earlier.  I reviewed the patch and it looked safe enough
<bryce> the patch was done by mjg59
<Q-FUNK> bryce: bartman's latest patch (CPUID) finally builds clean on all 3 arch. 
<tjaalton> bryce: mjg59 said that it was from upstream, but doesn't remember the bug id, and I couldn't find it ;)
<seb128> bryce: hey, do you have a bug about middle click events being duplicated on hardy sometimes?
<bryce> seb128: not that I've run across so far - tjaalton have you seen a bug report on this?
<tjaalton> not that I remember no..
<seb128> ok, I'll have a look to that later
<ubotu> New bug: #190282 in xserver-xorg-video-intel (main) "Bad video behavior on resume from suspend on intel i945GM" [Undecided,New] https://launchpad.net/bugs/190282
<ubotu> New bug: #145688 in linux-restricted-modules-2.6.22 "xserver crashes machine with nvidia quadro nvs140m" [Undecided,Fix released] https://launchpad.net/bugs/145688
<ubotu> New bug: #163767 in linux-restricted-modules-2.6.24 (restricted) "fglrx driver in linux-restricted-modules is out of date" [Undecided,Fix released] https://launchpad.net/bugs/163767
<ubotu> New bug: #185149 in linux-restricted-modules-2.6.22 "NVidia driver doesn't work with 3007WFP" [Undecided,Incomplete] https://launchpad.net/bugs/185149
<ubotu> New bug: #186124 in linux-restricted-modules-2.6.24 (restricted) "Blank screen with lates restricted-modules update" [Undecided,Fix released] https://launchpad.net/bugs/186124
<ubotu> New bug: #162677 in linux-restricted-modules-2.6.22 "restricted nvidia driver fails after gutsy upgrade" [Undecided,New] https://launchpad.net/bugs/162677
#ubuntu-x 2008-02-09
<bryce> tjaalton: do you want to revert the patch until there is a bug id we can reference?
<bryce> tjaalton: I've asked stevenk for a bug id or commit id but he doesn't have one
<bryce> I'll make sure in the future that patches the mobile team uploads come sourced with bug id's, etc.
<bryce> here we go:  http://lists.freedesktop.org/archives/xorg-commit/2008-February/014648.html
<bryce> I've added a note about that in the changelog, and checked all steven's stuff into git
 * jcristau can't see a patch by mjg59 there
<bryce> jcristau: <tjaalton> bryce: mjg59 said that it was from upstream
<jcristau> ah ok
<bryce> jcristau: it appears mjg59 modified the patch to apply against xserver 1.4
<jcristau> only saw the changelog on hardy-changes, so i was confused
<ubotu> New bug: #190347 in linux-restricted-modules-2.6.24 (restricted) "Bad entry in menu" [Undecided,New] https://launchpad.net/bugs/190347
<bryce> I fixed up the changelog and stuff in git, but didn't push out a new release
<ubotu> New bug: #188512 in ubuntu "Hardy Alpha 4 600x800 only in VMware  (dup-of: 172821)" [Undecided,New] https://launchpad.net/bugs/188512
<ubotu> New bug: #190378 in xorg (main) "Kubuntu Hardy Alpha 4: xserver-xorg loads Type1 fonts" [Undecided,New] https://launchpad.net/bugs/190378
<ubotu> New bug: #190381 in xorg (main) "edidfail for widescreen lcd (Dell 2405 FPW) causes incorrect resolution and refresh rates" [Undecided,New] https://launchpad.net/bugs/190381
<tjaalton> bryce: no the patch is ok, I'd just wish they would end up in git as well :)
<tjaalton> oh cool, you did that
<bryce> yeah
<bryce> I'm kinda bummed about my libxrandr changes
<tjaalton> there are a couple of patches (by Hong Liu) that are probably worth having if they don't end up in the stable branch..
<bryce> ok
<tjaalton> changes to libxrandr?
<bryce> carl worth had game night, with me and keith and some other folk, and I told keith that I'd have a patch for him soon for it
<tjaalton> ok, cool
<bryce> but he said since libxrandr is a protocol library, it can't take additional logic code, so it'd have to be done as a separate library
<bryce> which is disappointing since I'm already about 80% done with it this way, and it's only a week until FF.
<bryce> unfortunately if Xorg can't take the libxrandr patch, then gnome certainly won't take the gnome-control-center patch, so all of this will have to be ubuntu-specific :-/
<bryce> bleah
<bryce> it's particularly a shame because I could have saved a lot of time just copying the xrandr code in directly to gnome-control-center, but I figured this way others (like KDE) would be able to benefit from the library as well
<bryce> hmm
<tjaalton> would upstream take a separate library then?
<bryce> well yeah, that's what he was saying I should do
<bryce> but one of the objectives was to end up with no code I had to be the maintainer of ;-)
<tjaalton> hehe, right
<bryce> ah well, at least ubuntu will have a cool xrandr gui
<tjaalton> too bad that there has to be two separate apps for the configuration (user-settings and system-wide), but there's no easy solution to that I guess
<bryce> it sort of makes sense though, since conceptually we have two distinct workflows
<tjaalton> but two entries on the menu
<bryce> and also, the way things are going we'll have less and less system-wide configuration to do
<tjaalton> true, maybe dc-gtk could be dropped from the menu?
<bryce> that's sort of what I've been thinking
<bryce> it's mostly broken at this point for most people.  It may still make sense for the failsafe situation but in general it's mostly vestigial
<tjaalton> speaking of which, I think we should streamline the failsafeDexconf even more. What worries me is that when people end up in it and change their configuration, the resulting xorg.conf looks a lot different to the one they had after installation
 * bryce nods
<tjaalton> because I think that with the current xserver the only thing that would have to be changed with the failsafe-mode was the driver. rest is autoconfigured reliably anyway
<bryce> do you feel like working on cleaning that up?  It's been on my todo list to regen it based on the current dexconf, but I may not have time to get it done before FF
<tjaalton> so, maybe just feed the real dexconf with the failsafe driver?
<bryce> right
<tjaalton> that would cut duplication a lot
<bryce> that might work; I'm trying to remember what else drove me to having a separate copy
<bryce> oh, I also wanted to make it write to xorg.conf.failsafe instead of xorg.conf
<bryce> ah, and I put in code to disable dri, etc. etc. but that may not be necessary (probably those don't get enabled with vesa anyway)
<tjaalton> right
<bryce> I'd also forced it to 800x600 and 16 bit.  Dunno if it's better or worse to let xserver autodetect vesa's max
<tjaalton> hmm, I'm not sure what the server would do if it can't get the mode from the monitor
<bryce> I believe it defaults to 1024x768
<bryce> at least, I've noticed in bug reports that it seems to be doing that when failing to detect the monitor
<bryce> like for instance, I think that's what was screwing things up when it was thinking something was connected to s-video but couldn't get edid out of it
<tjaalton> hmm, vesa shouldn't care about s-video
<tjaalton> anyway, I'll take a look at it and see what can be safely dropped
<bryce> cool thanks
<bryce> I think the week after FF I'll devote to sorting out the displayconfig-gtk bugs, and fixing bulletproof-x stuff
<tjaalton> hmm, failsafeDexconf still uses discover :)
<tjaalton> if installed
<tjaalton> sorry, make that failsafeXServer
<tjaalton> gotta run ->
<ubotu> New bug: #190410 in linux-restricted-modules-2.6.24 (restricted) "[hardy] avm-fritz-firmware-2.6.24-7 is referenced, but package repositories include only avm-fritz-firmware-2.6.17-6" [Undecided,New] https://launchpad.net/bugs/190410
<ubotu> New bug: #190418 in xorg (main) "Server crash when starting totem-xine to play a DVD" [Undecided,New] https://launchpad.net/bugs/190418
<ubotu> New bug: #139582 in xorg (main) "volume knob on dell multimedia keyboard doesn't work out of the box, cannot be configured in gnome keyboard applet" [Wishlist,New] https://launchpad.net/bugs/139582
<ubotu> New bug: #190506 in xrandr "[Hardy] GNOME and GDM are starting up with wrong display resolution" [Undecided,New] https://launchpad.net/bugs/190506
<ubotu> New bug: #154937 in linux-restricted-modules-2.6.24 (restricted) "nvidia-settings defaults to "no" on 3 button mouse emulation" [Undecided,New] https://launchpad.net/bugs/154937
<ubotu> New bug: #190526 in linux-restricted-modules-2.6.24 (restricted) "laptop monitor does not turn on after inactivity when using nvidia-glx-new" [Undecided,New] https://launchpad.net/bugs/190526
#ubuntu-x 2008-02-10
<desertc> *waves*
<desertc> Perhaps this is a better question for the forums... If I wanted to take advantage of the new open source drivers being produced these days by Intel and AMD, then what would be the best (fastest or best performing) card to do so?
<desertc> I realize that the Intel drivers only support their on-board chipsets, but I am thinking about buying a new computer anyway, so it could be an option.
<bryce> presently the 945 is the best supported intel chipset
<bryce> the 965 is newer and promises better features but presently it's still got some kinks to work out in the driver
<desertc> yeah, I was eyeing the 965GM chips.  You think in 6 months the drivers will improve?
<bryce> most of the issues relate to compiz, so if you don't care about that, the 965 is quite serviceable
<bryce> yes
<desertc> Also, I had heard that the AMD (ATI) open source drivers were now featuring 3D components.  Any truth to it?
<desertc> Do you use the Intel graphics yourself?  I was wondering if they supported DVI connectors on the mainboard.  I can't seem to find that information anywhere.
<bryce> not exactly; there are actually two different open source drivers for ATI cards
<bryce> the first, -ati, is quite stable and I use it myself on my main desktop, however it's 2D only
<bryce> the other, -radeonhd, promises 3D functionality but is quite new and not mature enough for widespread use (we've not even put it in main or done much testing for integration in ubuntu)
<desertc> I am really excited about the new open source drivers being made available.  I am more than willing to give up speed to have the best Linux support possible.  But, all that said, I'd like to get the fastest ones I can get, too.
<desertc> It's really wonderful - just five years ago it seemed like there was never going to be any good cards with open kernel drivers, and now there is even a selection to which to choose.
<bryce> it depends a lot on your usage pattern
<bryce> if are into gaming heavily and want the best performance there, your choice will be different than if you want the be able to try out newish X technologies when they come out, but are less driven by 3D performance
<desertc> Do you know of a place that collects metrics on the open source driver performance?  I'd like to see a list of :  "Here's all the cards and chips with open drivers.  Here's the glxgears numbers for the cards, cross referenced by driver versions."
<bryce> also it depends on where you are on the scale of open vs. closed drivers.  If you absolutely don't want to touch closed source, then intel is going to be a stronger choice, whereas if you're more allowing of using closed source sometimes or all the time, the option to boot into fglrx might be valuable
<desertc> I would like this information not just for myself, but for all the people who say that for any kind of decent performance you still need to get a proprietary card.
<bryce> I'd look to phoronix.com
<bryce> oh, and fwiw, glxgears is not really a good benchmarking tool.  It's useful for troubleshooting performance regressions or to verify glx is working, but that's really about it
<desertc> I've been browsing phoronix today, but they don't have the focus on the open source drivers that I am seeking.  They do have some data on the open source drivers, just as a point of reference, but not the hard data comparing all open source solutions.
<bryce> desertc: maybe you should put a page together.  :-)
<desertc> If only I had the computer lab to run benchmarks... :)
<bryce> I think phoronix does ample testing of different cards and drivers, but I don't think they've gathered the data all into one easily digested page
<desertc> I posed this question to the guy who runs phoronix last year, but he did not seem all that interested.
<bryce> I'd be interested in knowing of a page like that to refer people to
<desertc> You don't know anything about DVI connectors on the Intel chips, do you?
<bryce> a bit.  they should work fine afaik
<desertc> Well, I personally am sick of seeing people saying that the open source graphic solutions are available, that they are not worth buying because they are all slow.  That's a real slap in the face to the companies that brought these solutions available, for Linux people to just dismiss them.
<desertc> If we had all the same people who were all begging and signing petitions for ATI and NVIDIA to open their drivers actually buying these solutions, then we would have a lot more eyeballs on the quality and performance of these open solutions.
<desertc> Instead, they seem to dismiss these open solutions and cling even tighter to their proprietary solution.  Makes me sad.  Makes baby Tux cry.
<bryce> well, the best way to help is spending time learning the driver internals and then sending patches.  ;-)
<desertc> I think I will post something on the Ubuntu Forums.  Maybe we can collect some numbers there from people who are already using the graphics cards.
<desertc> What kind of benchmark would you recommend that is maybe already available on Ubuntu or easily accessible to most Ubuntu users?
<desertc> Is there a better one than glxgears?
<bryce> well unfortunately I don't know of a good open source benchmark...  that might actually be a good research starting point
<bryce> mining through the xorg-devel@ mailing list at freedesktop might turn up something
<bryce> or get doom or some other relevant workload that provides fps numbers, and measure that
<desertc> Thanks for your advice, bryce!
<bryce> sure, let me know if you dig up interesting data!
<desertc> I was leaving glxgears running, and I was surprised what happens when GNASH starts up in Firefox.  Brings the FPS down from 5000+ FPS to 14-15 FPS.  Yikes.  They have some work to do there.
<desertc> Anyway, is glxgears available and usable for all graphic chipsets, do you think?
<desertc> And would it be a good indicator of 2D and / or 3D performance ?
<bryce> glxgears is usable for all chipsets
<desertc> thanks again!
<bryce> I don't think it's at all a good indicator of 3d performance
<bryce> use a game instead
<bryce> or, even better, use glxgears, plus 2 games to give several data points per card
<desertc> hmm - would have to find a game that is part of the ubuntu repository that is small enough for people not to be bothered by getting it
<bryce> each card and driver is going to vary in performance a lot depending on the workload
<desertc> not even sure what consists of "3D graphics" in games...  hmm...  isn't my screen 2D?  ;)
<desertc> I do like your idea of using two games and glxgears, however.
<bryce> 3d as in, games that utilize the 3d chip on the graphics card
<desertc> Can you think up any way to determine this is happening, easily?  Any way to tell what games in Universe are "3D" ?
<bryce> most first person shooters are...  quake, doom, tremulous, probably others
<desertc> Hmm - I guess I can search Synaptic for "3D" .. heh heh .. that worked pretty well, actually.
<ubotu> New bug: #190615 in xorg (main) "Sticking Keys" [Undecided,New] https://launchpad.net/bugs/190615
<desertc> http://www.phoronix.com/scan.php?page=article&item=994&num=1
<desertc> This test suite from Phoronix looks like it will be helpful.
<desertc> Coincidently announced on Thursday.... :-}
<bryce_> oh cool
<desertc> Would be nice if he gave us some open source code to put into the Hardinfo benchmark package in Ubuntu
<desertc> I will inquire with him about doing it.
<bryce_> yeah
<desertc> though -- I suspect he simply uses games and other pre-compiled packages... worth a shot anyway
<desertc> Finding any benchmarks is tough!  Any games would have to be configured to a specific video settings for everyone, and this setting is dependent on the monitors.  Generally people say glxgears is CPU bound, not GPU bound, and professional benchmark programs are either closed source or just for WinXP
<ubotu> New bug: #144732 in linux-restricted-modules-2.6.24 (restricted) "cannot resume from suspend with nvidia-glx-new and compiz" [High,Confirmed] https://launchpad.net/bugs/144732
<ubotu> New bug: #190623 in xserver-xorg-video-intel (main) "The restart after updates caused Ubuntu 8.04 Alpha4 to have fuzy vertical lines all over the screen." [Undecided,Incomplete] https://launchpad.net/bugs/190623
<ubotu> New bug: #190724 in xserver-xorg-video-i810 (main) "good" [Undecided,New] https://launchpad.net/bugs/190724
<ubotu> New bug: #190771 in xorg (main) "some keyboard layouts interferring" [Undecided,New] https://launchpad.net/bugs/190771
<ubotu> New bug: #190788 in xorg (main) "ubuntu doesn't respond to mouse in most opened applications" [Undecided,New] https://launchpad.net/bugs/190788
#ubuntu-x 2009-02-02
<tjaalton> desrt: ok, that's weird..
<tjaalton> pwnguin: we can use dbus though, and add the other devices with a daemon like what Alexia_Death has done
<pwnguin> oh yea
<desrt> tjaalton: any ideas?
<desrt> tjaalton: is this the sort of thing that was expected to be working out of the box?
<tjaalton> desrt: at some point
<Alexia_Death> desrt: with my daemon it already is pretty much a matter of starting the daemon and thats it.
<Alexia_Death> desrt: initial configuration is a bit of work.
<tseliot> tjaalton: it looks like my patch fixes the problem: https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/322659
<ubottu> Launchpad bug 322659 in xfree86-driver-synaptics "touchpad left mouse button does random other things in jaunty (dup-of: 320632)" [High,Confirmed]
<ubottu> Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [High,Confirmed]
 * wgrant is back on the planet now.
<tjaalton> tseliot: synaptics 1.0.0 was released, and according to the announce those things should be autodetected now and if not, the kernel is buggy
<wgrant> tjaalton: There are no changes to that end since 0.99.3
<tjaalton> so I'm thinking that these patches might break things for other users
<wgrant> Only manpage changes, FDI comments, and float properties.
<wgrant> The problem is that the autodetection is strange.
<wgrant> It decides that if it can use two-finger scrolling, it will disable edge-scrolling.
<tjaalton> wgrant: sure, but I meant the changes between 0.15.x -> 0.99.3
<wgrant> It's reasonable, but a complete change in behaviour from what we have traditionally had.
<tjaalton> right, and that's something the kernel should tell
<wgrant> No.
<wgrant> It's policy.
<wgrant> Everybody expects touchpads to have edge-scrolling on by default.
<tjaalton> Kernels up to excluding 2.6.29 announce multi-touch capabilities for all
<tjaalton> synaptics touchpads even if the hardware does not support it. If you have a
<tjaalton> such a touchpad, you will need to enable edge scrolling explicitly in the
<tjaalton> configuration.
<wgrant> But the new upstream policy is to enable it only when two-finger scrolling cannot be enabled.
<bryce_> heya
<tjaalton> hi bryce_ 
<wgrant> Evening bryce_ .
<tseliot> tjaalton: my new patch fixes what I broke with another patch therefore I think it's ok to upload it
<tseliot> hey bryce_
<wgrant> tseliot: May I see this patch?
<tjaalton> tseliot: ah, ok :)
<tseliot> wgrant: which one?
<wgrant> tseliot: The one that isn't in the archive yet.
<tseliot> wgrant: https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/320632/comments/53
<ubottu> Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [High,Confirmed]
<tjaalton> wgrant: according to the text I pasted, kernel 2.6.29 should be more wise about these issues, but maybe I'm misreading things
<tseliot> tjaalton: there's still something wrong in the detection of the touchpad edges for ALPS
<wgrant> tjaalton: It's a different, but related, issue.
<wgrant> tjaalton: Few people expect two-finger scrolling, but that's all most people will get (even with 2.6.29).
<tjaalton> I'm lucky not to have a touchpad, so it all is a bit irrelevant to me :P
<tjaalton> BMFH
<wgrant> tjaalton: Basically, pre-0.99, nothing was autodetected. Vertical edge-scrolling was always enabled, and 1-, 2- and 3-finger taps always emulated clicks on buttons 1, 2 or 3 respectively.
<tjaalton> wgrant: I trust your judgement, so whatever has your stamp-of-approval, I'll upload :)
<wgrant> Heh.
<wgrant> tseliot's patches are what I would have done.
<tseliot> ;)
<wgrant> Had I know there was going to be so much bugmail from the default changes, I would have done it myself before I went away...
<wgrant> And we finally have float properties.
<bryce-sprint> tjaalton: did you get a chance to look at the client limit patch?  I could rework that patch to s/1024/512/ if you haven't already, that should be pretty simple
<bryce-sprint> tjaalton: the hotel wireless here is ultra slow though
<tjaalton> bryce-sprint: well, the proto patch uses 16bits instead of 8, so maybe 9 would do for 512, but I guess 16 doesn't hurt. the one for xorg-server is trivial
<tjaalton> gotta run now ->
<wgrant> Huh, DRI2 actually works.
<bryce-sprint> wgrant: what did you need to do to flip that on?
<wgrant> bryce-sprint: Just change the AccelMethod to UXA.
<wgrant> It's only a little bit quirky with some menus.
<bryce-sprint> ok good
<bryce-sprint> wgrant: can you file bugs with the issues you find?
<wgrant> bryce-sprint: Against what? -intel?
<tseliot> when I tried UXA X started and when I launched gnome-terminal X froze (together with the kernel)
<wgrant> The menus do this very strange bright fadish thing when coming in and out.
<wgrant> But i915 with UXA and DRI2 works fine, with redirected direct rendering.
<wgrant> tseliot: Why do you go back to disabling multi-finger taps in your patch in commennt #53?
<wgrant> Disabling on non-MacBooks, that is.
<tseliot> wgrant: because it breaks drag and drop with physical buttons
<tseliot> which is not what we want ;)
<wgrant> tseliot: You mean it does strange scrolly thing and releases early?
<wgrant> There must be better ways to fix that, given that I'm sure it worked before.
<tseliot> if you have one finger on the touchpad and one to hold down the physical left button drag and drop would simply not work
<bryce-sprint> wgrant: yes 
<tseliot> and the cursor will just move
<wgrant> tseliot: I can drag and drop almost fine - the only problem is that it drops when I take a finger of the touchpad, rather than off the button.
<tseliot> hmm...
<popey> before I file a bug report against xrandr/xorg in jaunty, I just wanted to ask if there was some fundamental change in the intel driver that might cause regressions/breakages?
<popey> (specifically it ignoring a resolution I put either on the command line with xrandr and also if I put the correct modeline in xorg.conf)
<tjaalton> popey: change since when? the driver has supported randr-1.2 since feisty, so forcing a mode needs some work
<popey> tjaalton: well I used a little bit of gtf/xrandr magic as recently as a week or so ago, and now xorg just barfs when i try to set it to a specific res 
<tjaalton> popey: hmm, that sounds odd
<popey> tjaalton: worth filing a bug ?
<tjaalton> popey: probably.. where are the errors from?
<popey> there is no error, the screen just goes to a different mode - uniform colour of brown, no icons, no panels
<popey> system isn't locked up, i can restart gdm and get back in
<tjaalton> huh, weird
<popey> xorg.0.log doesn't even make reference to the resolution i set in xorg.conf
<popey> i know it's reading the xorg.conf because i added the necessary wacom stuff and that works
<tjaalton> you need to do something like here to force a mode: http://users.tkk.fi/~tjaalton/foo/xorg.conf
<popey> I had something similar, with a separate section for modes
<popey> have modified it to be more like yours and it still ignores the res I put in
<popey> http://popey.com/~alan/xorg.conf
<tjaalton> logfile might help
<popey> http://popey.com/~alan/Xorg.0.log :)
<tjaalton> what if you add 'Option "monitor-LVDS" "Generic Monitor"' to the device section?
<popey> oh I see, in the logs it's trying to set VGA to 1280x720?
<tjaalton> yes
<popey> ok, adding that option I get a lot of blinking but no x on the panel
<tjaalton> another logfile too?-)
<popey> http://popey.com/~alan/Xorg.0.log_2
<popey> http://popey.com/~alan/xorg.conf_2
<popey> oh, my bad
<popey> i set the option in the wrong place
<tjaalton> does it work if you move it?
<popey> heh, no
<tjaalton> yeah, according to the logfile it did try 12x7
<tjaalton> but I've no idea why it doesn't work
<tjaalton> hmm, are you sure it's a 75Hz screen?
<popey> i used gtf to generate that modeline, and specified "1280 720 60"
<tjaalton> oh
<tjaalton> I misread it
<popey> worth me filing a bug do you think?
<tjaalton> yeah
<popey> although from the xorg log it seems to be using 1280x720 for the external VGA still and autodetecting LVDS
<popey> oh, then tries later
<popey> tjaalton: further investigation reveals that actually my laptop can't switch to _any_ resolution other than the native one
<popey> tjaalton: fyi if you're interested i filed bug 324286 about it. thanks for the help
<ubottu> Launchpad bug 324286 in xserver-xorg-video-intel "[945] [jaunty] blank screen on resolution change" [Undecided,New] https://launchpad.net/bugs/324286
<tjaalton> popey: ok thanks
<jcristau> hrm. patches.ubuntu.com isn't getting updated?
<tjaalton> seems like it
<maxb> Hi, after the recent libgnome change to use the xorg detected dpi value for font sizing, my fonts are huge
<maxb> However, "xrandr --verbose" is getting the correct screen dimensions
<maxb> Hardware is an Acer Aspire One
<maxb> Can someone guide me to filing a useful bug? Thanks.
<jcristau> hrm.
<jcristau>     - Add libxinerama1 to build depends.
<jcristau> really?
<tjaalton> sounds odd
<tjaalton> maxb: just use 'ubuntu-bug -p xserver-xorg-video-FOO', that should include the useful logs
<maxb> tjaalton: xdpyinfo says the correct resolution and physical dimensions...does it still make sense to file against the driver?
<tjaalton> maxb: the logfile will tell
<maxb> ok
<jcristau> (probably not. but then the font size should be correct.)
<maxb> LP 324518 filed, anyway
<ubottu> Launchpad bug 324518 in xserver-xorg-video-intel "Overly large fonts" [Undecided,New] https://launchpad.net/bugs/324518
<tjaalton> (==) intel(0): DPI set to (96, 96)
<jcristau> tjaalton: i think that one's misleading
<jcristau> it says that here, too, but xdpyinfo says 125x125
<tjaalton> hmm, nice
<superm1> tjaalton, dpkg-shlibdeps complains elsewise...
<tjaalton> superm1: hum, ok
<jcristau> superm1: okay. i guess that makes sense. blobs ftl.
<tjaalton> maxb: could be that your font sizes are just too large?-)
<superm1> yeah. pretty much everything in that upload was working around ugly behavior that happens with the blob :(
<tjaalton> maxb: I believe the defaults have been changed in the past to work around some issues, so maybe they should be changed again
<tjaalton> hmm, although they should be smaller now
<maxb> tjaalton: Well, it could be that everything's working as designed, but if that's the case, then every Aspire One user is going to get their fonts blown up to an unhelpful size when upgrading
<tjaalton> maxb: I'm not sure what's going on, but probably the guys at the sprint will notice it too, and do something about it :)
<maxb> ooh, good point
<maxb> Hopefully there'll be a few netbooks there
<maxb> tjaalton: I just updated a second machine, with the same result - a distinctly excessive increase in font size. I suppose things are working as designed, but this design is liable to annoy people upgrading, I suspect
<tjaalton> maxb: AIUI the effect should be the opposite, but oh well :)
#ubuntu-x 2009-02-03
<RAOF> Is anyone else having compiz problems with nvidia-180?  Mine seems to corrupt all the GL transformed textures.
<RAOF> Woah!  Wobbly is *trippy*.
<andersk> RAOF: I'm not (but now I almost wish I did :-P). 
<RAOF> I wonder if istanbul will capture it.  It's truly nifty.
<RAOF> o/` Istanbul is Constantinople / now it's Istanbul not Constantinople / been a long time gone / Constantinople o/`
<RAOF> Well, that's disappointing.  Istanbul captures nothing but noise.
<RAOF> Mmm, temporary craziness.  Gotta love it.
<RAOF> Oh, even better.  Combined with that 'large windows sometimes don't update' XDamage bug.  Sweet.
<bryce_> tjaalton: what's your thoughts on UXA for jaunty?
<bryce_> I'm leery of it being still too unstable
<tjaalton> yeah, and there's the alpha-channel corruption thing
<tjaalton> and it crashes my X on resume
<bryce_> tjaalton: I'm wondering if we should revert -intel back to 2.4.x given how many people complain about the performance
<bryce_> tjaalton: what are your thoughts?
<bryce_> tjaalton: I'm wondering if we should revert -intel back to 2.4.x given how many people complain about the performance... your thoughts?
<tjaalton> bryce_: the ddx driver doens't have much to do about it
<bryce_> tjaalton: mesa?
<tjaalton> bryce_: xserver 1.6 depends on 7.3
<tjaalton> I think it would be silly to go back :)
<bryce_> tjaalton: then how to fix the performance issues?
<tjaalton> re-enable patch 107..
<tjaalton> and give KDE users the finger ;)
<bryce_> we were seeing performance issues before that was dropped
<bryce_> ^weren't
<jcristau> gem is probably responsible for at least some of the performance problems
<desrt> Alexia_Death: you wrote a program that reads the serial port and injects events into the kernel input layer, or...?
<Alexia_Death> desrt: No. I made a dbus daemon that adds and removes wacom devices.
<Alexia_Death> Why the question?
<desrt> just wondering why my tablet isn't working and what needs to be done to make it happen out of the box
<Alexia_Death> desrt: Jaunty with all the latest updates?
<desrt> downloaded alpha2
<Alexia_Death> And what tablet?
<desrt> it's an x200 tablet
<desrt> (lenovo)
<desrt> the tablet shows in hal.  complete with the 'input' and 'input.tablet' capabilities and "Wacom" appearing in the product string
<Alexia_Death> Its a serial TabletPC device?
<desrt> and the wacom fdi file is installed...
<Alexia_Death> you have stylus then.
<desrt> ya.  the serial.device points at /dev/ttyS0
<desrt> i suppose so
<desrt> when i hacked up xorg.conf to manually handle this i added stylus and eraser sections
<Alexia_Death> For taplet pc X xonf is OK.
<desrt> did you just try to tab-complete irc?
<Alexia_Death> Your serial device is not going anywhere.
<Alexia_Death> desrt: ?
<desrt> 'xonf'
<Alexia_Death> conf
<desrt> ah.  right.
<desrt> i was sort of thinking that it would be nice, though, to have it working for jaunty out of the box
<desrt> like, if i go edit my xorg.conf, then it works for me
<Alexia_Death> desrt: as to making it work out of the box, HAL should take care of enabling the stylus
<desrt> but anyone else who installs on a thinkpad ends up thinking 'ubuntu sucks'
<Alexia_Death> So it works there.
<Alexia_Death> My daemon can be used for per user conf
<desrt> so perhaps i need to know a little more about how X deals with hal
<Alexia_Death> desrt: if you are aup for making a configuration utility for it then thats good enough
<Alexia_Death> desrt: its really simple.
<tjaalton> desrt: didn't you say it works OOTB as a stylus?
<desrt> no
<desrt> nothing happens at all out of the box
<desrt> i mean.. i can make some nice drumming noises, i guess...
<tjaalton> then why does lshal show it? pastebin pleas
<tjaalton> +e
<desrt> but the cursor isn't moving :)
<desrt> erm
<desrt> that's going to take a little while.  hold on :)
<Alexia_Death> desrt: HAL should be able to make the stylus move if it recognizes it.
<desrt> right.
<desrt> so that's what i found odd :)
<Alexia_Death> that is a bug
<desrt> good!
<desrt> now we're getting somewhere :)
<Alexia_Death> the limitation of HAL is that it can add just one device
<Alexia_Death> So no eraser.
<desrt> it seems sort of like X should work around that
<Alexia_Death> you need the daemon for that.
<jcristau> Alexia_Death: that's the part i don't understand
<Alexia_Death> X does. with allowing DBUS conf.
<desrt> like.. this "one physical device = one XInput device" is an incorrect assumption in X, clearly
<desrt> hmm
<Alexia_Death> desrt: Its an incorrect assumotion in HAL not X
<jcristau> Alexia_Death: if the driver gets loaded, then it can add the other devices as it pleases
<Alexia_Death> And hall people have said they wont fix it.
<desrt> Alexia_Death: how is HAL to know?
<jcristau> so no need for a daemon or dbus or anything?
<Alexia_Death> jcristau: Im not a driver developer
<Alexia_Death> I knw how I can do it now.
<desrt> i could buy a brand new pen
<jcristau> meh. nobody is.
<desrt> and bring it near my laptop
<Alexia_Death> Besides, I think its smart to keep that out of the drver
<desrt> are you saying HAL should create a new device node for it when that happens?
<Alexia_Death> desrt: pen is not the device
<Alexia_Death> device is the surface
<desrt> absolutely agree
<Alexia_Death> that supports pens and erasers
<desrt> there is only one surface
<Alexia_Death> HAL can only give you support for pen
<desrt> supposedly i can use airbrushes and all sorts of other fancy stuff with this...
<desrt> any wacom device
<Alexia_Death> And like I said, Ive talked to HAL people about it.
<Alexia_Death> airbrush is a kind of pen
<Alexia_Death> IIRc.
<desrt> but i would expect it to show as a separate xinput device
<Alexia_Death> serials are used for that I think
<Alexia_Death> That support is iffi.
<Alexia_Death> I have to go for now.
<desrt> k.
<Alexia_Death> Ill be back in a little later.
<tjaalton> the product mapping could live inside the driver, and initialize the devices it supports
<desrt> i'll boot up the live cd again and get lshal
<tjaalton> so yes, no daemon needed
<desrt> tjaalton: that's sort of what i was thinking
<Alexia_Death> tjaalton: DAemon is still needed fpr per user configuration
<desrt> seems like it should be sufficient for hal to say "there's a wacom serial device here"
<jcristau> Alexia_Death: why?
<Alexia_Death> You dont expect all users to live with default conf do you.
<desrt> and for X to create as many Xinput devices as are required from it
<tjaalton> Alexia_Death: wacom should just support input properties, then the settings could live in .xsession or gconf or ..
<Alexia_Death> desrt: thats in the domain of wacom development. Talk to ping about it.
<desrt> tjaalton: you'd need something to bridge the settings over, in that case
<Alexia_Death> tjaalton: tablet properties need a UI and easy way to change.
<jcristau> desrt: that's called a desktop environment
<desrt> like gnome-settings-daemon or whatever
<Alexia_Death> its not a set once thing.
<desrt> jcristau: ya.  exactly.
<tjaalton> Alexia_Death: yes, but the gui should be provided by the DE (in the long run, we discussed this already :)
<Alexia_Death> Nice dreams guys
<tjaalton> hehe
<Alexia_Death> But its not happening dor jaunty 
<tjaalton> no
<Alexia_Death> what i do works now
<jcristau> the ui is completely unrelated to how you pass those properties to the driver..
<desrt> this seems to be sort of similar to how gnome configures the keyboard layout and stuff
<desrt> someone just needs to teach it about tablets :)
<desrt> Alexia_Death: do you have a link to the stuff you wrote?
<desrt> lshal -> http://pastebin.com/m49dbb4ad
<tjaalton> desrt: ok, then Xorg.0.log
<desrt> tjaalton: no mention of the word "wacom" anywhere in there
<tjaalton> sure is
<desrt> sure isn't
<tjaalton> lines 318-333
<desrt> in the Xorg.log i mean
<tjaalton> ah
<tjaalton> was this on jaunty?
<desrt> jaunty alpha 2 livecd
<tjaalton> ancient! :)
<desrt> :)
<tjaalton> still, I'd like to see it
<desrt> ok
<desrt> gimme a sec
<tjaalton> I'm surprised that hal picked that up
<desrt> http://pastebin.com/mf39b2d0
<tjaalton> (WW) config/hal: no driver or path specified for /org/freedesktop/Hal/devices/pnp_WACf004
<desrt> ahah
<desrt> good catch :)
<desrt> thing about that is that i have this /usr/share/hal/fdi/policy/20thirdparty/10-wacom.fdi
<tjaalton> from the wacom driver
<desrt> it says that if input.caps contains "input" and product contains "Wacom" then input.x11_driver is set to "wacom"
<desrt> and indeed, in the lshal output:
<desrt>   input.x11_driver = 'wacom'  (string)
<desrt>   input.x11_options.Type = 'stylus'  (string)
<desrt> for udi = '/org/freedesktop/Hal/devices/pnp_WACf004'
<tjaalton> yes, but I think they should be for /org/freedesktop/Hal/devices/pnp_WACf004_serial_platform_0
<tjaalton> also the capabilities
<tjaalton> that way the driver would be assigned for it
<desrt> the one that has the linux.device_file
<tjaalton> either kernel or hal boog
<tjaalton> depends where info.capabilities is coming from..
<desrt> could also argue that it's an X bug for not querying subdevices to find ports
<desrt> and, as these things go, i guess probably there -will- be an argument about that :)
<tjaalton> well, if it would list the capabilities for the subdevice, it'd just work
<tjaalton> you can do test that by not matching info.cap..
<tjaalton> -do
<desrt> ya.  i believe that it would work.
<desrt> it's also not quite right, though
<tjaalton> at least it should be confirmed, so that it's not something else
<desrt> because then it will assign the x11 driver to both nodes
<tjaalton> that's not a problem
<tjaalton> it'll fail to use it for the first one
<desrt> i know it's not a problem... X will just say "dur... dunno what to do, so i ignore"
<desrt> but that's not right
<desrt> seb128: this is why i switched to fedora!
<seb128> desrt: good for you!
<desrt> damn X hackers breaking my tablet :p
<desrt> (or hal hackers...)
<tjaalton> whot has done the same already, so you lose :)
<desrt> ya.  i noticed.
<LLStarks> yo.
<LLStarks> http://ubuntuforums.org/showthread.php?t=1058915
<LLStarks> hopefully i can get a nice tester pool for you guys
<desrt> X guys need to have a talk with HAL guys, i think
<desrt> and figure out what the correct thing to be doing here is
<desrt> any workaround done at the vendor level in the meantime will be more or less at the "quick hack" level...
<tjaalton> hal is just the messenger I guess
<desrt> which is like, half of making a distribution anyway :)
<jcristau> desrt: you know, you could send a mail to hal@ today, and get that fixed :)
<tjaalton> right, hal is full of quirks
<tjaalton> hal-info
<tjaalton> desrt: but you should try removing the other match rule to see if it would work then
<desrt> i'll just bug david on irc :p
<desrt> it's actually really hard for me to check if adding that match rule would make it work
<desrt> so i'm gonna hal-set-property instead
<desrt> did you guys add nozap?
<desrt> didn't fix it
<desrt> i think X doesn't even look at the subdevice at all
<desrt> i'm gonna try adding the linux device path to the parent node instead
<tjaalton> you need to restart hal
<desrt> i used hal-set-property
<tjaalton> oh
<desrt> i can't really make changes and restart... i'm running off of a livecd :)
<tjaalton> sure you can
<tjaalton> the console is right there
<tjaalton> if it works
<desrt> still no love
 * desrt wonders what xorg log will have to say now
<tjaalton> don't bother, just pastebin it ;)
<desrt> still "no driver or path" even when i specify the serial path
<tjaalton> there should be two entries for them
<tjaalton> ?
<desrt> i think X doesn't bother visiting the second one
<desrt> possibly because it doesn't have the input capability on it
<desrt> lemme try adding that
<jcristau> X just looks for input.x11_driver
<jcristau> afaik
<desrt> well, it has that
<desrt> i'll try adding the cap
<jcristau> then it's missing input.device
<tjaalton> oooh, right
<tjaalton> it's looking more and more like a hal bug :)
<tjaalton> it doesn't seem to handle serial devices too well
<desrt> ahh
<desrt> X looks for input.device key?
<jcristau> yes
<desrt> can that be a serial device instead of an evdev?
<jcristau> maybe not
<tjaalton> try :)
<desrt> i got X to notice the second device node by adding the input capability, btw
<desrt> but it still fails due to no input.device :)
<desrt> wtf
<desrt> well
<desrt> something happened?
<desrt> after so many X server restarts X decided that i was bored of looking at brown
<desrt> and put a nice purple pattern on my screen
<desrt> lovely as it is, i can't read anything anymore and my system appears to have crashed
<desrt> i guess this can't be blamed on HAL bug :)
<tjaalton> so no console anymore?
<desrt> nah.  completely dead
<desrt> my caps lock was flashing.  that's usually a bad sign.
<tjaalton> ok
<desrt> probably some weird race in the video driver or something
<desrt> and after so many restarts i finally hit it
<tjaalton> a feature in the drm driver
<tjaalton> or so
<desrt> yes.  feature.
<desrt> "you've seen too much brown.  how about some lovely purple?"
<tjaalton> how did you kill the server?
<desrt> either the ubuntu livecd boot has gotten one hell of a lot faster or my new laptop is cooler than i thought
<desrt> i logged out
<tjaalton> ok
<desrt> i think you guys enabled nozap
<tjaalton> no, upstream
<desrt> ah
<desrt> that is my preferred way of restarting X :)
<desrt> s/is/was/ i guess
<tjaalton> still there to be enabled if you wish
<tjaalton> just not on by default
<desrt> erm
<desrt> ok.  this is odd.
<desrt> it's doing it again
<desrt> this is the second time, now, that it has happened immediately after me adding input.device
<desrt> i'm starting to suspect causation
<desrt> i have no idea how that would work, though
<desrt> but no capslock flash this time
<desrt> maybe X has changed the video mode, but not put anything on the screen
<desrt> then it goes to open the device and crashes
<desrt> so i see the uninitialised screen -- purple
<desrt> whereas had it gotten past opening the device, it would have gotten to the part where it puts non-purple stuff on the screen
<tjaalton> dunno
<desrt> i'm gonna try starting X under gdb over ssh
<desrt> fecking network manager.  nm-applet appears to tear down the wifi when you take down X
<desrt> grrr
 * desrt stops caring for now and tries to get some real work done instead
<desrt> maybe later :)
<tjaalton> sure :)
<Alexia_Death> desrt: http://a.death.pri.ee/watahod-0.4.1.tar.gz bonuspointd for figuring out without handholding how to use it.
<LLStarks|Bored> hi. quick question. is there a reason why restarting x has been made impossible for laptops without a dedicated sysrq key?
<bryce_> LLStarks, because people accidentally hit the key combo and it kills their x.  sysrq has little to do with it
<tjaalton> LLStarks|Bored: try printscreen
<jcristau> 'impossible'. heh.
<jcristau> sudo killall Xorg still works :)
<Alexia_Death> bryce_: its intentional that I cant kill my X with ctrl alt backspace? Awww... its such a usefull combo
<tjaalton> Alexia_Death: sure you can, it's just not enabled by default
<Alexia_Death> no clue how to enable it:P
<jcristau> reading docs is hard
<bryce_> Alexia_Death: read http://wiki.ubuntu.com/X/Config/
<Alexia_Death> jcristau: figuring out if its a bioug ora feature that it does not work is hard:P
<jcristau> Alexia_Death: fair enough
<Alexia_Death> :)
<jcristau> maybe i should add that in NEWS.Debian so i at least can beat people with that stick :)
<tjaalton> heh
<_MMA_> In Jaunty, what nvidia driver should one use for a GeForce 6 series card?
<superm1> _MMA_, jockey isn't ready in jaunty yet, but you will probably need nvidia-glx-180 or nvidia-glx-177
<_MMA_> superm1: Ok. I think I got -180 installed and I *still* (since Edgy) cant get my proper res back on the HTPC. So I'm thinking I need to use a legacy driver or something.
<superm1> _MMA_, i would recommend holding off until jockey is ready.  it will be able to tell you what driver you are supposed to be using
<superm1> resolutions are detected via the EDID of your television set generally
<tjaalton> hmm so -180 supports the 6-series.. which means -177 should probably be dropped
<_MMA_> superm1: And that's when my problems started. ;) My modline no longer worked. :)
<superm1> _MMA_, if you have a bad TV EDID there are methods to add modelines.  You'll have to read the NV readme on their website for the exact options to let you do it though
<_MMA_> superm1: Hell with it. I'll just stick with windows on the box 'till I build a new one. I've really put out tons posts and read alot to try to solve this. Gonna be easier to just buy new stuff.
<superm1> _MMA_, the problem is most likely your TV set if the EDID is bad.  I'd check for TV firmware updates before you scrap all this
<tjaalton> and not get nvidia this time?-)
<superm1> tjaalton, TV's with bad EDID's don't handle so well with any of the drivers from what i've seen....
<_MMA_> tjaalton: Well they still work better than ATI. :)
<_MMA_> And I'm unsure if Intel can do 1080p. Still gotta look at that.
<superm1> at least for the moment the hardware acceleration you get out of NVIDIA drivers for XvMC and libvdpau and what not makes them more attractive generally for HTPC's.
<superm1> until Intel supports VA-API that will probably be the case
<tjaalton> oh well, I'm happy to not need the craphics card (pun intended) on my htpc at all
<_MMA_> superm1: Any of the jaunty players using XvMC and libvdpau now?
<superm1> _MMA_, mythtv trunk does.  we may or may not be uploading it to jaunty though.  it's living in a PPA until upstream blesses it
<superm1> _MMA_, I dont think ffmpeg is getting uploaded with the support until jaunty+1, so the rest of the apps will follow that
<_MMA_> superm1: Ok. Maybe one day, I'll get this all sorted out. I can't even find a soundcard that works with SPDIF right. I have one, but have only had it work correctly once.
 * _MMA_ shrugs.
<LLStarks> note to self. holding down printscreen for 1 second yields 100 prompts.
<LLStarks> alt+printscreen as well.
<LLStarks> i can't access sysreq from this inspiron.
<LLStarks> and if i can't  restart x on a whim, i'll be sad
<LLStarks> also, i want to punch the google earth devs for having atmosphere on by default.
<LLStarks> i know it sounds hypocritical with regard to my stance on uxa, but jeez.
<tjaalton> does alt+prtscr+h work from the console?
<tjaalton> should print out the hotkeys that work
#ubuntu-x 2009-02-04
<TheMuso> Is it known that multi-touch is broken for MacBook Pro 4,1 and up? I don't know if others are working, but mine isn't.
<TheMuso> To be more precise, I can do 2-finger scrolling, but I can't put two fingers on the pad, click the button and perform a right click.
<TheMuso> It also appears that the evdev and synaptics input drivers are loaded. Not sure what happens in Intrepid, would need to reboot to check.
<mnemo> anyone else seeing this on jaunty? --> http://files.minimum.se/bug_attachments/xorg_intel/opengl_surface_leaves_dirt_trail_when_moved/opengl_surface_leaves_dirt_when_moved.png
<mnemo> i've had that problem on my machine since 2.6.28 kernel landed (at which time a bunch of intel packages where updated as well)
<mnemo> hardware is intel g45
<tjaalton> mnemo: nope, works fine on my i965
<tjaalton> TheMuso: sorry, don't have a touchpad..
<TheMuso> tjaalton: Ok appart from the X logs, is there anthing else I can check?
<tjaalton> TheMuso: check if some of the recent patches for the driver broke something
<TheMuso> tjaalton: Kernel level, or X/Userspace level?
<TheMuso> never mind, I'll try with an intrepid kernel and see what happens.
<ziroday`> Hi, I have an odd bug where my left click sometimes acts as a middle click. Would that be a X bug?
<tseliot> mvo: just FYI Update Manager should migrate users who have nvidia-glx-177 installed to whatever nvidia-common recommends (since 177 is no longer in jaunty)
<mvo> tseliot: thanks, I will do that (or just we just run the nvidia detector again and install whatever package is recommended for the given hardware by it)?
<tseliot> mvo: nvidia-detector was triggered only if a driver with the old name scheme was detected
<tseliot> I could make it catch 177 too (for upgrades from the command line)
<mvo> tseliot: it sounds like it should go there, yes. if it does update-manager should pick the right driver for -177 automatically
<mvo> tseliot: it build-depends on nvidia-common so a rebuild of u-m should be enough :)
<tseliot> mvo: ok, great, I'll let you know when it's ready
<mvo> tseliot: it looks like its enough to add the name to old_drivers, right?
<tseliot> I can't remember :-P
<tseliot> but yes, that should be the way it's donw
<tseliot> done
<tseliot> mvo: aah, yes, it's sufficient to add it to the "oldPackages" list
<mvo> :)
<mvo> thanks
<mvo> nice
<mvo> the code is still active in u-m so we should be fine
<tjaalton> shouldn't -180 just replace -177?
 * mvo needs to reboot
<tjaalton> hmm
<tjaalton> tseliot: did you see my comment?
<tseliot> tjaalton: yes, in part. 173 should replace 177 too
<tseliot> some cards will use 173 others will use 180
<tjaalton> tseliot: did 180 drop support for some cards?
<tseliot> tjaalton: geforce 5
<tseliot> http://www.nvnews.net/vbulletin/showthread.php?t=122606
<tjaalton> I thought 173 was the last releae that supported it
<tjaalton> can' read links now
<tjaalton> +t
<tseliot> yes, you're right
<tseliot> I guess 177 was just a transitional driver
<tjaalton> well it was the stable one, now replaced by 180
<bryce_> can 177 be dropped then?
<tseliot> bryce_: pitti removed it from jaunty
<bryce_> ok
<tseliot> mvo: I have just pushed my changes but I haven't had the time to test them: https://code.launchpad.net/~albertomilone/nvidia-common/main
<tseliot> the diff is very small
<tseliot> tjaalton, jcristau: do you know what's the username of Peter Hutterer on IRC?
<tjaalton> tseliot: whot
<tseliot> tjaalton: thanks
<tjaalton> but he's in a funny timezone, so it's early morning down there
<tjaalton> too early
<tseliot> oh
<tjaalton> something like GMT+10
<tseliot> Australia?
<jcristau> yeah
<federico1> tseliot: the tablet stuff - http://mail.gnome.org/archives/distributor-list/2009-February/msg00000.html
<tseliot> federico1: ah, ok so it just allows users to decide whether screen rotations affect tablets too
<federico1> tseliot: yeah - it's an evil hack, but works for now
<tseliot> federico1: I'm working on a daemon (in C) which should make tablets hotplugging just work (Alexia_Death did it in Python)
<tseliot> and I thought that you were referring to something like that
#ubuntu-x 2009-02-05
<bryce_> tjaalton: mind reviewing the debdiffs on bug 260138 before I upload them?
<ubottu> Launchpad bug 260138 in xorg-server "Xorg needs client limit raised" [Wishlist,In progress] https://launchpad.net/bugs/260138
<tjaalton> bryce_: heh, they both are the same :)
<bryce_> erk
<bryce_> I'm such a moron.  right one uploaded now
<tjaalton> hmm, the git version already has xsfbs
<tjaalton> actually I was looking at the package, not  git.. wonder why the diff shows it
<tjaalton> the bits start from 0, so 8 would be enough?
<tjaalton> rather confusing..
<tjaalton> it should work as is, and allow to bump it to 1024 if needed AIUI
<tjaalton> the limit
<bryce_> ok
<bryce_> alright, I'll upload this once we're unfrozen
<bryce_> tjaalton: I can update you on some discussions/decisions at the sprint.
<bryce_> pgraner and I talked about moving x to vt1
<bryce_> for jaunty+1 most likely
<bryce_> so vt 1 == x, 2 == login console, 3 == log messages
<bryce_> for demoting fglrx for jaunty+1, a criteria that was raised was to be sure that 3d games like sauerbrauten work with -ati first.
<bryce_> if we can show that 3d games work fine now with -ati it would greatly help justify refocusing to just -ati
<bryce_> seb128 and I discussed removing the gnome 96 dpi, which is now done.  we've got some feedback from users who noticed it right away.  it doesn't seem to be wrong, just considerably different than they're used to.  So I put a note in release notes about this, and how to customize it.
<bryce_> I've been helping people test out uxa a good bit.  seems like 50/50 whether it works vs. not
<bryce_> I talked to timg about 320813.  he's got the patch for drm but wants to wait for the upstream discussion to be resolved first before incorporating it
<bryce_> meanwhile a LOT of people have reported this problem to me so far
<bryce_> xserver changes pushed to git.
<tjaalton> bryce_: ok, cool
<tjaalton> yeah the r6/7xx stuff needs to land in mesa first
<tjaalton> but I believe that'll happen in time for j+1
<tjaalton> about that bug.. maybe the cleanest solution would be to disable vblank again, since it doesn't seem like jbarnes/mrcooper will reach a consensus anytime soon. hope that I'm wrong :)
<tjaalton> UXA/DRI2 already disables vblank for some reason
<tjaalton> so that's why people aren't seeing the problem with it
<Alexia_Death> Isnt just one login console a bit little?
<tjaalton> you can have more if you need
<tjaalton> or use screen
<Alexia_Death> Well, couldnt it be 1-x 2-log 3-5 logins?
<Alexia_Death> Configuring more is sort ofa pita. moving X to 1 makes sense tho.
<tjaalton> every getty consumes memory, so one is enough
<Alexia_Death> :/
<superm1> tjaalton, ping.  102-fedora-vesa-1.3.0-range-hack.patch fixes bug 315588 for me
<ubottu> Launchpad bug 315588 in dell "[Unknown 14] Hardware w/ 1600x900 LCD does not boot up using vesa" [Medium,Confirmed] https://launchpad.net/bugs/315588
<superm1> tjaalton, i just got ahold of that hardware again and tested it
<superm1> why did you think it was able to be dropped back in intrepid?
<superm1> bryce, do you know remember why timo had recommended dropping that 102-fedora-vesa range hack patch in the first place?
<BUGabundo> I'm one of those afected by the HUGE DPI (https://wiki.ubuntu.com/X/Troubleshooting/HugeFonts). against what package should I file it ?
<tjaalton> superm1: probably because fedora dropped it
<superm1> tjaalton, there is no explanation as to why fedora dropped it from what i can find in their changelogs
<superm1> i'm wondering if it was just an oversight
<tjaalton> superm1: well, maybe ajax knows the history. it's not the first time they'd drop patches without mentioning it :/
<superm1> tjaalton, but if that's the only reason it was dropped, i'd prefer to put it back in so that this hardware will work again on live disks, at least until upstream has something better
<tjaalton> superm1: try without xorg.conf if you can
<superm1> tjaalton, same results, no X startup,  (VESA(0): No valid modes)
<tjaalton> could you attach the log to the upstream bug, and check the mimetype this time :)
<tjaalton> 22:49 < ajax> oh, blah.  yeah, the sync range stretch isn't there anymore.
<superm1> tjaalton, sure
<tjaalton> 22:49 < ajax> wonder what i was thinking.  if you get to that point in mode validation it's  probably the sane thing to do
<tjaalton> so, you'll get a new patch in a minute
<superm1> tjaalton, awesome
<tjaalton> superm1: ok, check 817fb65fc3a95d6c34952f241c92ba2d3760968e from vesa git master
<tjaalton> http://cgit.freedesktop.org/xorg/driver/xf86-video-vesa/commit/?id=817fb65fc3a95d6c34952f241c92ba2d3760968e
<tjaalton> untested of course
<superm1> right. doing a build right now
<superm1> tjaalton, yup I get X  with said patch :)
<tjaalton> marvellous :)
<superm1> want me to upload?
<tjaalton> sure
<superm1> okay uploaded. tjaalton thanks for bugging ajax and  getting that turned around so quickly :)
<tjaalton> superm1: np, thanks for raising this.. :)
<tjaalton> I believe there are dupes to be closed..
#ubuntu-x 2009-02-06
<mvo> tseliot: hey! do you want me to sponsor nvidia-common (from your bzr branch)?
<tseliot> mvo: thanks for your offer. I haven't tested it yet though. Give me a few minutes to see if nvidia-detector does what it's supposed to do
<mvo> tseliot: thanks, much appreciated
<tseliot> mvo: ok, it seems to work well
<tseliot> I installed driver 177 and now nvidia-detector says:
<tseliot> nvidia-glx-180
<tseliot> and having nvidia-177-modaliases installed won't confuse nvidia-common
<tseliot> mvo: I think you can upload it now. Furthermore you can remove driver 96 from the blacklist
<tseliot> since it works with Jaunty's xserver now
<tseliot> therefore you won't have to set the driver to "nv" any longer for 96 during a dist-upgrade
<tseliot> mvo: let me repeat what I wrote
<tseliot> mvo: I think you can upload it now. Furthermore you can remove driver 96 from the blacklist
<tseliot> (03:00:21 PM) tseliot: since it works with Jaunty's xserver now
<tseliot> (03:00:49 PM) tseliot: therefore you won't have to set the driver to "nv" any longer for 96 during a dist-upgrade
<mvo> tseliot: ok, thanks
 * tseliot restarts X
<maco> hey, i'm trying to do the UXA testing for Intel graphics, but I don't really understand the wiki directions...mostly because I don't *have* a Device section, so I don't know what all's supposed to go in there besides Option "AccelMethod" "uxa"
<maco> on here: https://wiki.ubuntu.com/X/UxaTesting
<maco> and if i try to have an empty (but for that option) section like on the wiki page, it tells me error parsing config file
<maxb> maco: odd that you don't have a Device section.... do you have anything at all there?
<tjaalton> it needs an Identifier
<maco> there was nothing at all
<maco> until i added DontZap
<maco> so now there's ServerFlags with DontZap disabled
<tjaalton> the default installation has a minimal xorg.conf
<maco> in installed intrepid and upgraded to jaunty. as far as i know, the xorg.conf was always a 0-byte file
<tjaalton> dexconf -o foo
<tjaalton> will create one for you
<maco> foo? literally foo?
<tjaalton> no
<tjaalton> 'xorg.conf' if you like
<maco> oh
<maco> the comments probably should stop recommending dpkg-reconfigure -phigh xserver-xorg since that's been useless since gutsy
<tjaalton> probably so
<maco> ok ill try restarting X now then
<maco> thank you
<tjaalton> np
<maco_> thanks again. uxa is definitely an improvement on here
<tjaalton> cool
<tjaalton> what chip do you have?
<tjaalton> ah, same as here
<tjaalton> compiz seems to trigger the crash on resume
<andersk> Anyone else have their logins freeze with compiz spinning after the xorg 1.5.99.902-0ubuntu2 (and ubuntu3) upgrade? 
 * maxb raises hand
<maxb> Well, I have a hanging login
<maxb> Just started debugging now
<maxb> andersk: I confirm. Have you filed a bug yet.
#ubuntu-x 2009-02-07
<joumetal> bug 319210 has fix available in ppa. nice.
<ubottu> Launchpad bug 319210 in xorg-server "[jaunty] segfault during X startup with randr < 1.2 drivers" [Unknown,Confirmed] https://launchpad.net/bugs/319210
<joumetal> tormod: New xserver-xorg-core from your ppa works well with i815.
<tormod> joumetal: good. will you report upstream?
<tormod> joumetal: that is the ubuntu4~tormod version?
<joumetal> yes that is ubuntu4~tormod.
<tormod> joumetal: i815, which driver is that?
<tormod> oh confusing, I did not have the -intel package installed for some reason
<tormod> but I thought the "intel" driver would be used for i815 cards, and "intel" has xrandr 1.2... do you use the "i810" driver?
<joumetal> no I am using intel-driver. Commenting upstream bug took a while.
<tormod> joumetal: thanks
<LLStarks> yo.
<Alexia_Death> hmm
<klasikahl> hey there... does nayone know where i can find xf86Version.h
<klasikahl> i have found many wacom related posts lamenting its absence, but none seem to offer a solution
<klasikahl> it's not in any of the many dev packages i have installed in search of it
<tjaalton> klasikahl: it's gone
<klasikahl> yeah that's what i had feared... so any advice on how to compile somethign that explicitly requires it?
<klasikahl> like the newest wacom driver?
<tjaalton> just don't include it
<tjaalton> remove the includes
<klasikahl> okay
<tjaalton> or just look at what the package in jaunty does
<klasikahl> well the jaunty package is an older version.. i found someone seems to have the new version in their ppa
<klasikahl> oh look that person is you! ;)
<tjaalton> the new version doesn't work for me, that's why it hasn't been updated
<klasikahl> ah.
<klasikahl> tjaalton: what are you testing it with? what kind of laptop/tablet?
<tjaalton> an OEM tablet
<klasikahl> okay
<klasikahl> i have a tosh m700
<tjaalton> the cursor doesn't move, and all I get is a lot of log noise because of a change made after 0.8.1.6
<klasikahl> i will let you know how it goes, restarting X in a second here
<tjaalton> not all models have that problem, but mine did
<tjaalton> bryce: looks like the intel vblank issue is fixed at last. I'll test the oneliner now
<tjaalton> afk->
<klasikahl> tjaalton: holy hell it wokrs.
<klasikahl> calibration is a bit off... how do i calibrate this thing?
<klasikahl> `wacomcpl`
<klasikahl> got it
<klasikahl> thanks!!!
<klasikahl> tjaalton: you're the man....
<tjaalton> klasikahl: ok, good to hear
#ubuntu-x 2009-02-08
<tjaalton> sigh, how do I make cursor keys scroll the pages in ffox again, instead of moving a cursor inside the page..
<tjaalton> ok found it
<tjaalton> for some reason I had the a11y option "navigate with cursor keys" set
<tjaalton> heh, bumping the maxclients breaks nvidia
<alex-weej> tjaalton: f7 is the key shortcut to toggle that i think
<tjaalton> alex-weej: yes, google revealed that. must've toggled it by mistake at some point
<alex-weej> acts of cat
<tjaalton> or a kid, more likely
<tjaalton> bryce: please push the latest xorg-server changes to git
<bryce> tjaalton, done
#ubuntu-x 2010-02-08
<Sarvatt> let me know if xserver-xorg-dev, libpixman-1-dev, x11proto-core-dev, is enough for your pbuilder build RAOF, thanks for the heads up
<Sarvatt> i'll try building without the xorg state tracker to see if it goes
 * bryceh waves
<jcristau> xserver-xorg-dev should be enough, it'll pull in the rest
<Sarvatt> don't know if --with-state-trackers=dri is enough, i always built it with --with-state-trackers=dri,glx and i used --with-state-trackers=dri,xorg,glx that time because thats what fedora uses :D
<Sarvatt> heyo bryceh!
<Sarvatt> RAOF: do you have edgers set up in your pbuilder? because you need the newer protos
<RAOF> I do have edgers set up in the pbuilder.
<RAOF> One of the few nice side-effects of pbuilder
<RAOF> One of the few nice side-effects of pbuilder-dist always passing --override-config is that you can add --othermirror very easily
<Sarvatt> jcristau: xserver-xorg-dev pulls in libpixman-1-dev?
<RAOF> Sarvatt: Looks like everything's building nicely
<Sarvatt> already uploaded with the new deps, hopefully it wont get mozilla-ed
<jcristau> Sarvatt: yes
<Sarvatt> sweet, didn't know that
<Sarvatt> oh yeah it does now that i look at the control
<RAOF> Mmm.  pbuilder-on-tmpfs is wonderfully fast until you start to hit swap :)
<kklimonda> heh, or (in case you have no swap) your builds start to fail ;)
<Sarvatt> i ran out of hdd space building mesa last time, thats why it took so long to see if the rule changes worked :D
<Sarvatt> used up around 2 gigs building
<RAOF> Wooop!  Ran out of swap space!
<kklimonda> btw, what is the status of hibernation with nouveau drivers? have devs started working on that?
<RAOF> I don't know; does it not work now?
<Sarvatt> i'd blame other userspace stuff for suspend/hibernate not working, haven't looked through pm-utils fully yet but i'm pretty sure there are some spots where it checks for the quirks to do based on the normal module names
<RAOF> AFAIK it should work, same as suspend.
<kklimonda> RAOF, it seems to hibernate just fine (i.e. computer shuts down) but after I start it again I get a gdm login prompt
<kklimonda> no idea how to debug hibernation on Linux as it has never worked for me
<kklimonda> which isn't really an excuse now that I think about it.. :D
<Sarvatt> guessing you mean it doesnt restore the old gdm session after you login again too?
 * Sarvatt isnt sure if a gdm login prompt after hibernate is the expected behavior because he's never hibernated
<Sarvatt> no swap partition here
<Sarvatt> finally mesa shows up on edgers, building now
<Sarvatt> /dev/dri/card0 didnt have the right permissions on nouveau without the udev change in the xorg-edgers/nouveau udev package
<kklimonda> what are the right permissions? 0660 root:video ?
<Sarvatt> yep
<Sarvatt> looks like its fine with --with-state-trackers=dri,glx, i'll do tomorrows update with that
 * johanbr reboots to try again
<Sarvatt> its not done building, what are you trying?
<Sarvatt> yep works fine without the xorg state tracker
<Sarvatt> almost done building on edgers, its packaging now
<RAOF> Woop!  Woop!
<Sarvatt> johanbr: its not ready until you get mesa 7.8.0~git20100207.1a45c2bc-0ubuntu0sarvatt3 offered, you need both xorg-edgers/ppa and xorg-edgers/nouveau in your sources too incase you missed that part, then you just install xserver-xorg-video-nouveau and reboot/restart gdm
<Sarvatt> can someone pass that along when he comes back? i have to run again
<virtuald> godmorgon
<RAOF> Sarvatt: Certainly.
<johanbr> hmm... nouveau seems to have trouble opening the DRI device: http://pastebin.com/f1cb1a313
<johanbr> and the permissions on /dev/dri/card0 are 660 root:video
<johanbr> should the kernel modules with or without lbm_ be loaded?
<Sarvatt> when's the last time you did a dist-upgrade? Current version of pixman: 0.16.2??
<Sarvatt> <Sarvatt> johanbr: its not ready until you get mesa 7.8.0~git20100207.1a45c2bc-0ubuntu0sarvatt3 offered, you need both xorg-edgers/ppa and xorg-edgers/nouveau in your sources too incase you missed that part, then you just install xserver-xorg-video-nouveau and reboot/restart gdm
<Sarvatt> does dmesg | grep efifb show anything?
<johanbr> nope
<kklimonda> Sarvatt, works fine for me
<johanbr> I built the mesa package locally, maybe that's the problem...
<johanbr> we'll see how it goes after a reboot
<Sarvatt> how did he manage to have a pixman version over a month old is what i'm wondering
<Sarvatt> kklimonda: compiz work? tried any 3D apps yet? I'm doing it all remotely so beyond compiz and glxgears I haven't seen if anything works
<Sarvatt> i dont know if theres any visual corruption in compiz either, just that it didnt give any errors
<kklimonda> Sarvatt, well - compiz works just fine. the quality of scaled windows (in alt+tab, super+w) isn't too good but it may be something I can tweak
<RAOF> You'll probably find gnome-shell exposes a little bit of corruption.
<kklimonda> Sarvatt, my cats are alive so at least it doesn't kill wicked ones ;)
<Sarvatt> theres probably something you can tweak in driconf to fix that
<Sarvatt> kitty halftime show on the puppy bowl is over :(
<Sarvatt> the alt-tab display looks like crap on intel here too
<johanbr> there we go... problem disappeared after I uninstalled plymouth
<Sarvatt> yeah not surprised there, i have to do all kinds of junk to get plymouth working right on every machine i have
<Sarvatt> its segfaulting every 3rd boot or so on intel too, and getting hung displaying the splash every time ureadahead profiles
<Sarvatt> how did you get in a state where you have pixman 16.2 though?
<johanbr> I'm a bit leery of running full dist-upgrades, so I tend to upgrade packages by hand every now and then
<johanbr> guess I mixed pixman
<johanbr> *missed
<Sarvatt> i was a bit worried that you might have missed a grub fix that was causing the same error you were getting on warm boots here
<johanbr> that is also possible, and that removing plymouth just papered over the symptoms
<johanbr> anyway, time to head home... thanks for the help!
 * RAOF checks the -rc7 gitlog to discover whether there's any nouveau updates that could be shoved into l-b-m-nouveau.
<BUGabundo> RAOF: bug I mention in cube with nouveau gallium
<BUGabundo> http://dl.dropbox.com/u/112892/cube.png
<hyperair> oh hey compiz works on nouveau =O
<BUGabundo> yes
<BUGabundo> spend the evening testing it
<BUGabundo> want my log from +1 ?
<hyperair> no need =)
<hyperair> i'll test it myself when i get home =p
<BUGabundo> (01:46:17 AM) freenode: conclusion: nouveau gallium 3D support works ok, but is *very* slow
<hyperair> oh heh
<BUGabundo> (01:45:15 AM) freenode: TOTALLY FORGET RAIN EFFECTS
<BUGabundo> (01:43:47 AM) freenode: windows previews FAIL
<hyperair> my card can't support rain anyway >_>
<kklimonda> BUGabundo, how do the fail?
<BUGabundo> (01:38:32 AM) freenode: if I go from Compiz to metacity, I get a freezes background
<kklimonda> they*
<BUGabundo> (01:43:59 AM) freenode: got the windown, but nothing in there
<BUGabundo> (01:43:10 AM) freenode: selective zoom works
<BUGabundo> (01:43:25 AM) freenode: all apps switcher seem to work
<BUGabundo> (01:42:52 AM) freenode: both apps expose and Desktop expose work
<BUGabundo> (01:42:57 AM) freenode: fire writing works
<kklimonda> now the next linux graphics gizmo I'm interested in is wayland..
<BUGabundo> RAOF: is it normal for collors to seem off with this driver??
<BUGabundo> some yellows are no longer as yellow
 * BUGabundo wonders if that is sleep deprivation 
<hyperair> lol
<kklimonda> it may be
<RAOF> No; it should be at least as good as nv.  If you happen to have an 18bit LDVS panel (and your laptop almost certainly does), it should actually look better.
<RAOF> Because nouveau sets the dither mode properly.
<BUGabundo> I noticed it looks smoother
<BUGabundo> but collors are off
<BUGabundo> even greys 
<hyperair> colours
<hyperair> or colors.
<BUGabundo> gramar nazy
<BUGabundo> :p
<BUGabundo> thanks !
<BUGabundo> RAOF: any way I can test this better?
<BUGabundo> or make sure I got one of those 18bit LDVS panel  ?
<RAOF> Well, if you didn't pay lots and lots of money to get a 24bit panel, you've got an 18bit panel.
<BUGabundo> eheh
<BUGabundo> got it
<BUGabundo> the screen look brighter too
<RAOF> And just general testing; suspend, resume, hibernate.  Use it for a while; does it die screaming after 5 hours?
<RAOF> That sort of thing.
<BUGabundo> then again I'm tired 
<BUGabundo> ok
<BUGabundo> suspend test coming up
<BUGabundo> brb
<RAOF> Just use it as your driver; if it's not obnoxious, great.
<kklimonda> BUGabundo says that suspend has failed for him - "I had sound a net, but no x or tty acess"
<Sarvatt> how are you getting gallium 3D support BUGabundo? building mesa yourself? i only added it to edgers a few hours ago, sure you aren't just using swrast?
<RAOF> Compiz would bomb out with swrast.
<kklimonda> Sarvatt, he uses xorg-edgers ppas
<Sarvatt> i just dont know how he could have spent the evening testing it when it was only up for under an hour when he said that and i only mentioned it in here, sounded like he might have been using swrast :)
<kklimonda> Sarvatt, either I or RAOF has mentioned it to him on #ubuntu+1
<Sarvatt> no problems here so far though outside of a 5 second stall closing the glxgears window once under compiz, openarena extreme tux racer and neverball are all very playable at 1280x800
<Sarvatt> the alt-tab graphics look as nasty under nouveau as intel, comparing them side by side :D
<Sarvatt> really ugly text rendering scaled down like that
<kklimonda> I'm suprised how good 3D support is
<kklimonda> I was expecting it to bork my system completely
<johanbr> yes, me too
<johanbr> a few minor rendering artifacts, but overall it works very well
<RAOF> I get a very fetching all-white screen.
<Sarvatt> doing what?
<Sarvatt> font shadows look a little funky
<RAOF> Starting compiz.
<Sarvatt> guessing everyone else testing is using nv50 :D
<RAOF> Ah.  Because I've got bad permissions somewhere.
<Sarvatt> ya get the udev upgrade?
<johanbr> changing the window translucency looks a bit funky...
<Sarvatt> standard main compiz profile RAOF? or do you have any extra plugins enabled?
<RAOF> No, I don't think I do have the udev upgrade.  Where is it?
<Sarvatt> should be 1:149-6~nouveau
<Sarvatt> its in xorg-edgers/nouveau
<RAOF> Oh.  I *can* make compiz SIGFPE in nouveau_dri.so :)
<Sarvatt> wonder if its related to not having ctxprogs from the blob on your nv40
<RAOF> Possibly.  I'll restart using the blob's ctxprogs.
<RAOF> I think it's more likely to be AIGLX being broken.
<Sarvatt> probably, seems to work decently on nv50 at least. going to test the patched lbm-nouveau that doesnt need firmware for nv50 again in a bit
<johanbr> did anyone try gnome-shell?
<RAOF> Well, that wasn't a ringing success; it seems setting ctxfw=1 is a good way of making nouveau just not come up.
<Sarvatt> oh it doesnt add the firmware to the initrd
<RAOF> Oh.
<RAOF> It doesn't?
<Sarvatt> noticed that when i built the one that doesnt need firmware, it only installed the firmware for the other models that need it
<RAOF> Oh!
<Sarvatt> modinfo lbm-nouveau lists the stuff it adds
<kklimonda> johanbr, not really - we all expect it to fail though ;)
<johanbr> hmm, sounds like a challenge ;)
<Sarvatt> i dont, mutter works fine :)
<Sarvatt> i did test that out, just not the full gnome-shell
<johanbr> starting gnome-shell causes a hard lockup
<johanbr> and no DRI after a cold boot
<RAOF> Sarvatt: Have you actually uploaded udev 149-6~nouveau?  I can't see it.
<RAOF> No, it should be there...
<RAOF> Why can't I see it?
<Sarvatt> what version do you have now?
<Sarvatt> you can just makes these changes to the 3 files in /lib/udev/rules.d/ http://sarvatt.com/downloads/patches/udev-lbm-nouveau.patch
<RAOF> 149-5
<Sarvatt> you have xorg-edgers/nouveau enabled right?
<Sarvatt> that'd be the only reason i can think of
<RAOF> I do, yes.
<RAOF> Oh.  It seems my apt-proxy was being stupid.
<RAOF> With bonus corrupted VTs!
<BUGabundo> guud afternoon
<kklimonda> hey
<BUGabundo> FYI suspend to RAM is broken with nouveau gallium on nvidia 8400gm
<BUGabundo> http://dl.dropbox.com/u/112892/Screenshot1.png
<BUGabundo> http://dl.dropbox.com/u/112892/Screenshot2.png
<BUGabundo> funny view of Cube bugs
<kklimonda> BUGabundo, what's weird is that it works on my quadro 140m just fine (and quadro is based on 8400something)
<BUGabundo> maybe an option
<BUGabundo> don't know
<BUGabundo> maybe Reflexion plugin
<kklimonda> right, you should try with default plugins probably
<BUGabundo> ahhhh
<BUGabundo> 3D Windows BUG
<BUGabundo> :)
<BUGabundo> "Paint Windows Like Backgroud" seems to be the cause of my Windows Preview bug
<BUGabundo> windows shifting may be slower
<BUGabundo> but browsers and some ups, scrolling is *much* smoother
<BUGabundo> there's no comparition in Firefox
<hyperair> no comparition?
<hyperair> comparison?
<BUGabundo> much nicer
<hyperair> ah
<BUGabundo> yea, ytpo
<hyperair> well i've heard nouveau does well in the 2D acceleration field
<hyperair> stuff like banshee's smooth scrolling works better on nouveau too.
<hyperair> although it's very jerky with intel
<BUGabundo> it needs a bit work here : http://dl.dropbox.com/u/112892/ubuntu-x.png
<BUGabundo> other then that, its very nice
<hyperair> lol
<hyperair> that looks bad
<BUGabundo> everything from tooltips, to other  overlays is like that
<kklimonda> overlays?
<BUGabundo> hyperair: I'm almost sure it's a bug in 3D Windows plugin
<BUGabundo> turning that off it does improve a lot
<hyperair> i see.
<BUGabundo> kklimonda: as in stuff that goes overing other
 * hyperair doe more
<hyperair> er
<hyperair> stupid lagging X
<BUGabundo> ahah
<hyperair> it just drops my keyboard events damnit >_>
<hyperair> i meant i don't use the cube any more
<BUGabundo> mew
<BUGabundo> its _pretty_ 
<hyperair> yeah, but not practical.
<BUGabundo> sure
<hyperair> i have three rows of workspaces
<BUGabundo> expose and zoom are nicer and usefull
<hyperair> it's a 3x3 grid.
<BUGabundo> 5x2
<BUGabundo> usually have 4 desktops filled
<hyperair> so with a maximum of 2 desktop switches, i can switch to any workspace in that 3x3 grid.
<hyperair> and have 9 workspaces.
<hyperair> the cube can't do that =\
<BUGabundo> right
<hyperair> if the cube supported multiple rows of workspaces, then sure
<BUGabundo> windows expose FTW
<hyperair> windows expose?
<hyperair> you mean scale?
<BUGabundo> yes
<BUGabundo> http://dl.dropbox.com/u/112892/expose.png
<hyperair> agreed.
 * hyperair uses that intensively
<hyperair> even for closing windows
<BUGabundo> ahah
<BUGabundo> got to have a BIG screen
<BUGabundo> to hit those X
<hyperair> what X?
<BUGabundo> close wind
<BUGabundo> lol
<BUGabundo> the cross 
<hyperair> um you close the X in expo mode?
<hyperair> that's not scale
<hyperair> that's expo!
<hyperair> i'm talking about scale. middle clicking on a window closes it
<BUGabundo> there used to be this 3rd party compiz plugin that would stick scale on a secondary Monitor
<BUGabundo> I loved it
<hyperair> never used it
<BUGabundo> http://dl.dropbox.com/u/112892/expose2.png this ?
<hyperair> yeah tht
<BUGabundo> yeah
<hyperair> middle click on a window and it closes
<BUGabundo> nice to find a wind
<BUGabundo> oooooooohhhhhhhhhhh
<BUGabundo> really?
 * BUGabundo tries
<hyperair> yep
<hyperair> and rightclick on it and it zooms in to normal size
<hyperair> temporarily
<hyperair> if you've got the text filter thing you can even filter the windows based on title
<BUGabundo> naa
<BUGabundo> mine does ZOOM
<hyperair> configure it in scale addons
<hyperair> http://www.ubuntu-pics.de/bild/41579/screenshot_01_FVjiE6.jpg
<BUGabundo> its already enabled
<BUGabundo> maybe it conflicts with zoom
<BUGabundo> wow that theme is scary
<hyperair> what?
<hyperair> and no it doesn't conflict with zoom
<BUGabundo> then I'm doing it wrong
<hyperair> lol
<hyperair> i think compiz by default has it enabled
<hyperair> er has it enabled by default
<hyperair> what's scary about my theme anyway? O_o
<hyperair> or am i missing something
<BUGabundo> bright blue
<hyperair> O_o
<hyperair> is bright blue scary?
<BUGabundo> for a DE: YES
<hyperair> O_o
<hyperair> but why?
<BUGabundo> lets see: super + w, get it scaled, then without letting go, mouse middle click?
<BUGabundo> doesn't work
<hyperair> oh, i see.
<hyperair> you're using the keyboard!
<hyperair> it doesn't work that way
<hyperair> you need to trigger the scale using one of the hot-edges
<kklimonda> it works from keyboard here
<hyperair> kklimonda: the scale addons thing?
<BUGabundo> confilts with Super-mouse2 for zoom box
<hyperair> BUGabundo: you're doing it wrong >_>
<BUGabundo> I don't use mouse!!!
<BUGabundo> if I can avoid it
<BUGabundo> so corners is a NO GO
<hyperair> heh
<hyperair> lol
<hyperair> okay, let's think..
<hyperair> there are keyboard shortcuts available for setting in scale addons
<kklimonda> hyperair, yes
<hyperair> set something there
<hyperair> BUGabundo: and set your scale plugin's behaviour to not require you to hold down your key
<hyperair> BUGabundo: like when you release your scale's keybinding, it should stay in scale mode
<hyperair> "Key  bindings toggle scale mode"
<BUGabundo> bah
<BUGabundo> never mind
<BUGabundo> don't use it either
<BUGabundo> would eventually forget about it 
<hyperair> lol
<Sarvatt> hmm, should this be fixed released or wontfix? his problem is r600_dri.so doesnt exist in karmics ia32-libs, its fixed in lucid but wont be fixed in karmic https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/515933
<ubottu> Ubuntu bug 515933 in mesa "[xorg-edgers] after rebuilding, Wine doesn't get same results with DRI R600 as glxinfo" [Undecided,New]
<Sarvatt> fix released it is, i can't set wontfix anyway :)
<Sarvatt> darn.. ya got me hoping the fix in your bug would fix the flickering post-resume alot of us are getting on 945 jcristau :D http://bugs.freedesktop.org/show_bug.cgi?id=25371
<ubottu> Freedesktop bug 25371 in DRM/Intel "[945gm] lvds panel blinking from time to time" [Normal,New]
<Sarvatt> still getting the flickering and lockup post resume here with drm-intel-next though
<Sarvatt> (with powersave=1)
<Sarvatt> i still cant suspend if i ever mount a sd card on the lastest .33, thats a nasty one
<knittl> EVIOCGNAME <- could this be related to failing wakeup from standby?
<Sarvatt> nah thats normal right now with the udevification and harmless afaik
<Sarvatt> looks like its loading evdev for every device and when something else like synaptics takes it over it gives that error and unloads evdev for that device unless I'm mistaken
<Sarvatt> (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device <- that?
<Sarvatt> jbarnes: are you around by any chance? I have a question about this commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7121413f2accf14cf05b38539fb7a8be77543370
<Sarvatt> aspire ones have a DMI product name of AOA110 or AOA150 and not Aspire one so I'm not sure it ever gets used?
<jbarnes> Sarvatt: hm
<Sarvatt> mine is quirky and always reports the lid closed to devicekit-power, I cant boot with the lid closed
<jbarnes> worked on my machine
<jbarnes> it had an old bios though iirc
<Sarvatt> would something like this potentially work? I'm no kernel hacker, not sure if its worth fixing kernel-package to build a new kernel to try it :D http://sarvatt.com/downloads/patches/0001-Make-drm-i915-blacklist-Acer-AspireOne-lid-status-ac.patch
<Sarvatt> am I supposed to be able to boot with the lid closed though? not sure if thats intended or if that would fix that
<jbarnes> well you should probably leave the existing one alone
<jbarnes> since I tested that on my aspire one
<jbarnes> the others look ok, though I'm not sure about the * matching
<Sarvatt> i'm using a gateway bios on my acer aspire one, its the same thing as the acer bios except with a gateway vendor name and it has more brightness levels exposed, acer blocked out the lower brightness levels because it causes backlight flickering but i like the lower power :D
<jbarnes> if you've tested and confirmed against those machines and it makes things work, definitely send a patch to intel-gfx and cc eric@anholt.net
<Sarvatt> ok I'll make another leaving the Aspire one match alone and add AOA1* seperately, I'm positive AOA1* only matches AOA110 (ssd model) and AOA150 (hdd model) aspire ones. I just wasn't sure if that commit was intended to let you boot with the lid closed because I dont have a problem booting with the lid open and didnt before that commit and I'm pretty sure that commit isn't doing anything here because Aspire one isnt anywhere in the dmi 
<Sarvatt> will try it out, thanks :)
<Sarvatt> devkit-power always reports lid-is-closed:   yes on this thing
<Sarvatt> nouveau has a module option to ignore acpi lid status that I need to boot if the lid is closed, guess its intentional that things dont start up right with a closed lid
<Sarvatt> was hoping [PATCH] drm/i915: handle FBC and self-refresh better would fix the blinking and eventual hangs with intel_gpu_top reporting 100% use in framebuffer compression that only happens after resume here on this netbook but no luck :(
<Sarvatt> hmm powertop saying Xorg is writing to /var/log/Xorg.0.log preventing the hdd from sleeping but its not writing anything to it, wonder what thats about
<johanbr> Sarvatt, I've noticed that powertop "writing to..." line can be pretty inaccurate
<johanbr> sometimes it claims that user programs are writing to /usr
<Sarvatt> jbarnes: just curious, but have you tried using intel 2.10 on your aspire one? I'm not aware of *anyone* able to use 2.10+ without random batchbuffer I/O error hangs on 915-945
<Sarvatt> sorry to bug you so much :)
<Sarvatt> some change in libdrm between 11-25 and 12-03 made 915-945 completely unstable with intel 2.10 on any kernel
<BUGabundo> evening
<Sarvatt> thats blocking us going to 2.10 in lucid :(
<jbarnes> Sarvatt: I haven't tried it yet
<Sarvatt> heyo BUGabundo 
<jbarnes> but yeah I've heard similar reports
<jbarnes> a bisect might help
<Sarvatt> i can't bisect libdrm to find out what did it because almost all the commits between are unstable on their own, I've been trying for months
<Sarvatt> but I know a libdrm git checkout from 11-25 is stable with intel 2.10
<Duke`> During the past days, I suffered less often of the Execbuf Error
<jbarnes> Sarvatt: just libdrm huh?
<jbarnes> I figured it must be an xf86-video-intel problem
<jbarnes> but if it's libdrm that could be even more serious
<Sarvatt> yeah some interaction between libdrm and the new things in the ddx there, libdrm git is 100% stable on its own with intel 2.9.1
<Sarvatt> and intel from 11-11 is fine with the newer libdrm as well
<jbarnes> is there new execbuf2 stuff in there possibly?
<Sarvatt> it happens on 2.6.30 and 2.6.31 kernels as well
<Sarvatt> intel git was broken between 11-11 and 12-06 or so for me as well so I can't bisect the driver to see what change in there messed it up
<jbarnes> arg
<bryceh> heya jbarnes
<jbarnes> bryceh: hi
<BUGabundo>  1211   0.80s   0.07s     0K     0K     0K     0K  --   - S  44% Xorg
<BUGabundo> I'm seeing much more CPU usage since I changed to nouveau gallium
<Sarvatt> seeing alot of  invalid BO alignment 4096 crashes under 2.6.31 as well, at least those dont happen under .32+ but people with the karmic kernel are having problems using edgers
<Sarvatt> BUGabundo: just dont expect nouveau gallium to work right, the call for testing was for the xorg-edgers/nouveau PPA because that's what's going to be in lucid :D
<BUGabundo> Sarvatt: that's what I started using last night
<Sarvatt> i'm just enabling 3D support in edgers for people that want to break things, they dont even want upstream 3D related bug reports yet because they know its broken :)
<BUGabundo> its terribly slow
<BUGabundo> I WANT 3D !  I WANT 3D !  I WANT 3D !  I WANT 3D !  
<BUGabundo> That's the only reason I installed it
<BUGabundo> 3D is NOT broken
<BUGabundo> it works fine here
<Sarvatt> that will change on a day to day basis for sure, it breaks all the time :D
<kklimonda> Sarvatt, so you were just lucky when grabbing git snapshot? :)
<kklimonda> ugh
<Sarvatt> well unlucky for some people, at least we're lucky its working well on nv50 :) its completely usable here, i already removed the blob
 * BUGabundo stabs Sarvatt
<BUGabundo> don't go kill it for me
<BUGabundo> I need it on its BEST mode for Saturday FLOSS presentation
<BUGabundo> gonna try getting a few more users to Ubuntu 
<BUGabundo> if Compiz is broken, then Ill lose points!!!
<BUGabundo> you don't want that on your shoulders do you ? 
<BUGabundo> :P
<Sarvatt> BUGabundo: not sure if you got the message but its expected to use both xorg-edgers/ppa and xorg-edgers/nouveau at the same time if you use nouveau
<BUGabundo> that's what I have
<Sarvatt> okie, just wanted to be sure since i said it in here when you werent around :)
<BUGabundo> I followed RAOF pointers
<Sarvatt> theres udev and plymouth updates to work for nouveau in xorg-edgers/nouveau that i didnt put in xorg-edgers/ppa yet
<BUGabundo>  1211   0.98s   0.18s     0K     0K     0K     0K  --   - D  57% Xorg
<BUGabundo> still this is TOO MUCH cpu
<Sarvatt> thats using compiz?
<BUGabundo> yes
<BUGabundo> nv blob was much nicer
<BUGabundo> $ ls
<BUGabundo> total 12K
<BUGabundo> -rw-r--r-- 1 root root 67 2010-02-07 23:13 xorg-edgers-nouveau-lucid.list
<BUGabundo> -rw-r--r-- 1 root root 63 2010-02-07 23:13 xorg-edgers-ppa-lucid.list
<BUGabundo> -rw-r--r-- 1 root root 63 2010-02-07 23:13 xorg-edgers-ppa-lucid.list.save
<Sarvatt> pastebin your xorg.0.log and dmesg? just curious what they look like on your system with that setup to see if i spot any more errors :D
<Sarvatt> btw if you want to go back to nouveau without 3D support just sudo ppa-purge xorg-edgers, it'll just remove xorg-edgers/ppa and leave xorg-edgers/nouveau
<kklimonda> Sarvatt, have I already thanked you for the ppa-purge script?
<kklimonda> Sarvatt, it's the best thing since sliced bread ;)
<kklimonda> ok, I got weird font colors in xchat :D
<Sarvatt> the -p argument to ppa-purge is broken after some changes tormod did so you cant remove xorg-edgers/nouveau yet :(
<Sarvatt> no worries kklimonda glad it helped, surprised there wasn't anything similar out there already
<BUGabundo> Sarvatt: $ pastebinit Xorg.0.log http://paste.ubuntu.com/372001/
<BUGabundo> $ dmesg | pastebinit http://paste.ubuntu.com/372003
<BUGabundo> Description: Disables a PPA and reverts to official packages
<BUGabundo>  This package provides a script capable of automatically downgrading all
<BUGabundo>  packages from a given PPA back to the official Ubuntu versions.
<BUGabundo> hey that's nice
 * BUGabundo is sad
<BUGabundo> this drivers suck for video!!!!
<BUGabundo> can't watch a single video .... it just shows horizontal strikes
<kklimonda> whoa, I've just all my fonts.. they have all disappeared
<bryceh> BUGabundo, please keep comments constructive
<BUGabundo> kklimonda: also you no longer know how to speak english
<BUGabundo> bryceh: I know
<BUGabundo> just frustrated
<bryceh> BUGabundo, perhaps take a break and come back to it later when you're more calm?
<BUGabundo> aahaha
<BUGabundo> bryceh: no worry my friend
<BUGabundo> all cool
<BUGabundo> I wouldn't be testing this, if I wasn't capable of having it breaking on me, would I ?
<BUGabundo> just that sometimes, one of you guys can have some tips that might make this better for me (and everyone else) or maybe I provide some useful report
<bryceh> BUGabundo, keep in mind people on this channel are busy with development work so requests for help on bugs often interrupts other important work, so it is a good idea to avoid impoliteness when asking for help
<BUGabundo> okidoki. go back to your work... I'll be in +1 :D
<BUGabundo> helping others too
<Sarvatt> it being slow is fully expected unfortunately, i'm worried about bugs like kklimonda's fonts disappearing.. is that with compiz disabled or enabled?
<kklimonda> Sarvatt, it was with compiz enabled but replacing it with metacity haven't fixed that
<kklimonda> Sarvatt, only after I've switched to VT and back again I got fonts back
<Sarvatt> do you have Force Synchornization between X and GLX enabled in compiz?
<kklimonda> yes
<Sarvatt> looks like you're hitting https://bugs.launchpad.net/bugs/517807 too btw BUGabundo_dinner 
<ubottu> Ubuntu bug 517807 in linux "iwlagn: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 free buffers remaining." [Undecided,New]
<BUGabundo> Sarvatt: for exactly what symptom ?
<Sarvatt> i just saw the [22076.107618] swapper: page allocation failure. order:2, mode:0x4020 in your dmesg
<BUGabundo> ah thanks
<BUGabundo> Sarvatt: my X fallback to no WM, I $DISPLAY=:0 compiz --replace &, but now I lost my top bar (gnome)
<coz_> just noticed nvidia drivers showing up in hardware drivers... is it safe to install and reboot??
<tseliot> yes, it should be
<tseliot> if you're referring to lucid
<coz_> tseliot,  ok let me try it now    
 * coz_ crosses fingers :)
<coz_> tseliot,  yes I have another system with lucid on it  so its installing now 
<coz_> tseliot,  do you know what the issue was this week ??  plymouth?
<coz_> nope  nvidia still not installing 
<coz_> let me reboot this again
<coz_> nope
<coz_> doesnt even go to text console
<coz_> pure black lol
<coz_> ah another reinstall I suppose lol
<bjsnider> is that problem with nvidia-current being blacklisted fixed?
<coz_> not sure   there were no drivers even listed in hardware drivers  all week
<coz_> manual install  didnt work last time I tried
<coz_> system freeze with manual install
<bryceh> RAOF, Sarvatt, question on https://edge.launchpad.net/~xorg-edgers/+archive/nouveau - is this all stuff staged to be uploaded for Lucid?  Any tasks needing done before I start looking at uploading these packages?
<bryceh> Also, do you suggest a particular order to upload them?
<RAOF> I think it's all ready to go, modulo the obvious versioning.
<kklimonda> bryceh, right now you can't install lbm -generic and -generic-pae packages at the same time - that should probably be fixed (even if they aren't to be installed side-by-side a Conflicts: field have to be added).
<RAOF> kklimonda: Thanks for reminding me.  Yes.
<bryceh> does lbm need uploaded before the X bits?
<RAOF> That should be fixed; l-b-m-n ships an initramfs hook.  That should be moved to the existing framebuffer copyfest.
<RAOF> Yes.  The X bits need lbm before they'll work at all.
<Sarvatt> the linux-backports is the most important one to get in, ROAF would be the one to ask though because I'm not sure whats going on with the libdrm/nouveau packages in there. looks like he has the libdrm updates queued in git though. it would be nice to have a metapackage in lbm that the ddx can depend on so its not broken every abi bump before going in as well
<bryceh> ok, so  0. nouveau-firmware, 1. lbm, 2. libdrm, 3. -nouveau, 4. xorg-server
<bryceh> what about the plymouth and udev bits?
<bryceh> guess those should follow lbm?
<RAOF> I think they want to precede lbm, actually.
<Sarvatt> those dont hurt anything if they are uploaded early
<bryceh> ok
<bryceh> ok, so  0. nouveau-firmware + udev + plymouth, 1. lbm, 2. libdrm, 3. -nouveau, 4. xorg-server
<Sarvatt> it shouldnt hurt anything if xserver is updated too before the rest too, it'll just fail to load nouveau and move on with no xorg.conf. it was just back when we had a default xorg.conf in early karmic with 1 device section and no named driver in there that we couldn't use those
 * bryceh nods
<bryceh> I put it last though since nouveau is not yet in main, so having it load nv is going to still be appropriate until we're closer to that point
<bryceh> (but perhaps I'm wrong?)
<Sarvatt> yeah, if anything it'll just be opt-in for people who choose it in an xorg.conf without that patch
<Sarvatt> a libdrm version bump would be nice right about now.. :)
<RAOF> We'd need to pull in a new DDX too, though.
<RAOF> :)
<Sarvatt> could we sneak nouveau-firmware in the lbm package with the other firmware in it? :D
<bryceh> is nouveau-firmware going to be a Ubuntu-X package, or the kernel team's?
<Sarvatt> it'll go away lucid+1 almost guaranteed
<bryceh> (I've been assuming the latter)
<bryceh> oh btw I talked to them about this a bit last week, and it sounded like they'd be keen on backporting the upstream stuff that makes it go away, so that it never becomes an issue for lucid
<bryceh> so if you have recommendations for what to backport, we should just let them know
<Sarvatt> i've been using that all this time with no problems but i'm sure theres some reason it's not upstream yet :D
<Sarvatt> i got nouveau gallium set up on xorg-edgers/ppa to play with too if you didn't see, compiz is working great here and the only game I've been had problems with is nexuiz (who doesnt have problems with that one)
<bryceh> great
<RAOF> It doesn't work for me, though, which is not great :`(
<Sarvatt> oh yeah about that - glxinfo show gallium being used? was it just compiz starting that killed things for you? tried any 3D games or anything without compiz?
<Sarvatt> ack
<Sarvatt> I'll break the kernel API and bump to 0.0.16 real soon now anyway, so
<Sarvatt> I'll fold the changes in when I update libdrm for it.
<RAOF> Compiz killed things; texture_from_pixmap is broken.
<Sarvatt> LIBGL_ALWAYS_INDIRECT=1 compiz --replace work?
<RAOF> Oh, it probably would, wouldn't it.  Let me check.
<Sarvatt> ah compiz --indirect-rendering does the same thing
<jcristau> oh, nice, tormod got a newer radeontool into debian
<bryceh> Sarvatt, RAOF, I added a small "how to revert nouveau" section at https://wiki.ubuntu.com/X/Nouveau - could you take a minute to look at that and let me know if I missed anything we'd need to do?
#ubuntu-x 2010-02-09
<setuid> I'm having trouble with coming out of resume using nvidia on Lucid
<setuid> Anyone else able to replicateit? 
<setuid> I have a blinking cursor in upper-left corner, and after several attempts at ctrl-alt-f1-f6, I can eventually hit alt-f7 and get to the gdm login menu.
<Sarvatt> just curious, what does cat /etc/default/console-setup | grep XKBOPTIONS return for you?
<setuid> # cat /etc/default/console-setup | grep XKBOPTIONS
<setuid> XKBOPTIONS="lv3:ralt_switch"
<jcristau> it returns 'useless use of cat' ;)
<setuid> console is a mess at boot, unless I pass vga=0... this is a big difference from karmic and jaunty
<Sarvatt> good point :D i was curious because alt+fkey is actually what I need to do to switch VT's outside of X and I had an option breaking control+alt+fkey
<setuid> I had a 1920x1200 console at boot with those, but with Karmic, unless I pass vga=0, I get all kinds of colored pixel garble, in two identical vertical columns
<bryceh> afaik resume on nvidia is broken for everyone
<bryceh> we were messing with it last week at the developer sprint but couldn't see any nvidia user get it to resume successfully
<setuid> It resumes fine, just takes a lot of vt switching to get it to go back into X 
<setuid> it's always worked great, until Lucid
<johanbr> I can also resume with the proprietary, but I get graphical artifacts if compositing is enabled
<johanbr> *proprietary driver
<setuid> Coming out of resume on Karmic and Jaunty to the gdm menu was about 3-4 seconds after opening the laptop. This takes about 30 seconds and a lot of ctrl-alt-fx'ing 
<bryceh> setuid, johanbr, then I think count yourself lucky ;-)
<bryceh> if you are interested in participating in debugging and patching the issue, contact tseliot
<setuid> Didn't he die in 1965? 
<Sarvatt> i'd like to figure out why alt+fkey is whats needed for vt switching now instead of control+alt+fkey :) when I had grp:ctrl_alt_toggle in my xkboptions I wasn't able to use control+alt+f at all, without it it at least ignores the control
<Sarvatt> bryceh: that seemed like it all, just added the backing out libdrm/plymouth/udev patches for lucid+1 part
<bryceh> ok thanks
<raevol> https://wiki.ubuntu.com/X/Drivers will this page be updated for karmic/lucid?
<bryceh> raevol, go ahead if you'd like to update it
<bryceh> if I have some time later I'll add to it
<raevol> :[ i don't actually know anything about the drivers aside from Karmic not having 3d support
<bryceh> I hadn't really given much priority to updating that page since you are actually the first person I have evidence of having even looked at it ;-)
<raevol> hahah ;D
<bryceh> maybe it should be deleted
<raevol> planet ubuntu just had a post about testing the proprietyary drivers, and linked the ubtuntu X wiki page for info on the open source ones
<raevol> and i clicked through to that because i am hoping against hope we get 3d support for r600 in lucid
<setuid> I've been looking around for some 'live wallpaper' ideas for the Ubuntu desktop... back in the day, we used to run things like xplanet, glmatrix, etc. in the root window, but that's not the same thing.
<setuid>  Anyone know of a Nexus One style live wallpaper app for Ubuntu? 
<bryceh> setuid, not really the right channel for that question, try #ubuntu-desktop maybe
<setuid> hahah, first I tried #ubuntu+1 because the problems I'm hitting are in Lucid only, they told me to go here, because they're X related... so I ask an X question, and that belongs in #ubuntu-desktop :) 
<raevol> gotta run, bye
<bryceh> RAOF, Sarvatt, https://wiki.ubuntu.com/X/Testing/NouveauEvaluation
<RAOF> I think you meant âgrep _dr*v*.so /var/log/Xorg.0.log...â
<RAOF> (If you're still editing that page)
<bryceh> modified
<bryceh> is that actually needed?  I've seen only _drv.so
<RAOF> Oh, I meant you currently have grep _dri.so rather than grep _drv.so
<RAOF> Also, users should be able to get away with just installing xserver-xorg-video-nouveau (& possibly the appropriate linux-backports-modules-nouveau); novueau-firmware will get pulled in by l-b-m-n.
<bryceh> ahh
<RAOF> Hm.  And it's missing a apt-get upgrade; the newer X won't get pulled in automatically.
<bryceh> `grep _dr*v*.so /var/log/Xorg.0.log`  actually did work on the cmdline :-D
<RAOF> :)
<bryceh> RAOF, go ahead and edit those switching directions into correctness
<bryceh> this is actually based off my experience pulling from xorg-edgers last week, I just cribbed it to the nouveau ppa, I've not actually run through and tested it yet (on the todo list for tomorrow)
<RAOF> Ok.  Is there a particular reason you didn't use âadd-apt-repositoryâ, or can I change that, too?
<bryceh> go ahead
<bryceh> I just wasn't aware of that tool
<RAOF> Oh, it's really neet.
<bryceh> my lamitude is irredeemable
<RAOF> There we go.
<bryceh> thanks
<bryceh> btw, did you get good feedback from your call from testing the other week?
<bryceh> Is this a reasonable way to advise people to shut off KMS if needed?
<bryceh> # Intel:
<bryceh> echo i915.modeset=0 > /etc/modprob.d/i915-kms.conf
<bryceh> # ATI Radeon:
<bryceh> echo radeon.modeset=0 > /etc/modprob.d/radeon-kms.conf
<bryceh> # Nouveau:
<bryceh> echo lbm_nouveau.modeset=0 > /etc/modprob.d/lbm_nouveau-kms.conf
<tjaalton> nouveau only supports kms
<bryceh> tjaalton, ah, right
<RAOF> bryceh: I got a much smaller response to the call for testing than I expected.  No one reported show-stoppers, though.
<bryceh> well that's good
<bryceh> then we should do another call with this new ppa and the testing page.  I've had a few people promise to do nouveau testing when it's ready, so maybe I'll call in those chits
<tjaalton> RAOF: I've got gf8600/9600/some quadro, need testing on those?
<tjaalton> quadro nvs 295 or so
<bryceh> tjaalton, https://wiki.ubuntu.com/X/Testing/NouveauEvaluation
<bryceh> if you ran through that to sanity check the directions it would be quite helpful
<tjaalton> sure
<ara> bryceh, xorg as package (from where you can reroot them) is a good choice for people to report bugs on the prop drivers project?
<RAOF> tjaalton: Everything's worth testing.  Frankly, I think everything that's not an IGP is going to be solid; it's the IGPs I'd worry about.
<bryceh> ara, that's fine
<tjaalton> RAOF: ok
<Sarvatt> a nvaa IGP seems to be working now surprisingly
<Sarvatt> tried my 8200 out, didn't try 3D out but 2D was working. it's in my HTPC and the wife wanted the tv back so I couldn't try it long :D
<Sarvatt> apw: regarding https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/404064 -- a fix has been cced to stable http://lists.freedesktop.org/archives/intel-gfx/2010-February/005803.html
<ubottu> Ubuntu bug 404064 in linux "KMS error message while intializing modesetting (during boot and resume) - render error detected, EIR: 0x00000010 [i915]" [Medium,In progress]
<apw> Sarvatt, hi
<Sarvatt> heyo! sorry to ping you, i was just scanning through bugs fixed by recent patches going into drm-intel-next and that one was assigned to you so thought you might want to know
<apw> ahh i see that now, missed the second link on first view
<apw> Sarvatt, i've added a link in the bug
<Sarvatt> the patch is actually attached in the upstream bug report thats already linked too
<apw> sweet
<bryceh> morning
<Sarvatt> any way to search the logs attached to bug reports on launchpad through the web interface? doesn't look like a search checks those
<Sarvatt> i'm looking for errors with [drm:i915_gem_object_pin] *ERROR* Failure to install fence: -28 fixed by a recent libdrm commit
<Sarvatt> morning bryceh
<bryceh> no, the web interface doesn't provide a way to search them
<Sarvatt> btw, how do we get the hwdb id for the nouveauevaluation wiki page?
<bryceh> there have been launchpadlib tools written which do that though, if you'd like to try your hand at crafting them
<bryceh> Sarvatt, I'm a bit fuzzy on how that works.  I think the user gets it when they sign up
<bryceh> and if we have the id, we can look up the info
<bryceh> but there isn't a way for us, knowing the person, to find their hw
<Sarvatt> when we sign up for what?
<bryceh> for the hwdb
<Sarvatt> hmm i dont see hwdb-client or hwdb-gui in lucid
<jbarnes> Sarvatt: looks like ickle just posted a fix for the libdrm crash you mentioned yesterday
<Sarvatt> it didn't fix 945 for me, already tested it :(
<jbarnes> damn was hoping it was fence reg overallocation
<Sarvatt> crashed after 7 minutes
<Sarvatt> http://pastebin.com/f4a62401d
<Sarvatt> commit message said it was just changing i915 and prior but i have 3 fences reserved on 945 too
<Sarvatt> actually, it was a bit different, theres no uxa_prepare_access() error before the hang like there normally was - http://sarvatt.com/downloads/intel_crashes/02092010/
<Sarvatt> in Xorg.0.log
<Sarvatt> http://sarvatt.com/downloads/intel_crashes/Xorg.0.log
<Sarvatt> thats what the hangs looked like before that libdrm commit
<Sarvatt> Duke`: are you around?
<Sarvatt> i just set up a 14 patch series for libdrm to revert intel back to 11-25 incase you want to try it with me to see if it still works
<Sarvatt> http://sarvatt.com/downloads/intel_crashes/libdrm-reverts/
<Sarvatt> just installed that and am building intel git against it to see if its still working right
<Sarvatt> uploaded the debs incase you wanted them too
<Sarvatt> bryceh: got enough ppa's? :D
<Sarvatt> trying to find your cairo 1.9 snapshot to see if cairo-trace is in it
<Sarvatt> woohoo it is built with your package, just not installed. that saves me alot of time :D
<kklimonda> Sarvatt, I get some color corruption - see the end of this dmesg: http://pastebin.com/f3ab3aa06
<kklimonda> Sarvatt, to be more precise it's font color corruption
<Sarvatt> http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=AIII,+invalid/inactive+channel+id+128
<Sarvatt> funny the first hits are your exact gpu :D
<kklimonda> heh :)
<Sarvatt> were you watching a video when it happened?
<Sarvatt> or opening a folder with videos getting thumbnailed in nautilus?
<Sarvatt> kklimonda: <stillunknown> Sarvatt: that one (i guess), there's a patch, just hasn't hit upstream yet
<Sarvatt> from #nouveau
<Sarvatt> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=250cc31f35f00b5dd4b76e6c0bb9425b4fe23304
<Sarvatt> will make a new lbm-nouveau with nouveau git instead of linus git in edgers sometime
<Sarvatt> we want testing with linus git though, if anything i'll try cherry-picking that into linus' tree and build a new lbm-nouveau but i can't at the moment because cloning kernel git will take a year on a tethered phone connection :)
<kklimonda> hehe
<Sarvatt> if anything you could grab the source, then grab http://cgit.freedesktop.org/nouveau/linux-2.6/patch/?id=250cc31f35f00b5dd4b76e6c0bb9425b4fe23304 then change the patch paths at the to a/updates/nouveau/whatever.c b/updates/nouveau/whatever.c and apply it  by hand with patch -p1 and rebuild
<Sarvatt> the linux-backports-modules-nouveau-whatever source that is
<kklimonda> Sarvatt, will do if it gets more distracting than it is now
<Sarvatt> http://sarvatt.com/downloads/patches/nouveau_pgraph.patch
<Sarvatt> that should apply with patch -p1 < nouveau_pgraph.patch from the linux-backports-modules-whatever/ directory
<Sarvatt> thanks for that though, something we should probably pick up if it doesnt go upstream in time :D
<tseliot> superm1: did you upload a new DKMS in Karmic with my  patch to fix bug #474917 ?
<ubottu> Launchpad bug 474917 in nvidia-graphics-drivers-180 "nvidia drivers 185.xx compile into kernel 2.6.28 instead of 2.6.31 on update from jaunty to karmic" [Critical,In progress] https://launchpad.net/bugs/474917
<tseliot> if you don't plan to upload an update I'll mark the task for karmic as a won't fix
<superm1> tseliot, didn't upload to karmic, probably wont at this point
<superm1> should be fixed in lucid however
<tseliot> superm1: yes, I know. I just wanted to double check with you
<tseliot> superm1: also, did you have the chance to work on fglrx?
<superm1> tseliot, yeah i think most of the conversion necessary should be done, but you should double check my work
<superm1> it's all on phorogit
<tseliot> superm1: ok, let me check
<superm1> since we dont have a (working) driver for lucid right now, it was a bit hard to verify 
<tseliot> superm1: I made these changes (on the basis of what we do with nvidia): http://pastebin.ubuntu.com/372728/
<superm1> tseliot, that first set of changes should be in dkms's common.postinst
<tseliot> right, but can I use them if I source from that file?
<tseliot> without executing the rest of the script, that is
<superm1> tseliot, Oh.  hm.
<superm1> what's update-initramfs's behavior without the -k flag?
<tseliot> superm1: it updates the kernel grub defaults to
<superm1> hm well  i understand better why you've  got that in place now...
<superm1> i guess that's the only way to do it for now then
<superm1> I wish there was a cleaner way
 * tseliot nods
<tseliot> superm1: I think I'll push my changes
<superm1> tseliot, okay.  do you know what piece is incompatible with the current fglrx in the X stack?
<superm1> perhaps you can revert that single piece to the karmic version to be able to test all this
<tseliot> superm1: they didn't tell me what's missing but it mustn't be trivial if it's taking so long
<superm1> tseliot, well a lot of that is probably their development process too.  they normally develop 2-3 releases out
<tseliot> superm1: yes, of course it must be a matter of priorities too
<bryceh> I am actually a bit surprised they did not already put out a driver that works with xserver 1.7
<tjaalton> tseliot: please make it provide the abi again and conflict with the current server. no reason to let people install it just to see the server crash
<bryceh> I would love it if they'd fix their development process to deliver released drivers in time for ubuntu.  Receiving those pre-release drops ends up just making everyone paranoid about canonical
<tseliot> tjaalton: that's a good idea
<superm1> I dunno, maybe as a patch to the packages carried in ubuntu
<tjaalton> tseliot: just providing the old abi is enough to make it conflict
<tseliot> bryceh: right, but I have a *secret driver* so they're not being paranoid :-P
<superm1> it's hard to gauge which releases get supported by the packaging kept in phorogit sometimes
<bryceh> tseliot, you're a very sinister guy
<superm1> and if you forget to update one of them, then suddenly a release that should work won't
<tseliot> bryceh: I am. Furthermore I'm working from our secret lab in Lexington right now :-P
<bryceh> say hi for me :-)
<tseliot> superm1: do you mean a patch which changes the control file?
<tjaalton> tseliot: btw, what's wrong with the e71?-)
<tseliot> bryceh: sure, I'll say hi to dr. evil :-P
<superm1> tseliot, just for now maybe uploading to lucid something that conflicts with the current x server
<superm1> but not making that change in the upstream packaging
<bryceh> btw, are you subbed to xorg-prop-drivers-testers@lists.launchpad.net ?
<tseliot> tjaalton: the browser is an abomination. I can't even login on launchpad or on the website which should allow me to have my wifi connection in the hotel. Furthermore I keep pressing the "p" key when I try to hang up...
<tjaalton> tseliot: heh yeah, the browser sucks. opera might be better though
<tseliot> superm1: aah, ok, that would definitely be better
<tseliot> bryceh: yes, I did
<tseliot> tjaalton: I'll try webkit when I get my nexus
<tseliot> :-)
<tjaalton> tseliot: boo :)
<tseliot> :-D
<jcastro> ok
<Duke`> Sarvatt, I'm x86_64, your packages are i386
<RAOF> bryceh: Oh!  I've just noticed something obvious missing from the nouveau testing page: suspend/resume.  I'll add that in.
<bryceh> RAOF, aha thanks
<Sarvatt> can you build it yourself Duke`?
<Sarvatt> i'll send the source if you want
<Sarvatt> Duke`: grab xserver-xorg-video-intel_2.10.0+git20100209.41784e15-0ubuntu0sarvatt2~karmic* from http://sarvatt.com/downloads/intel_crashes/libdrm-reverts/ then dpkg-source -x xserver-xorg-video-intel_2.10.0+git20100209.41784e15-0ubuntu0sarvatt2~karmic.dsc
<Duke`> Sarvatt, I'll see what I can do tomorrow, I need to go  to bed now or I'll have an hard day :)
<Duke`> good night
#ubuntu-x 2010-02-10
<Sarvatt> so much breakage in mesa master the past few days, been trying to update it for 2 days now and  now r600 isn't building right
<Sarvatt> -   dri2_set_tex_buffer2(pDRICtx, target, GLX_TEXTURE_FORMAT_RGBA_EXT, dPriv);
<Sarvatt> +   dri2_set_tex_buffer2(pDRICtx, target, __DRI_TEXTURE_FORMAT_RGBA, dPriv);
<Sarvatt> +#define __DRI_TEXTURE_FORMAT_RGBA        0x20DA
<Sarvatt> ...
<Sarvatt> oh whoops thought i read __DRM_TEXTURE_FORMAT_RGBA there
<Sarvatt> ah i did, pasted the wrong thing
<Sarvatt> -        r600SetTexBuffer2(pDRICtx, target, GLX_TEXTURE_FORMAT_RGBA_EXT, dPriv);
<Sarvatt> +        r600SetTexBuffer2(pDRICtx, target, __DRM_TEXTURE_FORMAT_RGBA, dPriv);
<bjsnider> i've got a dependent package issue here
<bjsnider> it's a philosophical thing
<bjsnider> if you want to use vdpau with va-api, you need a package called vdpau-video. that package links to the vaapi package, but not the other way around.
<bjsnider> i'm thinking i should add vdpau-video as a dependent package of libva
<bjsnider> even though there are other ways to use libva than vdpau. it can also be used with dxva
<bjsnider> the developer however in his debian scripts did not do so
<bryceh> bjsnider, what's the name of the developer?
<bjsnider> gwenole beauchesne
<bjsnider> frenchy
<bryceh> don't know him
<bryceh> bjsnider, I would recommend running this by jcristau first since he's well clued on the debian packaging of these things
<bjsnider> right now, to get vlc with va-api you need to install vlc from my ppa
<bjsnider> that pulls in a new version of ffmpeg, which pulls in libva
<bjsnider> then you have to manually grab vdpau-video
<bjsnider> that's the step that bugs me
<RAOF> So libva is a wrapper around video-decode-acceleration APIs?
<bjsnider> libva is the package name of va-api
<bjsnider> i'm sort of using them interchangeably here
<bjsnider> vdpau-video is the vdpau side of va-api
<bjsnider> and in fact installs a driver file into /usr/lib/libva
<bjsnider> i mean how much more linked together than can that get?
<RAOF> Ah.  So vdpau-video is a shim that implements VA-API over VDPAU?
<bjsnider> yes, i guess so
<bjsnider> so in my view, instaling libva should automatically pull in vdpau-video
<RAOF> For final bonus points: does libva dlopen VA-API backends?
<bjsnider> i think so. there are 3 backends
<bjsnider> i'm not a programmer per se, so i'm not sure of what it's doing exactly, but all the vdpau-video package does is installs the vdpau driver
<bjsnider> so libva is doing all the rest of the work
<RAOF> So, what you'd like to see happen is for the libva binary package to Recommend: vdpau-video?
<bjsnider> they should really be in the same package
<bjsnider> no, not recommend, to actually depend on it
<RAOF> Does vdpau-video have any other depends?
<RAOF> It sounds to me like Recommends: is the right relationship - âwill be found together in all but unusual circumstancesâ
<bjsnider> it has no other explicit depends int he control file, only shlibs
<bjsnider> givent he build-depends it is going to probably depend on libvdpau
<bjsnider> if it's a recommends, then the user would still have to manually install it right?
<RAOF> No; Ubuntu & Debian both install recommends by default.
<bjsnider> waldo bastian is listed as the maintainer for this thing
<bjsnider> maybe it's his fault
<RAOF> Is there a bug open?
<bjsnider> gwenole is in fact not mentioned in the control file
<bryceh> oh yeah
<bryceh> this library was one that came out with poulsbo
<bryceh> waldo probably would be the right contact for it
<RAOF> Everyone's favourite intel driver :)
<bjsnider> the gma4500 can do hardware accel too
<bryceh> I would get poulsbo drops with libva included, but libva wasn't released at that point so we had to delete it out.  fun times
<bjsnider> this works for nvidia cards too
<bjsnider> witht he blob
<bryceh> RAOF, btw did we ever sort out who has responsibility for nouveau-firmware?
<superm1> bjsnider, is libva on it's way into debian anytime soon?
<RAOF> bryceh: I don't recall sorting that out, no.
<bryceh> ahem
<bryceh> uploaded
<bjsnider> superm1, i don't know if it's in there now. but i just built all of it and tested vlc and hardware accel works fine here. it would be nice to get it into lucid
<bjsnider> i can ask waldo about this, assuming he responds to the email i just sent him
<superm1> bjsnider, what state are the packages in? if it's gonna take too long to get them in debian, we can try to fast track them into ubuntu before the New package deadline
<bjsnider> i didn't have to make any change to either package to get them to build
<superm1> i'm still a bit mixed up with how va-api and vdpau relate though
<bjsnider> they build -dev packages and -dbg packages too
<superm1> va-api can use a vdpau backend, but not vice versa?
<superm1> so projects like ffmpeg that have support for vdpau already don't benefit at all
<bjsnider> va-api can use vdpau, dxva, which is the ati thing, or one other...
<superm1> xvba is the ati thing
<bryceh> mm standards
<bjsnider> oh, right
<bjsnider> libva's description is "VA API extensions for VDPAU and XvBA backends"
<bjsnider> there is also an xvba-video package
<bjsnider> i haven't built it. i wonder if it would work with fglrx?
<superm1> it's supposed to 
<superm1> the guy developing it announces releases on the ati-beta mailing list all the time
<bjsnider> gwenole?
<superm1> yeah
<bjsnider> is there some rule that says you can't put these things in ubuntu if they're not in debian first?
<RAOF> Mainly the rule of -ENOTIME.
<superm1> its generally beneficial to both
<bjsnider> you can't have them in lucid just for testing before the stable release?
<superm1> so it's better to put it in debian and then be able to sync it from there
<superm1> then the debian folks are able to step up and help maintain it too
<RAOF> That's what I meant be not enough time :)
<bjsnider> i wonder what happens if you have both the xvba and vdpau packages installed...
<bjsnider> does it try to use both? does it know enough not to use the xvba side on an nvidia system?
<bjsnider> does the entire world explode?
<superm1> so on the client side, what supports va-api though so far?  VLC?
<superm1> anything else?
<bryceh> RAOF, weird, when I debdiff the udev nouveau changes, it produces infinite diffage
<bjsnider> it's used through ffmpeg, which actually doesn't have to be patched at this point
<bjsnider> gwenole has an mplayer patch which i haven't tested because mplayer works well as is
<RAOF> superm1: I actually think gstreamer has some va-api support, too.
<RAOF> Which would be nifty, because that means that things I actually care about support it.
<superm1> interesting
<bjsnider> it would be nice to see gstreamer catch up to xine, mplayer, and vlc
<bjsnider> and everything else
<bjsnider> ugh, the xvba-video package has two separate "latest" tarballs, one for i686 and one for x86_64
<bjsnider> oh, the other thing is gnash. there's a patch to enable gnash to use it
<bjsnider> va-api that is
<virtuald> Ã¥s
<RAOF> Really?
<virtuald> no I'm just kidding
<Belthazor> Good afternoon everyone!
<Belthazor> at least in Europe
<Belthazor> I have a problem: I'd like to install new stable stuff onto my production machine
<Belthazor> but the x-org edgers ppa for karmic now tracks mesa 7.8
<jcristau> the edgers ppa is everything but stable stuff
<Belthazor> which I don't want to use yet
<Belthazor> yes, that's why I opted for mesa 7.7
<Belthazor> which was released in december
<Belthazor> so I checked the x-updates ppa but that has only mesa 7.6.1
<Belthazor> which is too old
<Belthazor> any plans for upgrading that to 7.7?
<Belthazor> or any ideas where I can get that? there's git of course, but I'm lazy
<tjaalton> backport mesa from lucid
<Belthazor> is there an easy way for that?
<tjaalton> grab the source and build
<Belthazor> ppa or tutorial?
<Belthazor> well, that's pretty much the same as git, I guess
<tjaalton> why do you need 7.7?
<Belthazor> I have an ATi rv710
<Belthazor> that already has 3D
<tjaalton> okk
<tjaalton> -k
<Belthazor> worked nice on a pendrive install when it was in the edgers ppa
<jcristau> building the r600 driver from 7.7-branch should take you about 10 minutes
<Belthazor> yeah, maybe for an experienced user :)
<Belthazor> so I assume there are no debs for this
<jcristau> there are.  it's called lucid.
<Belthazor> that's true, but it was still not considered stable last I checked
<Belthazor> my plan is to have karmic with mesa 7.7 and 2.6.32 and .33 when it will be stable
<Belthazor> until lucid comes
<Belthazor> can't I just add an official repo for lucid which has mesa?
<Belthazor> X updates says: "This PPA is for stable upstream releases of X.org components."
<Belthazor> that's why I asked if there were plans to upgrade it to mesa 7.7
<Belthazor> since the edgers for karmic now has 7.8
<tjaalton> lucid won't have .33
<tjaalton> we are concentrating on lucid, not karmic
<tjaalton> and I doubt there are plans to update that ppa
<tjaalton> for karmic
<Belthazor> I know that lucid will have .32, but .33 has irq support for my card and hopefully .34 will bring power management
<Belthazor> I doubt these will be backported, so until lucid+1 I guess I'll have to live with an "unofficial" kernel
<Belthazor> "and I doubt there are plans to update that ppa" -- that's unfortunate
<Sarvatt> bryceh: http://cgit.freedesktop.org/mesa/drm/commit/?id=4f0f871730b76730ca58209181d16725b0c40184 
<Sarvatt> \o/
<tjaalton> and it works?
<Sarvatt> i just woke up and saw it and the bug was closed, haven't built it yet
<tjaalton> was that the blocker for 2.10?
<Sarvatt> yup
<tjaalton> ok, nice
<tseliot> ah, right the Execbuf bug. So I can haz 2.10 now plz :-P ?
<tseliot> superm1: I pushed my changes to the git repository yesterday
<superm1> cool.  hopefully we'll see a build that can use them soon too now :)
<tseliot> tjaalton: I added a provides abi 5 in the fglrx package in lucid
 * tseliot nods
<tjaalton> tseliot: thanks
<tseliot> tjaalton: thanks for reporting the problem. I thought it had that already
<tjaalton> tseliot: it used to, but got dropped for some reason
<tseliot> aah, ok
<Sarvatt> one pass of "CAIRO_TEST_TARGET=xlib ./cairo-perf-trace cairo-traces/benchmark/*" stable with the libdrm update, looks promising because this could crash it easy yesterday
<Sarvatt> ugh.. maybe I should start updaing ia32-libs on xorg-edgers as well, i've come across *so many* bug reports from people using edgers on x64 and not realizing wine uses the 32 bit libs so its using the distro mesa versions
<Sarvatt> tjaalton: https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/459961 is fixed whenever mesa is updated. dont know if you want to add it to the changelog? already fixed in the ubuntu git branch with the 7.7-3 merge
<ubottu> Ubuntu bug 459961 in mesa "radeon_dma.c:210: radeonRefillCurrentDmaRegion: Assertion `dma_bo->bo->cref == 1' failed." [Medium,Confirmed]
<Sarvatt> changed it to fix commited, not sure about karmic
<jcristau> libv: oh, so it's not just me who has no idea how x.org works, and who does what?
<libv> jcristau: :)))
<libv> i run the devroom
<libv> and i do so without help from the foundation
<jcristau> and you asked for help?
<libv> the fosdem folk do most for me, the extra expense (about 25EUR or so per day of devroom) is not worth the hassle
<libv> i did in the past
<jcristau> ok
<libv> first year i got 500usd, 2nd year i dropped the ball (RandR1.2 and stuff, remember?), third year i asked for 500EUR so we could have a local X.org foundation board member pick up the tab at the mirabelle (as this would be a "thank you" for everyone, and it would otherwise not cost a thing)
<libv> daniels complained about these 500EURs
<libv> while he had just spent a huge pile of money on cambridge
<libv> then i decided: i do not need them, and i can refer people who want travel sponsorship to the board directly
<jcristau> okay
<libv> so fosdem has basically been free. last year the extra expenses were shared between suse (printing and nametags) and me (water/random things needed for the devroom)
<libv> in any case, i wonder who got paid to go where
<libv> and how this is spread between different individuals and companies
<libv> i think the result will be that this money is used in a surprisingly limited fashion
<jcristau> yeah it would be nice to have some reports of what goes on to members@ from time to time
<libv> i personally have never received money from the foundation for my own expenses, only once did i ask for it, and later on there were issues, and i got like half my trainticket repaid by some other stash somewhere
<libv> gusarov was referred to the board when he asked me for support for travel to fosdem, he got some money, this is the only fact i have about what the board did in the last year
<libv> hehe
<libv> David Nicol his answer
<bryceh> Sarvatt, excellent.  I'd asked yingying about that yesterday, so this is good news :-)
<bryceh> Sarvatt, now I hope there aren't other bugs we're going to hit moving to 2.10?
<jcristau> bryceh: hah.  wishful thinking.
<Sarvatt> all those people using UMS because KMS doesn't work right for them will be crying :)
<Sarvatt> i would say we should update intel-gpu-tools to a newer version that has intel_reg_dump buuuut
<Sarvatt> reading /sys/kernel/debug/dri/0/i915_regs hangs the system on 2.6.32 :)
<jcristau> get anholt to release a tarball for it?
<jcristau> libv: hah.  this guy sounds like a clown.
<libv> jcristau: he is, and i now love him for it
<libv> jcristau: with this one sentence, he turned these elections into a complete farce
 * jcristau will hold his vote for a little longer.
<libv> yup :)
<libv> actually, these elections should be declared invalid
<libv> jcristau: don't you find it kind of strange that there are mostly just .us citizens on the board?
<Sarvatt> Duke`: if you didn't see the hang should be fixed with the latest libdrm in edgers, no need to rebuild that one :)
<Duke`> Hi
<Sarvatt> heyo
<Duke`> well, I haven't seen it for some days
<Duke`> but I had it sometimes
<Duke`> less frequently
<Duke`> so I don't know if there is a (partial) fix, or if my usage makes it crash less often
<Sarvatt> do you have limited arb_fragment_shader support enabled in driconf? because i think i found another bug with that where it can cause an invalid batchbuffer hang just like the other one
<Sarvatt> but that might have also been my pixman 17.3 snapshot causing it I think
<Duke`> no, it's disabled
<Sarvatt> how much uptime did you have at the most lately? longest i went without a hang was 3 days shortest was 110 seconds
<Duke`> I could reach a full day. I power off my laptop before going to bed (sleep is hardware-broken)
<Sarvatt> oops 117 seconds, [  117.964249] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged
<Duke`> shortest for me was the time to reboot + to reopen the webpage which hanged me + scrolling 3 seconds :)
<Sarvatt> that was boot, idle 1.5 minutes then open gnome-terminal :D
<Duke`>     intel: Handle resetting of input params after EINTR during SET_TILING
<Duke`> that should fix it, right?
<Sarvatt> yeah
<Sarvatt> and the commit before it fixes a similar thing people on <=915 were getting with failure to install fence errors in dmesg
<LLStarks> bryceh, is there anyone to set xrand full aspect as default?
<bryceh> huh?
<bryceh> LLStarks, dunno
<LLStarks> this: xrandr --output LVDS1 --set "scaling mode" "Full  aspect"
<LLStarks> can we make it default?
<LLStarks> i hate having to set it upon bootup
<bryceh> I haven't had to set that up myself
<LLStarks> i don't like how "full" is the default.
<LLStarks> stretches 4:3 games too much
<bryceh> it'd be best to convince upstream to change the default
<bryceh> and then have me pull a patch from them
<LLStarks> is there an x freeze i need to consider?
<bryceh> for features, alpha-3 is the target
<jbarnes> LLStarks: it was the default where supported for the X driver
<jbarnes> LLStarks: for the kernel I'm not sure why it changed... post a patch and I'll ack it
<BUGabundo> evening 
<Q-FUNK> are we gonna rebase our X to match Debian's 7.4.2  on time for Lucid?
<Q-FUNK> Ã¶Ã¶Ã¶.. 1.7.4
<Sarvatt> the stable 1.7 branch is mostly just fixes, i dont think it counts for the feature freeze? its already queued up in git anyway
<Q-FUNK> fixes are always welcome
<Sarvatt> just hasnt been uploaded yet
<Q-FUNK> ah, ok
<Q-FUNK> I'm just a bit aparanoid about ensuring that -geode is still remotely usable on Lucid.
<Sarvatt> nothing between 1.7.3.902 and 1.7.4 affects that anyway so no worries :D
<Sarvatt> (on the xserver front)
<Q-FUNK> well, there's already regressions when building the same geode source against 1.7, compared to 1.6, so I'm already worried.
<herman_> Sarvatt, 
<Sarvatt> ..kay
<herman_> hey, my ubuntu 9.10 is freezing sometimes, and stop all the activities and a i have to restart the notebook directly from the button on/off
<herman_> someone passed for the same problem?
<joumetal> There is radeon kms bugs in lucid like bug #507148. Is following backtrace useful?
<ubottu> Launchpad bug 507148 in xserver-xorg-driver-ati "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [Unknown,Confirmed] https://launchpad.net/bugs/507148
<joumetal> http://pastebin.com/m1055955
<joumetal> it's custom kernel with radeon module unloaded and reloaded with modeset=1.
<RAOF> Sarvatt: Hm.  System-wide nouveau_dri.so is not the problem; someone's obviously broken GL_EXT_texture_from_pixmap for nv40 in mesa git.
#ubuntu-x 2010-02-11
<jcristau> libv: looks like you managed to stir things up :)
<libv> jcristau: deservedly so too :)
<libv> this is why i am this loved a character
<libv> i do point out where the problem is
<bryceh> libv, heh
<libv> bryceh: ?
<bryceh> libv, it makes me wonder if they have a secretary or not.  What you're asking for is sort of organization 101
<libv> bryceh: yeah
<jcristau> i think bart is secretary?
<libv> jcristau: keithp
<jcristau> oh
<bryceh> m
<libv> i know someone who was on the board once :)
<libv> and so i do get some inside info, at least from until a few y ago
<libv> let's say that it's all a bit... interesting
<jcristau> http://www.x.org/wiki/BoardOfDirectors says keithp's term ended in 2008
<libv> ah... i think he is still the treasurer then
<libv> something like that
<libv> still, nobody has much of an idea of what is going on
<jcristau> treasurer but not on the board?  how does that work?
<libv> jcristau: there was some construction like that, when someone forgot to do any campaigning and then didn't get voted on the new board
<libv> not sure which year that was
<libv> not sure whether either of you guys know anything of this, but the xfree86-core team got accused of being horribly closed once
<libv> and xorg was going to change all this
<libv> xfree86-core explicitely had nothing to do with money or IP, just was a 90s style project organisation, and people got in after a lot of work on merit only
<libv> Xorg was going to change that, but nobody has any idea about what is happening with the 100-200k usd they have
<jcristau> well apparently they don't even know how much money they have..
<libv> yup :)
<libv> fun, isn't it :)
<libv> and then there is this nicol character with his fantastically comical remarks
<libv> i wonder if he even realizes how succinct he is
<jcristau> yeah he's a lot of fun
<libv> he is like the cuckoo clock in The Pink Panther Strikes Again
<libv> where Clouseau asks "Does your dog bite?"
<libv> jcristau: btw, too bad that you weren't at fosdem
<libv> jcristau: the duck a l'orange at le mirabelle stole my heart
<jcristau> heh :)
<jcristau> i was actually at the office on sunday
<libv> and when i had my talk i asked: who built X since modular -- 25 out of 100 hands. Who has built X in the last year or so: 22 out of a 100 hands. Then daniels said something about the build script, and then i asked again: who did this with the build script recently: no hands whatsoever
<libv> and then i explained i haven't done this recently either and instead used your git trees to build debian packages directly :)
<jcristau> :)
<libv> anholt did one constructive thing though: he told me redhat is already putting libmesa in an .so
<libv> pulled the BS card on everything else, as expected :)
<bryceh> libv, it's funny because when you file bug reports the bug triagers definitely tell you to go build stuff from git.  Maybe not the whole tree but seems like often you end up at least having to do a driver, mesa, libdrm, xserver, etc.
<libv> bryceh: sure, but nobody builds the whole thing anymore, even though from time to time they are almost forced to do so
<libv> i am about to start poking with mesa/dri to see which libdrm version it really depends on, when the drivers are not being built with it
<libv> xserver requirement for instance is just 2.3.0 (Aug 2006)
<libv> this simply because the drivers are not in the same built tree
<libv> s/built/build/
<libv> bryceh: from my answer, you should probably retain that i do not call for building the whole thing from scratch: i would like to see the ability to build drivers, all parts of it, built against a suitable range of common dependencies
<libv> if this means disabling features and performance: so be it. At least give people the ability to get the basics done without bugs
<libv> as time progresses, these features and performance become available anyway
<libv> i think it's only ubuntu LTS which comes with the 1st version exa today, even debian stable is beyond this
<libv> anyway, i will get larabel to get a real fun and sarcastic survey up on his website once he is back in the states (he is in Koeln atm iirc)
<bryceh> libv, yeah the hyperfocus on the bleeding edge trips us up from time to time
<libv> bryceh: i was at suse when we were bringing up SLE 11, and we basically got told, with some management from both sides on the phone, to go change our business model by someone who only relatively recently became a driver developer.
<libv> that's how bad it really is.
<bryceh> heh
<bryceh> sounds familiar, sadly
<libv> yeah, suse has gregkh telling the same story from inside the company too, also not liked by those parts of the company that try to get a working desktop out
<libv> all just useless discussions where no amount of arguments bring anything :(
<bryceh> shed paint color arguments
<bjsnider> why do packages like mplayer and vlc, and gst-ffmpeg use shared ffmpeg instead of internal in ubuntu?
<RAOF> Because internal libraries are harder to maintain.
<RAOF> bjsnider: In particular, what happens if everything's using internal ffmpeg, and a security flaw is discovered?
<bjsnider> that's an interesting point
<bjsnider> if you go to the mplayer irc channel and tell them you're using shared ffmpeg, 25 people will immediately chime in to tell you you're an idiot
<RAOF> How do we know what packages are affected?  Given that ffmpeg breaks API on occasion, and ABI more frequently, how do we know that dropping in a new ffmpeg version will work?  Will we have to backport the fix to a different ffmpeg version for each package using internal ffmpeg?  How do we know we've got all the vulnerable packages, etc.
<bjsnider> then if you say that is how it is packaged, it becomes the debian maintainers like siretart that are idiots
<bjsnider> let me ask you this: is siretart an idiot?
<RAOF> No.
<bjsnider> no, he is definitely not an idiot
<RAOF> ffmpeg is a curious upstream, really.  They don't seem to really care whether what they do is useful for anyone.
<RAOF> Well, that's not strictly true.  But, should you bring up shared libraries, there'll be the guy who claims ELF linkage is braindead-broken, and that he could develop a better library system, and just as soon as he does the world will have ponies.
<RAOF> I subscribed to the ffmpeg mailing list for a while; it's quite instructive in some ways.  There are some very smart coders there.
<bryceh> bjsnider, in the mplayer community you could say, "The sky is blue", and get called an idiot
<bjsnider> would you like me to tell them that? i'm talking to them right now...
<bryceh> lol
<bjsnider> "well, you know what bryce harrington said? he said..."
<bjsnider> meh, i don't want to start a flame war, so i'm not going to pass any more messages back and forth
<cwillu> bjsnider, wanna look at my mouse bug instead? bug #520250 :p
<ubottu> Launchpad bug 520250 in xorg "steelseries xai laser mouse detected as keyboard, doesn't function" [Undecided,New] https://launchpad.net/bugs/520250
<bjsnider> i already fixed that bug
<cwillu> did I file a dupe?
<bjsnider> it was right after i punched out god, beat roger federer in straight sets and singlehandedly won the nba championship
<cwillu> nice
<bjsnider> all in the same day, i might add
<cwillu> of course
<cwillu> fix is in lucid?
<cwillu> backported to hardy already?
<bjsnider> i created a driver completely from scratch. it is 100% bug free and has features not even present in the device's firmware.
<cwillu> beautiful!
 * RAOF suspects bjsnider might be talking out an orifice not normally associated with speech.
<cwillu> I was hoping to be able to write to the lcd on the bottom of the mouse <3
<bjsnider> actually come to think of it, i can comment on that bug. when you bought it, did you research whether there was a working linux driver for it?
<cwillu> it claims hid compliancy; been a while since I had a mouse not track at all
<bjsnider> does it work on older kernels/distros?
<cwillu> can't say that it does
<bjsnider> if it were me, i'd take the hardware back and get something that works
<cwillu> yes, I'm aware of that
<bjsnider> otherwise you're sitting there hopeing that someone eventually fixes it
<bjsnider> and hope ain't a plan
<cwillu> that's not a terribly precise summary of my plans :p
<cwillu> there we go
<alkisg> What is the name of the program that produces the "Ubuntu is running in low graphics mode" dialog? I want to uninstall it...
<alkisg> Got it: "x11-common: /etc/gdm/failsafeXServer". Now if only I could disable it without uninstalling x11-common...
<alkisg> Why does that need to run, anyway?
<alkisg> # cat /etc/X11/default-display-manager 
<alkisg> /usr/sbin/ldm
<alkisg> I don't even use gdm...
<cwillu> alkisg, dpkg-divert is your friend
<alkisg> cwillu: I was just trying to divert /etc/init/failsafe-x.conf, is that a good idea?
<cwillu> oh, in that case, don't even divert it, just modify it
<alkisg> Thanks, I'll try that.
<bryceh> jcristau, do you know if anyone has looked at autodetection of video devices on the USB bus in the xserver?  E.g. displaylink, sisusb, and the like
<jcristau> no idea
<verbalshadow> bryceh: ping
<bryceh> jcristau, interesting.  Not seeing any discussion on the mailing list archive
<bryceh> verbalshadow, I'm pretty tied up but what do you need?
<verbalshadow> bryceh: bad X issue with ati i get white scanlines and a hard lock in lucid
<verbalshadow> even remote login fails to get a bt
<bryceh> verbalshadow, install xorg-edgers and a mainline kernel from kernel team's ppa.  If the issue still exists after that, file a bug at bugs.freedesktop.org.  If they solve it, post the patch to bugs.launchpad.net and subscribe me to it and we can look at including it.
<bryceh> verbalshadow, I'm hoping to get new 2.6.33 drm for radeon into lucid, so bugs against the current stuff is not super interesting to me
<verbalshadow> bryceh: ok, cool thanks i'll take a stab at that
<bryceh> verbalshadow, if you're needing workarounds, try: 1) disabling kms, 2) disabling compiz, 3) switching between EXA and XAA
<bryceh> verbalshadow, btw what's your graphics card?
<bryceh> we had reports of similar issues on R100/R200 class hw
<verbalshadow> i have be using the -7 kernel and that worked until today
<verbalshadow> Radeon Xpress 200M
<bryceh> what changed today?  new kernel?
<bryceh> verbalshadow, if you have time/interest, looking at what piece(s) went in from the -7 to -8 kernel might be interesting
<verbalshadow> grabbed all the KDE updates and some gnome stuff as well
<bryceh> also, maybe this is obvious, but given that you had luck by holding back the kernel, that's a pretty strong clue of a kernel bug, so the kernel team might be more interested in this
<bryceh> again though, I suspect turning off kms will get things working, and the underlying issue may be solved when we pull newer drm bits into the kernel
<verbalshadow> what do i add to the boot line to disable kms?
<bryceh> verbalshadow, see https://wiki.ubuntu.com/X/KernelModeSetting
<verbalshadow> ok
 * bryceh eyeballs the topic ;-)
<verbalshadow> bryceh: :P yeah should have look harder, the good news is that i have cnetworkmanager (to easily connect to my wifi) and links installed so i can browse the web
<Sarvatt> soo, what are the odds we could get the driver specific drm headers removed from linux-libc-dev? :D adding the replaces: linux-libc-dev in libdrm keeps biting me because linux-libc-dev updates overwrite the libdrm headers
<Sarvatt> we either need include/drm/i915_drm.h from libdrm or to backport the overlay stuff into the 2.6.32 kernel to build intel 2.10, they are expecting us to use headers from libdrm upstream though
<jcristau> or disable the overlay code when you have too old headers
<Sarvatt> i kinda feel like having the updated libdrm headers would be better so the driver at least compiles with support for newer features if someone decides to use a newer kernel, since it does do runtime detection of those features and works right if they arent there.  just my opinion though and i'll be using xorg-edgers anyway most likely where i can keep that change seperate
<Sarvatt> if you're shipping new drm for radeon/nouveau though its going to affect intel, and linux-libc-dev is going to be out of sync anyway
<tseliot> bryceh: is nouveau's kms already in?
<bryceh> tseliot, not yet, coming soon
<bryceh> we got the udev and nouveau-firmware bits in; next up is plymouth and l-b-m
<bryceh> once those are in I think we can dump the remaining X chunks ourselves pretty easily
<bryceh> tseliot, how things going in MA?  Trust you're not too snowed in?
<tseliot> bryceh: things are better than the weather forecast predicted
<tseliot> things are fine
<bryceh> tseliot, btw I updated the Input Configuration page on the wiki to include docs about udev-based configuration
<tseliot> bryceh: ah, good
<Sarvatt> tseliot: they implemented tag matching stuff that you were suggesting for the xorg.conf.d stuff upstream if ya didn't see it
<bryceh> Sarvatt, are there some good examples of configuring input (or video) devices using xorg.conf.d?  I could docco that while I'm at it.
<jcristau> where "they" is RH
<tseliot> Sarvatt: yes, I did the work too but, after seeing that upstream did it, I just reviewed the patch and gave them some feedback
<tseliot> jcristau: Peter Hutterer. Dan Nicholson also reviewed the patch, as I did
<tseliot> it was a trivial change
<Sarvatt> theres a post on xorg-devel ML where someone brought up the fact removing the note.abi tag from libGL breaks the ordering like you were saying as well, is it a horrible hack to remove that tag so we could leave libgl.so.1 in /usr/lib and not have to have it at /usr/lib/mesa?
<Sarvatt> http://lists.x.org/archives/xorg-devel/2010-February/005563.html
<tseliot> maybe adding that tag to the nvidia binaries would be better. slangasek suggested something similar I guess
<jcristau> i think the tag could be removed.  your libc wouldn't run on a 2.4 kernel anyway.
<tseliot> jcristau: by disabling TLS?
<jcristau> no
<Sarvatt> we wouldn't have to disable TLS, just remove the tag from getting added from src/mesa/x86/glapi_x86.S
<tseliot> aah, I see what you mean now
<tseliot> yes, we could do that
<tseliot> bryceh: does failsafe mode still use vesa?
<tseliot> (just asking for debugging purposes)
<bryceh> yeah
<Sarvatt> well src/mesa/x86-64/glapi_x86-64.S would have to have it removed too
<Sarvatt> hmm, wonder if its possible to make an xorg.failsafe.conf with both fbdev and vesa (in that order) and have it move on to the second device section if the first fails like how the auto configuration works
<tseliot> ok
<herman_> Sarvatt, my ubuntu 9.10 is freezing. Sometimes everything freezes, can't move mouse etc. have to do hard reset. What can this be?
<Sarvatt> i havent been able to work out adding the check for a KMS fb in failsafeXServer
<jcristau> Sarvatt: what happens with vesa+kms?
<Sarvatt> its garbled and doesnt work
<jcristau> hrm
<jcristau> is it supposed to do that?
<Sarvatt> i think it tries to open up a 800x600 display inside the full rez one because you can partially see things
<tseliot> Sarvatt: do you mean when either radeon or intel kms modules are already loaded?
<Sarvatt> or nouveau yeah
<tseliot> right
<jcristau> grep drm /proc/fb
<jcristau> or some such
<Sarvatt> i tried adding a check for inteldrmfb nouveaufb or radeondrmfb to the failsafeXServer script but it didnt work
<tseliot> so does checking lsmod fail?
<jcristau> lsmod doesn't tell you what you want to know
<Sarvatt> yeah thats what i tried - if [$(grep -q -E '(nouveau|drm)fb' /proc/fb)]; then
<jcristau> you don't want [$(
<jcristau> just if grep -q foo; then
<Sarvatt> ohhh hmm
<Sarvatt> how can I force a failsafeX session again to try it? my old bugs I was abusing to do it before were fixed :)
<tjaalton> break the config
 * Sarvatt switches driver to nouveau and reboots with this - http://pastebin.com/f58621c19
<kklimonda> why is fbdev better than plain vesa?
<Sarvatt> fbdev works with a KMS fb (and full resolution at that) and vesa doesnt
<kklimonda> ach :)
<bryceh> Sarvatt, did that boot up ok?
<Sarvatt> darn it just fails with no screens found if i change the driver, how should i break the xorg.conf?
<Sarvatt> bryceh: trying to force a failsafe X session still
<Sarvatt> hmm maybe if i just run failsafeXServer directly
<bryceh> I do "echo 'foobar' >> /etc/X11/xorg.conf" to do testing
<bryceh> basically, any garbage in xorg.conf should pop it into failsafe mode
<bryceh> but yeah if you shut down gdm you can run failsafeXServer directly
<tjaalton> right
<bryceh> keep an eye out for generating stray X processes (do `pkill X` once and a while)
<Sarvatt> nope it still uses vesa
<Sarvatt> when it tries to start up with vesa I get the grub graphics on the screen at the start all garbled
<tseliot> Sarvatt: ouch, so it's broken so early in the boot process
<tseliot> I'm not sure as to whether we want to do something in the initramfs about it
<Sarvatt> well grub is using vesa, guessing it just dumps that stuff back up on the screen when you try to use vesa again
<tseliot> cjwatson would be the right person to ask about it
<Sarvatt> changing /etc/X11/xorg.conf.failsafe from vesa to fbdev works great for failsafeX
<Sarvatt> might have hit a bug with plymouth while i was screwing around there - [drm:i915_gem_madvise_ioctl] *ERROR* Attempted i915_gem_madvise_ioctl() on a pinned object
<Sarvatt> grep -q -E '(nouveau|drm)fb' /proc/fb && echo yes
<Sarvatt> yes -- that works at least, its just how to hook it in the script
<Sarvatt> anyone ever say that it's crazy to use plymouth (when its expected to be rewritten for libkms soon) and/or bring in nouveau in when its api is expected to get completely busted around release time for a lts? :D even radeon KMS is sketchy, an opt-in lbm module for it with KMS enabled and the normal one having kms disabled might be a better option
<Sarvatt> if you do make a lbm for radeon keep in mind it needs firmware not in linus' tree (non-free license) for r600-700 irq support and doesn't even start up right without the firmware last I checked
<jcristau> Sarvatt: airlied was advising to either use the 2.6.33 radeon bits or disable kms so i suspect some decision will be mad along those lines for lucid
<bryceh> yeah I'm trading emails with apw and sconklin on this
<jcristau> made, even
<Sarvatt> yeah I saw that in the radeon 7500 bug
<Sarvatt> btw jcristau, did you want to push main: move config_init() after InitInput() to server-1.7-nominations?
<bryceh> it's in my todo list to get this squared up but I need more info at this point... so if you have opinions shoot them at me and I'll add them to the pot
<jcristau> Sarvatt: no
<jcristau> Sarvatt: 1.7 doesn't have the udev stuff so should be fine without it
<Sarvatt> ah its related to udev which isnt in 1.7 branch isnt it
<Sarvatt> I dont know, airlied was saying radeon wouldn't get loaded right by udev if you had KMS enabled in the kernel config but booted with modeset=0 but we didnt see that in karmic
<jcristau> hal uses a timer to enable stuff, so it doesn't fire until the main loop.  so it's not affected.
<Sarvatt> we changed the default module option to modeset=0 there
<Sarvatt> ah thanks for the clarification, was just wondering because i'm getting the patch hooks set up for the 1.7.5 release soon
<Sarvatt> btw did you see that updated efifb patch jcristau? I *really* need to get kernel-package set up again to build my own kernels
<jcristau> yeah didn't work either here
<Sarvatt> ah darn
<Sarvatt> do you use kernel-package to build your kernels? how do you make it add a build an initrd hook if so?
<jcristau> make; sudo make install modules_install; sudo update-initramfs -c -k $mumble; sudo update-grub
<Sarvatt> ah you do it the normal way, i'll just keep using kernel-package and build the initrd myself because i build it on my vps (takes a year on this atom cpu)
<jcristau> make deb-pkg is supposed to work i thought
<Sarvatt> oooh gcc-4.5 is in experimental, I want to try building the kernel with -march=atom
<BUGabundo> rebooted into 2.6.33 and nouveau only works at 800px.
<kklimonda> if you mean -13 that's probably because there are no lbm for -13 built yet
<kklimonda> (and I have no idea how to build them myself so no reboots for me ;) )
<BUGabundo> correction: 2.6.32-13-generic
<BUGabundo> you can reboot, just choose -12 kernel
<kklimonda> ya, I know
#ubuntu-x 2010-02-12
<Sarvatt> looks like pm-utils needs an update for nvidia, no wonder suspend wasnt working
<Sarvatt> using_nvidia() {  [[ -d /sys/module/nvidia ]]; }
<Sarvatt> (should be nvidia-current or whatever?)
<Sarvatt> in /usr/lib/pm-utils/sleep.d/98-video-quirk-db-handler
<kklimonda> Sarvatt, can you build new lbm for -13 kernel? I have no idea how to do it the right way :)
<Sarvatt> have_nvidia_g80() looks like it will take affect if nouveau is in use on a g80 and add --quirk-vbe-post that shouldnt be there too
<RAOF> kklimonda: It's surprisingly easy.  You just add a new changelog entry as 2.6.32-13.something.
<BUGabundo> Sarvatt: and nouveau ? I can't get my LCD back after suspend to ram
<BUGabundo> haven't tested hibernation yet
<kklimonda> RAOF, oh? I got scared by all those control.stubs :)
<Sarvatt> yeah looks like pm-utils needs some adapting for all this new stuff, not surprised
<kklimonda> probably should just run debuild -S and see how it works
<BUGabundo> cool
<BUGabundo> ping me back once those are done, and ill test again
<Sarvatt> the ddx depends on -12 too, needs more than just lbm bumped
<Sarvatt> sheesh theres a *ton* of vendor specific quirks in pm-utils that kind of dont take into account if kms and such is used from what i see
 * BUGabundo hands an eraser to Sarvatt
<Sarvatt> anyone know what the older nvidia kernel modules are renamed to?
<Sarvatt> besides nvidia-current
<Sarvatt> looks like its nvidia-173 and nvidia-96
<bryceh> yeah
<Sarvatt> using_nvidia() {  [[ -d /sys/module/nvidia-current || /sys/module/nvidia || /sys/module/nvidia-173 || /sys/module/nvidia-96 ]]; } works
<Sarvatt> err
<Sarvatt> [[ -d /sys/module/nvidia-current || -d /sys/module/nvidia || -d /sys/module/nvidia-173 || -d /sys/module/nvidia-96 ]]
<Sarvatt> elif have_nvidia_g80; then
<Sarvatt> if i want to extend that to have_nvidia_g80 and !=have_kms what would it be?
<Sarvatt> pushing changes here - https://code.edge.launchpad.net/~sarvatt/ubuntu/lucid/pm-utils/bugfixes
<bryceh> gonna do a merge proposal on that?
<Sarvatt> or should i extend_nvidia_g80() to return 0 if have_kms or else do what it does now
<Sarvatt> yeah, want to test it first though
<bryceh> how proper of you ;-)
<Sarvatt> oh the have_nvidia_g80 check is after the have_kms check and wouldnt get called i think
<superm1> Sarvatt, if that's all it was for fixing suspend on all nv hardware, owe ya a beer :)
<superm1> could you maybe just do an 'if ls /sys/module/nvidia* >/dev/null 2>&1' or similar though?
<superm1> that would hopefully cover beta versions and what not too
<Sarvatt> ah yeah good point
<Sarvatt> corrupted screen on resume, bah
<Sarvatt> http://pastebin.com/f3feec8de http://pastebin.com/f1cc31346
<Sarvatt> hmm that one was funky
<Sarvatt> came back to a black screen, switched vt's to 7 and got the unlock message, then it looks like gdm restarted and asked me to log in again
 * Sarvatt tries without plymouth
<Sarvatt> wonder how i get more verbose info out of pm-suspend
<Sarvatt> there we go, PM_DEBUG env variable
<Sarvatt> yeah that pm-utils change doesnt do anything, its still /sys/module/nvidia/ even though its aliased to nvidia-current
<Sarvatt> darn
<bryceh> Sarvatt, I've sponsored your plymouth patch for nouveau
<bryceh> I don't know whether they maintain the packaging in bzr, but if so you may need to push it in there
<Sarvatt> thanks bryceh! looks like udev went in too, doesn't look like pm-utils needs an update after all after looking into it more.. 
<Sarvatt> anyone have a nvidia box thats able to suspend/resume with the blob? even if it's on karmic. i'd like to see your /var/log/pm-suspend.log after running sudo PM_DEBUG=true pm-suspend if so :)
<Sarvatt> i got it resuming, but it just sits at a black screen until I vt switch a few times to get back and it looks like a really common problem
<kklimonda> heh - I was going to say that hibernation works with nouveau just fine (had to add resume=/dev/sda2 by hand to command line arguments) and then X crashed after I've pressed enter..
<Sarvatt> might want to try removing quiet splash and try again, i've heard people getting the crash hitting enter from plymouth
<kklimonda> Sarvatt, it was with quiet splash removed :)
<bryceh> Sarvatt, yeah pitti helped with udev yesterday
<bryceh> Sarvatt, I've let apw know to put out l-b-m now
<Sarvatt> i just crashed after hitting enter right after booting - http://pastebin.com/f49b04d77
<Sarvatt> hmm https://bugs.edge.launchpad.net/ubuntu/+source/libxext/+bug/519576
<ubottu> Ubuntu bug 519576 in libxext "Race condition in libXext" [Undecided,New]
<Sarvatt> fixed in our libxext 1.1.1 but could be backported
<Sarvatt> well they turned off shm support in chrome now to work around it
<johanbr> Sarvatt, well I can suspend/resume, but I have to switch vt's a few times too
<johanbr> still interested in a log?
<Sarvatt> nah its the same as here if thats the case, wondering what happens in a working suspend thats different
<Sarvatt> thank you though
<johanbr> you're welcome
<Sarvatt> tjaalton: https://bugs.edge.launchpad.net/ubuntu/+source/x11proto-dri2/+bug/520796
<ubottu> Ubuntu bug 520796 in x11proto-dri2 "Sync x11proto-dri2 2.2-1 (main) from Debian unstable (main)" [Undecided,New]
<BUGabundo_remote> good morning
<BUGabundo_remote> please advice: http://paste.ubuntu.com/374554/p://past!
<BUGabundo_remote> please advice: http://paste.ubuntu.com/374554/
 * BUGabundo_remote has week paste fu so early
 * BUGabundo_remote and English skills too, it seems
<RAOF> I think someone's updated the DDX to depend on the -13 l-b-m, but the -13 l-b-m has not been built yet.
<RAOF> Read: now isn't the time to upgrade.
<BUGabundo_remote> ok
<BUGabundo_remote> no full upgrade for me then
<BUGabundo_remote> I did a safe upgrade
<BUGabundo_remote> and it did remove linux-backports-modules-nouveau-2.6.32-12-generic
<bjsnider> tseliot, with the 195 driver, did you have to create any symlinks for the new files included in that driver?
<tseliot> bjsnider: honestly I don't remember, let me check
<tseliot> bjsnider: yes, links for libOpenCL and libnvidia-compiler
<bjsnider> because you're worried about the linker not being able to find them?
<bjsnider> i was really hoping you'd say no, but i couldn't be that ucky
<tseliot> bjsnider: no, the linker should find them when you're using nvidia as they are in /usr/lib/nvidia-current/
<bjsnider> well, i have to modify the old build scripts
<tseliot> aah, now I see why you were asking
<bjsnider> why create symlinks then?
<bjsnider> i don't understand the purpose of it
<tseliot> yes, if you want to make a backport you will have to modify it
<tseliot> the purpose of what?
<bjsnider> i can see in the old scripts that you're deliberately creating symlinks for some of the shared libs. why is that necessary?
<tseliot> do you mean, when I create .so and .so.1?
<bjsnider> well, i don't have the scripts in front of me right now, but i guess so
<tseliot> bjsnider: maybe have a look at this page? http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html
<bjsnider> i don't understand why, if .so and .so.1 are necessary, nvidia didn't include them.
<bjsnider> tseliot, i was just going to put the opencl libs in the nvidia-glx-xxx package. is that how you would do it?
<tseliot> bjsnider: the nvidia installer would create those links, see the manifest file (it's a hidden file in their installer)
<tseliot> bjsnider: yes, that would be fine
<bjsnider> did you also install that file to the /etc directory?
<tseliot> bjsnider: nvidia.icd? Yes, it does't hurt to install it
<bjsnider> of course debian upstream creates a whole separate opencl package at this point
<tseliot> superm1: it looks like in new releases of fglrx the modaliases file is empty. I guess they removed the ids from the driver which is why I think we'll have to generate a kernel module and extract the ids with modinfo from there
<superm1> tseliot, are you sure of this?  are you looking at generic releases, or releases intended for an OEM?
<superm1> i'm wondering if perhaps they are stripping it out in the releases intended for OEM (because these are tied to SSID instead)
<tseliot> superm1: is 8.70 an OEM release?
<superm1> tseliot, it depends where it came from
<tseliot> it could be then
<superm1> this is just a theory i'm suspecting though, I don't know for sure
<tseliot> I'll check a new release from AMD's website when I'm back home
<tseliot> just to be sure
<superm1> that or check the latest beta that they've posted it
<tseliot> yes, that too
<pgraner> bryceh: you about?
<apw> bryceh, we have any feel for whether any ati cards are working with KMS, are the issues leaning towards 'turn off for these cards' or 'turn off'
<apw> upstream saying 2.6.33 will have a longer support life seems to fly in the face of stable teams plans
<jcristau> i guess rhel will ship with the .33 radeon stuff backported
<apw> that is one hell of a heap of backport
<apw> and if you pull back radeon you are pulling back drm, and then you need i915 etc to match
<apw> how much of 2.6.32 are you left with
<tjaalton> apw: is that a problem? it's just one subsystem (a big one at that, in terms of LOC), and becoming more and more important due to kms..
<apw> tjaalton, replaceing the whole of drm ... thats a biggie surley, all the testing is rendered meaningless
<apw> and we don't get long term support goodness from stable as its not .32 anymore
<Sarvatt> how about just having a linux-backports-graphics people can opt-in to with KMS enabled ati and all the rest of drm, and making ati default to modeset=0 ala karmic in 2.6.32-x? could we extend the installer to install the backports by default for certain pci id ranges if it was on the cd?
<Sarvatt> or make it show up in jockey for people to pick
<tjaalton> apw: .32.x probably won't get much drm updates, probably only intel
<tjaalton> duh, damn evening messing my language :)
<Sarvatt> intel is expecting people to backport 2.6.33 features (overlay support) to use 2.10 too :( 
<tjaalton> +up
<Sarvatt> we could just add a postinst to -radeon checking the pci id and disabling KMS for r100 (and maybe some others like RS480)
<Sarvatt> that would be something safe to update post-release as we find new ones with problems and need to be disabled.. I still think modeset=0 should be the default for radeon if we arent backporting though and instead have whitelisted cards
<Sarvatt> apw: I dont know if you've seen but 2.6.33's radeon needs extra firmware not in linus' tree or linux-firmware for ati hd2xxx and newer cards also, just something else to look out for if its backported
<bryceh> pgraner, apw, yeah the kms+2.6.32 combo is proving to be pretty bug ridden.  We need to either turn it off, or backport 2.6.33 there.
<bryceh> pgraner, apw, I know there's lots of strong desire to have kms across the board, which means 2.6.33, but if that's not feasible to do then yeah kms probably should be shut off.  Otherwise we're going to be breaking a lot of systems
<pgraner> bryceh: noted, apw can speak better to the backport work
<pgraner> bryceh: I have some funky nouveau stuff to show you some time
<bryceh> ok
<pgraner> bryceh: very strange things on my card, I get X on my left monitor, on my right monitor I get a console vt
<pgraner> bryceh: and I can switch between them using ctl-alt-F1 for text & ctl-alt-F7 for X
<bryceh> pgraner, we're in a similar boat with nouveau btw.  In order to get fixes from upstream we must be pulling from the 2.6.33 drm tree.
<bryceh> wow, that's a bug I've not heard of before
<pgraner> bryceh: I'll make a video and send it to ya
<pgraner> bryceh: its a: nVidia Corporation G92 [GeForce 9800 GX2]
<bryceh> hmm, weird well file a bug via ubuntu-bug xserver-xorg-video-nouveau and post the video and any other useful info there
<pgraner> bryceh: wilco
<bjsnider> gx2, so there are dual gpus
<bjsnider> pgraner, there's a nouveau channel that has all of the devs in it including skeggs
<bjsnider> i wonder if the dual gpus might be an issue
<Sarvatt> not sure if i got disconnected or not but - <Sarvatt> oh wow, we *really* need to update libdrm it looks like, that fix fixed more than just 915-945 with intel 2.10+, people were hitting the crashes on vt switching and lid close as well 
<Sarvatt> https://bugs.launchpad.net/bugs/505271
<ubottu> Ubuntu bug 505271 in linux "[gm45] "*ERROR* Execbuf while wedged" when closing laptop lid with compiz running" [Unknown,Confirmed]
<Sarvatt> had a chance of crashing on anything triggering an interrupt without the fix it looks like
<Sarvatt> asking for a new libdrm release, been 2 months and theres other major changes like radeon KMS enabled by default as well as the fixes
<Sarvatt> we should probably just do a git snapshot if theres no release soon, other fixes in there like the <=915 fence starvation fix and we already have a 9 patch series of backports for nouveau thats outdated and needs updates already
<Sarvatt> what are we going to do about intel 2.10 though, we either need the overlay stuff from 2.6.33 backported to 2.6.32 like intel wants, ifdef out the overlay code in 2.10 and dont use it (blocking off people from using it even if they use a newer kernel with support) or install i915_drm.h in libdrm-dev and have libdrm-dev replace linux-libc-dev
<Sarvatt> just reverting this would be enough if we use the second option it looks like http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=bd81734465912d79d6320a6fb021ce43d258b906
<Sarvatt> would be so much nicer if the drm headers weren't installed in linux-libc-dev since they want people using the libdrm-dev headers now because everything has runtime feature detection
<tjaalton> yes that's where upstream is going
<jcristau> they just went the other way a few months ago..
<bryceh> Sarvatt, airlied seemed to suggest they were thinking of putting out a new libdrm soonish
<bryceh> Sarvatt, meanwhile we can consider updating to a newer git snapshot, I've added to my todo list for next week to look at it; if you get some time to test on it that'd be great
<bryceh> Sarvatt, regarding 2.10, I'm sort of mixed about it.  With the exec buffer bug fixed, we now have the main blocker we identified removed, so we ought to move ahead on it.  However, I'm concerned about losing UMS permanently, and sounds like we would be wanting to backport a bunch more stuff
<Sarvatt> same here, doesn't look like theres much in the way of fixes outside of fixes for the performance enhancements they added post 2.9.1 in 2.10 :D
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=c87585229b36790f883b9b8954ed061e00624df6 might  be worth pulling back into 2.9 branch
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=10946118dd3a63f1375a1bfde0b2f0542a93c1c2 ?
<jcristau> tell cworth that?
<Sarvatt> yeah i'm looking at things that might be worth it then planning on asking
<jcristau> cool
<jcristau> thanks :)
<bryceh> Sarvatt, Geir mentioned on the list that we need 2.6.33 for Clarkdale support
<jcristau> eh? i thought that was in .32..
<Sarvatt> it *should* work fine on 2.6.32.x, alot of fixes for that went into 2.6.32-13
<Sarvatt> we just had an old 2.6.32.6 before that was missing a bunch of fixes
<bryceh> ah
<Sarvatt> http://sarvatt.com/downloads/patches/103_increase_idgng_stride.patch 
<Sarvatt> jbarnes: does "Disable bo reuse on shadow framebuffer" fix a bug that would exist on 2.9 branch?
<jbarnes> Sarvatt: yeah wouldn't hurt
<geser> anyone familiar with the mesa packaging still around?
<Sarvatt> we might end up shipping 2.9 branch with lucid because of the the dropped UMS support and the fact we're stuck with an old kernel, just looking at things that might be relevant
<Sarvatt> whats up geser?
<geser> libgl1-mesa-swx11 doesn't have it's own ld.so.conf snippet which makes that libGl.so.1 from that package doesn't get found
<geser> and as it is a valid alternative for libgl1-mesa-glx it makes all packages using libGL.so.1 not find it
<geser> my guess is that libgl1-mesa-swx11 should also have a ld.so.conf snippet like libgl1-mesa-glx
<Sarvatt> eww
<randomaction> I can confirm that replacing "libgl1-mesa-swx11-dev | libgl-dev" with "libgl1-mesa-dev" in build-deps fixes this FTBFS: http://people.ubuntuwire.org/~lucas/ubuntu-nbs/32/rss-glx_0.9.0-2ubuntu3_llucid32.buildlog
<Sarvatt> hmm shouldn't libgl1-mesa-swx11 conflict with libgl1-mesa-glx?
<geser> it does (indirectly about conflicting with libgl1 which libgl1-mesa-glx provides)
<geser> but when libgl1-mesa-glx get removed also the ld.so.conf snippet gets removed which allows libGL.so.1 in /usr/lib/mesa to get found
<Sarvatt> if we had libGL.so.1 in /usr/lib we wouldn't need an alternative installed with mesa would we? asking because I know how we can move libGL back to /usr/lib
<jcristau> i think you'd need an alternative that said "don't use fglrx or nvidia"
<geser> libGL.so.1 was in /usr/lib but got moved to /usr/lib/mesa (don't know the details)
<geser> I guess I've to wait for tseliot
<Sarvatt> geser: yeah, just trying to work out how we could get around moving libGL at all which is causing all these problems
<geser> as far as I know it got moved to fix other problems
<Sarvatt> why would we need an alternative that said dont use fglrx or nvidia though? there would be no alternative at all for it unless nvidia or fglrx was specifically installed
<Sarvatt> it got moved because ldconfig wouldn't let libGL.so.1 from another directory have a higher priority over the one in /usr/lib because of the abi tag in the lib
<geser> as I told, I don't know the details why it moved just that it caused much trouble
<Sarvatt> http://sarvatt.com/downloads/patches/100_no_abi_tag.patch would fix that (on x86 or amd64 at least)
<jcristau> Sarvatt: i thought the plan was to be able to install them all, and choose which one to use dynamically
<Sarvatt> that tag doesnt get added on other arches anyway it looks like
<Sarvatt> hmm good point
<Sarvatt> well the only people that would want to use mesa instead of nvidia or fglrx would be people with nvidia or fglrx installed, maybe those packages could install the mesa alternatives too at lower priority? dunno
<Sarvatt> i just dont like not being able to install packages from nvidia.com directly anymore since the alternatives were added to mesa :D and we keep having problems pop up with the mesa libGL being moved
<Sarvatt> i guess adding a         echo "/usr/lib/mesa" \
<Sarvatt>         > $(CURDIR)/debian/libgl1-mesa-swx11/usr/lib/mesa/ld.so.conf
<Sarvatt> to the rules should work?
<Sarvatt> and adding the prerm and postinst to libgl1-mesa-swx11
<jcristau> i guess
<geser> the same that was done to -glx to setup the alternatives needs to be repeated for -swx11 too
<tjaalton> better to fix the loading order and move the libs back to where they belong?
<bjsnider> has somebody got nvidia-current installed here?
<Sarvatt> yep
<bjsnider> can you check for the existence of this link: /usr/lib/libvdpau_nvidia.so
<bdmurray> bryceh: do you have process for bugs with patches like bug 402260?
<ubottu> Launchpad bug 402260 in xorg-server "segfault when running Xdmx" [Undecided,Confirmed] https://launchpad.net/bugs/402260
<bryceh> bdmurray, yes
<bryceh> bdmurray, generally the steps I follow are first to look at each patch and see whether it is a patch from upstream, or one that the user created, or one that they just picked randomly from elsewhere in the internet
<bryceh> in the latter two cases I *usually* ask that they get the patch accepted upstream first, or at least run it by them.
<bryceh> Sometimes I will go ahead and post it upstream for them, if I'm in a good mood.
<BUGabundo> evening o/
<bryceh> (or if it looks important)
<bdmurray> I'm trying to figure out how x packages will fit in the ubuntu-reviews team workflow...
<bryceh> bdmurray, for ones which are pulls from upstream, the next step is to see if it applies to our tree.  Often the upstream patches are against upstream git trees and so don't apply.
<jcristau> xdmx is fixed in 1.7 afaik
<jcristau> ah the guy nominated it for karmic
<Sarvatt> bjsnider: lrwxrwxrwx 1 root root   36 2010-02-11 20:24 /usr/lib/libvdpau_nvidia.so -> /etc/alternatives/libvdpau_nvidia.so
<bryceh> bdmurray, if they don't apply, then it is a choice between a) wait until we update (in which case I just put "[Needs 1.2.3]" in the subject, b) backport the patch myself, or c) leave it for someone else to look at
<bjsnider> Sarvatt, and does the so.1 link also exist?
<bryceh> bdmurray, along with all the above, it is also important to see if people have actually tested the patch.  Often I see people will post patches that they *think* fix the issue because upstream told them so, but they're afraid of patching/building the X component themselves, so are sort of hoping someone else will do that bit for them.
<bryceh> sometimes I do this; this is why I have so many ppas ;-)
<bryceh> these days I find I haven't so much time to do this for people though
<bryceh> bdmurray, anyway take from the above what you may
<Sarvatt> should I commit this to the ubuntu branch of mesa git? http://sarvatt.com/downloads/patches/0001-Add-100_no_abi_tag.patch.patch
<Sarvatt> bjsnider: http://pastebin.com/f51587796
<bryceh> bdmurray, does that answer your question or is it TMI?
<bryceh> hi rickspencer3
<rickspencer3> hiya bryceh
<rickspencer3> apport?
<bryceh> rickspencer3, btw I'm confused about when we have that call with alice? 
<bryceh> apport?
<rickspencer3> did she send an invite?
<rickspencer3> she said she would schedule it
<bryceh> rickspencer3, yes but it was for yesterday
<rickspencer3> lol
<bdmurray> bryceh: it was a bit too much TMI.  The reviews team is more of a sorting / assigning team.  We'd assign bugs with patches to the main reviews team or universe or upload the patch our selves.  But since you have a fairly detailed process what should we do with them?
<rickspencer3> well, I can only assume that was a Friday afternoon mistake for her
<bryceh> rickspencer3, try again tuesday?
<rickspencer3> bryceh, sure
<bryceh> bdmurray, maybe you should explain what you do for non-x patches, and we can see if there is a good overlap
<bjsnider> Sarvatt, i don't understand why a .so.1 version isn't also there, but thanks
<bryceh> rickspencer3, maybe right after the team meeting so it's not too late london time for her?
<rickspencer3> bryceh, sure
<rickspencer3> I don't actually see an invite from her
<rickspencer3> could you just bounce it back and ask her to try again?
<bryceh> sure
<bryceh> rickspencer3, is it cool if we use your conference line for this?
<rickspencer3> sure
<Sarvatt> tjaalton: how does this look for libgl1-mesa-swx11 alternatives? http://sarvatt.com/downloads/patches/0001-Install-alternatives-for-libgl1-mesa-swx11-as-well.patch
<bryceh> rickspencer3, ok email sent, you're cc'd.  9:30am Tuesday, your conf call line
<rickspencer3> okee dokee
<bryceh> Sarvatt, sorry, in the middle of reviewing your patch, one sec
<tjaalton> Sarvatt: tbh I haven't given much thought on our current mesa, and I've been up too long to think straight ;)
<bryceh> Sarvatt, one question, would it not be sufficient to simply undefine GLX_USE_TLS via configure or something?
<jcristau> it would work too, but it would be a completely different fix
<Sarvatt> nah alot of other changes are done for GLX_USE_TLS in there, undefining it would stop using TLS at all
<Sarvatt> could just stop passing --enable-glx-tls to disable it completely
<Sarvatt> which would fix https://launchpad.net/bugs/259219 but thats way over my head
<ubottu> Ubuntu bug 259219 in mesa "Broken TLS support in libGL.so" [Undecided,Confirmed]
<tjaalton> tls should improve performance
<Sarvatt> debian/ubuntu seem to be the only people enabling it, fedora gentoo and mandriva when I looked
<Sarvatt> *dont
<tjaalton> because of selinux?
<tjaalton> fedora at least
<Sarvatt> nevermind gentoo does, i'm blind - $(use_enable nptl glx-tls) \
#ubuntu-x 2010-02-13
<kklimonda> hmm.. is the fact that I have to add resume=/dev/sdXY to resume from hibernation related to nouveau in any way?
<kklimonda> I have never really had a working hibernation before so I don't know where to look :)
<bjsnider> RAOF, what's going on upstream in gstreamer? do they have mkv support and va-api and all that?
<RAOF> bjsnider: They've had a matroska demuxer forever; it's been working whenever I've tried it.
<hyperair> kklimonda: no it means that your /etc/initramfs-tools/conf.d/resume is outdated.
 * hyperair wonders if there's a PPA for nouveau for karmic
<jcristau> you'd need new X and new kernel.  might as well upgrade everything :p
<kklimonda> hyperair, but it's not
<hyperair> kklimonda: well that's weird then.
<kklimonda> Sarvatt, I just had to REISUB my laptop - the only thing I can find in logs that may be relevant is http://pastebin.com/m49bb99cf
<Sarvatt> sheesh you're too quick jcristau, went looking through bug reports to see if we needed to backport http://cgit.freedesktop.org/pixman/commit/?id=cf1f034fef34478c528bedf1e59be443fa72429c but you did the same thing on 23 Aug 2009
<jcristau> Sarvatt: that code was too ugly to live :)
<jcristau> Sarvatt: i pointed it out to them in http://lists.x.org/pipermail/xorg-devel/2009-May/000899.html btw..
<Sarvatt> ubuntu arm would have been all kinds of screwed up without your fix since (most of?) the reference platforms have neon disabled
<jcristau> heh
<libv> jcristau: "might as well upgrade everything", exactly what's wrong with graphics drivers today
<jcristau> hehe
<jcristau> i'm not disagreeing
<libv> i know ;)
<libv> but sometimes i feel like preaching to the choir :)
<libv> better than having the bullshit card pulled on you every five seconds :)
<Sarvatt> http://paste.ubuntu.com/375749/
<Sarvatt> crash pressing enter the first time after booting i'm randomly getting now
<jcristau> sigquit?
<Sarvatt> doesn't seem to happen with splash disabled
<libv> hey, what do you know, the mesa 7.7 dep of libdrm >= 2.4.15 is purely a driver thing. building real nicely with 2.4.1
 * libv heads for a debian stable now
<jcristau> yeah it's all intel and drm things
<jcristau> *intel and radeon
<libv> i seem to have a similar thing for dri2proto
<libv> lie in the autoconf, and libmesa.a is all happy
<libv> but suggest that maybe splitting up libdrm into libdrm and driver specific parts and tracking them differently, and lo and behold the amount of crap you get thrown at you
<libv> ye-es, 2.3.1 is just as fine.
<libv> and 2.3.0
<libv> just like the xserver
#ubuntu-x 2010-02-14
<bjsnider> a lot of the upstream debian packages i'm seeing are set up in an unusual way. there's a debian/source/format file containing this: "3.0 (quilt)". pbuilder is ok with it, but the ppa build system rejects it.
<superm1> I think that will only start working with lucid
<bjsnider> i don't see h ow it's an improvement though. why is creating a new directory and file better than putting that info into the rules file?
<kklimonda> bjsnider, this is a so called new source format and there are apparently good reasons to use it..
<kklimonda> I just can't find them and it made my life harder ;)
<bjsnider> good reasons are there?
<superm1> bjsnider, http://people.debian.org/~hertzog/dpkg-source.html
<superm1> there's a section there that explains what makes v3 cool
<Sarvatt> hmm regarding the sigquit getting sent pressing enter - http://www.mail-archive.com/xorg@lists.freedesktop.org/msg07800.html
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=22679
<ubottu> Freedesktop bug 22679 in Server/general "Xorg sporatically crashes during first session after boot running compiz" [Normal,New]
<Sarvatt> 4 boots without compiz and it hasn't happened, hmm
<Sarvatt> doesnt seem to happen when i disable splash and X starts on VT1 either
<Sarvatt> ..and just happened first boot with compiz+splash with X on VT7
 * Sarvatt blames the input stuff added to plymouth recently for now
<kklimonda> is it going to be possible to switch between nouveau and nvidia driver using jockey?
<Sarvatt> kklimonda: yeah I imagine so, once its all in just disabling nvidia will drop you back to nouveau
<BUGabundo> Sarvatt: when VirtualBox fails to set a proper guest resolution for window screen size, is it a bug in VB, the X driver, or screen detection ?
<jadams> I'm having some problems booting the lucid alpha (both my in-place upgrade and the livecd...to get the livecd to boot I have to add the safe graphics mode)
<jadams> here are my Xorg.0.log from the last attempt - I'm using nouveau now, had the same problem with nvidia
<jadams> http://gist.github.com/304115
<BUGabundo> Sarvatt: kklimonda: ^^^
<kklimonda> BUGabundo, I have no idea :)
<Sarvatt> jadams: you dont have xserver-xorg-video-nouveau installed and you're using xserver-xorg-video-nv
<Sarvatt> plus you're booting the karmic kernel
<Sarvatt> it only works with 2.6.32-13 right now
<BUGabundo> thanks Sarvatt
<paran> will nvidia-glx be updated to 190 in lucid?
<BUGabundo> isn't it already there?
<bjsnider> paran, the 190.53 driver is in lucid, it is called "nvidia-current"
<paran> hm, seems you are correct. The package nvidia-glx-185 in lucid is at version 190.53
<paran> thanks :)
<bjsnider> that is a transitional package
<superm1> i'm still not keen on us needing to have transitional packages like that
<superm1> but they're functional i suppose
<bjsnider> they get 'er done
<paran> The reason I missed it was that I only looked for a nvidia-glx-190 package
<bjsnider> the changes to the driver are more than just in the name
<bjsnider> completely new set of packaging scripts
#ubuntu-x 2011-02-07
<Q-FUNK> RAOF: actually, the fix for geode's ZTV module is a lot simpler than that: we simply need to stop including "linux/videodev.h" and that's it.  our driver is already V4L2. :)
<RAOF> Q-FUNK: Heh, ok.
<RAOF> I admit, I didn't look any further than âooh, V4L1.  No-one will miss it if I just disable itâ :)
<RAOF> Anyone feel like sponsoring a final round of rebuilds for the X server?
<tjaalton> RAOF: sure
<RAOF> tjaalton: http://cooperteam.net/Packages
<RAOF> Thanks.
<tjaalton> RAOF: yeah, uploaded
<RAOF> Ta.
<apw> if one has nvidia h/w one does not get 3c in nouveau, is there a recipe for getting the gallium drivers for that ?  (and do they indeed sort that out)
<tjaalton> 3d, yes, install libgl1-mesa-dri-experimental (or such, don't have the package name handy)
<tjaalton> apw: ^
<apw> tjaalton, thanks
<apw> tjaalton, actually jockey offered that to me, and installed it, but it doesn't seem to work at all
<tjaalton> apw: breaks stuff? which card do you have?
<apw> tjaalton, no breakage, just classic desktop and unity saying 'software renderer in use'
<apw> 05:00.0 VGA compatible controller: nVidia Corporation GF100 [GeForce GTX 480] (rev a3)
<apw> apparently
<tjaalton> hmm, wonder if it's too new
<apw> tjaalton, could well be ... such is life
<tjaalton> Xorg.0.log should tell
<tjaalton> kms works though?
<apw> yeah it switches into high res i recon
<tjaalton> k
<apw> nouveau is kms only right ?
<jcristau> yes
<apw> [    27.543] (--) NOUVEAU(0): Chipset: "NVIDIA NVc0"
<tjaalton> ok, but does it load the DRI2 driver?
<tjaalton> or even attempt that
<apw> [    27.426] (II) Loading extension DRI2
<apw> nothing to say if it worked or not
<tjaalton> put the full log on pastebin
 * apw should warn that this is a very new machine and quite possibly has stupidly new h/w
<apw> the kernel won't even boot the secondary cpus, not that that should matter
<apw> pastebinit Xorg.0.log
<apw> http://paste.ubuntu.com/563843/
<tjaalton> thanks
<tjaalton> [    28.528] (EE) NOUVEAU(0): Error initialising acceleration.  Falling back to NoAccel
<tjaalton> guess that's it then
<tjaalton> and the line above
<tjaalton> apw: the gallium driver for nvc0 was merged upstream on nov 12th, dunno if it's in 7.10 or not
<apw> ah ... very very fresh then
<jcristau> tjaalton: afaict it's not
<tjaalton> jcristau: yep, latest commit from october
 * apw will have to purchase an older one then and ram that in instead
<tjaalton> apw: xorg-edgers might have a newer mesa for you :)
<tjaalton> yep
<apw> how well does X cope with two cards inserted, different manufactueres,  i'd be happy selecting one or other in some way; making a dual card test setup
<jcristau> it sometimes work.
<apw> jcristau, sounds like something to avoid then
<marjo> apw, bryceh: FYI, I just submitted # 693093
<marjo> apw: thx
<apw> bug #693093
<ubot4> Launchpad bug 693093 in linux (Ubuntu) (and 1 other project) "[i945gme] 2.6.37-10.24: Black Screen on Boot (affects: 10) (heat: 136)" [High,Confirmed] https://launchpad.net/bugs/693093
<apw> marjo, thats an old bug ...
<marjo> apw: sorry
<marjo> apw, bryceh: # 714635
<marjo> apw, bryceh: #714635
<tjaalton> bug 714635
<ubot4> Launchpad bug 714635 in linux (Ubuntu) "[i945gme] 2.6.38-2: Black screen on boot (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/714635
<apw> marjo, did you get the intel_reg_dumper outptu ?
<marjo> apw: yes, attached it already
<apw> marjo, to the right bug ?
<apw> marjo, oh its mixed in with the apport stuff, didn't know you could do that
<apw> marjo, we probally should get the Xorg.log.0 onto that bug as well
<marjo> apw: done
<apw> tjaalton, i'd say that that X startup has gotten stuck, HW cursor is not the last thing one sees on my boxes
<tjaalton> apw: yeah
<apw> marjo, i wonder if you are able to try an strace on the Xorg process once it is stuck
<apw> to find out whether it thinks it is in the kernel
<marjo> apw: sure, can you please give me specific directions?
<apw> ps -ef | grep /X
<apw> take the pid from that ... second column
<tjaalton> could also try with 'Option "HWCursor" "off"'
<marjo> apw: next?
<apw> you wait while i recover the machine i tried the command out on (stupidly) from within X, no no no, supid
<tjaalton> :)
<apw> yeah i know, /me takes the dunce of the day hat and puts it on
<tjaalton> need to run, back in 3,5h
<apw> ok ... back.  
<apw> marjo, ok this should do the trick: sudo strace -p `pidof X`
<apw> and see what that says
<apw> not something one should run in an xterm, no not a good idea
<marjo> apw: "attach: ptrace(PTRACE_ATTACH, ...): No such process"
<marjo> apw: i'm doing this through ssh
<apw> ps -ef  | grep X
<apw> whats the output of that look like
<apw> marjo, ^^
<marjo> 1000      1298  1181  0 10:57 pts/0    00:00:00 grep --color=auto X
<apw> so you have no X running at all then
<marjo> apw: ack
<apw> add that info to the bug, i would not not expect X to exit without telling us why it did so
<apw> bryceh, ever heard of that ^^
<jcristau> can happen if it aborts e.g. because of a missing symbol
<jcristau> would show up in gdm log
<marjo> apw: what's weird is I can go into recovery mode/low graphics mode
<apw> marjo, could we have the gdm log as well please
<marjo> apw: will do in a few minutest, ok?
<marjo> minutes, ok?
<apw> no rush
<marjo> apw: thx
<marjo> apw: i see a few *.log and -slave.log files
<marjo> apw: any specific one to upload to bug report?
<apw> marjo, probabally :0.log
<marjo> apw:ok, will do
<marjo> apw: :0.log attached to bug #714635
<ubot4> Launchpad bug 714635 in linux (Ubuntu) "[i945gme] 2.6.38-2: Black screen on boot _after_ visible splash (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/714635
<jcristau> win.
<jcristau> /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: intel_batch_wait_last
<jcristau> marjo: sounds like you have an obsolete version of the driver
<marjo> jcristau: which driver?
<jcristau> the one that's missing a symbol
<jcristau> the xserver-xorg-video-intel package
<marjo> jcristau: when you say obsolete, do you mean that i don't have an updated one? or is there a new one that i did NOT pick up?
<jcristau> i mean that bug was fixed in 2:2.14.0-1ubuntu2
<marjo> jcristau: installed  xserver-xorg-video-intel and now things are working!
<marjo> jcristau, apw: thx much!
<apw> marjo, yay ...
<apw> jcristau, thanks for the help getting to the right log :)
<jcristau> np
<marjo> jcristau: was there a previous bug I can refer to in my bug report?
<jcristau> none mentioned in the changelog afaict, so no idea
<marjo> jcristau: that's too bad
<marjo> so i'll just say fixed with  xserver-xorg-video-intel 2:2.14.0-1ubuntu2, right?
<marjo> so i'll just say fixed with  xserver-xorg-video-intel 2:2.14.0-1ubuntu6, right?
<bryceh> marjo, yes fixed with  xserver-xorg-video-intel 2:2.14.0-1ubuntu2
<bryceh> marjo, that was an obvious issue we caught right away; we simply hadn't caught it before uploading due to insufficient testing
<RAOF> Mornin all.
<jcristau> heya RAOF 
<RAOF> jcristau: Good $TIME_OF_DAY :)
<jcristau> :)
<RAOF> Hm.  apw has an nvc0 card?  Congratulations for volunteering to test the acceleration we may or may not merge in for those cards!
<jcristau> it's a wheezy evening.
<RAOF> I presume wheezy is currently in a mad state of flux?
<jcristau> yeah
<jcristau> sid got libreoffice today
<jcristau> probably new compiler and libc soon..
<RAOF> Any coordination with our libreoffice maintainer?
<jcristau> aiui your libreoffice packages were based on the ones in experimental
<RAOF> Heh.  Now sid's unfrozen I'll need an actual sid chroot for testing rather than everything going through the experimental one.  Let's see if it's debootstrappable!
<apw> RAOF, seems so ... its scheduled for an unscrewing and shoving in a box shortly for replacement with something supported, but happy to test
<RAOF> apw: How well did it work (3D excepted) while it was in there?
<RAOF> Did you notice that there was no 2D acceleration, for example :)
<apw> RAOF, its still in there, runs in 2D well enough
<apw> heh no, but the machine has a lot of CPU :)
<RAOF> I suspect that correlates well with brand new GPUs :)
<apw> RAOF, but if you have some test bits in a bucket somewhere please point me at it
<RAOF> xorg-edgers has the test bits.
<LLStarks> does ubuntu-x have a dedicated triage team like the the ubuntu mozilla squad?
<apw> RAOF, ahh ok will try and get those one it, when i've bought something that it can drive other than the 37in tv in the front room
<RAOF> No.  We've got bryceh and his amazing band of arsenal scripts, though.
<RAOF> apw: Yeah, no hurry.  I'm not in a great rush to grab new libdrm, nouveau packages to speed up but possibly break new cards.
<LLStarks> because i've been thinking about joining the ubuntu-x-swat team and i'm not sure if i have enough credentials
<tjaalton> or quota for your inbox ;)
<tjaalton> meh, wanted to try alpha2 & nouveau, but the dvd-drive seems broken
<RAOF> LLStarks: You're welcome to start triaging, although we're actually pretty on top of it at the moment.
<RAOF> What do you want to do in the swat team?
<LLStarks> be mindful of my hardware and continue giving good reports regarding how stable and unstable bits affect said hardware
<LLStarks> i know a little c, but i am not well-versed in the graphics stack to do any coding
<RAOF> That can change :)
<RAOF> A good way to learn how to give good reports is to look at what happens when bugs get upstreamed - what questions get asked, etc.
<RAOF> Also, if you want to invest a little time then bisecting regressions is an excellent way to help get them fixed, and can get you a little familiarity with the build process.
<LLStarks> i've been bisecting -intel as needed, getting proper kernel drm bits is more of a pain for me
<RAOF> Yeah, that's quite awkward.
<LLStarks> i've been looking for a good jumping in point for learning about the stack. drm, glx, xserver, etc
<jcristau> usually a jumping in point is a bug that annoys you so much that you fix it.
<LLStarks> had that the other day with libswscale. feels good man.
<RAOF> The stack is actually a lot less complex than it looks from the outside.
<bryceh> heya RAOF
<RAOF> bryceh: Good evening.  Or afternoon.
<RAOF> Or whenever!
<tjaalton> ok, alpha2 boots fine with a working media, but compiz fails after installing the nouveau gallium driver
<tjaalton> compiz: nv50_pc_emit.c:863: emit_flop: Assertion `STYPE(i, 0) == 0x09' failed.
<tjaalton> crashes there
<tjaalton> and the livecd still offers to install the blob
<tjaalton> thought it was disabled for now
<RAOF> :(
<RAOF> Yeah, so did I.
<RAOF> Oh, actually - Jockey doesn't know about server ABIs.
<tjaalton> right
<RAOF> But I thought we *were* disabling it on the livecd.
<tjaalton> and actually, talked with pitti about it and he
<tjaalton> damn us layout
<tjaalton> anyway pitti said he would add that support once the drivers itself had all the deps/breaks in place
<tjaalton> the blobs, that is
<RAOF> Ah, good.
<tjaalton> RAOF: is mesa 7.10+git possible for natty?
<tjaalton> will try edgers tomorrow to see if compiz works with it
<RAOF> We can certainly try.  We'll pull in 7.10.1.
<tjaalton> sure, and this crasher is something that should be .1 material anyway
<jcristau> assuming you trust the nouveau people to care about stable branches
<tjaalton> hehe
<tjaalton> anyway, 2D is very snappy on my 8600GT
<RAOF> Well, if we can identify the fix, applying it hopefully won't be *too* hard.
<RAOF> Yeah.  Nouveau's 2D is excellent.
<tjaalton> maybe ill just upgrade it lucid->natty anyway, compiz aint _that_ important
<tjaalton> but tomorrow
<RAOF> I think you might find that compiz will work as long as you're not loading unity.
<tjaalton> oh, hmm
<tjaalton> k, will play with it in the morning
<tjaalton> night! ->
#ubuntu-x 2011-02-08
<LLStarks> re bug 714719, no lockups on 945gm, so the problem shouldn't reside in shared code
<ubot4> Launchpad bug 714719 in xserver-xorg-video-intel (Ubuntu) (and 2 other projects) "[i915gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000004) (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/714719
<tjaalton> duh, some sort of dependency loop prevents upgrade to maverick
<tjaalton> between nouveau and libdrm
<tjaalton> weird
<tjaalton> had to remove nouveau and video-all
<RAOF> tjaalton: Upgrade to maverick, or from maverick to natty?
<tjaalton> RAOF: to maverick
<tjaalton> from lucid
<RAOF> Weird.  I would have thought there would have been much complaining about that.  Perhaps you've hit an uncommon case?
<tjaalton> no idea, they both are the lucid versions
<mvo> good moring! I used to be able to write Identifier "trackpoint"\nMatchIsPointer "on"\nOption "Emulate3Buttons" "on" (in the inputclass section). but with the recent xorg upgrade that does no longer seem to work after resume - worth a bugreport?
<tjaalton> mvo: probably so.. 
 * bryceh waves to RAOF, tjaalton, mvo
<tjaalton> hey
<RAOF> Aloha!
<bryceh> RAOF, btw just now noticed we're getting a lot of auto-dupes of bug #712785.  Might be something interesting going on there (haven't looked at the bug at all)
<ubot4> bryceh: Bug 712785 on http://launchpad.net/bugs/712785 is private
<mvo> thanks tjaalton
<tjaalton> upgrade to maverick almost done, then reboot to check that it works, and then to natty alpha2
 * mvo waves back to bryceh
 * bryceh unprivates
<bryceh> ahem, bug #712785
<ubot4> Launchpad bug 712785 in xorg-server (Ubuntu) "Xorg assert failure: *** glibc detected *** /usr/bin/X: corrupted double-linked list: 0x0a435968 *** (affects: 9) (dups: 8) (heat: 74)" [Medium,New] https://launchpad.net/bugs/712785
<tjaalton> mvo: btw, I had a weird conflict on upgrade from lucid->maverick, caused by nouveau and libdrm. solved it by removing x-x-v-nouveau, and all the logs should be on the disk if you're interested
<mvo> tjaalton: please mail them to me, can't hurt to check them
<bryceh> bug #711422 looks like a variant with it's own collection of dupes
<ubot4> Launchpad bug 711422 in xorg-server (Ubuntu) (and 1 other project) "Xorg assert failure: X: double free or corruption (!prev): 0x089f5b20 *** (affects: 13) (dups: 12) (heat: 106)" [High,Triaged] https://launchpad.net/bugs/711422
<tjaalton> mvo: ok, will do, after lunch :)
<tjaalton> though it's really weird that it happened
<RAOF> Ah, hello GLX resource tracking.  How much fun are you!
<RAOF> Yeah, we should investigate and fix/send upstream.
<bryceh> RAOF, can you try to reproduce it?  I tried but I haven't seen it at all on my own hardware.
<bryceh> RAOF, if not, then yeah maybe bumping it upstream is the right next step
<RAOF> bryceh: Yeah, I don't think I've reproduced it.
<RAOF> Or maybe I have - it's probably another one of those on-shutdown crashes.
<mvo> tjaalton: sure, no rush
<RAOF> Hm, no, some people seem to have that bug kill their sessions.
<jcristau> you need to play more 3d games
<jcristau> for work.
<RAOF> Time to fire up Civ Vâ¦ FOR SCIENCE!
<bryceh> RAOF, I sent half of the gpu lockup bug reports upstream today.  The other half seemed less common; I'll send them up once we get some action on the first half.  That double free bug looks worth a bit more study before sending it upstream.
<RAOF> I've got a patch series in mind to investigate there.
<bryceh> RAOF, you rock.  :-)  Ok, bedtime for me, cya tomorrow.
<RAOF> Catch you!
<tjaalton> upgrade to natty complete, still no compiz on nouveau, unity or not
<tjaalton> I'll start digging if it might be fixed somewhere already
<mvo> I have no copiz on nouveau too (fwiw). the unity checker claims I should be able to run it though
<mvo> but no texture_from_pixmap iirc
<tjaalton> i get the same error as on bug 710588
<ubot4> Launchpad bug 710588 in mesa (Ubuntu) (and 1 other project) "compiz assert failure: compiz: nv50_pc_emit.c:863: emit_flop: Assertion `STYPE(i, 0) == 0x09' failed. (affects: 16) (dups: 5) (heat: 100)" [Medium,Confirmed] https://launchpad.net/bugs/710588
<tjaalton> I'll try mesa from edgers next
<tjaalton> still the same
<tjaalton> even with libdrm/nouveau etc from there
<tjaalton> oh well, best to get a proper backtrace and see what to make of it
<apw> tjaalton, for that nv0 or whatever it was, i added xorg-edgers and dist-upgraded, is that sufficient to get support?
<tjaalton> apw: I think so yes
<tjaalton> nvc0
<apw> hrm, then i think it doesn't work
<tjaalton> duh
<apw> tjaalton, it is still saying 'sw renderer' ... am fully rebooting to be sure
<tjaalton> check for the (EE) lines of the logfile
<tjaalton> see if they are the same
<tjaalton> or something else
<tjaalton> though could be that the kernel drm from .38 isn't enough
<apw> yeah says the same 'Erorr creating GPU channel: -19
<tjaalton> ok, then maybe the drm code isn't fully baked yet
<tjaalton> though 2d works
<apw> yeah 2d is passable indeed, shame though
<apw> i assume the official soln is binary drivers for these
<tjaalton> actually, you might be missing the firmware
<tjaalton> suggested on #dri-devel
<tjaalton> though I've no idea where those are
<apw> ahh yes, it says failed to load fuc409d
<apw> which is ammusing to read
<tjaalton> "extract it from a blob trace"
<tjaalton> they'll write a free one later
<apw> do what?
<tjaalton> dunno :)
<apw> that sounds like running windows or something
<tjaalton> no just the blob
<tjaalton> I think
<apw> oh i see
<apw> hmmm
<tjaalton> ok, so compiz on nouveau works after all..
<tjaalton> after I figured out that the profile had to be changed to default
<tjaalton> tomorrow I'll try if unity works without the assert
<jaytaoko> bryceh: ping
<bryceh> hi jaytaoko
<jaytaoko> bryceh: hello
<jaytaoko> bryceh: I was wondering if the fglrx can be installed right now and work with the latest release of XOrg 1.10
<bryceh> jaytaoko, I wouldn't think so, unless amd has a new one for private testing available
<jaytaoko> bryceh: I was told that it wouldn't be released before march... Just checking with you about it
<bryceh> jaytaoko, yeah sorry, I'm fairly sure the options are either run -ati or downgrade xserver (and/or kernel)
<bryceh> jaytaoko, the updated driver will first be available via their internal testing program, but I think you're already subscribed to that?
<jaytaoko> bryceh: yes, I am
<bryceh> jaytaoko, ok yeah then keep an eye there for a fixed up driver
<jaytaoko> bryceh: ok, I will... In the mean time, I wonder how they are going to help us solve Unity on fglrx
<jaytaoko> bryceh: but, we have identified a few places that could help us resolve the issue...
<jaytaoko> bryceh: I will talk to them about it
<bryceh> jaytaoko, not to sound heartless but this sort of sounds like a problem of their own making ;-)
<jaytaoko> bryceh: yes, they knew XOrg 1.10 was coming
<bryceh> again though, they could use a snapshot of ubuntu from prior to the xserver and kernel bumps if they need to do the dev work against older versions, or they could manually downgrade X and the kernel on a current snapshot if they prefer
<bryceh> or they could do the development using their development drivers that do support 1.10
<bryceh> seems like they have many more options than we do... ;-)
<bryceh> well, at least one more
<jaytaoko> bryceh: in the meantime, we can work on the opensource driver and fix the issues that are there... 
<bryceh> sounds good
<bryceh> jaytaoko, are you aware of issues with unity and -ati?
<bryceh> I've mostly been focusing on -intel since the updates; it's the one with all the bug reports
<jaytaoko> bryceh: yes, there are some bugs such as random screens bugs.. things that you see only on the ati driver
<jaytaoko> bryceh: you don't get them on nvidia or intel...
<jaytaoko> bryceh: it looks more like low level driver issues
<bryceh> jaytaoko, ok, point me to bugs that look like driver issues; I should get those upstream asap
<jaytaoko> bryceh: I am searching in the bug list
<jaytaoko> bryceh: https://bugs.launchpad.net/unity/+bug/684992
<ubot4> Launchpad bug 684992 in unity (Ubuntu) (and 1 other project) "Artefact in launcher tooltip and icons (affects: 4) (dups: 2) (heat: 64)" [Medium,Triaged]
<jaytaoko> bryceh: I am still getting this one
<bryceh> ok
<jaytaoko> bryceh: it is random, and only happens with the ati radeon driver. Never saw it on other GPUs
<bryceh> jaytaoko, yeah rendering artifacts like that are sort of a distinguishing characteristic of -ati ;-)
<bryceh> I'll forward it upstream.  I recall them discussing a rendering fix patch recently, perhaps they have something we can test
<jaytaoko> bryceh: thanks... I knew there was nothing in our rendering that could cause something like that... glad that you confirms it!
<bryceh> jaytaoko, yeah so if you can post X logs to the bug I'll forward it upstream today
<jaytaoko> bryceh: alright
<seb128> bryceh, hey
<seb128> bryceh, just for info debian landed a cairo build with the gl backend enabled and I did merge that in natty
<bryceh> seb128, oh, finally
<bryceh> seb128, yeah I know while I was blocked that debian has been working on getting wayland in themselves
<seb128> bryceh, yeah sorry about the delay
<seb128> bryceh, but didn't you work in ppa for it?
<bryceh> seb128, yes
<seb128> ok, so "blocked" was for landing in the official archive only
<bryceh> seb128, but I couldn't upload the packages to natty until the dependency was available
<seb128> anyway it's done now
<seb128> sorry about the delay again
<seb128> bryceh, right, but is there any interest to have wayland in the distro? like is it usuable for anything else than testing (which could be done in the ppa as well)?
<bryceh> seb128, I think I saw one blog post from someone interested in having wayland in the distro ;-)
<seb128> :-)
<bryceh> but no it won't be usable until GNOME or other window managers support it
<seb128> bryceh, right, I'm just saying why it was not on top of my todo but no point arguing over upload delay since that's over and uploaded
<bryceh> so the motivation for getting it in is to make life easier for those folks that will be doing that development work
<seb128> sorry if that blocked other tasks for you
<bryceh> ok, yeah I've had enough other stuff to keep me busy, and you're right it seems few actual people have interest in wayland
<bryceh> hopefully I'm not wasting my time, although probably I am ;-)
<bryceh> seb128, anyway thanks for letting me know; I was going to ask about that.  Glad to have it done and I can wrap up work on this stuff.
<tjaalton> meh, so nouveau dri2 is crashing, but the backtrace is useless even though I have all (?) the dbg-packages
<tjaalton> http://pastebin.com/fVnw771q
<tjaalton> wat
<tjaalton> has the X wrapper changed... there is no Xorg process anymore
<bryceh> look for an 'X' process
<tjaalton> yes, but the path for Xorg
<tjaalton> now we got something :)
<tjaalton> http://pastebin.com/HB6PN3bc
<tjaalton> but no time to debug further atm :)
<jaytaoko> bryceh: How do I generate an X log
<bryceh> tjaalton, hmm, "nouveau_bo_handle_get(nouveau_pixmap(ppix)->bo, &nvbuf->base.name);" has quite a few derefs in there
<bryceh> jaytaoko, how do you mean?  The Xorg.0.log should generate automatically from the server
<jaytaoko> bryceh: ok I have it... I though it was something else
<jaytaoko> bryceh: apport-collect won't let me add my system info to  684992
<bryceh> jaytaoko, hrm, what's it say?
<bryceh> jaytaoko, work around just attach your dmesg, /var/log/Xorg.0.log, /etc/X11/xorg.conf (if any), and output of 'lspci -vvnn'
<bryceh> I think that should be enough
<jaytaoko> bryceh: You are not the reporter or subscriber of this problem report, or the report is a duplicate or already closed. Please create a new report using "apport-bug".
<bryceh> ohh
<bryceh> jaytaoko, ok that makes sense
<bryceh> jaytaoko, you could file a new bug using 'ubuntu-bug xserver-xorg-video-ati' then, and link to it from the original bug
<jaytaoko> bryceh: will do
<bryceh> jaytaoko, also if you can take a photo of the screen corruption you reproduce for comparison, that might be helpful too
<jaytaoko> bryceh: yes, I just took one
<jaytaoko> bryceh: here https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/715405
<ubot4> Launchpad bug 715405 in xserver-xorg-video-ati (Ubuntu) "Graphics artifact in Unity, around the tooltips (dup-of: 684992)" [Undecided,New]
<ubot4> Launchpad bug 684992 in xserver-xorg-video-ati (Ubuntu) (and 2 other projects) "Artefact in launcher tooltip and icons (affects: 5) (dups: 3) (heat: 34)" [Undecided,Incomplete]
<bryceh> jaytaoko, ok upstreamed at https://bugs.freedesktop.org//show_bug.cgi?id=34051
<ubot4> Freedesktop bug 34051 in Driver/Radeon "Graphics artifact in Unity, around the tooltips" [Normal,New]
<jaytaoko> bryceh: great!
<jaytaoko> bryceh: thanks
<bryceh> hopefully we will get a helpful response
<tjaalton> bryceh: ookay
<bryceh> tjaalton, I would set a break in that first routine and inspect the state of the variables
<bryceh> tjaalton, however given that the next call is from -nouveau to libdrm I would wonder if there's abi breakage or something
<tjaalton> bryceh: hmm ok, I could try edgers to see if I can reproduce it
<bryceh> it doesn't look like the function signature in libdrm changed recently though 
<tjaalton> but that's for tomorrow
<bryceh> tjaalton, do you only see the crash when running edgers? 
<tjaalton> the assert with unity should just be removed "and it should be fine"
<tjaalton> bryceh: no this is with stock natty
<bryceh> hm
<tjaalton> looks like my suspend issue should be fixed in .38rc4
<tjaalton> sweet
<bryceh> nice
<bryceh> RAOF, what are your thoughts on the double free bug?
<RAOF> I recall a series of patches on xorg-devel about GLX resource cleanup, one of which was to avoid a double free.
<bryceh> that does sound promising
<bryceh> RAOF, are you able to reproduce the bug locally?
<RAOF> I haven't managed to yet, but it's early in the day :)
<RAOF> I don't think they got applied, or perhaps there's another codepath that needs fixing.
<bryceh> ok, you thinking maybe just roll the patch(s) into a ppa and solicit testers?
<RAOF> Yup.
<bryceh> sounds like a good plan
<RAOF> I'll see whether I can reproduce locally first, and then make that happen.
<bryceh> btw I've accumulated a few random -intel patches I'm going to put in
<bryceh> nothing earth shattering, just odds and ends and minor fixes that look worth including
<RAOF> Cool.
<bryceh> oh there was one bug I was puzzled about the response on, which might make more sense to you
<bryceh> forwarded upstream at https://bugs.freedesktop.org//show_bug.cgi?id=34017
<ubot4> Freedesktop bug 34017 in Driver/intel "[i965gm] GPU lockup during login" [Major,Reopened]
<bryceh> ickle pointed to a commit which is already included in 2.14.0 that the user reported against; am I missing something obvious?
<RAOF> I can't *see* anything obvious there, no.
<bryceh> ok, well I pushed back to ickle maybe he'll flame me more sensibly ;-)
<RAOF> :)
<bryceh> I think we're on the verge of bringing http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg back down.  Looks like we're able to dupe/close/upstream bugs as fast as they're coming in, 
<LLStarks>  /ns identify robert
<RAOF> Time for a new throwaway password!
<LLStarks> yes, i fear the righteous ubuntu-x team stealing my password
<LLStarks> btw, yay dithering
<RAOF> Fonud the problem?
<LLStarks> it's fixed
<LLStarks> in a custom apw kernel
<RAOF> Hurray!
<RAOF> Let's see if I can trigger that double-freeâ¦
<LLStarks> Observations, measurements
<LLStarks> wrong cp
<LLStarks> raof, you mentioned occasional graphical corruption on 945, what bug was that?
<bryceh> bug #710961 ?
<ubot4> Launchpad bug 710961 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack (affects: 3) (heat: 505)" [Undecided,New] https://launchpad.net/bugs/710961
<LLStarks> yeah, seeing that from time to time
<LLStarks> firefox too
<bryceh> RAOF, do you think we should accept i8xx bug reports or just close them and redirect people upstream?
<RAOF> I think close them and point them upstream, for the moment.
<bryceh> e.g. bug #714634 (which looks like a kernel regression in any case)
<ubot4> Launchpad bug 714634 in xserver-xorg-video-intel (Ubuntu) "intel 82852/82855 cannot display login screen (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/714634
<bryceh> alright
<RAOF> That long-awaited hope of the kernel working around those hardware problems is still brewing; maybe in Natty+1 we'll be able to turn things back on :)
<bryceh> bit of an essay, but here's my spiel for 8xx - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/714634/comments/2
<ubot4> Launchpad bug 714634 in linux (Ubuntu) "intel 82852/82855 cannot display login screen (affects: 1) (heat: 6)" [Undecided,Won't fix]
#ubuntu-x 2011-02-09
<RAOF> Seems about right.
<RAOF> Hah, yes.  There it is.
<bryceh> good bye McCreary desktop.  hello sandybridge desktop
<RAOF> Ooooh funky.
<LLStarks> yup, that graphical corruption from bug 710961 can be reliably replicated while scrolling sites in firefox.
<ubot4> Launchpad bug 710961 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack (affects: 4) (heat: 22)" [Undecided,New] https://launchpad.net/bugs/710961
<LLStarks> shut up ubot
<LLStarks> j/k love ya
<RAOF> Ok, that's useful to know.
<tjaalton> mvo: looks like bug 614993 has some people complaining about the same upgrade issue I had yesterday, removing nouveau was the cure
<ubot4> Launchpad bug 614993 in xorg-server (Ubuntu) (and 2 other projects) "10.04 -> 10.10 upgrade fails: pkgProblemResolver::Resolve generated breaks: xserver-xorg-video-v4l demoted to universe (affects: 46) (dups: 11) (heat: 250)" [High,Fix released] https://launchpad.net/bugs/614993
<tjaalton> with logs, even
<mvo> tjaalton: hm, fix released, is the fix incomplete?
<tjaalton> mvo: they hijacked the bug.. :/
<mvo> bÃ¤Ã¤
<tjaalton> :)
<tjaalton> I could open a new one and ask them to join
<mdeslaur> A small Haiku to sum up my feelings this morning:
<mdeslaur> Nouveau drives my card,
<mdeslaur> Makes my graphics open-source.
<mdeslaur> Please stop freezing though!
<tjaalton> yes, likely a kernel bug
<tjaalton> you can try vanilla 2.6.36 and see if that helps :)
<tjaalton> apparently the changes in .37 broke it
<tjaalton> well, causes a hang that I'm seeing
<mdeslaur> tjaalton: and it's still not fixed in .38?
<tjaalton> no
<tjaalton> see fdo bug 33999
<ubot4> Launchpad bug 33999 in kubuntu-meta (Baltix) (and 1 other project) "/dev/ram Alert! does not exist (DVD install) (dup-of: 27539)" [Medium,Invalid] https://launchpad.net/bugs/33999
<ubot4> Launchpad bug 27539 in ubuntu "issue in booting live dvd (dups: 1) (heat: 1)" [Critical,Fix released] https://launchpad.net/bugs/27539
<tjaalton> bah
<tjaalton> freedesktop bug 33999
 * mdeslaur kicks ubot4
<ubot4> Freedesktop bug 33999 in Driver/nouveau "2.6.37 - NV11 crashes X if glxgears started" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=33999
<tjaalton> the same trace with my nv50
<mdeslaur> tjaalton: ah, yes, I get that with libgl1-mesa-dri-experimental installed. But, I don't have it installed right now, and am getting freezes 3-4 times a day.
<tjaalton> mdeslaur: hmm yes, could be related or not
<tjaalton> seen it too
<tseliot> tjaalton: is the kernel in xorg-edgers Natty's kernel?
<Sarvatt> tseliot: yep it is
<tseliot> Sarvatt: ok, thanks
<pwnguin> had a random question from a frustrated user. they want to remove -nouveau but leave other x drivers intact
<pwnguin> why does xserver-xorg-video-all use depends vs recommends?
<RAOF> Because it's not essential itself.
<dandel> I don't know about removing the driver, however, it's easy enough to disable (Blacklist the nouveu module), or boot with the xforcevesa boot option added.
<RAOF> ie: there's no penalty to not having xserver-xorg-video-all installed.
<pwnguin> the complaint is that debian dependencies are too complicated, unlike arch
<pwnguin> so when you go to remove nouveau, it asks to remove -all, and then autoremove everything else
<dandel> hmm... sounds like your request is to lighten the cd load a bit by using vesa or vga driver by default, and then do like what is done with the closed source drivers, and ask if you want the other drivers installed ?
<pwnguin> well, i donno about that. mainly just trying to figure out why this is different than ubuntu-desktop
<RAOF> At least in part because Ubuntu-desktop's Recommends: are user-visible.
<dandel> personally, i think that would be a better option to begin with, actually.
<RAOF> Wheras the user-visible difference between having -nouveau installed or not is ~400KiB of disc space.
<dandel> I have had issues with Ubuntu 10.04 boot because of my video card (not supported by radeon driver) in that release... so it's harder.
<dandel> most end users who are new will grab the lts version, and if it auto-sets things which are not properly supported it can be troublesome... 10.04 kernel does not support rhd5000 or newer cards, but forces radeon driver by default on them anyways.
<RAOF> Well, that's a bug.  The drivers *should* fall back cleanly to vesa when encountering unsupported hardware.
<RAOF> But using vesa on the livecd isn't a good option.
<LLStarks> https://lists.launchpad.net/hybrid-graphics-linux/msg00450.html
<dandel> well, the livecd in 10.04 is useless with rhd5000 (or newer) cards unless you force vesa.
<pwnguin> im just looking at the policy and it's not quite an absolute dependency. i think recommends would be sufficient, and traditional for metapackages, so i was thinking there might have been a reason for it
<LLStarks> if we can turn optimus cards off, i hope we can turn them on.
<dandel> RAOF, the problem with that is the xorg driver does not always know that the device is unsupported, and is blanket enabled on all cards which have the rhd 2000 or higher id set.
<RAOF> pwnguin: It's probably a holdover from when Debian didn't install recommends by default.
<RAOF> dandel: Actually, it's got a list of supported PCIIDs and checks aganist that.  The X server will always try to load radeon on all ati hardware, but the radeon driver will check against its list.
<dandel> RAOF, True, however, what happens when the kernel module does not support the card... which is the case with 10.04 and the rhd5000 series.
<LLStarks> does radeonhd support it?
<dandel> Not in 10.04.
<RAOF> LLStarks: radeonhd doesn't usefully support anything anymore :)
<dandel> i get garbage and system freezes with the open source driver on 10.04.
<RAOF> dandel: In that case, the radeon driver should fall back to its UMS support; if that doesn't work, it's a bug in the driver.  But it's not because it doesn't (in theory) support the card :)
<dandel> Yea, and i can reproduce this bug every time... on livecd and usb (although usb creation for 10.04.1 amd64 is also broken, no boot menu)
#ubuntu-x 2011-02-10
<RAOF> Hm.  It's not *too* hard to do the ForceGallium patch in a potentially-upstreamable way.
<bryceh> heya RAOF
<RAOF> bryceh: Howdie.
<RAOF> bryceh: I commented on fdo bug 34017 by the way, although I haven't really read the code to know whether that's it or not.
<ubot4> Launchpad bug 34017 in linux-restricted-modules-2.6.24 (Ubuntu) "Include nvidia-settings and nvidia-xconfig (heat: 1)" [Wishlist,Fix released] https://launchpad.net/bugs/34017
<bryceh> wow that's an old one
<bryceh> oh fdo
<RAOF> fdo 34017
<RAOF> Understand that, ubot4? :)
<RAOF> The 965 lockup on boot thingy.
<bryceh> hm interesting
<RAOF> I guess I could have ppa'd up some packages for users to test, but Chris is responsive and actually knows what he's talking about :)
<bryceh> what's the typo he's referring to in comment #8?
<RAOF> I presumed it was somethnig to do with the output, but I couldn't spot the typo.
<bryceh> I dunno, he may be responsive but his terse replies are sometimes cryptic and less than helpful
<RAOF> Any comments on https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/715939 ?  If it's what I'm guessing, it's an unavoidable side-effect of our ForceGallium patch, which I could fairly easily re-do in such a way as to not break what their doing.
<ubot4> Launchpad bug 715939 in xserver-xorg-video-ati (Ubuntu) "6.14.0 and 101_select_between_classic_and_gallium_dri.patch doesn't work properly (affects: 1) (heat: 6)" [High,Incomplete]
<RAOF> At the cost of not having an xorg.conf option to switch between gallium/not gallium.
<bryceh> I'm curious if they did a manual install of something
<bryceh> too bad they didn't report the issue via ubuntu-bug
<RAOF> I think they did do a manual install of mesa, or at least are using LIBGL_DRIVERS_PATH.  We *could* say not our problem, don't use ForceGallium + home made stuff.
<bryceh> sounds like they might be playing with builds of upstream code, so yeah could be they got into a weird situation where they're using our mesa with upstream's drivers
<bryceh> or vice versa
<RAOF> Yeah.
<bryceh> I think I'd be sort of tempted to do that.  If he's using xorg-edgers that's one thing but if they start running hand rolled stuff, then I think the pottery barn rule kicks in
<bryceh> otoh working properly in such a situation might encourage more testing or something... your call I guess, if you think it's worth the effort
<bryceh> ickle's on crack
<bryceh> although, I do notice the user is on xserver 1.9.902
<jaytaoko> bryceh: ping
<bryceh> hi jaytaoko, I'm EODing in 2 minutes so need to be quick
<bryceh> ok wife is calling me away.  ttyl
 * RAOF needs a new router.
<RAOF> jaytaoko: Can I tag-team for bryce?
<jaytaoko> RAOF: hello
<RAOF> Were you talking about the radeon unity graphical corruption bug?
<RAOF> Oh, also.  Hi! :)
<jaytaoko> RAOF: thank you for responding. Would it be possible to revert to the previous X (before 1.10) on a system?
<jaytaoko> RAOF: oh, we talked about the radeon corruption bug yesterday
<RAOF> Yes, it should be possible to revert to a previous X.  It'll be easiest if you've still got the old packages around in /var/cache/apt/archives, but possible even if not.
<jaytaoko> RAOF: does that also mean a revert of the kernel?
<RAOF> jaytaoko: Hm.  I presume your question is in aid of installing one of the propritary drivers; I'm unsure if they build against the 2.6.38 kernel or not.  If you weren't going for a proprietary driver, then you wouldn't need to care.
<jaytaoko> RAOF: the think is I am facing another bug with the radeon driver... and I wonder if by reverting I can use my NVidia card instead
<RAOF> The kernels are parallel installable, however; unless you've deliberately cleaned them up, you can probably select an older one with the grub menu.
<RAOF> I _think_ that nvidia works on 2.6.38; that got uploaded before Xserver 1.10, so users would have complained about kernel breakage which I haven't noticed.
<jaytaoko> RAOF: do you know if NVidia has released a new driver for the latest kernel...
<RAOF> I don't know, sorry.
<jaytaoko> RAOF: ok, because if they have, maybe I can try and put back my NVidia GPU
<jaytaoko> RAOF: ok, what are the steps to revert?
<jaytaoko> RAOF: also I can tell you more about that radeon bug... maybe you have an idea...
<jaytaoko> RAOF: I have noticed since using my radeon with the open source driver, that some of my opengl programs don't respond visually as they should
<jaytaoko> RAOF: for instead, I have a text editor entry based on OpenGL
<RAOF> When using particular GL features, or just generally?
<jaytaoko> RAOF: generally
<jaytaoko> RAOF: my text editor entry does not show a cursor and when I type characters, they don't show up on the screen
<jaytaoko> RAOF: The screen updates only after I move the entire window
<RAOF> Hm, interesting.
<jaytaoko> RAOF: this correspond to an X ConfigureNotify event
<jaytaoko> RAOF: It works fine on Intel and NVidia.
<jaytaoko> RAOF: I have it working on my dell mini 9
<RAOF> Or possibly just _any_ X event?  It could be that something's not getting flushed, and so the X connection is waiting to fill a buffer...?
<jaytaoko> RAOF: Do you think I should flush a buffer after calling the buffer swap for opengl?
<jaytaoko> RAOF: XFlush for instance?
<RAOF> You could try that, but I'm not sure that it should be needed.
<RAOF> That's just my first-order wild guess after hearing the symptoms.
<jaytaoko> RAOF: let me try...
<bjsnider> jaytaoko, the problem is the x server not the kernel. but they haven't released a new one today
<jaytaoko> bjsnider: yes, I understand NVidia and ATI have to release new drivers that works with the latest release of X
<jaytaoko> bjsnider: proprietary drivers that is
<bjsnider> do you further understand that you should be using the x-updates ppa for those updates and not installing them from nvidia's website?
<RAOF> As for downgrading, I think âsudo aptitude install xserver-xorg-core=2:1.9.0.902-1ubuntu4 xserver-xorg-input-evdev=1:2.6.0-1ubuntu5 nvidia-currentâ should give you a downgrade path, if the packages are still in your apt cache.
<jaytaoko> bjsnider: I always get them from the ubuntu updates
<bjsnider> ok
<RAOF> If they're not, you can download them from launchpad: https://launchpad.net/ubuntu/+source/xorg-server/2:1.9.0.902-1ubuntu4/+buildjob/2146215 and https://launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/1:2.6.0-1ubuntu4/+buildjob/2235322
<jaytaoko> RAOF: thanks!
<jaytaoko> RAOF: unfortunately, XFlush has no effect on issue... 
<jaytaoko> RAOF: but has you said, it should not be necessary to call XFlush
<RAOF> Are you mixing X rendering (ie: fonts) with GL calls?  Although IIUC that shouldn't be fixed by a ConfigureNotify...
<jaytaoko> RAOF: no pure GL...
<jaytaoko> RAOF: I only do OpenGL calls
<RAOF> Hm.  Font rendering in GL?  Cool :).  I'm... not sure, then.
<jaytaoko> RAOF: The text entry I am working on use pango+cairo for font rendering in software
<RAOF> Ah, right.
<jaytaoko> RAOF: then from the software rendering of the text, transform that into an opengl texture
<jaytaoko> RAOF: and use that texture 
<RAOF> Hm, yeah.
<jaytaoko> RAOF: but I have other simpler program that don't use pago+cairo and they exhibit the same issue
<RAOF> I guess the only other thing to check would be whether the problem is in the rendering, or in the displaying; you could possibly distinguish between those by dumping the front/back buffers as an image file and looking at them?
<RAOF> It certainly just *sounds* like a driver bug :)
<jaytaoko> RAOF: ther program does some optimization to avoid rendering when it does not have to...
<jaytaoko> RAOF: if I disable these optimizations, they the program renders as expected... But it becomes much slower, because some operations are done much more frequently
<RAOF> Ah, ok.
<RAOF> This sounds like it could relatively easily be made into a small automated test, which could be incorporated into piglit?
<jaytaoko> RAOF: in this particular case there is some allocation of texture and framebuffer surface that are done at every frames if I disable the optimizations
<jaytaoko> RAOF: it is part of Nux test case
<jaytaoko> RAOF: The program uses the rendering architecture of Nux 
<jaytaoko> RAOF: so I don't know how to reproduce that in a smaller test case
<RAOF> Ah.  That's probably not small enough to go into piglit :).  Hm.  Is there a bug filed for this?
<jaytaoko> RAOF: no, I haven't filled a bug yet. because I don't have a case to make it a bug in the driver just yet
<RAOF> Ah.  You're not totally convinced that nux is doing something that's not guaranteed to work, but that intel and nvidia happen to make work as a happy accident?
<jaytaoko> RAOF: I suspect a driver issue, but filling it in that way with reference to a big program such as Nux won't be helpful
<jaytaoko> RAOF: yes, I am not convinced... 
<RAOF> Ah.  Ok.
<jaytaoko> RAOF: unless I can pin-point the issue precisely, I can't say with 100% certainty that this is a driver bug
<jaytaoko> RAOF: still I suspect a driver bug :-D
<RAOF> Right. :)
<RAOF> If you *could* narrow it down to a smallish test-case, I'd be happy to do the manouevering required to get it into piglit, where it'll become a part of the test-suite.
<jaytaoko> RAOF: thanks, I am going to try and find where the issue is... I hope I can tell you that soon
<RAOF> Sweet.
<thesheff17> once in a great while about once a day my x server crashes.  Any in site into this problem? http://pastebin.com/F2mQm5Qn
<RAOF> thesheff17: Urgh, fglrx.  It might be an Xserver problem, in which case we could potentially do something about it, or it might be an fglrx problem, in which case there's little to do but hope amd fix it.
<RAOF> thesheff17: Have you filed a bug?  A better backtrace would be useful, too.
<thesheff17> RAOF: I have not filed a bug yet...how can I get a better backtrace of it?
<RAOF> thesheff17: https://wiki.ubuntu.com/X/Backtracing is a good reference.
<thesheff17> RAOF: ok I enabled the apport service.  
<thesheff17> RAOF: unfortunately the crash is completely random...about once every 24 hours.
<RAOF> Well, hopefully apport will catch it next time.
<RAOF> You should also install the debugging packages; at least xserver-xorg-core-dbg, but possibly others mentioned on the debugging page.
<thesheff17> RAOF: sure will do.
<thesheff17> I installed xserver-xorg-video-ati-dbg, xserver-xorg-core-dbg, libgl1-mesa-dri-dbg and will let you know when it happens again....what should I do when it does happen again?
<jaytaoko> RAOF: I have another Natty system that I haven't updates in  2 months. Can I update it to a point in time before alpha 2?
<RAOF> thesheff17: Apport will *hopefully* pop up and offer to help you report the bug.  Do so :)
<RAOF> jaytaoko: If you update it from the command line you can upgrade it without upgrading the X server - aptitude is good at offering choices (some of which will be wrong âº).
<thesheff17> well the screen goes black...and I actually see like 10.10 loading screen.  I have ssh access though
<thesheff17> also all the ctrl-alt F keys don't work as well :-/
<jaytaoko> RAOF: will try that!
<RAOF> jaytaoko: Failing that, âapt-get upgradeâ will guarantee an upgrade without removing nvidia.
<RAOF> thesheff17: apport should record the crash, and offer to file it when you start up next time.
<thesheff17> RAOF: ah excellent 
<thesheff17> RAOF: thanks for the help.
<tjaalton> ..and now the laptop froze.. duh
<tjaalton> fun with nouveau _and_ intel
<tjaalton> interesting, now all the menus open behind the windows..
<tjaalton> don't get it.. thunderbird on one machine opens links fine, on the other firefox tries to open "www.%u.com"
<tjaalton> both running natty
<thesheff17> RAOF: ping
<bryceh> Internal error:   Could not resolve keysym XF86TouchpadOn
<bryceh> Internal error:   Could not resolve keysym XF86TouchpadOff
<bryceh> anyone else have ^^ in their .xsession-errors ?
<bryceh> (this is on a desktop with no touchpad)
<RAOF> thesheff17: Pong
<thesheff17> RAOF: I had the xserver crash but it didn't let me report anything once it crashed.
<RAOF> :(
<RAOF> Hm.  The apport hook doesn't always catch crashes.
<RAOF> But with those debug symbols installed the backtrace in /var/log/Xorg.0.log might be better.
<thesheff17> RAOF: hmm.strange I don't see it crashing in Xorg.0.log. I SSH into the machine from my laptop and did an /etc/init.d/gdm restart did that over write the log?
<RAOF> Yes, it would, but it would move it to Xorg.0.log.old.
<RAOF> Hah!  But if you can SSH in then you can attach gdb and grab a really good backtrace!
<RAOF> As long as you don't mind having gdb attached for a day or so, until the crash happens :)
<thesheff17> RAOF: yea that is no problem.
<RAOF> Then that's a good way to get a good backtrace, but if Xorg.0.log.old has a backtrace in it, that would be useful to see first, too.
<thesheff17> here is my Xorg.0.log.old http://pastebin.com/sd7LkHFF I just went through the steps to attach it. I think it is already running.
<RAOF> There are a couple of non-obvious pitfals to having gdb attached to X; they're listed on the X/Debugging page I linked you to yesterday.  Basically, you want to âhandle SIGUSR1 nostopâ so VT switching works, and âhandle SIGPIPE nostopâ so closing apps doesn't cause X to stop in gdb.
<RAOF> Urgh, no.  That backtrace is just as useless as the last one.  Oh, well.  gdb should grab a better one!
<thesheff17> RAOF: yea it didn't look much different then the last one I was looking at.  So basically I attached the pid to gdb and then did cont.  Should I stop this so I can address those SIG stuff? and then re attach?
<RAOF> If you hit ctrl-c in the gdb window that should stop X and return control to gdb, where you can do the SIG handling stuff.
<thesheff17> k
<RAOF> Then cont will start X back up again.
<thesheff17> should X be stopped prior to attaching gdb?
<LLStarks> ooh: http://www.nvnews.net/vbulletin/showthread.php?t=61644
<thesheff17> nm...that last thing I said didn't make sense. Just knew to all this.
<thesheff17> *new
<RAOF> Whenever gdb catches a signal - SIGSEGV (generated by the crash), SIGINT (generated by ctrl-c), SIGUSR1 (generated by VT switching) - it stops the process that it's attached to.
<RAOF> And throws up a gdb prompt.  Since one of those things is something that you're not interested in debugging - namely VT switching - you want gdb to not stop there.
<thesheff17> RAOF: ah ok
#ubuntu-x 2011-02-11
<bdmurray> bryceh: should I report a bug about the compiz version tagging part of the Xorg package hook?
<bryceh> bdmurray, yeah is it not working right?
<bdmurray> bryceh: right its not adding the version
<bryceh> bdmurray, I think I may have already fixed it
<bryceh> it may have not gotten uploaded due to the alpha-2 freeze though; I'll check
<bryceh> bdmurray, for the kernel apport hook "how often does this occur" you need a "multiple times per day" option
<alex_mayorga> bryceh: ping
<alex_mayorga> bug 713781
<ubot4> Launchpad bug 713781 in xserver-xorg-video-nouveau (Ubuntu) (and 1 other project) "[natty] Video corruption on kernel 2.6.38-1-generic and nVidia Corporation GT216 [GeForce GT 230M] (rev a2) (affects: 1) (heat: 10)" [Undecided,Incomplete] https://launchpad.net/bugs/713781
<bryceh> alex_mayorga, thanks
<alex_mayorga> bryceh: no problem, maybe I need to change the bug to include 2.6.38-2
<alex_mayorga> I'm fetching -3 right now, any chance that would help?
<bryceh> definitely worth trying
<bryceh> didn't know a -3 was available already
<bryceh> alex_mayorga, this is definitely a kernel bug, I'm only leaving it open against X because we sometimes can help in triaging the bugs down to a kernel patch to make life easier for the kernel guys ;-)
<bryceh> alex_mayorga, since this is -nouveau, RAOF may have more clue to share than I on what may be causing this
<alex_mayorga> RAOF: hi, mind taking a look?
 * RAOF is currently debugging unity crap.  I'll look at it later.
<alex_mayorga> RAOF: thanks
<alex_mayorga> how buggy is the nvidia blob? should I try it?
<bryceh> alex_mayorga, it doesn't work at all right now
<alex_mayorga> I see, so I'll hang into 2.6.37 for now :) Thanks! Sorry to bother
<alex_mayorga> guess I should go for Intel card on my next upgrade :D
<bryceh> oh, no bother, actually I'm appreciating getting the nouveau bug reports since I really want there to be a solid fallback for when nvidia isn't available
<bryceh> (and maybe one day enabling people to not need the proprietary driver for ordinary usage)
<bryceh> alex_mayorga, Intel isn't necessarily perfect either...  check out http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<bryceh> we're having a lot of problems with different freezes on -intel right now
<alex_mayorga> so basically this is not the "year of linux on the desktop" either :D
<bryceh> of course just as I was about to say -ati is more reliable my -ati desktop system spontaneously reboots
<alex_mayorga> bryceh: :)
<alex_mayorga> should I close the bug on the mysterious hang I had or link it to this one
<bryceh> alex_mayorga, probably link it
<alex_mayorga> bryceh: how? My other bugs are 696104 and 581385
 * alex_mayorga reboots to try 2.6.38-3
<RAOF> Amaranth: Are you still getting those intel freezes?
<apw> bryceh, you have pushed bug #542660 upstream in the past, and we have gotten a patch from upstream suggested, but with that patch applied people are still seeing this issue
<ubot4> Launchpad bug 542660 in linux (Ubuntu Natty) (and 6 other projects) "New Apple iMac (Core i5) fails to display anything (affects: 11) (dups: 1) (heat: 70)" [High,Confirmed] https://launchpad.net/bugs/542660
<apw> bryceh, i am torn between fileing a new bug upstream or continuing the old, whats the norm
<siretart> hi.
<siretart> I've just installed natty on one of these newly fangled i5 sandy bridge systems, and encountered a complete system freeze after xorg starts with intel drivers. vesa works fine (FSVO fine). bug #715122 looks related, but there 'only' the drm module is stuck, not the whole system
<ubot4> Launchpad bug 715122 in xserver-xorg-video-intel (Ubuntu) "[sandybridge] GPU lockup - *ERROR* i915_do_wait_request returns -11 (affects: 2) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/715122
<siretart> if someone has some ideas what I can test further, just tell me :-)
<apw> can someone remind me what the experimental gallium package is called
<tjaalton> apw: libgl1-mesa-dri-experimental
<bryceh> apw, either approach would be ok.  Given the age of that bug report it might be better to file a new one, with new logs and such, and get a fresh look.  But make sure to mention something like, "This may be related to bug #27322" or "seems similar to #27322, maybe a dupe?"
<ubot4> Launchpad bug 27322 in epiphany-browser (Ubuntu) (and 1 other project) "Epiphany shows Deer Park password save dialog (dups: 1) (heat: 4)" [Medium,Fix released] https://launchpad.net/bugs/27322
<apw> bryceh, yeah good plan
<alkisg> My laptop has 2 outputs, LVDS1 (1280x800) and VGA1 (1920x1080). My gnome session automatically runs at the highest common resolution, 1024x768.
<alkisg> If I use xrandr --addmode VGA1 1280x800, I get the desired result: both my monitors to have 1280x800.
<alkisg> My question is, where can I declare that so it's done automatically? In xorg.conf, even if I sometimes don't have the external monitor plugged in? In some udev event?
<cnd> bryceh, RAOF: have you seen any input related x 1.10 regressions so far?
<cnd> the foundation of the mt work is in 1.10 (masked valuators), so it would be helpful to know if that looks solid
<bryceh> cnd, yes 
<cnd> bryceh, yes, there are regressions?
<bryceh> well, regression is such a strong word ;-)
<bryceh> but yeah spotted a few little things
<bryceh> http://bugs.launchpad.net/bugs/716712
<ubot4> Launchpad bug 716712 in xserver-xorg-input-synaptics (Ubuntu) "Could not resolve keysym XF86TouchpadOn (affects: 1) (heat: 6)" [Undecided,New]
<bryceh> http://bugs.launchpad.net/bugs/710762
<ubot4> Launchpad bug 710762 in xserver-xorg-input-evdev (Ubuntu) (and 1 other project) "Middle mouse button no longer works (affects: 2) (heat: 502)" [Undecided,Confirmed]
<bryceh> cnd, haven't mentioned them to you cause I'm not 100% sure whether it's the mt stuff or just general X issues
<cnd> yeah
<bryceh> cnd, btw I maintain a list of all known X bugs in natty here, if you want to periodically check for regressions that you do care about - http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/workqueue-natty.html
<bryceh> half of it is gpu lockups (which technically probably belong to the kernel package actually)
<bryceh> cnd, that first bug I bet is a client bug, but wonder if it might be related to some of your stuff.  but I didn't poke into it at all
<cnd> bryceh, thanks, and those two bugs don't look relevant
<cnd> which makes me happy :)
<bryceh> well at least you're happy ;-)
#ubuntu-x 2011-02-12
 * penguin42 seems to have stmbled into a bunch of 'r600_packet3_check:1330 invalid cmd stream 408' errors after doing an upgrade on natty; it was working as of last weekends version - I'm running with edgers; it doesn't seem to be related to any kerenl upgrade that just happened - last 2 or 3 versions all do it
<penguin42> removing edgers fixes it
<LLStarks> sarvatt, all games in wine are not rendering alpha with stable intel drivers on natty. is there new xrender code?
#ubuntu-x 2011-02-13
<LLStarks> anyone know their way around xrender or ddb?
<LLStarks> i945gm with natty bits is failing render-bench
<LLStarks> ?
<penguin42> LLStarks: Just passed here - although to be fair I've not rebooted after having done this weeks update on this machine
<LLStarks> it's been like this for a while though, even on fresh installs.
<LLStarks> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
<penguin42> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
<penguin42> how does it fail for you?
 * penguin42 goes to bed
<Cobalt> Gah. X versioning is a bit obscure. X11R6.7 Xserver 1.9, for example...
<dupondje> somebody checked https://bugs.launchpad.net/ubuntu/+source/clutter-1.0/+bug/714280 ?
<ubot4> Launchpad bug 714280 in mesa (Ubuntu) (and 2 other projects) "The error was 'BadLength (poly request too large or internal Xlib length erro'. (affects: 5) (dups: 1) (heat: 32)" [High,New]
<jcristau> dupondje: cbe9fc12a64c3ae89fd1b20e9e165aa4b76293a5
<jcristau> in mesa.
<jcristau> dupondje: i assume this is with xserver head?
<jcristau> there's a pending patch nobody seems to want to review to work around the mesa bug.
<dupondje> this is with natty up-to-date :)
<jcristau> i don't know what's in natty.
<jcristau> i just know i fixed that bug.
<dupondje> 7.10-1ubuntu1
<jcristau> (to be fair, i also made it show up, but.)
<dupondje> hÃ©hÃ© well it just need to find its way to natty now :D
<jcristau> the commit you linked from the bug isn't the one i said.
<dupondje> err :) http://cgit.freedesktop.org/mesa/mesa/commit/?id=cbe9fc12a64c3ae89fd1b20e9e165aa4b76293a5
<dupondje> is the one
<dupondje> patched the ubuntu package now, and building, lets see if it solves the bug
<jcristau> http://patchwork.freedesktop.org/patch/3987/ is the xserver workaround
<dupondje> could you maby comment the bug with a full description ? :) then it can get fixed asap :)
<jcristau> should i mark it as invalid in clutter and xlib then?
<dupondje> prolly, but i'm testing the patch 
<dupondje> its building now
<dupondje> to double check
<dupondje> seems like it refuses to build ... mm
<dupondje> thanks :)
<jcristau> things might also work in a sane locale
<jcristau> (one that has . as decimal separator)
<jcristau> (because of an unrelated bug in mesa where it uses strtof to parse the glx version, and strtof depends on the locale)
#ubuntu-x 2012-02-06
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/927424
<ubot4> Launchpad bug 927424 in plymouth (Ubuntu) "Please backport commit to enable building without irrelevant drm libs on some arches (affects: 1) (heat: 6)" [Undecided,New]
<Sarvatt> going to run into that with tomorrow's libdrm update, really dont want to have to revert the x86/x64 only commits in libdrm
<Sarvatt> if that goes in libdrm can be a straight sync
<seb128> bryceh, RAOF, others: could you look at bug #889068? it's not the first time we get bugs about that and seems a rather important issue that we should look at for the lts
<ubot4> Launchpad bug 889068 in xserver-xorg-video-intel (Ubuntu) "eog logs me out when I try to turn right or left an image (affects: 3) (dups: 1) (heat: 22)" [High,Confirmed] https://launchpad.net/bugs/889068
#ubuntu-x 2012-02-07
<tjaalton> RAOF: have you tried llvmpipe yet? unity3d doesn't seem too useful with it, there's actually a bug report already, bug 926859
<ubot4> Launchpad bug 926859 in xorg (Ubuntu) "Desktop almost useless - due to corruption and flikering (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/926859
<tjaalton> but I'm not sure if it's the driver or unity failing
<RAOF> tjaalton: A bit of both - compiz does weird, weird things.
<tjaalton> in any case, it might be wise to blacklist it?
<RAOF> We already do, right?
<RAOF> Or not?
<RAOF> If it's not blacklisted, it should be.
<tjaalton> I didn't need to do anything to use it
<tjaalton> yeah
<RAOF> Oh, the renderer string changed, so the existing software rasteriser blacklist doesn't kick in.
<RAOF> Yeah.  One bug to file against unity!
<tjaalton> not that it has those already :)
<tjaalton> hmm that wasn't right
<RAOF> One *more* bug to file against unity :P
<tjaalton> :)
<tjaalton> unity2d was quite snappy on the sis-crap though
<tjaalton> using vesa, of course
<RAOF> Heh.
<RAOF> Yeah, Qt's renderer is pretty hot stuff.
<stgraber> any reason why I'm getting compiz running in my Precise VMs now? :) (obviously it's all broken and full of artifacts)
<stgraber> (it's rather annoying when you try to debug the live environment and you don't see what you're doing or just get apport windows popping up every 10s ;))
<Sarvatt> stgraber: software rendering uses llvmpipe instead of the old swrast, theres probably a hardcoded check for the old GL renderer string somewhere, hmm
<Sarvatt> looks like unity-support-test in nux
<stgraber> Sarvatt: I "think" we may want to change that check ;) It's certainly interesting to have an option of running compiz on the llvmpipe stuff but it doesn't seem quite ready at this point :)
<Prf_Jakob> stgraber: which host software?
<stgraber> (I wouldn't mind compiz running in my VM if it wasn't using 50% of CPU to render garbage)
<Sarvatt> yep, was hopeful it'd work but sounds like its a nogo
<stgraber> Prf_Jakob: kvm
<Sarvatt> Prf_Jakob: i'm sure he's using kvm or virtualbox
<Prf_Jakob> ok, nm then.
<Sarvatt> stgraber: btw vmware 3D passthrough works great out of the box with unity-3d now :P
<stgraber> Sarvatt: apparently we'll be getting a new compiz soon, but I don't know if it's going to work any better under llvmpipe
<Prf_Jakob> Sarvatt: In case he wasn't I couldn't let the oppertunity to brag about that ;-)
<Prf_Jakob> go*
<Sarvatt> yep definitely needs to be fixed in unity-support-test in nux
<Sarvatt>   // Check for software rendering.
<Sarvatt>   if (results->renderer != NULL &&
<Sarvatt>       (strncmp (results->renderer, "Software Rasterizer", 19) == 0 ||
<Sarvatt>        strncmp (results->renderer, "Mesa X11", 8) == 0 ||
<Sarvatt>        strstr (results->renderer, "on softpipe") != NULL)) {
<Sarvatt>     results->flags |= FLAG_SOFTWARE_RENDERING;
<cnd> urgh, X synaptics has a new motion regression algo, and it's completely broken
<cnd> the question is whether we should fix it, or just revert the algo
<Sarvatt> stgraber: https://bugs.launchpad.net/ubuntu/+source/nux/+bug/926859
<ubot4> Launchpad bug 926859 in nux (Ubuntu) "llvmpipe software rendering needs blacklisting in unity-support-test (affects: 1) (heat: 6)" [High,Triaged]
<stgraber> Sarvatt: thanks
<bryceh> hey tjaalton, for bug #745112 is it correct that it got fixed in 2.6.39 (and 2.6.38 via natty-updates) but then has regressed starting with 3.0?
<ubot4> Launchpad bug 745112 in xserver-xorg-video-intel (Ubuntu Precise) (and 6 other projects) "[arrandale] desktop is messed up with external monitors (x86_64) (affects: 133) (dups: 13) (heat: 581)" [Medium,Invalid] https://launchpad.net/bugs/745112
<bryceh> tjaalton, Sarvatt , RAOF - any of you have arrandale laptops with docking stations that can reproduce ^^ this bug?
<RAOF> bryceh: Sorry, no arrandale here.
<Sarvatt> no docking stations and no arrandale
 * RAOF runs a SandyBridge and GM45 shop.
<broder> what generation of cpu would go with arrandale?
<RAOF> That's the original Core iX chips, IIRC.
<bryceh> http://en.wikipedia.org/wiki/Arrandale
<bryceh> nehalem/westmere
<Sarvatt> 3 digit numbers after the i3/i5/i7
<broder> ok. i have a 1st-gen i7 machine here. i can probably test that for you guys, but will take a bit because somebody's using it at the moment
<bryceh> broder, does it have a displayport and docking station?
<bryceh> broder, the testing is probably going to be of the kernel bisection variety
<broder> it has a DP and a docking station, which has DP, DVI, and VGA
<bryceh> broder, ok cool; when you get a chance see if you can reproduce the bug, which appears to occur just when you dock the laptop (possibly when the docking station has 2 external monitors configured).  It should black-screen fairly reliably within 1-2 tries
<broder> precise or oneiric?
<bryceh> broder, apparently the bug affects both
<bryceh> broder, however I'm most interested in precise
<broder> ok. i'll go ahead and grab a new daily then
<bryceh> if it can be repro'd on precise, next thing to test after that would be http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-fixes/
#ubuntu-x 2012-02-08
<broder> so, uh, on the crazy ideas front, is it possible to use llvmpipe with the nvidia binary driver? nvidia's libgl is giving me no end of trouble
<bryceh> broder, I believe llvmpipe is gallium only
<broder> meaning it needs a server component?
<bryceh> meaning it's mesa-only, which rules out nvidia and fglrx
<broder> and there's no way to turn on mesa with the nvidia ddx? am i just saying things that don't make sense?
<bryceh> right, the -nvidia binary driver just isn't architected to work that way
<broder> :(
<bryceh> raof is the gl guru though, he may know tricks
<RAOF> broder: You could do that, but you'd need to set LD_LIBRARY_PATH to the mesa libGL.
<broder> RAOF: right, i tried that but i got an error
<broder> of course, in the process of trying harder, i've broken my laptop, so i can't tell you what that error was at the moment :)
<broder> something about fbconfig and RGB visuals
<RAOF> Oh, right.
<RAOF> nvidia *also* replaces the Xserver's GLX with an incompatible version.
<RAOF> Yeah, you're out of lucke.
<broder> oh, so i should swap that out separately?
<bryceh> broder, to unbreak, purge nvidia and reinstall
<bryceh> broder, best case even if it worked with nvidia+llvmpipe you'd be entered into unsupported/untested crazy land :-)
<broder> bryceh: oh, i'm well aware of that, but if it's unsupported/untested crazy land that *works*, i'll take my chances
<broder> right now i'm seeing both compiz and mutter crash with a fairly high probability whenever i make a display geometry change with nvcontrol
<broder> which is causing all kinds of unfortunate cascading problems
<RAOF> broder: If you're willing to completely break nvidia's GL I *think* you could swap out nvidia's GLX for Xorg's GLX.
<RAOF> I believe you'd want to divert /usr/lib/nvidia-$DRIVER_VER/xorg/libglx.so to do that, then restart X.
 * broder nods
<broder> right now, i appear to be falling down a http://xkcd.com/349/ shaped rabbit hole
<broder> (i think i busted my initrd while i was screwing with things)
<bryceh> broder, time to grow your beard longer
<broder> heh
<Sarvatt> bjsnider: woohoo libva
<Sarvatt> so like, mesa 8.0 wont be shipping the default drirc to make unigine games work, hmm
<Sarvatt> we'll need to add some /etc/drirc handling to mesa
<Sarvatt> 19 files changed, 1146 insertions, 517 deletions in a mesa 8.0.1 stable update single commit..
<bjsnider> yeah, i saw that they pulled in the libva stuff
<bjsnider> they didn't even ask for the pbuilder proof
<RAOF> We'll just hunt you down if it fails :)
<bjsnider> i touched the code so long ago that i don't really remember much about it
<bjsnider> i spent a lot more time working on the gmtk/gnome-mplayer scripts, so it's nice to see them included
<tjaalton> bryceh: yeah to me it sounds like it's been like that all the time :/
<tjaalton> bryceh: but as you pointed out, seems to be an issue with a dock and displayport, which only a few arrandale owners seem to have
<bryceh> tjaalton, unfortunately one being our ceo
<tjaalton> :)
<tjaalton> at least it looks like upstream has a way to reproduce that one
<tseliot> broder: hi, RAOF mentioned the fact that you did some work on hybrid graphics. Maybe some script on boot? Can you tell me more about it, please?
<bryceh> tseliot, I can forward his script
<bryceh> hmm, getting 403 errors from bugs.freedesktop.org
<tseliot> bryceh: thanks, I've just seen your email
<bryceh> anyone else getting 403's accessing https://bugs.freedesktop.org/ or is it just me?
<tjaalton> works here
<bryceh> hm
<seb128> wfm
<cnd> bryceh, RAOF, tjaalton, Sarvatt: I would like to push a new xserver (based on 1.11.4 and latest upstream input bits), libxi, evdev, and synaptics tomorrow
<cnd> any issues with that?
<RAOF> I don't have any problem with that.
<Sarvatt> cnd: not here, there was an issue where you commited a fix when the previous hadn't been released yet but that was totally my fault for marking it precise instead of UNRELEASED thinking i'd find a sponsor fast
<bryceh> cnd, sounds ok to me
<cnd> Sarvatt, ahh, was this in xorg-server?
<Sarvatt> yeah
<cnd> Sarvatt, did you just squash the changelog into the unreleased one?
<Sarvatt> i still had ubuntu9 checked out locally and tjaalton sponsored a package made from that, worked out ok
<Sarvatt> so 10 wasnt in it
<Sarvatt> was urgent because of mesa and the archive test rebuilds and wasnt sure if you're was ready
<cnd> ok, so everything should be good to go?
<Sarvatt> yup!
<cnd> cool
<Sarvatt> was just saying what issues i'd had in xserver in the past week, everythings ok now
<cnd> Sarvatt, you should go to the DMB and ask for the creation of an X package set, and for upload rights to it
<cnd> I'd be happy to give a positive assessment for it
<Sarvatt> yeah tell me about it, going to do that "very soon now"
<cnd> heh
<RAOF> Have I not already asked for an X package set?
<Sarvatt> have you?!
<Sarvatt> i thought you short circuited it and got core-dev
<RAOF> I did, but after that I think I also asked for an X package set.
<Sarvatt> cnd: looking forward to it though, thanks for doing that :)
#ubuntu-x 2012-02-09
<RAOF> cnd: Hey, where's the canonical source for xorg-gtest?
<cnd> RAOF, sadly, it's still my personal repo on fd.o
<cnd> I'm still waiting for a fd.o sitewrangler to flip perms bits so it can move into xorg/test/
<cnd> we're near a 0.1.0 release
<cnd> I just need to not have other fires to put out :(
<RAOF> )
<RAOF> :)
<RAOF> I can happily use it from your personal repo.
<RAOF> cnd: And, just so that I can shamelessly copy some examples, where are some of your tests? :)
<cnd> RAOF, check out lp:utouch-grail and lp:utouch-frame
<cnd> in the test/ subdirs
<cnd> RAOF, if you need to reply device recordings you'll find some nice classes in there
<RAOF> That actually might be really useful.  At the moment I'll be happy with XTESTing the pointer around, I think.
<RAOF> Sarvatt: The mesa ubuntu5 sitting in git - has that been uploaded?
<Sarvatt> RAOF: nope
<RAOF> Ok; I'll add more fixes to it.
<Sarvatt> RAOF: 8.0 final is due any time now, possibly even in the next few hours
<Sarvatt> if you're just cherry-picking things post rc2
<RAOF> No.  I'm fixing up the -dev dependencies a bit more.
<Sarvatt> oh cool, what else did you find?
<RAOF> xcb-x11
<RAOF> Bah.  x11-xcb
<Sarvatt> sheesh, no wonder, clutter using EGL only on armel/armhf
<Sarvatt> xcb-glx was the only one we hit between the other consumers of libegl-mesa-dev, edgers cairo wayland-demos and hadn't rebuilt mesa-utils but that would have failed too
<RAOF> Sarvatt: You're happy for me to push mesa with the depends fixes now?
<Sarvatt> RAOF: much appreciated
<RAOF> Oh, bah.  Mesa doesn't build on a tmpfs because overlayfs sucks.
<Sarvatt> pretty darn safe to say that wont fail to build :)
<RAOF> I always like to check.
<Sarvatt> PPA?
<RAOF> It doesn't take *that* long to build on an i5.
<Sarvatt> sandybridge? its about 9 minutes on an i7-2600 and ~20 on an i5-2557M
<RAOF> Yeah, sandybridge.
 * RAOF 's sad the i7 went to the big lenovo heap in the sky.
<Sarvatt> RAOF: CRAP
<Sarvatt> should have pilfered the CPU
<Sarvatt> swapped with the i5 :)
<Sarvatt> then again it's barely any different
<RAOF> Did not occur to me :)
<RAOF> Eh, a bit more cache, a bit higher clockspeed IIRC.
<Sarvatt> ricotz: hey is precise broken after the eglibc updates on 295.17 too?
<ricotz> Sarvatt, works fine here
<ricotz> but i am running 3.3rc3
<Sarvatt> ricotz: what version libc6 package?
<Sarvatt> and have you rebooted since updating?
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/929384
<ubot4> Launchpad bug 929384 in nvidia-graphics-drivers (Ubuntu) (and 1 other project) "nvidia drivers broken by the recent libc update (affects: 17) (dups: 17) (heat: 176)" [High,Confirmed]
<tseliot> cnd: how come did you update the changelog of X without any other changes in git?
<cnd> tseliot, you'll have to ask tjaalton what happened
<tseliot> cnd: never mind, it was some terminal corruption I guess...
<tseliot> it looks fine now
<cnd> ok
<cnd> oh wait, I think it was Sarvatt
<cnd> there was a snafu when he packaged it up last time
<cnd> but all should be ok now
<tseliot> it is
<ricotz> Sarvatt,  2.15~pre6-0ubuntu10, and yeah i rebooted
<Sarvatt> ok thats really good news
<ricotz> but i am seeing problems with totem videoplayback (using clutter) not sure if it is related
<ricotz> since there were some gstreamer and libav updates too
<tseliot> ricotz, Sarvatt: I need to test it here (I'm updating my laptop) and then I'll upload nvidia
<bryceh> tseliot, did you see 929384?  sounds like new elibc broke nvidia
<tseliot> bryceh: it seems that the latest nvidia (beta) driver solves the problem ^^
<tjaalton> ~15 lines above ;)
<Sarvatt> bryceh: yes he knows :)
<tjaalton> so we get to upload 1.12 now?
<bryceh> great
<tjaalton> isn't it that time of the cycle, where everything breaks before feature freeze
<Sarvatt> tjaalton: ha, fglrx is busted with 1.11 and wont be fixed until 1.12 is supported, new nvidia upload will support it
<tseliot> tjaalton: :D
<tjaalton> Sarvatt: fglrx broken as well?
<tseliot> Sarvatt: err, can we discuss fglrx in private?
<Sarvatt> tjaalton: yeah xv crashes xserver
<tjaalton> oh that
<tjaalton> who needs xv anyway
<Sarvatt> not like every video app uses it by default or anything
<tseliot> :)
<ricotz> Sarvatt, tseliot, yeah i am running 1.12 too which is another difference
<Sarvatt> ricotz: eglibc problem in their libGL
<tseliot> yep
<Sarvatt> doubt xserver would matter
<tseliot> let's hope it doesn't ;)
<ricotz> ok
<ricotz> tseliot, Sarvatt, but is sounds like this isnt specifically related to nvidia blob?
<ricotz> maybe libc is broken
<tseliot> ricotz: I haven't had the time to debug it properly. Apparently the issue can't be triggered with Mesa's libGL
<tseliot> but yes, libc shouldn't break things like this...
<ricotz> ok, my intel graphic is still running as it suppose to
<jpds> bryceh: Hey, apw said that you might be able to help me with https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/929655
<ubot4> Launchpad bug 929655 in xserver-xorg-video-intel (Ubuntu) "Unity randomly freezes after 11.10 upgrade (affects: 2) (heat: 12)" [Undecided,Confirmed]
<bryceh> jpds, hi, what's up?
<jpds> bryceh: I have someone with a laptop which keeps freezing and we're trying to figure out what the issue is.
<bryceh> well lets take a look
<apw> bryceh, its one of those 'invalid frambuffer id' jobs, this one restarting compiz allows the world to continue, so i am suspicious is userspace rather than kernel
<apw> bryceh, and its an x60 so i'd expect it to work :)
<bryceh> yeah it's not a gpu lockup
<bryceh> jpds, it says in the report that only unity freezes?
<jpds> bryceh: Yes, the entire graphical part just freezes up.
<bryceh> jpds, anything printed to .xsession-errors when this occurs?
<jpds> bryceh: Don't have a copy of that; will try and get it.
<bryceh> jpds, I'm not spotting obvious errors in the kernel or X logs, aside from the "(EE) intel(0): Couldn't create pixmap for fbcon" that apw mentioned
<apw> [11567.680932] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
<apw> [11567.680943] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
<apw> [11644.821929] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
<apw> [11644.821937] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
<apw> [11678.477663] init: tty1 main process ended, respawning
<apw> [11680.331193] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
<apw> [11680.331205] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
<apw> bryceh, those are in the dmesg, though a little back, that was the bottom at the time the issue occured i believe <- jpds
<bryceh> jpds, have you tried booting without the xorg.conf?
<jpds> bryceh: No.
<bryceh> jpds, if there is one, move it aside, it's probably not needed
<Sarvatt> invalid framebuffer id is 100% not a problem with anything, its just from the seamless transition not working when X is respawned from the display manager instead of from a normal boot
<bryceh> Sarvatt, yep.  Wonder if we should silence that error to avoid the confusion
<bryceh> or is that something that can be fixed in lightdm directly?
<bryceh> jpds, got your hands on that .xsession-errors?  I think that's our main hope for diagnosing this.  It is sounding like the bug is in compiz rather  than X or the kernel; I'm hoping error messages in .xsession-errors will help prove or disprove that
<jpds> bryceh: I'm awiting for sonia to reappear.
<bryceh> Sarvatt, wish we could put .xsession-errors into the apport hook...
<jpds> bug #870003 - weird.
<ubot4> Launchpad bug 870003 in apport (Ubuntu) "Should collect xsession errors when the issue happens, not when the user reports it (affects: 1) (heat: 1)" [Medium,Triaged] https://launchpad.net/bugs/870003
<bryceh> jpds, yeah we have the same problem with X bugs
<bryceh> I've got apport hooks that run (or, SHOULD run) when X crashes, and when the GPU locks up
<bryceh> I've my suspicions that they're not working 100%, but they're catching enough to keep us X guys fully occupied
<bryceh> jpds, presumably compiz could use similar functionality
<jpds> bryceh: Got it.
<jpds> "gnome-session[1430]: CRITICAL: We failed, but the fail whale is dead. Sorry...."
<bryceh> heh
<bryceh> wtf kind of error message is that
<bryceh> jpds, anything else?  that sounds like a generic fault handling error
<jpds> bryceh: PM.
<bryceh> (gnome-settings-daemon:1498): color-plugin-WARNING **: failed to reset xrandr-Lenovo Group Limited gamma tables: gamma size is zero
<bryceh> ** (gnome-fallback-mount-helper:1522): DEBUG: ConsoleKit session is active 0
<bryceh> gnome-session[1430]: WARNING: Application 'compiz.desktop' killed by signal
<bryceh> gnome-session[1430]: WARNING: App 'compiz.desktop' respawning too quickly
<bryceh> gnome-session[1430]: CRITICAL: We failed, but the fail whale is dead. Sorry....
<apw> bryceh, so ... who to finger, compiz or unity :)
<bryceh> apw, one of the two :-)
<bryceh> probably next step is to enable more debug messages for compiz, or run it in gdb or some such
<bryceh> these warnings actually just tell us what we already knew... compiz got stuck in a loop
<apw> bryceh, ok, then i would suggest jpds does the gdb thing when it occurs next and we shove a compiz task on it for fun :)
<bryceh> yep.  I can take care of the latter.
<bryceh> also, could be entertaining to try booting into a guest session.  If *that* works, then possibly there's stray ccsm config or something in the user's session
<apw> bryceh, thanks
<ricotz> Sarvatt, good old eglibc ;)
<ricotz> bryceh, ^ ;)
<ricotz> and indeed i am on amd64
<bryceh> ricotz, http://people.canonical.com/~doko/tmp/eglibc-2.15/i386/ looks like it may fix it
<Sarvatt> ricotz: yeah see #ubuntu-devel, probably wont be too much longer till i386 fix for nvidia and x64 fix for audio is uploaded
<ricotz> bryceh, everything amd64 here
<ricotz> Sarvatt, yeah i guess i am hit by the audio one though
<bryceh> ricotz, http://people.canonical.com/~doko/tmp/eglibc-2.15/ has amd64 too
<ricotz> bryceh, thanks
<bryceh> RAOF, hey is there a way to tune/disable the pointer barrier stuff?  it's a bit too grabby on dual head
<seb128> bryceh, gnome-control-center, the appearance capplet, second tab has a slider?
<bryceh> thanks
<bryceh> seb128, actually that's not quite it
<seb128> ok, dunno then
<bryceh> that controls the speed that the dock pops up, but it appears the grabbiness of the pointer barrier is constant regardless of how that's set
<bryceh> (possibly the two should be coupled in some fashion?)
<Sarvatt> ricotz: oh yeah forgot to mention, i was trying to resurrect natty in edgers
<Sarvatt> but llvm-3.0 is NOT happening
<Sarvatt> it needs a binutils update
<Sarvatt> don't care enough to conditionally switch mesa patches to llvm-2.9 just for natty so i'm just going to do libdrm and ddx updates automated and mesa by hand every week or so, thats what all the noise with failed builds was in the ppa yesterday
<jcristau> you guys might want to sync up pixman 0.24.4.
<Sarvatt> jcristau: just looked when you said uploaded, it takes an hour or two before we can, thanks for uploading that though!
<Sarvatt> E: The versions in Debian and Ubuntu are the same already (0.24.2-1). Aborting.
<jcristau> ah right it's only on ftp-master not on the mirrors yet
<ricotz> Sarvatt, yeah, i noticed ;)
<Sarvatt> ricotz: thanks for retrying the mesa ones, noticed ya fixed it :)
<ricotz> Sarvatt, did you had a look at ppa:ricotz/unstable, if you feel like 1.12 for oneiric copy it and rebuild the world against it
<ricotz> oh, i didnt hit retry ;)
<Sarvatt> whoa
<Sarvatt> i dont remember drinking that much last night..?
<ricotz> ;)
<ricotz> hehe
<Sarvatt> ricotz: wow, i think ppa's actually auto retry depwaits now
<ricotz> oh, a depwait then this could be
<Sarvatt> wasnt awake 13 hours ago to do it
<ricotz> it probably doing it automatically then
<RAOF> bryceh: That's not really my department (although I am still trying to get the velocity calculations to be more useful); DBO is your man for that.
<Sarvatt> guess i should have refreshed the bug before marking the nvidia task invalid https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/929384
<ubot4> Launchpad bug 929384 in glibc (Fedora) (and 2 other projects) "nvidia drivers broken by the recent libc update on i386 arch (affects: 31) (dups: 23) (heat: 278)" [Unknown,Unknown]
<bryceh> Sarvatt, maybe leave it open assigned to tseliot for him to track?
<Sarvatt> sounds good, he was going to bring it up with nvidia on a call
<Sarvatt> hopefully i dont screw something up cherry-picking RAOF's mesa fix to debian-experimental this way http://paste.ubuntu.com/835828/
<RAOF> Oh, yeah.  I should have committed that to the debian-experimental branche, too.
<RAOF> That looks right to me; thanks Sarvatt.
<bryceh> RAOF, seems there are easily half a dozen bugs already filed on it
<RAOF> Against xorg?
<bryceh> unity
<RAOF> Yeah.  As I say, I'm trying to work out how to give better data to unity.
<Sarvatt> yay mesa 8.0
<Sarvatt> still can't requestsync pixman
<cnd> RAOF, bryceh: got a bit of a quandry
<cnd> I have clickpad support working
<cnd> it's pretty nice
<cnd> it still has some issues with semi-mt devices, but overall it's a much-needed improvement
<cnd> however, on synaptics semi-mt devices (and maybe others too) the mt data used for clickpad behavior comes at a different scan rate
<cnd> this throws the pointer velocity acceleration profile off
<cnd> so it feels like the pointer moves twice as fast
<cnd> I don't know what to do :(
<RAOF> Why does the reduced scan rate thorw the velocity calculation off?
<cnd> maybe if it's synaptics branch we can kludge it by dividing the hw motion by some magic number?
<cnd> RAOF, no idea
<RAOF> The stuff that I've seen calculated velocity as dx/dt, which should be rate-independent.
<cnd> one would think
<bryceh> cnd, dividing by 2 sprang to mind, however I'd worry that would just mask bugs that'd only get found later
<cnd> yeah
<cnd> bryceh, I was thinking maybe for semi-mt synaptics trackpads only, divide by 2
<bryceh> cnd, is your question about how to fix the issue, or more about whether to push it into the repo vs. hold back until it's solved?
<cnd> well, both actually
<bryceh> ok thought so ;-)
<RAOF> It sounds like something I'd want to push to a PPA and get some opt-in testing.
<bryceh> yeah, personally I'd also be reticent having it go in until the issue is at least understood if not fixed
#ubuntu-x 2012-02-10
<cnd> I can push in the stuff for non-semi-mt devices
<RAOF> It also depends on how bad the bad behaviour is.
<cnd> though I guess I don't know that synaptics non-semi-mt don't do the same
<cnd> it's not that bad of behavior
<bryceh> xorg-edgers?
<cnd> it's just a little faster than expected
<cnd> if I had to guess, somewhere between 1.5 and 2 times faster
<cnd> and only when you hold the button down
<cnd> so click+drag
<bryceh> hmm, that ratio sounds familiar
<cnd> in fact, it's hardly a regression since click+drag didn't really work at all before :)
<cnd> before this, clickpads would try to scroll if you did click+drag
<cnd> which isn't really what the user wants
<bryceh> oh, there was an input bug with touchpads when used on HD monitors that the X speed would be different from Y by the aspect ratio of the HD monitor
<RAOF> bryceh: Yeah, that's the intended behaviour :)
<bryceh> RAOF, no, there was a period where it was mis-calculated.
<RAOF> Oh.  I didn't notice that :)
<RAOF> cnd: Given its not a regression, the main concern would be that changing to the correct behaviour might be susprising.
<cnd> heh, I don't think that's really a concern
<cnd> clickpads are just broken broken broken on ubuntu right now
<cnd> and this makes them not be :)
<cnd> so it doesn't have anything to do with the X server's acceleration profile
<cnd> whew
<cnd> phew*
<cnd> aha, I found the culprit
<cnd> the estimate_delta function in synaptics
<cnd> tbh, I think there's way too many independent acceleration, dampening, etc. functionalities through synaptics + xserver
<cnd> and commenting out estimate_delta makes things behave normally
<jschall> I have an nvidia gtx 560m... i get video tearing in all video players (incl. flash, mplayer) with compositing on, flash still tears with compositing off, mplayer is also seemingly dropping frames with compositing on, which is a lot more noticable when on battery (gpu clocks down to 202MHz gpu/324MHz ram)
<jschall> and i NEVER had problems with the 8800gts on my desktop. what an insane regression.
<jschall> any help? i've spent a lot of time trying to fix this... at the moment i'm running xorg-edgers, nvidia-current 295.17.
<RAOF> jschall: You've got the relevant âsync to vblankâ things flipped? (In Compiz, in nvidia-settings)
<jschall> RAOF: kubuntu... i have vsync on in kwin, in nvidia-settings
<jschall> wonder if noveau will ever be as good as the nvidia drivers
<jschall> nouveau*
<RAOF> Depends on what you mean by âas goodâ
<jschall> well, doesn't seem to even allow kwin compositing to work
<jschall> but maybe i didn't have a package i needed or something
<RAOF> The 560m is, I think, too new to get acceleration support.
<RAOF> At least in an Ubuntu release.
<jschall> well, anyway, i'm happy with this laptop apart from this stupid video tearing thing... love to get it fixed
<jschall> RAOF: any ideas at all?
<jschall> RAOF: other than vsync switches?
<RAOF> Not really, sorry.
<jschall> maybe it'll be fixed in a new nvidia driver some day...
<RAOF> Possibly ;)
<jschall> RAOF: the juddering thing just seems weird, though... why wouldn't a modern video card be able to decode some video without dropping frames?
<jschall> RAOF: the cpu can do it no problem...
<jschall> RAOF: even though it's avc
<RAOF> Shrug.
<RAOF> It's not like we have much insight into the driver ;)
<bjsnider> RAOF isn't the one to ask because he's a nouveau partisan
 * RAOF prefers drivers we can fix, sure :)
<Sarvatt> is it just fullscreen thats tearing? there was a change recently in kde to stop unredirecting fullscreen windows which might be why it changed for you that you might be able to undo with a setting somewhere but yeah KDE, dont use or know anything about it
<RAOF> I also don't spend much time using the nvidia binary driver, so I'm particularly good at fixing problems with it.
<jschall> Sarvatt: it does tear in fullscreen with or without compositing on.
<Sarvatt> i was going to suggest reporting it but apparently you did and they told you to come here, it really sounds like a kde/kwin specific problem though
<Sarvatt> err reporting it at nvnews.net forums
<bjsnider> i don't think the 560m is too new
<bjsnider> if the blob supports it it should get compositing and whatnot
<jschall> bjsnider: will it run games with nouveau?
<Sarvatt> probably not as good as you want if you cared enough to get a good GPU :)
<jschall> Sarvatt: does it have support for all the opengl extensions that the proprietary drivers provide?
<RAOF> No.
<Sarvatt> nowhere near it :)
<jschall> Sarvatt: honestly the only game i really ever run any more is heroes of newerth... that's going to change when d3 comes out.
<bjsnider> that's a laugh
<Sarvatt> you really dont want nouveau
<jschall> hmm. k
<jschall> i just don't want screen tearing
<bjsnider> have you tried gnome?
<jschall> there is an option in kwin to unredirect fullscreen
<bjsnider> it's pretty good
 * RAOF still contends that it's probably too new for acceleration under nouveau.
<Sarvatt> RAOF: it should be fine in precise
<jschall> bjsnider: you know, i haven't tried gnome but i really just don't want to use it. i did run a livecd to check for tearing
<Sarvatt> did that have tearing too?
<Sarvatt> then again that was nouveau :)
<bjsnider> yes but i think it would be interesting to see if there was tearing in gnome
<jschall> it didn't seem to have tearing
<jschall> but yeah, i guess it would've been nouveau
<bjsnider> there's no tearing by design in mutter, so i would try gnome-shell
<jschall> i can't remember if i installed the nvidia drivers
<jschall> i guess i couldn't have in a live usb
<RAOF> Of course, there's no tearing by design in compiz either; that doesn't prevent tearing :)
<bjsnider> sure there's tearing in compiz
<bjsnider> you can turn off vsync and screw up the frame rate
<bjsnider> but i'm an evil gnome-shell partisan so of course i'm going to recommend that
<Sarvatt> jschall: have you tried disabling gpu acceleration to see if its any different?
<Sarvatt> in whatever playback apps you're using
<jschall> Sarvatt: well, mainly its flash
<RAOF> bjsnider: I just meant that vsyncing in the compositor is insufficient to ensure tear-free. (Indeed, I don't think it's possible to ensure tear-free)
<jschall> Sarvatt: and it does have that option but it makes no difference
<jschall> Sarvatt: i don't even think it does anything
<Sarvatt> ah gotcha
<bjsnider> jschall, in which playre?
<Sarvatt> how about in smplayer?
<jschall> bjsnider: that's flash
<Sarvatt> switching to gl, or xv, or x11
<bjsnider> jschall, are you talking about right-clicking?
<jschall> Sarvatt: let me try it again
<jschall> bjsnider: yes
<bjsnider> it doesn't do anything
<jschall> ah
<bjsnider> that has been disabled in linux because it causes minor aggravations like taking down x
<bjsnider> smplayer was abandoned
<jschall> bjsnider: with xv if there's any tearing its unnoticeable in smplayer
<jschall> bjsnider: only issue is decoding avc EATS cpu
<bjsnider> xv is useless
<jschall> bjsnider: why?
<bjsnider> which version of ubuntu is this?
<jschall> gl has tearing
<jschall> and is kinda slowish
<jschall> juddery
<jschall> its not a lot of tearing though
<jschall> gl (fast) seems better
<bjsnider> go ask uau in #mplayer2 which output driver you should use
<jschall> gl2 also juddery
<bjsnider> what version of ubuntu?
<jschall> and tearing
<jschall> kubuntu 11.10
<jschall> -vo caca is perfect.
<bjsnider> ok, well, there shouldn't be more than 30% cpu usage decoding avc, because we have ffmpeg-mt now
<bjsnider> unless you're doing that 3d crap
<jschall> 3d crap?
<jschall> bjsnider: mplayer using 75% cpu decoding 1080p avc. cpu clocking to 2000mhz ish
<jschall> bjsnider: with kwin compositing ("3d crap") disabled
<jschall> bjsnider: that's with xv out
<bjsnider> no, 3d video i meant
<bjsnider> 10-bit video
<jschall> bjsnider: oh
<bjsnider> i'm assuming this is standard 1080p
<bjsnider> what cpu?
<jschall> bjsnider: vdpau out clocks the cpu down to 1200 and mplayer uses 10-25%
<jschall> bjsnider: i7 2670qm
<bjsnider> are you kidding me?
<jschall> bjsnider: no
<bjsnider> this is absurd
<bjsnider> these numbers can't be correct
<jschall> bjsnider: they are
<bjsnider> you should get 5% with vdpau, and around 30% with ffmpeg-mt
<jschall> bjsnider: as reported by i7z and top
<bjsnider> is this just kde suckage?
<jschall> bjsnider: no.
<jschall> bjsnider: that's how much cpu it takes to decode avc
<bjsnider> i've got an nvidia card that's crap compared to yours and i do much better
<bjsnider> what about 1080p x264?
<jschall> bjsnider: dunno if i have any
<jschall> bjsnider: i can run mplayer with no output i assume
<bjsnider> that's alright, just search for and download big buck bunny
<bjsnider> what is the mplayer command you're using?
<jschall> bjsnider: mplayer -vo null filename
<jschall> bjsnider: 80% usage at 1.8-2.4ghz
<jschall> bjsnider: kde not being used at all
<jschall> bjsnider: compositing still off
<bjsnider> mplayer -vo vdpau -vc ffvc1 -ao pulse file
<jschall> Cannot find codec matching selected -vo and video format 0x31637661.
<jschall> and then just the audio plays
<bjsnider> mplayer -vo vdpau -vc ffh264 -ao pulse file
<jschall> that's the one it uses normally
<jschall> maybe i have an h264 file and not an avc file
<bjsnider> no, it's the same thing
<bjsnider> what's the cpu at?
<jschall> bjsnider: 80%
<bjsnider> are these actual blurays?
<jschall> bjsnider: no
<jschall> bjsnider: probably ripped from them though
<bjsnider> alright, download big buck bunny and play that
<bjsnider> give me the url and i will play it too
<bjsnider> then we can compare
<jschall> bjsnider: mmm firefly bluray rips
<jschall> big buck bunny won't be avc so won't eat cpu
<jschall> which version of bbb should i download?
<jschall> mp4, h264, ogg?
<bjsnider> h264 1080p
<jschall> yeah, 40-60% and 1500-1800mhz
<jschall> which comes out to like 20% at 3400mhz
<jschall> which is what it can clock up to if it wants
<jschall> what i should really be doing is power consumption tests
<jschall> because that's what i care about if i'm going to watch on battery
<jschall> anyway, something i noticed with mplayer -vo vdpau is that it didn't tear with compositing on...
<jschall> so maybe its an smplayer thing
<bjsnider> ok, try -vc ffh264vdpau
<jschall> oh
<jschall> bjsnider: yeah usual slowness and tearing
<jschall> bjsnider: but low cpu usage!
<bjsnider> how low?
<bjsnider> 5%?
<jschall> bjsnider: 15
<jschall> bjsnider: oh and...
<bjsnider> it should be around 5% maximum, so i expect this is a kwin issue
<bjsnider> and watching it that way is the way to get around power issues
<jschall> bjsnider: and like 1ghz
<jschall> bjsnider: so at 3ghz it'd be 5%
<bjsnider> ok
<jschall> bjsnider: well lets find out watts up
<jschall> bjsnider: =P
<jschall> bjsnider: pulled battery, plugged into watt meter
<jschall> bjsnider: 66.5 watts with this
<bjsnider> with vdpau?
<jschall> bjsnider: 78w with no vdpau on -vc
<jschall> 66.5 with vdpau
<jschall> with no vdpau can jump to 80
<bjsnider> to be fair you'd have to run the cpu to full throttle
<jschall> bjsnider: 72 with -vo xv and no vdpau in the codec
<jschall> bjsnider: vdpau is the way to go for watts
<jschall> bjsnider: for sure
<bjsnider> we've known that for years
<bjsnider> it's no surprise
<bjsnider> but playback should be smooth and relatively judder-free
<bjsnider> what's your screen's refresh rate?
<jschall> bjsnider: but wait, different results with compositing off: vdpau uses MORE power than xv
<jschall> bjsnider: wait, no
<bjsnider> vdpau is superior to xv though
<jschall> bjsnider: ran the test again, didn't give the meter enough time i guess
<jschall> bjsnider: and now akonadi is doing something that uses 40% cpu...
<jschall> bjsnider: oop, it just stopped
<jschall> bjsnider: time to put battery back so i don't forget it's not there
<jschall> bjsnider: anyway, interesting experiment
<jschall> bjsnider: vdpau just sucks with compositing
<bjsnider> constantly throttling the cpu down to the level of an old pentium isn't going to help performance
<jschall> bjsnider: and flash just always sucks no matter what
<jschall> bjsnider: umm, it works great...
<jschall> bjsnider: it throttles it when it needs to
<jschall> bjsnider: its a laptop
<bjsnider> keep in mind that vdpau and compositing both use the gpu, at the same time
<jschall> bjsnider: if i turned throttling off it'd eat a solid 40 more watts
<jschall> bjsnider: yeah, but so does running heroes of newerth (should use a LOT more gpu than vdpau)
<jschall> bjsnider: and heroes of newerth runs like 200fps if i turn vsync off
<bjsnider> i doubt it
<bjsnider> h264 is awfully hard on any cpu/gpu
<jschall> bjsnider: why can my phone play it then?
<bjsnider> if we didn't have ffmpeg-mt your sandybridge cpu couldn't play it
<jschall> bjsnider: my phone plays sintel on youtube with no tearing just fine, but my $1400 laptop can't, apparently
<jschall> bjsnider: but then, my phone isn't playing it at 1080p
<jschall> bjsnider: and my phone has hardware decoding
<bjsnider> my q6600 kentsfield cannot play 1080p consistently without multithreading
<jschall> bjsnider: my q6600/8800gts played all the content i wanted to consistently, but i had it clocked at 3.4ghz...
<jschall> bjsnider: 2.8ghz was the lowest i ever had it clocked to over a long period of time...
<jschall> bjsnider: and it played anything i wanted perfectly with kwin compositing on
<jschall> bjsnider: and i don't think the 8800gts was doing vdpau... if so i wasn't using it because i always used vlc
<jschall> anyway i have to do my precalc homework for tomorrow
<jschall> wonder if i can sell a netbook with linux on it on craigslist
<jschall> because there's basically no way to reload win7 starter on it...
<cnd> bryceh, RAOF: I ran out of time to get to the X uploads today
<cnd> I don't have anything big planned tomorrow, so I should be able to get to them
<bryceh> cnd, ok
<bryceh> heh, I had a system with two dual head monitors, hot swapped them for two new monitors (different brand but same resolution), rebooted and it came up mirrored.  Obviously.
<cnd> bryceh, RAOF, tjaalton, Sarvatt: I just sent a couple patch series out to xorg-devel
<cnd> they enable proper clickpad support
<cnd> I want to get this into precise
<cnd> I would suggest putting everything up through the first series (the synaptics touch handling) into precise asap (i.e. tomorrow)
<cnd> I can put the second series into a ppa and put out a CFT
<bryceh> cnd, you sound a lot more confident than earlier!  :-)
<cnd> bryceh, I was afraid the motion issue was unresolvable
<cnd> but it turns out to just be a bad algo
 * bryceh nods
<cnd> before I put out a CFT, if you could smoke test it I would appreciate it
<cnd> git://people.freedesktop.org/~cndougla/xf86-input-synaptics branch clickpad-synaptics-ubuntu
<cnd> bryceh, it should help your netbook
<bryceh> heh, the one computer I *haven't* updated so far today
<cnd> and I bet the four of you have a few clickpads around
<cnd> heh
<bryceh> cnd, ok will do
<bryceh> seriously my fibre has been on fire today
<cnd> note that you will need to manually set the "Synaptics ClickPad" property to 1
<cnd> in most cases
<RAOF> It's not possible to detect that easily?  Bah.
<cnd> RAOF, it is, if the kernel driver tells us
<cnd> I need to add it to the magic trackpad driver
<RAOF> Fair enough.
<cnd> but I don't know what the state of it all is for synaptics
<cnd> the detection logic is in the synaptics patch set
<cnd> it's just not likely that people will have drivers that tell us they're clickpads
<cnd> RAOF, actually, maybe most synaptics clickpads will work OOTB
<cnd> I see support for setting the clickpad property in the kernel driver
<cnd> I think it's just my specific trackpad on my older dell netbook that doesn't appear to the driver to be a clickpad
<cnd> ok, off to get dinner
<bryceh> cnd, make check fails
<bryceh> make[2]: Entering directory `/home/bryce/ubuntu/xserver-xorg-input-synaptics/clickpad-synaptics-ubuntu/test'
<bryceh> /bin/bash: line 5: 28107 Segmentation fault      (core dumped) ${dir}$tst
<bryceh> FAIL: eventcomm-test
<cnd> bryceh, hmm. interesting
<RAOF> That's a symbol-mismatch, right?
<cnd> RAOF, bryceh, no, it's an issue with the new mechanism for instantiating SynapticsHwState
<cnd> I missed that the test program needs to be updated
<cnd> bryceh, thanks for catching it, I'll fix it tomorrow
<cnd> it's not hard to fix, but not something I can fix in 30 seconds
<bryceh> no prob, I worked around it (just hacked out the test)
<bryceh> I've got it installed and will play with it this evening while watching Dexter
<bryceh> cnd, are there any lp#'s associated with this work?
<bryceh> well I already see a problem
<bryceh> cnd, with one finger moving, if a second finger happens to touch the touchpad, the pointer stops dead
<bryceh> hmm, including if second finger is just carefully touching the left mouse button.  IOW drag and drop becomes impossible.
<bryceh> so.. no dexter for the netbook
<cnd> bryceh, no lp#s
<cnd> bryceh, drag and drop should work...
<cnd> that's the point of the clickpad support
<cnd> check to make sure the "Synaptics ClickPad" property is set to 1
<bryceh> oh, right!
<cnd> bryceh: testing to see if I'm connected on my iPad
<cnd> do you see this?
<RAOF> Yes.
<cnd> k
<cnd> bryceh: did setting the property fix things?
<bryceh> cnd, no, mouse cursor doesn't work at all
<bryceh> cnd, after setting the property in xorg.conf.d
<cnd> bryceh: how did you set the property?
<cnd> I suggest using xinput as it's faster to test
<bryceh> ah
<bryceh> well, wife's calling me to dinner so I'm out of time
<cnd> if you do xinput list-props <device id> it will show it
<cnd> and set-prop to change it
<cnd> thanks for trying though... I hope it works better when you try again
<bryceh> cnd, alright lets try
<bryceh>         Synaptics ClickPad (266)       1
<bryceh> still, same behavior
<cnd> hmmm...
<cnd> so when you put two touches down, the pointer stops moving
<bryceh> right
<cnd> when you press a button, it still doesn't move?
<bryceh> I've put packages up of what I used at https://launchpad.net/~bryce/+archive/clickpad-synaptics-ubuntu
<cnd> when two touches are down but the button isn't pressed, it will emit scroll events (if enabled) or do nothing
<bryceh> cnd, yes if I depress the button it will begin moving again
<bryceh> if I just touch the button, it stops
<cnd> bryceh, ahh, so click and drag works, right?
<bryceh> anyway, gotta go
<cnd> k
<tjaalton> syncing pixman
<tjaalton> ..later
<tjaalton> not possible yet it seems
<tjaalton> whoa, xorg dev position open?
<tjaalton> not one but two..
<tjaalton> amazing what a piece of hair in front of the mouse laser does to it's accuracy..
<jschall> RAOF: btw, flash 11.2 beta fixed my screen tearing
<tjaalton> checking for glXCreateContext in -lGL... no
<tjaalton> why the #&%#Â¤ does it fail on sbuild but not pbuilder
<tjaalton> don't care anymore, ship it
<tjaalton> (gstreamer-vaapi)
<tjaalton> whee, patch to fix scrolling from whot.. will test asap
<tjaalton> cnd: whot posted a patch to fix bug 925785 and I verified it works
<ubot4`> Launchpad bug 925785 in xorg-server (Ubuntu) (and 1 other project) "Starting to scroll is erratic with edge scrolling on touchpad or mouse scrollwheels (affects: 10) (heat: 50)" [Critical,Triaged] https://launchpad.net/bugs/925785
<cnd> tjaalton, ok, I'll be sure it's folded into the packages I upload today
<tjaalton> cnd: I can add the patch, have it locally
<cnd> tjaalton, if you don't mind, I'd rather add it
<tjaalton> ok
<tjaalton> sure :)
<cnd> so I can keep track of what are patches vs what are merged from upstream
<tjaalton> yeah this is pretty fresh (posted 20min ago), so probably not upstream yet
<cnd> hasn't come across xorg-devel yet even :)
<tjaalton> nope, took it from bugzilla
<tjaalton> now to see if a newer kernel fixes nouveau on my laptop..
<tjaalton> it's failing to use nouveau dri, falling back on swrast
<tjaalton> promising, plymouth splash
<tjaalton> nah, "error creating GPU channel: -19"
<tjaalton> ok, accel disabled by default
<cnd> tjaalton, do you have a clickpad?
<cnd> Sarvatt, you too?
<tjaalton> cnd: no, just the thinkpad
<cnd> ok
<tjaalton> Sarvatt does
<tjaalton> macbook air
<Sarvatt> this isnt a clickpad
<tjaalton> oh
<Sarvatt> broadcom BCM5974 touchpad
<tjaalton> what's a clickpad then?
<Sarvatt> actual synaptics touchpads that click
<Sarvatt> this just uses the synaptics driver
<tjaalton> ok
<Sarvatt> i dont even have any systems with real synaptics touchpads in them anymore, crazy
<cnd> Sarvatt, no, I'm meaning clickpad in the functional sense
<cnd> so macbook trackpad counts
<cnd> not in the Synaptics ClickPad (R) sense
<Sarvatt> oh! let me read the scrollback and see what ya asked
<cnd> Sarvatt, install the package from https://launchpad.net/~bryce/+archive/clickpad-synaptics-ubuntu
<cnd> then, use xinput to set the "Synaptics ClickPad" property to 1 if it's not already
<cnd> then see if you can drag and drop with two fingers
<cnd> and if everything else seems sane
<bryce> cnd, from last night, yes click and drag worked.  Anything else need tested?
<Sarvatt> cnd: going to invalidate any testing if i use it against 1.12?
<Sarvatt> ah it doesn't even build against 1.12
<Sarvatt> damn, gonna take me about 45 minutes to remove edgers
<cnd> Sarvatt, you can fetch from git and build from sources
<cnd> http://cgit.freedesktop.org/~cndougla/xf86-input-synaptics
<Sarvatt> i did last night and it failed the same way
<cnd> branch clickpad-synaptics
<Sarvatt> oh clickpad-synaptics, i used the ubuntu one
<cnd> yeah, the ubuntu one has two patches for the 1.11 backport
<bryce> cnd, what's the cleanest way to install (and uninstall) it if you build from source?
<cnd> bryce, I usually use --prefix=/usr
<cnd> that way when I reinstall the dpkg everything is overwritten
<cnd> bryce, does the trackpad now behave as you expect?
<cnd> any issues?
<cnd> my hope is this makes these devices much saner
<bryce> cnd, well there's the issue that when both fingers are on the pad, the pointer does not move
<cnd> bryce, that's expected
<cnd> it will either perform scrolling or do nothing
<cnd> depending on your scroll options
<cnd> or send touch events
<bryce> cnd, ah, there's a way to configure that?
<bryce> like, a way to get it to just ignore the second mouse touch?
<cnd> bryce, in gtk mouse settings you can enable two-touch scrolling
<cnd> bryce, are you asking if there's a way to make the cursor move when you have two touches on the device?
<Sarvatt> override_dh_auto_test:
<Sarvatt>         dh_auto_test || echo "Test suite failure, but keeping on anyway"
<Sarvatt>  ftw
<bryce> cnd, that's correct
<cnd> bryce, no, that's not possible anymore
<cnd> it would interfere with sending touch events
<cnd> Sarvatt, yeah, I'm going to fix that today
<cnd> bryce, did you often do that?
<cnd> move the cursor with two touches?
<bryce> cnd, yes, typically when I'm going to click something I'll rest my finger momentarily on the button without pressing it while I finish moving the pointer with my other finger
<bryce> with this setting, I find the cursor halting suddenly
<cnd> bryce, hmmm... do you think it's a problem if that's not possible anymore?
<cnd> or will people get used to it?
<bryce> also, the way the netbook works I often have stray touches while cursoring, but I'd have to examine my usage more
<bryce> it does not feel to me like something people would get used to, it feels more like a severe bug
<cnd> hmm...
<bryce> I do have to say I haven't seen the weird random go-to-0,0 problem that it had before
<cnd> I don't think I ever used my trackpad like that
<cnd> I always hover my button finger above the trackpad
<cnd> and then press when I'm in the right spot
<cnd> maybe that's because I always have two-touch scrolling enabled
<cnd> in previous versions, if you had two-touch scrolling enabled you'd have the same issue
<cnd> the pointer would stop as soon as you touch with the second finger
<Sarvatt> first really annoying thing is i can't move while clicking when clickpad is enabled
<Sarvatt> so no highlighting text
<bryce> Sarvatt, did you set the xinput setting?
<Sarvatt> yeah
<Sarvatt> it was fine without it set
<bryce> hmm
<bryce> I had that problem before I changed the setting, but it worked (more or less) after
<Sarvatt> two finger click doesn't right click
<Sarvatt> so cant right click at all
<cnd> Sarvatt, can you press with one finger and drag?
<Sarvatt> no, pointer doesn't move
<cnd> what about pressing with one finger and dragging with a second?
<Sarvatt> nothing
<bryce> two finger click works here for bringing up the context menu
<Sarvatt> it all works properly on the mac trackpads without clickpad turned on
<cnd> Sarvatt, hmm... I'll play around some more here
<cnd> it works fine on the magic trackpad
<cnd> I haven't tested on my macbook
<cnd> I assumed it would work
<Sarvatt> http://ubuntuone.com/1uzkRjwx0x4JtGpM30pm47
<Sarvatt> why are we changing the default speed in a patch?
<Sarvatt> had to adjust it because it was way too slow
<cnd> Sarvatt, it's likely a side effect of a change, which we had patched in a speed change for a month ago
<cnd> I think when I package stuff up it will be resolved
<Sarvatt> err, whats the deal with xbitmap and xbitmaps?
<Sarvatt> hmm
<Sarvatt> x11-apps in debian recommends: xbitmap but the package is xbitmaps it looks like
<bryce> bug #930176
<ubot4`> Launchpad bug 930176 in x11-apps (Ubuntu) "x11-apps recommends xbitmap but it doesn't exist (xbitmaps is in the archive) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/930176
<Sarvatt> yeah
<Sarvatt> was just looking at that
<bryce> I think we dropped it a while back
<Sarvatt> was xbitmap a separate package from xbitmaps?
<Sarvatt> it looks like just a typo
<bryce> maybe
<bryce> when I first joined the X apps were all packaged individually
<bryce> tbh I don't remember there ever being an 'xbitmap' tho
<Sarvatt> asking in debian-x
<jschall> if i run xset -q, i see dpms is randomly getting reset to 180 270 360. How can i fix this? It's really annoying, I've set my distro's power management to not blank the screen when power is connected.  i've grepped /usr and /etc for dpms and come up with nothing that seemed relevant. I can probably fix it by just setting up a cron job to xset -dpms every minute but I'd like to find the source of the problem. on kubuntu, btw
<jschall> how can i set nvidia's nologo option in 11.10? isn't xorg.conf deprecated?
<broder> jschall: no, it's just not needed by default. you can still create an /etc/X11/xorg.conf file
<bryceh> I'm going to delete the canonical-xorg team, since we have canonical-x for the same purpose
<bryceh> I vaguely recall canonical-xorg was set up so I could be included in dell hardware bug reports
<bryceh> however these days those issues are handled by hwe and oem groups
<bryceh> if there's value to having us on that, might want to have the dell team sub canonical-x instead
<cnd> argh... the allowevents struct stuff seems to be broken...
<bryceh> boom, canonical-xorg gone.
#ubuntu-x 2012-02-11
<kklimonda> hey, I have a weird issue with precise under virtualbox - when I use mouse scroll to scroll down sometimes it emits scroll up - I can see  in xev that button 4  is pressed/released (but I obviously don't scroll up myself). Any idea what may be causing it?
<kklimonda> hmm, maybe it's because it is being detected as a tablet.. hmm
<bryceh> kklimonda, yeah a few people have mentioned seeing that issue
<bryceh> there's a bug filed about it, but I don't know if a workaround is identified yet
<kklimonda> ah, great
<cnd> bryceh, Sarvatt: fyi, I just pushed new x11proto-input, libxi, and xorg-server patches into precise
<cnd> I'm about to update evdev and synaptics
<bryceh> okie
<Sarvatt> cnd: so about clickpad, do you plan on enabling it via dmi quirks?
<Sarvatt> thats going to be a massive quirk list i bet
<cnd> Sarvatt, the kernel drivers should tell us
<cnd> emphasis on "should"
<Sarvatt> oh?
<Sarvatt> for actual synaptics clickpads only?
<cnd> the magic trackpad and macbook trackpad drivers don't yet
<cnd> no, for all "buttonpads" in the kernel terms
<cnd> I need to update the apple trackpad drivers so they do
<cnd> we may need to dmi quirk a few synaptics models here and there
<Sarvatt> good thing the kernel freezes waaaaay later than userspace :)
<bryceh> wonder if/when we get the 2 new X guys if it'd be worth holding a X-team sprint?
<Sarvatt> bryceh: same time as desktop sprint?
<Sarvatt> imagine theres going to be individual team sprints, was assuming tjaalton and me would just go out to the desktop one
<bryceh> ah, didn't know we were having a desktop sprint
<Sarvatt> me neither
<bryceh> yeah that'd make sense
<Sarvatt> talking out of my rear
<bryceh> well, if we don't still might make sense for us to do orientation for the new guy(s)
<Sarvatt> worst case though yeah we totally have enough people to do an x team sprint now
<Sarvatt> with 2 new people
<Sarvatt> portland sounds good :)
<bryceh> good point, saves at least 2 people's air fare
<Sarvatt> well, DC, italy, tasmania, portland, portland, finland, insert 2 new people here
<cnd> Sarvatt, bryceh: portland would be awesome
<cnd> then I could come :)
<cnd> hang out at least
<bryceh> totally
<cnd> what's our naming scheme when we need to upload something based on the latest stuff in git?
<Sarvatt> what package?
<cnd> evdev and synaptics
<Sarvatt> version-debian-giteuropeandate-0ubuntu1?
<cnd> Sarvatt, what's the definition of europeandate?
<cnd> UTC?
<bryceh> shouldn't it be +git ?
<bryceh> YYYYMMDD
<cnd> yeah, seems like it should be +git
<cnd> oh, no timestamp
<cnd> yeah, that would get annoying
<Sarvatt> oh version+giteuropeandate-fooubuntubarX it looks like, just use whatever it used before :)
<Sarvatt> 1.5.0+git20120101-1ubuntu1
<cnd> k
<cnd> oh yeah, it should be obvious in the changelog
 * cnd slaps himself
<Sarvatt> you're doing all the stuff there, use whats most obvious for you :)
<cnd> I just want to be sure I don't do anything stipid
<cnd> like put the git version in front of the date
<Sarvatt> well if you update the git revision past debian use 0ubuntu instead of 1ubuntu
<cnd> hmmm... looks like they've done that in the past
<cnd> yeah
<bryceh> yeah only use 1ubuntu when debian made the snapshot.  0ubuntu when we make it
<bryceh> hum.  I have no idea what my son did but my control key no longer seems to work
<bryceh> xev doesn't even see it
<kklimonda> bryceh: maybe he's spilled something?
<bryceh> no evidence of that
<kklimonda> maybe he's cleaned it afterwards ;)
<bryceh> (although he did do that to a laptop keyboard once)
<bryceh> heh, if I press both ctrl keys simultaneously it gives me a ctrl
<bryceh> well now that was fun
<JanC> bryceh: either ctrl doesn't give anything, but both combined does?
<bryceh> JanC, right
<bryceh> after messing with it a while I lost all keyboard input, so had to reboot anyway
<bryceh> think it might have been a window manager bug, although it affected the console too.  I'll see if it happens again.
<bryceh> JanC, yeah if I held the L ctrl and typed R ctrl, xev showed CTRL_R clicked, and vice versa.  interesting bug.
<JanC> if it works right after reboot, it sounds like its a software bug indeed, but still sounds weird  âº
<bryceh> yup
<JanC> laptop keyboard or USB ?
<bryceh> USB
<JanC> in case of USB, you can try to unplug/replug?
<bryceh> I did try unplugging/replugging a few times, but no effect
<JanC> then it's even weirder âº
<JanC> as I suppose some of the software stuff gets reset then
<JanC> bryceh: and if the console has the same bug, that might indicate a kernel bug  :P
<bryceh> yeah, nothing was in dmesg though
<bryceh> restarting the window manager had a weird effect.  It made it seem like ctrl was always depressed.  or something.
<bryceh> after restarting it once or twice more I lost keyboard entirely
<jschall> Can anyone help me with this problem? My touchpad is too sensitive after an update: http://pastebin.com/QfJkDKif
#ubuntu-x 2012-02-12
<jschall> how do i get rid of xorg-edgers? ppa-purge goes nuts and wants to hose my system
<FernandoMiguel> Sarvatt: ping
<FernandoMiguel> got a new dell n5110 for work, i7 
<FernandoMiguel> anything you want to throw at me to test or optimize?
<FernandoMiguel> fresh daily iso installed
<bjsnider> FernandoMiguel, you got _another_ new pc?
<FernandoMiguel> bjsnider: new job! 
<FernandoMiguel> this Dell Vostro is my own (home) one
<FernandoMiguel> it could have been a mac.... but I rather ask for a dell :p
<FernandoMiguel> so, ubuntu and chromeOS are installed onto it, and ready for my trip to Germany :\
<FernandoMiguel> *-*17ÂºC don't sound confortable 
<bjsnider> did it come with windows?
<FernandoMiguel> w7
<FernandoMiguel> home edition....
<FernandoMiguel> duh... at least it should have been professional.... boss was in an hurry
<FernandoMiguel> gonna give me troubles when I setup the LDAP domain :\
<FernandoMiguel> I was about to update my linkedin when you pingged me
<broder> besides xdpyinfo, where could i look as an X client if i wanted to learn more about my X server? i'm trying to come up with a fix for bug #682338 that actually distinguishes the NoMachine X server from the 6.7.0 server it was forked off of, but am having trouble making the distinction
<ubot4`> Launchpad bug 682338 in cairo (Ubuntu Precise) (and 2 other projects) "GTK programs in Ubuntu 10.10 are sluggish over NX (affects: 6) (heat: 26)" [Low,Triaged] https://launchpad.net/bugs/682338
<broder> err, sorry - 6.9.0
<broder> ServerVendor() is "The X.Org Foundation" and VendorRelease() is 60900000
<RAOF> tjaalton: Oh, are you packaging gstreamer-vaapi?
<Sarvatt> RAOF: yeah he's got it mostly ready to go
<RAOF> Funkiness.
<Sarvatt> big part of it was gstreamer-plugins-bad needing a dev package to build it and thats already done
<RAOF> Hm.  Today's sorta-public holiday might be dedicated to apitrace.
<Sarvatt> royal hobart regatta!
<Sarvatt> was holding off on the mesa 8.0 release merge because it sounded like intel QA found a lot of problems, but a few of these are pre-rc2 so we already have the problems
<RAOF> Hurray!
<RAOF> How does anyone ever get any work done on a 1366x768 display?
<Sarvatt> RAOF: you forget what its like having something usable after awhile..
 * RAOF wonders if any ivybridge systems are likely to ship with a 140+ DPI screen in a 12-14" form factor
<Sarvatt> i lived with 1024x600 exclusively for 2 years, dont know how the hell i did it anymore
<kklimonda> Sarvatt: really?
<kklimonda> Sarvatt: all I can use my netbook with 1024x600 is web browsing - but then I have a 24" HD display on my desktop, so small 10" feels more like a toy ;)
#ubuntu-x 2013-02-04
<bryce> NOUVEAU(0): [drm] failed to set drm interface version.
<bryce> mlankhorst, ^^ ideas on that one?
<bryce> nouveau drm driver appears to have loaded ok according to dmesg but X quits with that error
<mlankhorst> forgot, google is your friend probably, EOD for me
<mlankhorst> race condition with plymouth iirc?
<bryce> ah
<bryce> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/966871
<ubottu> Ubuntu bug 966871 in linux (Ubuntu) "X failed to start, failed to set drm interface version" [Medium,Fix released]
<bjsnider> what's the deal with this: http://www.phoronix.com/scan.php?page=news_item&px=MTI5MjI
<bjsnider> first time i've heard of software being rejected because there's "too much functionality"
<bryce> tjaalton, 1103345 is duped to 1099054 but the stack traces look different, so I'm thinking they're not dupes?
<tjaalton> bryce: it's the same user, so thought it's dupe anyway
<tjaalton> and 1115177 is probably a lightdm bug
<tjaalton> those started during quantal
<tjaalton> it's not behaving well with current plymouth
<tjaalton> I booted my ivb today after moving it under the new desk, and it took a few tries to actually get X running after boot
<tjaalton> stock quantal..
<tjaalton> the error message in xserver log can vary
<tjaalton> lightdm is doing tricks with plymouth, so that it can start the xserver before plymouth has exited or such
<bryce> uff
<tjaalton> so 1.4.0 made some racy changes that you can hit with a fast machine + ssd
<bryce> tjaalton, happen to know if there's a master bug about that?
<tjaalton> the one you found with google, bug 982889 :)
<ubottu> bug 982889 in xorg-server (Ubuntu) "X trying to start before plymouth has finished using the drm driver" [Undecided,Confirmed] https://launchpad.net/bugs/982889
<bryce> heh
<tjaalton> the description is actually misleading, since that's what lightdm does..
<bryce> well, guess what I'm asking is does someone else already know about this?  e.g. robert?
<tjaalton> he's never around :)
<tjaalton> wrong tz for me
<tjaalton> not sure if he knows
<bryce> ok, then I'll follow up with him when I see him
<bryce> we appear to have several of these bugs reported
<tjaalton> oh yes
<tjaalton> good thing that it doesn't affect 12.04.2
 * bryce nods
<bryce> think bug 1065288 is the same thing?
<ubottu> bug 1065288 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT "Cannot run in framebuffer mode"" [Medium,New] https://launchpad.net/bugs/1065288
<bryce> tjaalton, also am I correct in assuming that the DRM needs to hit Initialized *before* the xserver starts?  Versus just before DRI2 is initialized?
<bryce> one of the bugs showed DRM after DRI2, the other showed it before DRI2 but after xserver started
<tjaalton> yeah that's probably a dupe
<tjaalton> haven't really dug into these.. tried once but then my head said no after trying to make some sense of how it's supposed to run
<bryce> hmm, maybe not with 1065288, it doesn't follow the pattern; X is starting after DRM
<bryce> tjaalton, yeah andy and I tried back a few releases ago and tossed our hands up.
<tjaalton> heh
<bryce> but if it's true that DRM must hit init before X is started, that's something we can mechanically check for in bugs
<tjaalton> it's lightdm starting it..
<tjaalton> bryce: btw, can you see why #1041790 isn't shown on the list of raring intel bugs?
<bryce> ok
<bryce> tjaalton, it does not show up on http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-raring-workqueue.svg because that excludes bugs that have been forwarded upstream and are still open upstream
<tjaalton> oh
<tjaalton> guess i need to make my own searches :)
<bryce> yeah I'm working on adding more searches for types of queues we want, but that's medium priority work I only get to now and then... 
<tjaalton> no worries
<bryce> tjaalton, the one at the top of the list is "Bugs against X packages that the X team members are assigned to", so if that sounds suitable, I'll try to have it up by the end of this cycle
<tjaalton> bryce: yeah it could be useful
 * bryce bumps it up the todo list
<bryce> tjaalton, hmm robert says he just starts X when udev tells him to
#ubuntu-x 2013-02-05
<tjaalton> bryce: hmm, didn't seem that simple last time I looked, but could be wrong then
<tjaalton> actually, even if you take plymouth out of the equation (boot without splash) it still happens, so it's not the plymouth->lightdm interaction which is wrong, but lower down the stack.. (udev then?)
<mlankhorst> morning
<tjaalton> mlankhorst: hey, what's the status with llvm?-)
<mlankhorst> its on my list, just the fact that other things are on my list as well kept me from working on it ;P
<tjaalton> ok
<mlankhorst> need to resend some other patches first :)
<tjaalton> -intel 2.21.0..
<tjaalton> heh, ickle marked the sna video crash bugs as fix committed.. wondered where they went from the search view..
<mlankhorst> we should have ickle apply for PPU for xxv-intel :P
<tjaalton> hehe
<tjaalton> doubt he runs ubuntu, but arch or such
<mlankhorst> aw doesn't say from ctcp version
<tjaalton> hmm, I'll chat with doko about the possibility of a llvm snapshot for mesa..
<mlankhorst> ok :)
<tomreyn> Sarvatt, ricotz: i'm using xorg-edgers on 12.10 and am having some trouble with ACPI errors. Those should be fixed in mainline by now (and I assume in 12.10 default generic kernel images, too). Could you provide an updated kernel image (the 3.7.0 one dates back to december 15)?
<Sarvatt> tomreyn: I held off because iwlwifi is messed up on 3 of my machines in 3.8 and didn't want to inflict that on everyone, i'm bisecting that right now actually
<Sarvatt> try a mainline kernel?
<tomreyn> yes i'll try that
<tomreyn> thanks
<Sarvatt> just in the interim, shouldn't be too much longer
<Sarvatt> guess i shouldn't hold edgers to a higher standard that raring.. nevermind i'll copy it now :)
<tomreyn> :)
<Sarvatt> its synced now, will be up in about 6 hours or so
<tomreyn> thank you
<mlankhorst> Sarvatt: you don't, you jsut leave it at a 'works for me' standard which is sane ;P
<tjaalton> hm, no doko it seems
<bryce> Sarvatt, tjaalton think 1.13.99 is ready to stick in xorg-edgers?
<Sarvatt> are we doing 1.14 this cycle?
<mlankhorst> erm I thought we wouldn't go to 1.14?
<Sarvatt> not really looking forward to breaking unity when it wont be fixed until next release
<bryce> the main reason not to do 1.14 is that it would break tegra
<Sarvatt> re: the new pointer barrier stuff that landed in it thats different than ours
<bryce> however I've word NVIDIA will work on getting 1.14 support for tegra if we can put 1.14 in a ppa for them
<Sarvatt> oh easy enough to shove it in another ppa for that
<Sarvatt> would do that anyway to see how badly unity is broken
<bryce> Sarvatt, that'd work.  They'd need an arm build anyway.
<Sarvatt> edgers has arm, but good point..
<bryce> does it?  I only checked the cairo build for raring
<Sarvatt> knowing me i would have shoved it in a ppa without it and had to rebuild it all :)
<Sarvatt> odd
<Sarvatt> oh!
<Sarvatt> i386 build of linux 3.8.0-4.8 in ubuntu quantal RELEASE
<Sarvatt> Build started 2 hours ago on chindi07 (arm ppa builder) and finished 30 minutes ago taking 1 hour 50 minutes â see the log
<Sarvatt> thats why i was confused
<bryce> it builds i386 images on arm hardware?
<Sarvatt> builds arm on x86 hardware virtualized and i guess they use it for other arches when they are idle
<bryce> funkadelic
<bryce> ok, so if I can scare up an arm-enabled PPA, you can slam xserver in there, we can maybe get -tegra on the new abi, and then figure out the PB unity issue?
<Sarvatt> tomreyn: it's going to be longer than i thought, looks like linux-tools from raring doesn't build on quantal
<tomreyn> Sarvatt: alright, thanks for the update. i'll be fine.
<tjaalton> bryce: maybe the staging ppa then
<bryce> ok
<tjaalton> ..which should get enabled for arm if not already
<bryce> yep.  ok I'll check with achiang
<jcristau> bleh
<jcristau> gpg: BAD signature from "Maarten Lankhorst <maarten.lankhorst@canonical.com>"
<jcristau> on the libdrm announce.
<tjaalton> again :)
<jcristau> i blame thunderbird
<tomreyn> enigmail snapshots are currently more stable than the stable release.
<mlankhorst> jcristau: o.O
<mlankhorst> works here just fine
<Sarvatt> gpg: Signature made Tue 05 Feb 2013 08:17:00 AM EST using RSA key ID A67013C3
<Sarvatt> gpg: BAD signature from "Maarten Lankhorst <maarten.lankhorst@canonical.com>"
<Sarvatt> invalid here too :(
<mlankhorst> weird
<jcristau> mlankhorst: in icedove?
<mlankhorst> thunderbird from precise
<jcristau> yeah that's what i meant :)
#ubuntu-x 2013-02-06
<bryce> hum, there's an ickle in our bug tracker
<tjaalton> yeah
<Sarvatt> bryce: you didn't notice him pinging us about things? maybe because he only pings tjaalton now :) but yeah it's much appreciated
<bryce> yeah didn't see any pings much
<bryce> works for me; I got sick of forwarding all those bugs to bugzilla
<tjaalton> whoa, still four weeks until the feature freeze
<mlankhorst> :o
<mlankhorst> plenty of time to get unity through then
<tjaalton> yup
<tjaalton> and mesa :)
<tjaalton> slash llvm
<mlankhorst> yeah llvm is the blocker atm
<tjaalton> doko doesn't seem to be around..
<tjaalton> maybe I'll just create the snapshot and we can bikeshed it later
<mlankhorst> sure
<mlankhorst> could you do a patch to debian/rules for libLLVM-3.2.so too?
<tjaalton> for the snapshot, not mesa?
<mlankhorst> yeah seems like a packaging error
<mlankhorst> looks like we will also need a newer dh-exec in precise to build it
<mlankhorst> tjaalton: first stab at fixing things, pending build.. http://paste.ubuntu.com/1616315/
<mlankhorst> probably messed up with email address
<tjaalton> mlankhorst: thanks. so the r600 tree is based on 3.2, so it should be possible to create a (huge) diff that just pulls the backend..
<mlankhorst> yeah needs to be ubuntu-devel-discuss@ubuntu.com
<mlankhorst> but agreed, big diff ought to be reasonable for now, maybe package llvm-3.3 snapshot too before freeze, then choose which one we want to keep closer to 9.1 release?
<tjaalton> i guess it's easier to go the diff route
<mlankhorst> yeah but would be nice if we could reach to an agreement with doko about it
<tjaalton> of course
<tjaalton> upstream doesn't seem to use tags, or they don't work on the git mirror
<mlankhorst> probably using svn
<tjaalton> yep
<mlankhorst> http://paste.ubuntu.com/1616523/ fixed version that worksforme (TM)
<tjaalton> why did you touch the source-building target?
<mlankhorst> because it was upset at my quiltrc file
<tjaalton> what would be the changelog entry for the symlink?-)
<tjaalton> I'll create an "official" debdiff for doko
<tjaalton> adding the r600 backend was a breeze
<mlankhorst> erm something like "remove extra libLLVM-3.2.so.1 installed by llvm-3.2-dev"
<mlankhorst> and "add libLLVM-3.2.so symlink to /usr/lib/llvm-3.2/lib to satisfy programs expecting it to be there (mesa)"
<tjaalton> ok, building
<tjaalton> bah
<tjaalton> forgot to enable the backend
<mlankhorst> :-)
<tjaalton> --enable-experimental-targets=R600
<mlankhorst> but is the diff isolated to just adding the extra target, then?
<tjaalton> yes
<tjaalton> http://pastebin.com/Ld5stjBa :)
<tjaalton> or rather http://pastebin.com/ygUcWEaF
<tjaalton> diffing tstellars master to release_32
<tjaalton> pinged sylvestre to hear what he thinks about adding the patch..
<tjaalton> built fine btw
<mlankhorst> hm to sru mesa 9.0.2 I would have to revert a whole bunch of wayland patches
<mlankhorst> seems to be easier if I could just disable wayland altogether
<mlankhorst> oh it built
<mlankhorst> git diff a5776ac0b8c015bf5d6a8513cefec5920895cc8e^ src/egl/wayland/ src/egl/drivers/dri2/*wayland* src/gallium/state_trackers/egl/wayland/   src/egl/drivers/dri2/egl_dri2.h | patch -Rp1
<tjaalton> should I upload llvm to x-staging?
<mlankhorst> sure, for raring I guess?
<tjaalton> yup
<mlankhorst> shall I push my WIP for mesa 9.0.2 sru to ubuntu-quantal branch?
<tjaalton> yup
<mlankhorst> done
<mlankhorst> just need to find some bug as justification, or maybe I should file one and find an excuse to play supreme commander for a few hours
<mlankhorst> ;P
<mlankhorst> bryce: since you were running piglit tests before, what is the setup you use to check for regressions between micro releases?
<mlankhorst> argh stupid game won't crash! need another testcase now
<tjaalton> wth again https://launchpadlibrarian.net/130535383/upload_4278734_log.txt
<mlankhorst> 6 mar?
<tjaalton> huh
<mlankhorst> from that log
<tjaalton> so it is my machine
<tjaalton> shit
<tjaalton> how did that happen..
<mlankhorst> did you suspend a few times? I had it live a year in the future with that sometimes
<tjaalton> hibernate
<mlankhorst> guessing that's possibly why :-)
<tjaalton> great, git histories messed up then
<tjaalton> hum, so canonical-x staging ppa has the arm builders set up, so perhaps it's best to use that one instead..
<mlankhorst> you can get arm builders on your own ppa if you awnt
<tjaalton> well this is one hassle less
<tjaalton> pushed llvm there, fixed timestamps first
<tjaalton> should upload fine now..
<tjaalton> cleaned canonical-x/staging from old packages
<bryce> mlankhorst, piglit includes a script that lets you chart several runs together, that's really all I've been using to do comparisons.  I probably should get something a bit more structured set up... some day.
<mlankhorst> :/
<bryce> mlankhorst, what exactly are you looking for?
<mlankhorst> some structured way to run tests for mesa 9.0 against mesa 9.0.2 for sru'ing to quantal
<bryce> mlankhorst, this is basically what I use:  http://paste.ubuntu.com/1617512/
<bryce> then like I said, I do the comparisons by running that other command manually
<bryce> mlankhorst, the original script I was using is http://paste.ubuntu.com/1617523/, but just runs one test
<bryce> Sarvatt, to set up an xorg-server 1.14 ppa, what all needs done?  Will we need the protos and so on too?  Can we just use the edgers scripts to do the snapshot?
<tjaalton> bryce: we already have the ppa
<tjaalton> canonical-x/staging
<tjaalton> it has arm builders and all
<tjaalton> pushed llvm for mesa there, not sure if that gets in the archive or not
<tjaalton> and it only needs to carry the server & drivers
<bryce> tjaalton, ah thanks
<tjaalton> protos, libs (if any) we can push to raring
<Sarvatt> inputproto and libxi should be all that needs updating besides xserver
<tjaalton> yeah
<bryce> tjaalton, ah I mean I'm looking for xserver in particular
<tjaalton> mlankhorst has tested some rc already, not pushed anywhere yet
<mlankhorst> build tested
<tjaalton> ship it
<tjaalton> no commits upstream since jan 23rd
<tjaalton> keithp has been travelling
<bryce> looks like we're mostly caught up on the proto packages that have been released, so I guess unless they depend on changes only in git, we should be ok?
<bryce> we have inputproto 2.2.99.1 already, libxi could be updated
<tjaalton> oh we had that
<Sarvatt> yeah whoops, just uploaded inputproto to the ppa too :P
<bryce> oh that's not supposed to be in raring?
<tjaalton> just delete it :)
<tjaalton> no harm having it in raring..
<bryce> ok
<Sarvatt> doing libxi now
<bryce> has someone already snapshotted xserver?  We going to use what's in the ubuntu+1 branch currently, or update to a newer snapshot?
<tjaalton> need newer
<bryce> it's from Jan 9th, so fairly new
<bryce> ah ok
<tjaalton> bumps xi minor version etc
<tjaalton> and major too..
<tjaalton> err, input abi I mean
<tjaalton> 35 commits since then
<Sarvatt> xi's up there, doing xserver now
<tjaalton> use git too..
<tjaalton> :)
<tjaalton> because we'd be able to then binary copy the packages straight to raring
<Sarvatt> well hell, i thought we just wanted a testing ppa
<tjaalton> so same standards apply :)
<tjaalton> we can have both! :)
<tjaalton> at the same time
<tjaalton> maybe there was some miscommunication then, sorry :/
<bryce> hum, I'm trying to understand how raof's pointer barrier velocity changes got taken upstream, but am having trouble seeing it.  It appears no one gave review comments on the patches upstream, and I don't see anything relating to velocity in the current xfixes/cursor.c.  What am I missing?
<bryce> is it possible we are going to need to keep the patch and forward port it?
<tjaalton> haven't looked
 * bryce looks harder
<bryce> ah? http://lists.x.org/archives/xorg-devel/2012-June/031647.html
<bryce> ok, it's there.  s/velocity/dx,dy/ and so on :-)
<tjaalton> maybe just ask jasper/peter :)
<tjaalton> ah
<bryce> yep, found everything I needed.
<tjaalton> Sarvatt: I've cherry-picked your commits to u+1 to d-e ;)
<tjaalton> libxi uploaded to raring
<bryce> tjaalton, need help with anything?
<mlankhorst> sleeping, I would imagine :-)
#ubuntu-x 2013-02-07
<tjaalton> bryce: what mlankhorst said :) guess it's xserver and at least some drivers today
<tjaalton> llvm built, finally
<tjaalton> still no sign of doko or sylvestre
<tjaalton> I'll just email them
<tjaalton> updating libdrm for newer mesa snapshot
<mlankhorst> I guess I better test mesa 9.0.2 now then :P
<mlankhorst> time to run the piglit tests I suppose
<tjaalton> meh, how hard can it be to get reprepro signing work.. i've done this before, years ago
<RAOF> What are you trying to do?
<tjaalton> to test the builds locally with sbuild
<tjaalton> pulling from a local repo
<tjaalton> include/export works, now sbuild-update claims the pubkey isn't known
<RAOF> http://paste2.org/p/2834017
<tjaalton> oh :)
 * mlankhorst just builds on launchpad with high priority, evil, I know
<mlankhorst> I do feel guilty about it though, so it's ok!
<RAOF> tjaalton: Dump in /etc/schroot/setup.d as 60add-local-repository, combine with http://paste.ubuntu.com/1619254/ and you've got a raring-local chroot that builds against ~/Builds
<tjaalton> that's neat
<tjaalton> I'll probably use reprepro still for some stuff, but this is good enough for builds :)
<mlankhorst> but if I had to test before pushing, I'd probably mess up my own raring chroot/netboot image instead. It can do both :-)
<RAOF> Arsing llvm
<RAOF> What's a man got to do to build mesa in a ppa these days :)
<mlankhorst> push dh-exec 0.6 to precise? :P
<tjaalton> next I'd like it to build under /run/shm, guess my ssd will wear more quickly because of sbuilding all the time :)
<mlankhorst> It needs 0.3 or newer for building llvm-3.2
<RAOF> tjaalton: Heh. My sbuild config used to also have raring-tmpfs, too, before btrfs-snapshot.
<mlankhorst> tjaalton: it will kill itself even faster here because I'm using encryption, I tested, it's not cpu limited any more after a fix!
<mlankhorst> and it's going like 400 mb/s 
<RAOF> tjaalton: I could probably find the config I was using to do tmpfs stuff.
<tjaalton> that would be nice
<tjaalton> my ssd died after one year, so will try to minimize it's use now
<mlankhorst> I'm a terrible person, and keep backups for that. :-)
<tjaalton> me too, but only of my own $HOME, screw the others :)
<tjaalton> or the system files
<mlankhorst> oh everything important is in a git repository
<tjaalton> still don't have a working smtp config..
<RAOF> Actually, from memory I think it's pretty easy - you mount /var/lib/schroot/tmpfs-overlay in /etc/fstab, then use that as the overlay dir in the schroot config.
<mlankhorst> since ssd's have been so fast I've been pretty lazy though. I'm just building from ssd since doing otherwise takes more effort and longer
<tjaalton> i have 16 gigs of ram, better use it for something!
<mlankhorst> I do too
<mlankhorst> Cached:         12110996 kB
<mlankhorst> it's practically building from memory already
<tjaalton> hmm, I should probably clean up my build dir :)
<tjaalton> a ton of cruft there slowing sbuild down
<mlankhorst> that's why I don't use tmpfs ;-)
<tjaalton> the destination is on ssd
<tjaalton> E: 60add-local-repository: gpg: keyring `/var/lib/sbuild/apt-keys/secring.gpg' created
<tjaalton> E: 60add-local-repository: gpg: keyring `/var/lib/sbuild/apt-keys/pubring.gpg' created
<tjaalton> E: 60add-local-repository: gpg: no default secret key: secret key not available
<tjaalton> E: 60add-local-repository: gpg: signing failed: secret key not available
<tjaalton> did I miss something?
<tjaalton> probably should create the key first :)
<tjaalton> meh, refuses to install llvm-3.2-dev
<tjaalton> RAOF: I guess your sbuild runs update too :)
<mlankhorst> did I mess up? :s
<mlankhorst> oh wait in sbuild I suppose
<tjaalton> nah, it's the repo
<tjaalton> well, now it's claiming libdrm* is unsigned
<tjaalton> the llvm maintainer promised to add the backend \o/
<mlankhorst> \o/
<tjaalton> grr
<tjaalton>  sbuild-build-depends-mesa-dummy : Depends: libdrm-dev (>= 2.4.39) but it is not going to be installed
<mlankhorst> you forgot to bump libdrm-dev? :P
<mlankhorst> probably needs to be 2.4.42 there
<tjaalton> didn't update the branch yet
<tjaalton> this is the apt resolver failing
<tjaalton> refuses to install stuff from the local repo
<tjaalton> ok, it was 2.4.42-1 test build that was broken
<tjaalton> rebuilt -0u1 and it's fine now
<tjaalton> mlankhorst: did you test that it built using shared llvm libs?
<tjaalton> I got the same issue with gensymbols
<tjaalton> or did i
<mlankhorst> I'm testing on quantal atm
<mlankhorst> I want to get the 9.0.2 sru done first :)
<tjaalton> I'll pastebin this.. guess it's normal after all
<tjaalton> http://pastebin.com/8bMUBdDU
<tjaalton> hm no :)
<mlankhorst> do you have the full debdiff to llvm-3.2 btw? I'm missing radeonsi
<mlankhorst> hm indeed, tons of symbols
<mlankhorst> sounds like it statically linked against libgallium or something
<mlankhorst> surprise surprise, it probably did
<mlankhorst> oh well build libgallium dynamically and you're fine
<tjaalton> is there a separate option for it?
<mlankhorst> one line hack would be noinst_LTLIBRARIES -> lib_LTLIBRARIES
<mlankhorst> in src/gallium/auxiliary/Makefile.am, but no idea if it works yet
<tjaalton> ok
<tjaalton> wth, the diff with the upstream branch shows changes all over the place
<mlankhorst> aw still broken
<mlankhorst> grabbing rbug, svga and some vmw symbols
<mlankhorst> could be fixed in the same way I suppose
<mlankhorst> either that or I just hack in the visibility things for now
<mlankhorst> probably better for now
<tjaalton> so my merge of git master on jan 9th created issues
<tjaalton> dunno what's the best way to get out of it, other than maybe cleaning them up in a separate commit, or losing history of debian/
<mlankhorst> do you want to rewind?
<mlankhorst> or move forward
<tjaalton> well, rewind wouldn't be that bad
<tjaalton> I guess..
<mlankhorst> well trying to build it atm, hopefully working this time by adding some visibility cflags back
<tjaalton> I'll rebuild the branch, first merge whatever was there before the bad merge, then cherry pick the commits to debian/ after that
<mlankhorst> down a lot of symbols..
<mlankhorst> still missed a few
<mlankhorst> driver_descriptor@Base remaining
<mlankhorst> as good as it gets I suppose
<mlankhorst> tjaalton: http://paste.ubuntu.com/1620151/
<mlankhorst> there's probably a better fix, but meh..
<tjaalton> mlankhorst: ok, thanks
<mlankhorst> you need to add driver_descriptor@Base to the symbols list btw
<tjaalton> sigh
<tjaalton> conclusion; git merge does funky stuff
<tjaalton> despite merge -s ours
<tjaalton> i got exactly the same diff
<tjaalton> for some reason it decides the remote is more important
<mlankhorst> you can override it. :P
<mlankhorst> git checkout whatevercommit . git commit --amend
<tjaalton> hmh?
<mlankhorst> to amennd the merge commit
<tjaalton> what's whatevercommit
<mlankhorst> erm what you want the HEAD to look like after merge
<tjaalton> sure I can touch whatever but it's work
<tjaalton> http://pastebin.com/kGwnuACC
<mlankhorst> git rm debian src; git checkout COMMIT src ?
<tjaalton> don't want to lose history for debian
<mlankhorst> erm skip the rm debian then
<tjaalton> hmm
<tjaalton> hah
<tjaalton> did the trick
<tjaalton> amended with the merge
<tjaalton> checkout $path sounds interesting..
<mlankhorst> :-)
<tjaalton> well, it does lose history, so it's not useful for pulling the packaging
<mlankhorst> not really? or at least git log debian/ kept working for me
<tjaalton> only if your branch had debian/ at some point
<mlankhorst> yeah you need to start from debian branch
<tjaalton> but if you checkout the upstream branch and then the packaging on top of it
<tjaalton> right
<tjaalton> works for src/ etc
<tjaalton> now where was I ..
<tjaalton> have a dozen branches to weed through :P
<tjaalton> attached a power meter between the outlet and ups, combined consumption is around max 200W including the monitor and DAC when building mesa with ivb :)
<tjaalton> idle is 90-100
<tjaalton> libgles2 needed one symbol added, seems fine now
<tjaalton> mlankhorst: libxatracker1 is still big, but at least it didn't complain about the symbols
<mlankhorst> tjaalton: yeah that was the goal :-)
<mlankhorst> I didn't feel like making all those libraries shared just yet
<tjaalton> ok now onto the ubuntu branch..
<mlankhorst> well radeon piglit results done, now i915 I suppose.
<mlankhorst> well afaict no regressions on radeon \o/
<tjaalton> ugh, the gallium dricore patches make my head hurt.. I'll just push what I have so far
<mlankhorst> want me to rebase the gallium and dricore patches again? :P
<tjaalton> well, yeah, all the files 117 touches have vanished :)
<tjaalton> for starters
<mlankhorst> well I'm waiting on piglit to finish anyway
<mlankhorst> why not
<tjaalton> mlankhorst: force-pushed
<mlankhorst> tjaalton: nitpick, it's not from llvm. it's from libgallium and those other static libs where I added the flags to
<tjaalton> well, do it properly and we can drop the patch :)
<tjaalton> with a properly-named one
<tjaalton> er, replace it with..
<mlankhorst> I'm probably just going to push it upstream..
<tjaalton> of course, even better
<mlankhorst> tjaalton: 117 patch should no longer apply, but the fix is even easier to make :-)
<tjaalton> good
<mlankhorst> but I think it's better to just check with upstream first
<mlankhorst> actually I guess I could just do an ugly hack for now
<mlankhorst> seems we don't add version to libgallium in previous patches anyway
<mlankhorst> done with libgallium, now dricore gallium..
<mlankhorst> oh right, that one was annoying
<mlankhorst> it was a bit of abuse since I needed libmesagallium to be done after libdricore, so I had to move it to the mesa/libdricore directory
<mlankhorst> wow, only d3d1x is still using makefiles
<mlankhorst> ok I'm still thinking about the best way to approach the dricore fix, but gallium was easy
<tjaalton> so it wasn't a great idea to push libxi to raring, need to revert the new stuff for now :P
<mlankhorst> broke unity?
<tjaalton> kde builds
<mlankhorst> ah, worse
<tjaalton> but probably others too
<tjaalton> if includes both XInput2.h and Xfixes.h it'll go boom, duh
<mlankhorst> well lets see if it builds now
<mlankhorst> oh right
<mlankhorst> need new llvm and new libdrm
<mlankhorst> tjaalton: I pushed what I have
<mlankhorst> it's guaranteed to break on building
<mlankhorst> but hopefully that only happens when it finds a new libmesagallium*.so
<mlankhorst> if not, let me know
<tjaalton> yup, fails
<tjaalton> http://pastebin.com/xQM8QVb5
<ricotz> tjaalton, hi :)
<ricotz> mlankhorst, hey
<ricotz> tjaalton, did you notice some conflicts between libxi-dev and libxfixes-dev?
<ricotz> /usr/include/X11/extensions/Xfixes.h:274:17: error: conflicting types for 'BarrierEventID'
<ricotz> /usr/include/X11/extensions/XInput2.h:173:22: note: previous declaration of 'BarrierEventID' was here
<Sarvatt> #ubuntu-devel :P
<ricotz> ah good
<mlankhorst> ricotz: hello
<tjaalton> ricotz: yeah, fixed already
<tjaalton> I'll upload another one to the ppa, reverting the revert.. and then libxfixes dropping the old stuff
<ricotz> tjaalton, thanks!
<mlankhorst> tjaalton: yeah looks like I'm including too much somehow
<mlankhorst> I guess you need to exclude state_tracker/st_glsl_to_tgsi.cpp from the 118 patch
<mlankhorst> in src/mesa/libdricore/Makefile.am
<ricotz> tjaalton, will be barrier stuff move away from xfixes?
<ricotz> be/the
<mlankhorst> looks funny there anyway, it was probably to work around some issue
<tjaalton> ricotz: yes
<ricotz> tjaalton, ah i see
<tjaalton> slightly different anyway
<mlankhorst> tjaalton: anyhow I have to leave for a bit, I think that specific issue should be easy to fix with that hint :-)
<tjaalton> mlankhorst: ok, I'll give it a got..
<tjaalton> -t
<mlankhorst> afk!
<tjaalton> fixesproto and lib pushed to c-x/x-s
 * mlankhorst back-ish
<tjaalton> hmm, could I upload xserver to the ppa then
<mlankhorst> did you get mesa running?
<tjaalton> ah, no
<tjaalton> http://pastebin.com/xQM8QVb5
<mlankhorst> that's  the same you posted earlier?
<tjaalton> oh right :)
<tjaalton> http://pastebin.com/p65CeikP
<mlankhorst> oh so that's why I needed that file
<mlankhorst> tjaalton: I pushed the fix, I hope..
<tjaalton> building..
<tjaalton> mlankhorst: http://pastebin.com/axgf3Wst
<mlankhorst> still the case? evil!
<tjaalton> :)
<mlankhorst> I guess it needs to be moved around
<mlankhorst> tjaalton: what if you move that egl_gallium_la_LIBADD += $(MESAGALLIUM_LIBS) line in egl-static/Makefile.am all the way down to bottom of the file?
<mlankhorst> I'm just guessing, I need to get my hands on a working llvm-3.2 build
<tjaalton> mlankhorst: grab it from the ppa :)
<tjaalton> mlankhorst: still the same
<mlankhorst> oh :/
<mlankhorst> I'll look tomorrow
<tjaalton> yeah
<Sarvatt> tjaalton: going to upload xserver?
<Sarvatt> or want me to do it? I can do the drivers too
<Sarvatt> oh, long queues :(
<Sarvatt> and sorry for not pushing it to expeirmental, didn't realize it was there also
<tjaalton> ha, no worries, sorry for being tired/grumpy last night :)
<tjaalton> feel free to upload them!
<Dandel> Sarvatt: I spotted a major problem with piglit packages :/
<Dandel> when running from installed packages, I found out that resume is broken.
<Sarvatt> doh, did it just start happening one day or always been like that?
<Sarvatt> it's building daily git snapshots and i haven't looked at git in like 8 months
<Dandel> it's not a one day issue
<Dandel> it's a combination of bugs
<Dandel> 1 sec while i get the log from git to find out which commit is the likely culprit. 
<Dandel> most likely, it's this file ( in combination): http://cgit.freedesktop.org/piglit/log/framework/shader_test.py
<Dandel> Sarvatt: also, on a similar note, piglit really needs to capture the core dumps ( and heap stacks )
<bryce> Dandel, agreed
<bryce> Dandel, well possibly we need a wrapper
<Dandel> bryce: that's actually somewhat easy to "mimic"
<Dandel> it already can identify when the test crashes
<Dandel> it just needs a little bit of expansion ( based on what xbmc does for their launcher ) to be able to fully capture the stack.
<Dandel> Sarvatt: I have a few fixes that should work... want to give em a try?
<Dandel> just double checked, and there's some patches on the piglit mailer that seem to address the issue about resuming tests.
#ubuntu-x 2013-02-08
<mlankhorst> morning
<tjaalton> same
<tjaalton> looks like the r600 llvm branch got a bunch of updates, I'll update the patch and feed it back to the maintainer, we'll get the proper version then
 * RAOF will need to build a desktop system to stick his southern islands chip in, I see.
<tjaalton> i'll be getting one early next week too
<tjaalton> nice to have a discrete card with displayport :)
<tjaalton> hate the thick dvi cable, which doesn't fit the kvm switch either
<Dandel> displayport's in a lot of radeon cards... just depends on the card.
<tjaalton> these days yes
<tjaalton> not in my hd6450
<tjaalton> or nvidia gf8600gt
<Dandel> i see... i have two main gpus with it ( hd5770 and nvidia gf gt545 )
<Dandel> sadly, the laptop i work from didn't get it ( but at least it has two gpus and hdmi out to work with )
<tjaalton> my laptop has, but owned by nvidia so not available :)
<Dandel> actually, I'm wondering when the the xorg edgers ( for 12.04 ) will see prime support... I'm itching to see what mesa can do with the hd6650m i have ( so far all i could try with mesa is the hd6520G )
<Dandel> anyways, I noticed something interesting... The xorg edgers kernel for 12.04 lts doesn't fully match all the options from the stock kernel from ubuntu... two key modules are not built/included ( namely vesafb and uvesafb ).
<tjaalton> probably matches that of a later release
<tjaalton> *fb are evil anyway
<Dandel> tjaalton: not when it knocks out virtual terminal 1 to 6 :/
<tjaalton> why would it do that?
<Dandel> nvidia/ati/amd blobs
<tjaalton> don't see them requiring vesafb?
<Dandel> it's a combination of things... when i boot normally with radeon driver, i get terminals, but the moment i switch to fglrx, it is lost
<Dandel> tjaalton: normally it's included with ubuntu 12.04 ( and 12.04.1
<tjaalton> also in quantal & raring
<tjaalton> dunno then
<Dandel> precise.
<tjaalton> it's edgers..
<Dandel> hmm... oh wait... might be the kernel... i did install mainline 3.5.0-030500
<tjaalton> ..
<tjaalton> :)
<Dandel> however, it does not change that uvesafb is not even loaded ( i noticed that it was included )
<tjaalton> mlankhorst: fixed mesa yet? ;)
<mlankhorst> tjaalton: I'll take a look
 * mlankhorst has sports on friday morning :)
<tjaalton> i get to shovel snow, makes us even
<mlankhorst> building llvm first
<mlankhorst> oh right looks like you get to update a lot of packages for missing mibstore
<tjaalton> yeah, doing -qxl
<mlankhorst> you get a bonus if you're going to run xorg-integration-tests too :D
<tjaalton> on what?
<mlankhorst> new xserver
<tjaalton> not today
<mlankhorst> tjaalton: argh you took out my quiltrc from llvm? :(
<tjaalton> you get to explain that to the maintainer, and changelog :)
<tjaalton> or just changelog, I'll give the diff to sylvestre anyway
<mlankhorst> "* Set QUILTRC environment to /dev/null so if a user specifies a custom QUILT_PATCHES in their quiltrc the build will not fail"
<tjaalton> thx
<mlankhorst> tjaalton: did libdrm fail to build on raring or did you not push something to libdrm git?
<tjaalton> I did push, it's in raring
<mlankhorst> dh_install: usr/share/man/man3/drmAvailable.3 exists in debian/tmp but is not installed to anywhere
<mlankhorst> was getting a few of those
<tjaalton> hmm, not here
<mlankhorst> I pushed the fix anyway
<mlankhorst> oh right
<mlankhorst> need to enable xsltproc
<tjaalton> so you had that installed?
<mlankhorst> yeah it should be a build dep
<tjaalton> k
<mlankhorst> cherry picked to debian branch
 * mlankhorst has faith in git merge
<mlankhorst> checking for docbook manpages stylesheet... no
<mlankhorst> aw 
<jcristau> you need docbook-foo i guess
<mlankhorst> needs docbook-xsl
<mlankhorst> tjaalton: fixed up libdrm, no idea if it's worth pushing to raring though
<mlankhorst> weird, don't see dricore or mesagallium linked
<mlankhorst> oh I'm an idiot
<mlankhorst> tjaalton: I'll fix it shortly
<tjaalton> drivers almost fixed
<mlankhorst> finishing my test build first
<mlankhorst> heh, fails on some documentation stuff
<mlankhorst> build-stamp no longer works correctly
<mlankhorst> tjaalton: are those pkgstriptranslations hacks still needed?
<tjaalton> not sure
<mlankhorst> it breaks for me
<tjaalton> how?
<mlankhorst> no longer works because of conversion to automake
<tjaalton> ah
<tjaalton> guess I never got that far with the ubuntu branch
<mlankhorst> I guess I'll remove the NOT_INSTALLED_EITHER stuff too, no point to remove glut if it's not inside the mesa tree any more
<tjaalton> yeah that's possibly lost in the merge
<tjaalton> not-installed was slimmer before, but couldn't see why :)
<tjaalton> damn -sis
<mlankhorst> well no idea what the whole not-installed is for now
<mlankhorst> just getting in the way now
<tjaalton>         dh_install -s --fail-missing
<tjaalton> ?
<mlankhorst> yeah that fails because it removes some files
<tjaalton> so drop them from the list
<mlankhorst> yeah
<mlankhorst> still missing some deps
<mlankhorst> dpkg-shlibdeps hates me
<mlankhorst> other than that, should build at least
<mlankhorst> tempted to throw in a -Wl,--as-needed ... -Wl,--end-as-needed hack
<mlankhorst> s/end/no/
<mlankhorst> libxatracker1 needs libdrm, libgbm needs something from egl/wayland/wayland-drm and libdrm,  some need libstdc++, libgallium needs to link against llvm, libdricore needs to link against libglapi
<tjaalton> goddammit wacom
<mlankhorst> you know what, I'm just going to see if the libraries work or not..
<mlankhorst> actually it won't work afaict
<tjaalton> video drivers all built, wacom hopefully too in a minute
<mlankhorst> libgallium hates me slightly less now
<tjaalton> wacom still laughs at me
<tjaalton> i'll just disable the tests, like fedora..
<mlankhorst> :-)
<mlankhorst> -$(LLVM_CFLAGS) +@LLVM_CFLAGS@, should fix libgallium complaining
<mlankhorst> somehow didn't.. what's going on
<mlankhorst> oh, lacking LLVM_LIBS 
<tjaalton> virtualbox doesn't build on current raring, so apart from that the ppa should soon be all green
<tjaalton> mesa seems to build too
<tjaalton> but not ok yet?
<mlankhorst> ok screw it.. I'm building libmesagallium static again, no easy way for dynamic build
<mlankhorst> it should just be in libgallium.so now
<mlankhorst> instead of separate
<mlankhorst> mesa's a mess.. hope shlibdeps will stop complaining too much now
<mlankhorst> pushed, if you want to test on raring, it should hopefully work now but dont push it to archive yet :)
<tjaalton> not to staging either?
<tjaalton> that's where I was meaning to put it
<tjaalton> and that's where it went :)
<mlankhorst> ah sure push to staging
<Evpok> Hi, there. I am testing raring and having an issue with custom symbols files
<Evpok>  I use a custom /usr/share/X11/xkb/symbols/fr. It used to be loaded a startup before raring. Now at startup, the default fr symbol file is used instead. When I `setxkbmap fr -variant oss`, my custom file comes back, but it blocks the keyboard layout applet in the system tray.
<Evpok> *the kde keyboard layout applet
<Evpok> Is there anyone with an idea on why?
<Dandel> it appears test resumes on piglit will appear with the updated build of piglit in the next 24 hours ( infrastructure fixes have taken place )
<bryce> anyone else having trouble pulling up wiki.x.org?
<Dandel> bryce: Just checked; yes... taking greater than 30 seconds to load page
<bryce> Dandel, thanks.  reporting.
#ubuntu-x 2013-02-09
<Sarvatt> Dandel: you need to install linux-image-extras for anything quantal kernel config based, aka 3.5+ stuff
<Sarvatt> those modules are in that package
<Sarvatt> Dandel: you can install linux-image-generic-lts-quantal which will install the metapackage to get quantal kernels on precise also that will pull in -extras automatically
<Dandel> Sarvatt: Understood, but the issue i'm pointing out has increased importance when the kernel has config_vt completely removed
<Dandel> is there any way to use optirun and have it keep all opengl executions made within a script to go to the nvidia gpu?
<Dandel> without having to call optirun each time an opengl program is ran
#ubuntu-x 2014-02-05
<jinzo> Hello
<jinzo> I'm not sure if this is the correct place but newertheless: I'm using ubuntu 12.04 Precise and I'we been playing with the xorg-edgers ppa
<jinzo> the interesting thing is that when I upgraded the glxinfo displays the OpenGL string: OpenGL version string: 2.1 Mesa 9.2.0 and the previous (raring enablemend stack turned on) said OpenGL version string: 3.0 Mesa 9.1.7
<jinzo> so I'm only geting OpenGL 2.1 instead of OpenGL 3.0 if I'm not mistaken?
<jinzo> The graphic card is RV710
<jinzo> hm, also my /usr/lib/x86_64-linux-gnu/dri/ directory was last modified in october
<jinzo> oh I see. It actually odesen't contain newer packages for precise
<jinzo> So it looks like the best/most up to date packages I can get on Precise is to use the LTS Enablement to raring stuff?
<jinzo> but then again I'm hitting some race condition on startup there that I have to check and sort out
<Prf_Jakob> Hey does anybody know which mesa version you are going to use for 14.04?
<Prf_Jakob> And does anybody know where the ubuntu kernel guys hang out?
<Prf_Jakob> We (VMware) would like to backport some hw enablement code to the 14.04 kernel.
<ogra_> Prf_Jakob, try #ubuntu-kernel 
<Prf_Jakob> ogra_: thanks
<tjaalton> Prf_Jakob: 10.1 is the plan
<tjaalton> 10.1.x
<Prf_Jakob> tjaalton: thanks
#ubuntu-x 2014-02-07
<tjaalton> hmm xmir crashers.. even with latest versions
<mlankhorst> no surprise there
<mlankhorst> they still didn't merge the multiscreen fixes that have been queued since saucy :p
<mlankhorst> afaik
<tjaalton> why keep those patches around if all they cause is new bugreports..
<mlankhorst> i have no idea
#ubuntu-x 2014-02-08
 * JanC tries to remember how to tell Ubuntu/Xorg to Do The Right Thing and read ~/.XCompose ...
<jcristau> JanC: you mean gtk.
<JanC> jcristau: well, yeah, although "Ubuntu" sort of implies that...
<jcristau> no, it really doesn't
<JanC> jcristau: Ubuntu desktop is (for now?) almost entirely Gtk-based, so yes it does
<JanC> but probably not something Xorg devs can help with  :)
#ubuntu-x 2015-02-02
<jderose> does anyone know when the *-lts-utopic packages will get included in the daily trusty ISO? in other words, where  are the 14.04.2 ISOs being staged?
<tjaalton> not here, try -release
<jderose> tjaalton: gotcha, thanks!
<mlankhorst> considering the release is on the 5th, i would imagine 'soon'
#ubuntu-x 2015-02-04
<tjaalton> Noskcaj: libinput 0.9.0 is now in experimental, should it be synced now and transition things to use it?
<Noskcaj> tjaalton, I've got it all done in a staging PPA, just need o make debdiff for the bug. If you have upload rights, could you please take the stuff of ppa:noskcaj/libinput, fix the versions, and upload
<Noskcaj> s/o/to
<Noskcaj> and it can be synced
<tjaalton> ok sounds good
<Noskcaj> is that sounds good to make debdiff or sounds good to you will sponsor from PPA?
<tjaalton> i'll do it
<Noskcaj> great
<Noskcaj> ty
<tjaalton> "for the bug" meaning what exactly?
<tjaalton> is there a tracking bug?
<Noskcaj> yeah
<Noskcaj> bug 1416274
<ubottu> bug 1416274 in weston (Ubuntu) "libinput 0.9.0 transition" [Undecided,In progress] https://launchpad.net/bugs/1416274
<tjaalton> thanks
<tjaalton> so I'll sync libinput first then
<tjaalton> need to bump build-deps too
<ogra_> tjaalton, hmm, does your libinput upload add a new system group ? 
 * ogra_ sees all touch images fail with out of sync /etc/group 
<tjaalton> huh, no
<ogra_> something adds an input group at install time 
<ogra_> but yeah, your upload cant be it ... the images failed before it landed
<tjaalton> only the source has been released to vivid-proposed on a.u.c so far
<ogra_> yeah, i missed the timestamp :)
<ogra_> sad, it seemed so obvious :P
<tjaalton> it's just a lib :)
<ogra_> yeah, buut now i need to actually dig :)
<tjaalton> have fun
<tjaalton> Noskcaj: all uploaded
<tjaalton> now waiting for the builds to finish
<ginggs> hi, i have a request from the opencl packagers in debian (pkg-opencl-devel) for mesa to be built with opencl support.  i have re-opened LP: #1319835
<ubottu> Launchpad bug 1319835 in mesa (Ubuntu) "please enable opencl" [Undecided,Confirmed] https://launchpad.net/bugs/1319835
<tjaalton> there's a MIR to move the required deps to main first
<tjaalton> opencl will be revisited for 10.5
<ginggs> can you point me to the MIR, please?
<tjaalton> wish I knew
<tjaalton> which packages it needed
<tmpRAOF> libclc IIRC.
<tjaalton> thanks, so https://bugs.launchpad.net/ubuntu/+source/libclc/+bug/1412441
<ubottu> Launchpad bug 1412441 in libclc (Ubuntu) "[MIR] libclc" [Undecided,Incomplete]
<ginggs> thanks very much!
<tjaalton> tmpRAOF: a stealthy nick ;)
<tmpRAOF> tjaalton: Care of losing my freenode credentials without a registered email :)
<tjaalton> tmpRAOF: I noticed that vanvugt asked about upstreaming the mesa mir patch, you probably know the status?-)
<tmpRAOF> tjaalton: Yeah. Status is: should be rebased on the DRI3 infrastructure, which will remove some changes, and then it needs to be reproposed.
<tjaalton> okay
<tjaalton> so skylake needs 10.5 and the current patch didn't need much rebasing to at least make it compile, guess it works too
<tjaalton> need to try current master too, last time opening the dash crashed compiz (on SKL)
<tjaalton> huh, our xutils-dev is ancient, blocks new xinit
<tjaalton> merged
<mlankhorst> oke
<Noskcaj> tjaalton, thanks
#ubuntu-x 2015-02-05
<bhearsum> hi there, i've got one of the latest edition X1 Carbons. its "physical" mouse buttons turn out to be buttons 4 and 5 of the synaptics pad, which means they scroll by default. i've got them working as button 1 and 2 by setting UpDownScrolling=0 - but now button 1 always double clicks. is there a way to shut that off?
<bhearsum> oh hi chrisccoulson, long time no see :)
<bhearsum> in case anyone else was looking, i found a workaround in https://bugs.freedesktop.org/show_bug.cgi?id=88609#10
<ubottu> Error: Could not parse XML returned by Freedesktop: The read operation timed out (http://bugs.freedesktop.org/show_bug.cgi?id=88609&ctype=xml)
<bhearsum> hah
#ubuntu-x 2015-02-06
<tjaalton> tmpRAOF: hey, can you check the mir patch in https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1418486 and if good I can commit/upload it
<ubottu> Launchpad bug 1418486 in mesa (Ubuntu) "Mir Mesa EGL platform leaks memory with every frame" [High,In progress]
<tmpRAOF> Man, we need to refactor egl_dri2 so hard :/
<tmpRAOF> Hm. Is that actually correct?
<tmpRAOF> tjaalton: I'll have breakfast and then try and convince myself that it's not broken.-
<tjaalton> oh, in a decent timezone then? :)
<tjaalton> ok sounds good
<tmpRAOF> tjaalton: Ok, I think that's ok.
<tjaalton> cool
<FOSS_drivers_FTW> Hello
<FOSS_drivers_FTW> is there any reason why xserver-xorg-video-ati is still at 7.4.0 in vivid?
<FOSS_drivers_FTW> see:
<FOSS_drivers_FTW> http://packages.ubuntu.com/vivid/xserver-xorg-video-ati
<FOSS_drivers_FTW> Debian already has 7.5.0, see:
<FOSS_drivers_FTW> https://packages.debian.org/search?keywords=xserver-xorg-video-ati&searchon=names&suite=all&section=all
<FOSS_drivers_FTW> 7.5.0 is the latest version, see:
<FOSS_drivers_FTW> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
<FOSS_drivers_FTW> so, is there any reason why vivid is still using an old version? why hasn't the latest version been imported from Debian?
<tjaalton> probably not, though there's not much new besides pci-id's
<FOSS_drivers_FTW> tjaalton: the wiki says: "Packages that have recently been added to Debian unstable will be automatically synced into Ubuntu prior to the Debian Import Freeze (DIF)."
<FOSS_drivers_FTW> see: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<FOSS_drivers_FTW> but obviously that is not the case
<FOSS_drivers_FTW> Debian Import Freeze has not occured yet. according to the release schedule it will happen on February 19th, see:
<FOSS_drivers_FTW> https://wiki.ubuntu.com/VividVervet/ReleaseSchedule
<FOSS_drivers_FTW> the wiki goes on saying:
<FOSS_drivers_FTW> "After the Debian Import Freeze, you will have to file a bug with the summary field "Please sync <packagename> from debian <distro>" where <packagename> is the package you would like to see. Find the date for Debian Import Freeze on the release schedule page. "
<FOSS_drivers_FTW> so, what should one do to ensure the package will be synced _before_ DIF?
<FOSS_drivers_FTW> filing a bug as well?
<FOSS_drivers_FTW> or is it enough to report it here in #ubuntu-x?
<tjaalton> that sentence is only true for packages which don't carry a diff
<tjaalton> -ati can't be synced, needs a merge instead
<tjaalton> what is it you're after anyway? a missing pci-id in the driver?
<tjaalton> mlankhorst will probably do a new release closer to FF anyway, and we'll have that (or a snapshot)
<FOSS_drivers_FTW> tjaalton: yes, the new pci ids mainly. with "FF" you mean feature freeze? and what do you mean with "snapshot"? do you mean a fresh build from git? yeah, that would be even better of course, as there have already been some more commits after 7.5.0
<tjaalton> all ten of them
<tjaalton> -ati is not like -intel
#ubuntu-x 2015-02-07
<FOSS_drivers_FTW> still would be appreciated to have them in Ubuntu ;P
<FOSS_drivers_FTW> by the way: is vivid going to get X.Org Server 1.17?
<tjaalton> maybe
<tjaalton> depends on fglrx as always
<FOSS_drivers_FTW> that's sad...
<FOSS_drivers_FTW> well, I'm wondering if there will be any update to fglrx at all, now that they have released their "omega" release and are prepaiing for the new "amdgpu" driver...well, who knows...
<FOSS_drivers_FTW> -prepaiing +preparing
<FOSS_drivers_FTW> good night
#ubuntu-x 2015-02-08
<salty-horse> hey. I have issues with Nvidia 750GTX on Ubuntu using the drivers in xorg-edgers. is this on topic for this channel?
<soee> salty-horse: dont think so
<soee> tryasking on #ubuntu but xorg-edgers is not official/recommended repo
<salty-horse> thanks
#ubuntu-x 2016-02-09
<tseliot> ricotz, mamarley: I asked nvidia about the arm driver (waiting for an answer). Also, we are going to need some changes for GLVND (I'm on it)
<ricotz> tseliot, ok -- did you notice the mtrr_add mtrr_del problem on 304? (with kernel >= 4.3)
<tseliot> ricotz: in xenial?
<ricotz> I would assume so since it is 4.4 ;)
<ricotz> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2baa891
<ricotz> tseliot, are working on 361.28?
<tseliot> yep
<ricotz> tseliot, are you ...
<ricotz> ok
<ricotz> https://devtalk.nvidia.com/default/topic/893282/304-128-and-kernel-4-3-can-compile-but-cannot-insert-it-mtrr-symbols-related-errors-/
<ricotz> tseliot, ^
<tseliot> I'm pretty sure I wrote a patch for mtrr_add and _del. I can't remember which driver I did it for
<ricotz> hmm, just tried the 4.4.0 ppa build on trusty with 304 and it failed
<ricotz> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/trusty/log/?h=lts-backport-xenial
<tseliot> I can write a patch for that. It's pretty easy
<ricotz> tseliot, alright
<mamarley> Oh wait, there is a new driver out?  Darn, sorry I missed it.
<mamarley> tseliot: Which route are you taking, GLVND or non-GLVND?
<tseliot> mamarley: the former
<mamarley> tseliot: Cool!  Let me know once you are done and I can test. :)
<tseliot> mamarley: sure
<soee> hows the new nvidia drivers packaging going ?
<mamarley> tseliot is gone at the moment.
#ubuntu-x 2016-02-10
<tseliot> ricotz: if I give you a patched 304, will you test it for me? (if yes, 32bit or 64 bit?)
<ricotz> tseliot, can do when I get to it, 64bit
<mamarley> tseliot: Any update on 361.28?
<tseliot> ricotz: sure, no hurry
<tseliot> mamarley: I have packages available for testing but I haven't tested them myself yet. Would you like to try them anyway?
<mamarley> tseliot: Sure, I enjoy potentially breaking my computer! :)
<tseliot> good, let me upload the packages then
<mamarley> Thanks!
<tseliot> mamarley: the packages are here. Thanks! http://people.canonical.com/~amilone/nvidia/
<tseliot> ricotz: and this is for you. Thanks! http://people.canonical.com/~amilone/nvidia-304/
<mamarley> tseliot: Initial impressions are good. :)  The system boots, SDDM and KDE both start properly, glxgears and es2gears both work, and VDPAU works.
<tseliot> mamarley: that's certainly a good sign ;)
<mamarley> Once you upload it to the repository I can see what you changed from the diff and make packages for Wily, Vivid, and Trusty too.  I will also go ahead and package nvidia-settings in a bit.
<tseliot> ok, good :)
<tseliot> I only need to test my fix for the FTBFS on armhf
<ricotz> tseliot, honestly I would prefer a source package
<tseliot> ricotz: how about a patch?
<ricotz> that works too
<tseliot> ok
<tseliot> ricotz: http://people.canonical.com/~amilone/nvidia-304/0001-Add-support-for-Linux-4.3.patch
<tseliot> if that works I will upload it (I have no hardware that works with 304)
<ricotz> tseliot, ok
<ricotz> tseliot, remember testing this on a trusty install with https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+sourcepub/6053228/+listing-archive-extra
<tseliot> ricotz: that would be fine
<ricotz> mamarley, hi, btw, don't bother to do packages for Vivid/15.04
<marlinc> Anyone who can take a look at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1542629 ?
<ubottu> Launchpad bug 1542629 in xorg (Ubuntu) "Session crashes when second monitor is connected" [Undecided,New]
<tseliot> marlinc: does that happen if you switch to power saving mode from nvidia-settings?
<marlinc> Mm sure sure if its in power saving mode already
<marlinc> I haven't specifically enabled that
<tjaalton> with or without nvidia
<marlinc> Ah, it happens when I use the NVIDIA card
<marlinc> I don't have the same issue when using Intel
<marlinc> I normally switch using 'prime-select'
<mamarley> ricotz: How come?  Is it about to go out of support?
<tjaalton> vivid is EOL
<marlinc> I've haven't had the issue when I first installed Xenial. Then I upgraded and just used it for a few days. Now it keeps crashing. I (using ZFS) went back to when I first installed Xenial (and the NVIDIA driver) and its still crashing. That's why I'm thinking it might be related to something in my home folder
<marlinc> The guest user for example works just fine
<ricotz> tseliot, builds and runs fine (7900GTX)
<marlinc> Ah tjaalton the reason I added xorg is because it crashes with a segfault. Sorry if its not related 
<tjaalton> marlinc: you verified that it only happens with nvidia, and the logs didn't show a crash
<marlinc> Do I have to ask about it somewhere else?
<tjaalton> no
<tjaalton> attach a logfile with the crash
<marlinc> Okay lets try 
<tseliot> marlinc: it's an intel issue then
<tseliot> ricotz: great, thanks
<marlinc> I was able to obtain a crash log tjaalton, I'll upload it in an hour
<mamarley> ricotz: I uploaded nvidia-settings 361.28 to my staging PPA and tested it.  Should I go ahead and copy it to the main PPA?
<ricotz> mamarley, if you want to please the fanboys (e.g. no-change upload with bumped version)
<ricotz> it is still the same as 355.11
<mamarley> Haha
<mamarley> I actually do tend to get multiple requests for updates whenever anything in the PPA isn't up-to-date though.
<marlinc> tjaalton, tseliot I've attached a log of X org crashing. https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-352/+bug/1542629
<ubottu> Launchpad bug 1542629 in nvidia-graphics-drivers-352 (Ubuntu) "Session crashes when second monitor is connected" [Undecided,New]
<marlinc> That do you mean by 'it's an intel issue then'? I've not having issues when I run on the integrated graphics (as far as I know)
<tseliot> marlinc: power saving mode = intel only
<tjaalton> that's a config fail
<tjaalton> crashes before it even starts
<tseliot> marlinc: I misread your answer though
<marlinc> I'm only having the issue when not in power saving mode tseliot 
<marlinc> Interesting tjaalton is there a way to check the config or to find it somewhere? Is it stored in my home directory somewhere?
<tjaalton> err no
<tjaalton> /etc/X11/xorg.conf
<marlinc> Then how is it possible that X still crashes when I go back to when I first installed Xenial. The only thing not included in the snapshots is my home directory
<tjaalton> dunno
<tseliot> marlinc: even without using the nvidia driver then?
<marlinc> It only crashes when I use the NVIDIA driver
<marlinc> Even when going back
<tseliot> going back to Xenial+nvidia then?
<marlinc> The reason why I think its very strange is that it did work at that point but now (when I go back) it doesn't. That leads me to think its something related to my home directory
<marlinc> The guest user for example works perfectly fine
<tseliot> hmm...
<tseliot> do you have a xorg.conf in your home directory
<tseliot> ?
<marlinc> I haven't made it myself but I can check if it exists
<tjaalton> what does prime-select do?
<tjaalton> on the system
<marlinc> As far as I know it switches between intel and nvidia
<marlinc> Wait, I'll give you a strace so you can see what it does
<tjaalton> i know what it does, but how
<marlinc> Ah, it uses update-alternatives
<marlinc> https://gist.github.com/Marlinc/866306bfb08ec938f999
<tjaalton> the monitor layout config is saved somewhere in your $HOME
<tjaalton> but the crash happens before even lightdm is up
<tjaalton> so it's your xorg.conf at least which is broken
<marlinc> It does crash as well when I change the monitor layout
<marlinc> Or rather when it applies it
<tjaalton> that might be more interesting to see
<tjaalton> or your xorg.conf..
<marlinc> When it does work (which it does sometimes when the monitor layout gets lost) and I change the config it crashes again
<marlinc> I'll check again when I get home, haven't got a second monitor at my disposal at the moment
<marlinc> Do you know where the monitor layout is stored in the home directory?
<marlinc> I guess monitors.xml?
<tjaalton> do you have one?
<tjaalton> I don't
<marlinc> I'll attach it
<marlinc> I haven't made it
<tjaalton> I don't need it
<tjaalton> move it aside
<marlinc> Want me to remove it?
<tjaalton> does it crash now even without the monitor hooked?
<marlinc> I can't remember what the error is but when I try to apply a config I get a error from the Unity screen thingy. It then shows my smaller monitor inside my larger monitor in the setting screen. Then I move my smaller screen to the left again and that's when it crashes
<marlinc> One moment, I'll switch but that should work just finne
<marlinc> Working fine tjaalton 
<marlinc> OpenGL vendor string: NVIDIA Corporation
<marlinc> OpenGL renderer string: GeForce 840M/PCIe/SSE2
<tjaalton> ok so you can't test anything now :)
<marlinc> Okay ;) if there's nothing I can do now I'll switch over to spare battery
<tjaalton> sure
<marlinc> What's the part that for example reads monitor.xml and creates the Xorg config? Or does Xorg read it itself using some module?
<tjaalton> the capplet does not write xorg.conf
<tjaalton> some nvidia tool might
<tjaalton> pastebinit?
<marlinc> This is the config file https://launchpadlibrarian.net/237745049/monitors.xml
<tjaalton> no, xorg.conf
<marlinc> That would be this https://gist.github.com/Marlinc/bf79005e715a3f057b72
<marlinc> I haven't got a /etc/X11/xorg.conf
<tjaalton> where was that then?
<marlinc> Its called xorg.conf.02102016
<tjaalton> anything in /usr/share/X11/xorg.conf.d?
<tjaalton> besides the usual
<tjaalton> input stuff
<marlinc> Nothing strange as far as I can see https://gist.github.com/Marlinc/724c9ed02d4cc0950d9e except for glamoregl.conf which is a symlink
<tjaalton> so there is xserver 1.18.1 in ppa:canonical-x/x-staging which will enter xenial next monday
<tjaalton> no idea if it might fix anything but could be something to test..
<tjaalton> with nvidia enabled it's using modesetting+nvidia
<marlinc> I
<marlinc> I'll check when I get home, possibly debug some stuff with you and then try the PPA
<tjaalton> EOD here
<marlinc> Ah, no problem :) Hav efun
<marlinc> Ah, no problem :) Have fun
<tseliot> ricotz, mamarley: do you have a testing ppa that supports arm?
<mamarley> wgrant: Could you please enable ARM builds on ppa:mamarley/staging ?
<mamarley> tseliot: ^
<tseliot> thanks
<tseliot> 304 is in xenial now
<mamarley> On the other hand, maybe we should have an "official" staging PPA to which we can all upload.
<tseliot> good point
<mamarley> ricotz: What do you think about that?
<mamarley> tseliot: I am not at home so I am unable to create the PPA at the moment, but unless ricotz objects you should be able to create it.
<tseliot> mamarley: ok
<ricotz> mamarley, tseliot, for what is it needed? just for 361?
<tseliot> in the meantime I'm going to build 361 on my Meizu Mx4...
<mamarley> Just a general-purpose staging PPA to which we can all upload for stuff like testing builds that we aren't sure are ready for general consumption.
<mamarley> Like this armhf test.
<ricotz> more ppas will just get confusing imo, just push it to the main ppa
<ricotz> in case of armhf just use a local pbuilder or so to test if it at least builds
<tjaalton> tseliot: x-staging has all archs..
<tseliot> tjaalton: that's good
<tseliot> ricotz: I tried my schroot (which usually works well for armhf) but the packaging scripts kept thinking it was amd64...
<ricotz> tseliot, this would mean DEB_BUILD_ARCH is populated wrong?
<tseliot> it's not necessarily wrong. Something goes wrong with foreign vs native arch
<ricotz> tseliot, use pbuilder which uses qemu
<ricotz> it is crawling slow but seems to do it right
<tseliot> ricotz: I use qemu-static I think
<tseliot> I should really check...
<tseliot> my phone works for testing :)
<marlinc> tjaalton, tseliot I've tested a few things and added instructions of how I got it to crash. I also attached two screenshots of errors I got from 'Screen Display' the display utility in Unity https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-352/+bug/1542629
<ubottu> Launchpad bug 1542629 in nvidia-graphics-drivers-352 (Ubuntu) "Session crashes when second monitor is connected" [Undecided,New]
<tjaalton> marlinc: ok, test the ppa then
<tseliot> ricotz, mamarley: I've finally got the packaging of 361 right for arm too. I am going to upload in a bit. The packages will end up in NEW though :/
<marlinc> Will do tjaalton
<ricotz> tseliot, great
<marlinc> Lets see what happends
<marlinc> Lets see what happenss
<marlinc> Lets see what happens
<marlinc> Is this bad? Its about to remove xserver-xorg-input-mouse
<marlinc> Well anyway, lets try. I can always go back using ZFS
<mamarley> tseliot: Great, thanks!  When I get home from work later I will do the packaging for gpu-drivers.
<tseliot> it's uploading now. I will also push to my git branches when the uploads are over
<marlinc> Okay, the PPA kind of makes it worse, when I now switch to the NVIDIA driver using prime-select not even lightdm can start.
<marlinc> Its spewing quite a few errors, I'll gist those
<marlinc> tseliot, tjaalton here are logs of LightDM errors when using prime-select nvidia using that PPA
<tjaalton> here?
<tjaalton> noone uses -mouse, it's going to be removed from the archive too..
<marlinc> I'm sorry.. I guess I didn't include the link m
<marlinc> One moment
<marlinc> tjaalton, https://gist.github.com/anonymous/2d6ec0b85280241fc0c7
<tjaalton> so unity-greeter crashes for some reason
<tjaalton> but only with nvidia?
<tjaalton> /usr/share/lightdm/lightdm.conf.d/90-nvidia.conf what's this?
<tjaalton> marlinc: try commenting out the line with "type="
<marlinc> Let me check
<marlinc> type=xlocal
<marlinc> So I guess I have to reconfigure the PPA
<marlinc> Let me make a clone using ZFS so I can switch back and forth
<tjaalton> reconfigure?
<tjaalton> just edit the file
<marlinc> I've rolled back to before I installed the PPA
<tjaalton> uh
<tjaalton> ok
<marlinc> Okay brb, I'll reboot to the cloned dataset and add the PPA again
<marlinc> Okay done that tjaalton, I'm rebooting with it uncommented
<tjaalton> tseliot: what does that bit do btw? (type=xlocal)
<marlinc> Its still crashing
<marlinc> https://gist.github.com/anonymous/0dbd5db73a13bf83fe03
<tjaalton> well then try commenting out the rest
<tjaalton> I guess those scripts are failing
<marlinc> Would restarting lightdm do? Or do I have to restart?
<tjaalton> restart lightdm
<marlinc> Now the screen stays black, lets check the logs
<tjaalton> but doesn't crash
<tjaalton> tseliot: looks like this one is on you ;)
<tjaalton> nvidia-prime and/or gpu-manager is unhappy with x-staging
<marlinc> I am getting a lot of errors in the log though, let me gist them
<marlinc> In the greeter log that is
<marlinc> https://gist.github.com/anonymous/1f8d9e00474afbf209b8
<tjaalton> because it probably really needs the scripts working
<marlinc> I'm getting quite of bit of this as well, not sure if its related, this is in the kernel log https://gist.github.com/anonymous/a7d2b4a15560f99f9703
<tjaalton> a bios update might get rid of the acpi stuff
<tjaalton> what intel cpu is it?
<marlinc> Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
<tjaalton> haswell
<tjaalton> don't think the fifo underruns are critical
<marlinc> Okay, not sure what they mean so I though I'd at least show them
<tjaalton> the original dmesg had them
<marlinc> Going to reboot back to my normal install, since I've created a clone I can always go back to this exact environment
<marlinc> How do you actually test this stuff and how do you make it reproducible
<tjaalton> i don't, no hybrids here
<marlinc> Well thanks a lot tjaalton, sorry for the inconvenience
<soee_> mamarley: why only new nvidia-settings is uploaded to ppa and not the drivers ?
<mamarley> soee_: Because uploading NVIDIA drivers isn't what pays the bills. :)
<soee_> :)
<mamarley> I think there is already 361.28 in NEW for Xenial, so when I get home, I will use that as a basis for packages for all the other versions.
<soee_> in NEW ?
<soee_> i'm no Xenial and dot see it in drivers ppa
<mamarley> soee_: It was uploaded to the official Xenial repository, but last I heard, it is still in NEW which means it isn't published yet.
<tseliot> tjaalton: type=xlocal means that it shouldn't be using the system compositor
<tseliot> marlinc: if you're around, we can debug this tomorrow
<marlinc> Sure
<tseliot> ok
#ubuntu-x 2016-02-11
<mamarley> tseliot: ricotz: Last night I tried to package 361.28 for the PPA based on a diff between 361.18 and the 361.28 in NEW for Xenial, but I had a few questions.  First, how long are packages stuck in NEW?  Would it be worth it to re-upload 361.28 for Xenial in the PPA?
<mamarley> Second, I'm not quite sure how to handle Wily and Trusty.  In the PPA, the packaging for Xenial and Wily was identical besides the EGL alternative stuff in Xenial.  Should I upload the Xenial packaging for 361.28 to Wily (minus the EGL alternatives), should I base the Wily 361.28 off of the Wily 361.18, or should I backport some subset of the changes?
<mamarley> The packaging for Trusty had several differences between that of Wily and Xenial, so I am not sure what if any of the changes from 361.28 I should backport to that.
<tseliot> mamarley: as for NEW, that's anybody's guess. I pinged an admin
<tseliot> you can reuse the Xenial packaging (minus EGL) in Wily
<mamarley> OK, that's what I though.
<mamarley> s/though/thought
<tseliot> as for trusty, I think the same as Wily would work
<mamarley> Ah, OK, that makes things easier.  Thanks!
 * tseliot has just uploaded nvidia-settings in xenial
<ricotz> don't forget the substvars modifications
<mamarley> ricotz: I don't think I am familiar with that change?
<ricotz> for trusty to allow installation of the lts-xorg stacks
<mamarley> Ah, yes.  OK, I will make sure to get those.
<tseliot> ricotz, mamarley: only the xorg-video-abi-$number is needed though
<tseliot> no need to depend on xserver-xorg-core-lts-* any more
<marlinc> Good afternoon!
<mamarley> tseliot: It already depends on one of xorg-video-abi 11 throught 20 in the Xenial packaging, so that will be sufficient?
<tseliot> mamarley: yes, I think so
<mamarley> Cool, thanks!
<mamarley> ricotz: I have uploaded 361.28 to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.
<ricotz> "nvidia-graphics-drivers-361 - 361.28-0ubuntu1+gpu16.04.1" <- NO
<ricotz> the official upload should/must override it
<mamarley> OK.
<mamarley> Oops, I actually didn't mean to use a + there.
<mamarley> ricotz: Are Wily and Trusty OK?  I can re-upload Xenial with a ~.
<ricotz> mamarley, I don't like to have the 352 transitionals just yet
<ricotz> so for any 361 upload those should not be there
<mamarley> ricotz: OK, I will cut those out.  Anything else?
<ricotz> mamarley, that should be it
<ricotz> tseliot, btw, I really don't like you starting a new changelog with every new series, the packaging doesn't appear out of thin air ;P
<mamarley> ricotz: Should I leave the transitionals in for Xenial since the official package with transitionals will override ours anyway?
<ricotz> mamarley, no, otherwise the ppa packages of 352 are gone with them
<mamarley> ricotz: OK
<tseliot> ricotz: well, it's really a new source package though ;)
<ricotz> tseliot, still, you know what I mean
<tseliot> I do
<tseliot> I keep track of all the changes in git, so I really don't need the changelogs to remind myself of what I included (from previous releases) in the packaging
<mamarley> ricotz: Do you mind if I upload the fixed packages straight to gpu-drivers or should I make another temporary staging PPA for that?
<ricotz> mamarley, if you are sure you got it right
<mamarley> For Xenial, I replaced the + with a ~ in the version.  For everything, I removed the 352-related stuff from the control.in template.
<ricotz> mamarley, alright, double-check and upload ;)
 * mamarley nervously quadruple-checks his work.
<mamarley> ricotz: OK, it is all uploaded.  I even checked after running debuild -S -sd to make sure the 352 stuff was gone from the generated control file before uploading. :)
<mamarley> soee: 361.28 is ready for testing.  Please use the version from the gpu-drivers PPA and not the one from my staging PPA.  (I hope you disable that when you aren't actively testing something?)
<soee> mamarley: i have drivers ppa always enabled :)
<ricotz> mamarley, clear your ppa?
<mamarley> ricotz: D'oh, yes, I should do that.
<soee> updating now
<tseliot> marlinc: can you reproduce the problem and show me your dmesg and X log, please?
<marlinc> Any specific things I should enable first? Should I use the PPA?
<tseliot> marlinc: was the problem there after enabling the PPA?
<tseliot> I'm talking about the last problem you mentioned yesterday
<marlinc> I'm sorry tseliot, lost my connection to the bouncer
<tseliot> marlinc: I was already away yesterday, and you pinged me about a problem with hybrid graphics that maybe involved the PPA. Whatever the last problem you ran into was, I would like to see those two files, and possibly the output of a command
<marlinc> Okay, tjaalton asked me to try the PPA. Then I ran into issues where LightDM wouldn't start
<marlinc> One moment
<marlinc> I'm starting using the PPA now tseliot 
<tseliot> ok
<soee> new driver works fine :)
<marlinc> Okay, so yesterday we commented everything in /usr/share/lightdm/lightdm.conf.d/90-nvidia.conf as LightDM was crashing when I switched to the NVIDIA driver using prime-select
<marlinc> Currently that's causing a black screen with the following errors in the greeter log https://gist.github.com/anonymous/1f8d9e00474afbf209b8
<soee> hmm, mamarley ping
<mamarley> pong
<soee> mamarley: steam now yields this: http://wstaw.org/m/2016/02/11/snapshot65.png
<marlinc> I see there's a ton of updates, I'll install those to make sure I'm not missing any fixes
<marlinc> Including ZFS, nice
<mamarley> soee: I'm not where I can look at that.  Can you give a quick description?
<tseliot> marlinc: I see a lot of errors but none specific to nvidia
<soee> mamarley: Could not find required OneGL entry point 'glGetError'! Either your video card is unsupported, or your OpenGL driver  needs to be updated.
<marlinc> LightDM runs a X server right? Is there a way to look at what its doign?
<marlinc> Doing*
<tseliot> marlinc: /var/log/lightdm/ has the different logs
<marlinc> One moment, I'll reboot the server. Got a kernel update
<marlinc> Reboot the laptop*
<marlinc> Okay, I've removed all the logs and restarted LightDM
<mamarley> soee: This is new for 361.28?
<soee> mamarley: i think so. never seen it before
<marlinc> These are all the logs tseliot https://gist.github.com/anonymous/24846fdffb2cc60f1935
<marlinc> I'll post dmesg as well
<marlinc> And this is dmesg tseliot https://gist.github.com/anonymous/ade956eeec744021417f
<tseliot> I don't see it execute the script for prime...
<marlinc> Ah, yes tjaalton and I disabled that to debug
<marlinc> I'll re enable it and post some new logs
<tseliot> ok
<marlinc> The logs might be confusing as LightDM keeps restarting, or rather the X server that LightDM uses I think. Will post the logs now
<marlinc> There you go tseliot https://gist.github.com/anonymous/c30e9500c63007c82ba0
<tseliot> marlinc: the greeter got an error from X, and died
<marlinc> I guess that makes sense, unity-greeter crashes which causes the X server to shutdown. And then LightDM tries to start the X server again
<marlinc> Anything else I can do to get more information on the issue
<tseliot> maybe it's a problem with the modesetting driver.  Try booting with either gpumanager_uxa or gpumanager_sna, and see which one works
<tseliot> (kernel parameters)
<marlinc> Will do
<tseliot> tjaalton: I should probably test the PPA myself with hybrid graphics
<tseliot> just in case...
<marlinc> Okay, uxa doesn't work. Will test sna now
<marlinc> Same greeter errors
<tseliot> ok
<tjaalton> hmm, my old laptop has i+n.. will steal it from the wife and upgrade it to x
<tseliot> that would be a good idea... don't tell your wife though :P
<marlinc> Okay now sure if this is better or worse. With sna its just starting X and nothing else
<marlinc> Fatal server error:
<marlinc> (EE) Failed to recover from error!
<marlinc> This is it https://gist.github.com/anonymous/8c5421e8510189a57361
<marlinc> And the two lines I pasted above are what's in the X log
<tjaalton> tseliot: it was still on vivid, so about time I upgraded it
<tseliot> right ;)
<tseliot> marlinc: ok, so sna is not expected to work (they broke it in the previous release cycle). If uxa doesn't work though, then something else is going on
<tseliot> but I can't see what from the logs
<tseliot> calling xrandr likely causes the issue
<tseliot> are you doing this while the external screen is connected?
<marlinc> Yes, I'll disconnect it and restart LightDM. But I guess I first have to boot over to either uxa or a regular boot
<marlinc> But I'm back in about 20-30 minutes have to eat, thanks!
<tseliot> regular boot would be fine
<tseliot> ok
<marlinc> Okay back tseliot 
<tseliot> ok
<marlinc> A single screen crashes as well tseliot 
<marlinc> Same greeter error
<tseliot> marlinc: and it doesn't crash if you comment out the nvidia script?
<marlinc> Then the screen just stays black
<marlinc> Wait let me check to be sure
<marlinc> Yep stays black
<tseliot> marlinc: if the screen stays black, you can try to log in blindly. Just type in your password and press enter, after your hear the drums. Then ssh into the computer
<tseliot> I need you to run a command after that
<marlinc> I can try logging in, I'm already logged in SSH if that helps
<marlinc> Via SSH*
<marlinc> Lets see what the log says if I try to login
<tseliot> marlinc: the thing is you need to login from the greeter or the command will fail
<tseliot> this is the command: DISPLAY=:0 xrandr --listproviders
<marlinc> Ah, you need a active X server. I should be able to run that now
<marlinc> Providers: number : 0
<tseliot> did you log in from the black screen?
<marlinc> I did
<marlinc> I can see that I logged in as the LightDM shows that
<marlinc> Let me gist it
<tseliot> both intel and nvidia should show up there
<marlinc> https://gist.github.com/anonymous/e8b91e4ccc411f3ed65f
<tseliot> right I can see that
<tseliot> tjaalton: randr 1.4 support is broken ^^
<tseliot> no wonder X dies
<marlinc> <marlinc> I can see that I logged in as the LightDM log shows that
<tjaalton> that'd be surprising
<marlinc> I have typing problems at the moment :p
<tseliot> marlinc: what does /var/log/gpu-manager.log say?
<marlinc> Let me try something, I'll switch to intel using prime-select and see what happens
<marlinc> Okay
<marlinc> https://gist.github.com/anonymous/881c50c143a2315f5f59
<marlinc> There you go
<marlinc> Just tried starting by switching to intel using 'prime-select'. That does work and show LightDM
<marlinc> Switched back to NVIDIA which has the problems we're looking at
<tseliot> can you try this command again after switching to intel, please? DISPLAY=:0 xrandr --listproviders
<tseliot> the log looks fine BTW
<marlinc> Sure
<marlinc> marlinc@marlinc-laptop:~$ DISPLAY=:0 xrandr --listproviders
<marlinc> Providers: number : 0
<marlinc> Btw the actual session, works just fine when I log in using intel
<tseliot> tjaalton: that is wrong ^
<marlinc> Ah that explains it, it started on another display number
<marlinc> Its 1 now
<marlinc> marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr --listproviders
<marlinc> Providers: number : 1
<marlinc> Provider 0: id: 0x47 cap: 0x9, Source Output, Sink Offload crtcs: 4 outputs: 4 associated providers: 0 name:Intel
<tseliot> oh
<tseliot> maybe try again with nvidia then on display 1
<marlinc> Okay, will do
<tseliot> remember to log in
<tjaalton> Progress: [ 39%]
<tjaalton> getting there
<tseliot> :)
<marlinc> Ah, there you go
<marlinc> marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr --listproviders
<marlinc> Providers: number : 2
<marlinc> Provider 0: id: 0x204 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 0 name:NVIDIA-0
<marlinc> Provider 1: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 0 name:modesetting
<tseliot> ok, that looks much better
<marlinc> Not sure what display 0 is
<marlinc> I can even get GLX info
<marlinc> OpenGL renderer string: GeForce 840M/PCIe/SSE2
<marlinc> OpenGL core profile version string: 4.5.0 NVIDIA 352.63
<marlinc> OpenGL core profile shading language version string: 4.50 NVIDIA
<marlinc> I guess that this could make sense?
<marlinc> marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr
<marlinc> Screen 0: minimum 8 x 8, current 640 x 480, maximum 16384 x 16384
<marlinc> Its supposed to show a VGA, HDMI and internal connection
<tseliot> yes, it's just that attaching the outputs to nvidia causes X to crash
<marlinc> Ah
<tseliot> once attached you will see the outputs
<marlinc> What does prime-offload do? When I run DISPLAY=:1 sudo prime-offload it actually gets the outputs and doesn't crash
<tseliot> maybe try crashing X yourself. I'll give you the command
<tseliot> so maybe this time we get the error in the log
<marlinc> Shall I first restart the LightDM so that the session in which I did prime-offload is closed?
<tseliot> isn't that a different X?
<tseliot> it shouldn't really matter
<marlinc> Okay ;)
<tseliot> DISPLAY=:1 xrandr --setprovideroutputsource modesetting NVIDIA-0
<marlinc> That didn't do much
<tseliot> meaning? 
<tseliot> what does this say? DISPLAY=:1 xrandr --listproviders
<marlinc> marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr --listproviders
<marlinc> Providers: number : 3
<marlinc> Provider 0: id: 0x204 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 1 name:NVIDIA-0
<marlinc> Provider 1: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting
<marlinc> Provider 2: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting
<tseliot> err...
<marlinc> Wait, let me restart the session so its clean. The fact that I ran prime-offload might have done something
<tseliot> ok
<marlinc> So that's clean again
<marlinc> marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr --listproviders
<marlinc> Providers: number : 2
<marlinc> Provider 0: id: 0x204 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 0 name:NVIDIA-0
<marlinc> Provider 1: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 0 name:modesetting
<marlinc> After I ran your command I got the same
<marlinc> marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr --listproviders
<marlinc> Providers: number : 3
<marlinc> Provider 0: id: 0x204 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 1 name:NVIDIA-0
<marlinc> Provider 1: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting
<marlinc> Provider 2: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting
<tseliot> it looks like a bug
<tseliot> try running prime-offload manually
<marlinc> Just 'DISPLAY=:1 sudo prime-offload'>
<marlinc> Just 'DISPLAY=:1 sudo prime-offload'?
<tseliot> yes
<marlinc> Okay, once again I got somewhat of an image
<marlinc> Might have to make a picture
<tseliot> DISPLAY=:1 xrandr --listproviders
<marlinc> marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr --listproviders
<marlinc> Providers: number : 3
<marlinc> Provider 0: id: 0x204 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 1 name:NVIDIA-0
<marlinc> Provider 1: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting
<marlinc> Provider 2: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting
<tseliot> hmm...
<marlinc> https://lh3.googleusercontent.com/cvbNSL8LTfSSHrOodsAoEZiX09S_pw2VPEI5d9Jzh7mPJffgdS2cclFBgqaI0g5ZK_OKcpI8-2xjX-KsR8Gj1jkwcNywsfbvmgmEuowYeAS3kj6_MSOnGWP5N4aHp5gtmx3pNmgnMv5wCsUMqfAL0ywrfdc2avJfnSXgA_YfMWc9KaytTsXJV61sCp66lBhtu-02ehQejFe7C11ksKrBHnkXT1E5j3hUd6rSmAyMdxQUJPL2XFgVj2nxrmxL4YR4VFSTMu6y3lxwPwNvL-B7n1lzyEYbnwsglsASdP4RiHiz-REn1h454jtkPNQNXSipB6KaBVllF3sPzSq5dtP8_dVgJa5rMoSCXISBBeXEUGh1BBG6Uo2ywYVi4nipNqoxcDxAOQHFBBa7rNco8h6c8kycustrS4_7
<marlinc> Z0vYVHE91zLY6NRekqu60MiXiLqo7uANLLGxuABCbtKNctJ0w9EIB9ppEZQoR7PEfi-xE0OM75TC2XeOrvzCDFXYb0SOWS_MJ0jCMFIiJnaaBXkLYcdgPDSbp-Pty7LUonDsQg15pZDPdprbaTF8ajhYnXhlNmwGC7jn-Q=w940-h705-no
<tjaalton> tinyurl
<marlinc> https://goo.gl/MP1mEv
<tseliot> multiple screens within the same screen
<marlinc> Now it out of nowhere started to show https://goo.gl/PpJWId
<tseliot> maybe try removing your ~/.monitors.xml
<marlinc> https://gist.github.com/anonymous/1db59dd738a71bcf281d is the general xrandr output
<marlinc> Removed it
<tseliot> so that kind of worked
<tseliot> try simply restarting
<tseliot> (no external screen plugged in)
<marlinc> Okay, I reran all the commands, LightDM restart, --setprovideroutputsource, prime-offload. Same result as the first picture
<marlinc> It will probably in a minute switch to the second picture
<marlinc> Now I got https://goo.gl/Vbp0tT instead of the other picture
<tseliot> the bug must be in the open drivers
<marlinc> And now it again switched to the second picture I posted
<marlinc> But with a second system error pop up
<marlinc> I'm using the nvidia-352 driver
<marlinc> And the regular Intel driver that you get out of the box
<tseliot> can you try adding a "sleep 2" in prime-offload and before this line, please? # Remove any previous logs
<tseliot> then restart lightdm
<marlinc> Sure
<tseliot> BTW it's beyond EOD for me. We can continue tomorrow
<marlinc> No change at all
<marlinc> Okay, I'll reboot to my regular install without the PPA
<marlinc> Thanks a lot
<mamarley> tseliot: Do you get the emails sent to the graphics drivers PPA team?  We just got an email reporting the same issue soee reported earlier about Source engine games not running on 361.28.  I think something might be out-of-whack with the libraries.
<soee> mamarley: i tried also reinstalling steam, but with no luck
<mamarley> tseliot: Maybe we need to extract the .run files with "--glvnd-glx-client"?
 * mamarley doesn't actually have Steam on his system.
<ricotz> mamarley, one reason not to force an update with transitionals ;)
<mamarley> ricotz: Indeed, but both of these people upgraded manually.
<ricotz> mamarley, so if needed they can simply switch back in the meantime until this gets settled
<mamarley> Hmm, the --glvnd-glx-client argument has no effect when -x is used...
<mamarley> Because all the libraries are extracted, not just the GLVND or non-GLVND ones.
<mamarley> But when installed, the libraries are set up exactly the way https://devtalk.nvidia.com/default/topic/915640/unix-graphics-announcements-and-news/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/ recommends...
<mamarley> Hmm, after reading https://devtalk.nvidia.com/default/topic/915789/-solved-361-28-gtx-580, it appears that the arch people only got it to work by switching to the non-GLVND libraries.  In other words, this appears to be an upstream regression between 361.18 and 361.28 and not a packaging error on anyone's part.
<mamarley> soee: ^
<soee> mamarley: i see, so we have to wait or next release :)
<mamarley> tseliot: If you have a contact at NVIDIA, it might be worth mentioning that.
<tseliot> mamarley: ok, I'll do that tomorrow. Thanks
 * tseliot -> off
#ubuntu-x 2016-02-12
<tjaalton> meh, installing nvidia kinda blacklists nouveau but not exactly
<tjaalton> nouveau still gets loaded here
<tjaalton> nvidia-352_hybrid.conf is not included in the initrd
<tjaalton> etc/modprobe.d/nvidia-352_hybrid.conf
<tjaalton> where's tseliot.. :)
<tjaalton> with that fixed, hybrid on current xenial is totally busted, yes
<tjaalton> tseliot: hi, so nvidia hybrid is broken here too with stock xenial
<tjaalton> now the question is, what changed since wily, where I assume it worked
<tjaalton> xserver didn't
<tseliot> modesetting?
<tseliot> or maybe some options are default now?
<tjaalton> builtin
<tjaalton> have you tried xenial?
<tseliot> since that's common, I need to debug this myself here
<tseliot> yes but I haven't tried the PPA
<tjaalton> no this is stock xenial
<tjaalton> doesn't need the ppa to trigger
<tjaalton> also, first boot after installing the driver nouveau blacklist wasn't effective
<tjaalton> enabled it via the additinal drivers thing
<tjaalton> +o
<tjaalton> and it didn't have the restart button
<tjaalton> after the driver was installed
<tseliot> ah
<tseliot> ok, I'll try stock xenial again then
<tseliot> I always use apt-get to install nvidia BTW
<tjaalton> dunno what users use
<tjaalton> but this is available, and I remember seeing crasher bugs where the system hadn't been restarted but just logged out and back in
<tseliot> it should be the same though
<tseliot> I'm not sure about the restart notification
<tjaalton> vivid seems fine, but prime-switch segfaults
<tjaalton> when run as user
<tjaalton> as root it complains "/etc/modprobe.d is not a file"
<tjaalton> and "no alternatives for x86_64-linux-gnu_gfxcore_conf"
<tjaalton> upgrading this to wily then
<tseliot> those two are just warnings
<tjaalton> but why?-)
<tseliot> the latter is expected, as only fglrx has that alternative
<tseliot> the former is just for debugging
<tseliot> prime-switch requires root privileges
<tseliot> also the version of gpu-manager in vivid is old
<tjaalton> which one should a noob user run?
<tseliot> switching between profiles is done through nvidia-settings
<tseliot> with a nice UI
<tjaalton> ok
<tseliot> assuming the driver works correctly
<tjaalton> right
<tseliot> let me update my xenial installation
<tseliot> BTW if nouveau wasn't blacklisted, either the alternative was not set or the initramfs hadn't been updated yet
<tjaalton> well driver installation didn't run update-initramfs then
<tseliot> the package should have (in the postinst)
<tseliot> mamarley: "The NVIDIA Linux OpenGL driver added support for GLVND with the release of the 361.16 beta driver. During the beta test phase, it was discovered that several applications relied on behaviors or attributes of the NVIDIA OpenGL driver that fall outside of the Linux OpenGL ABI [2]. As the GLVND-based libGL.so.1 library does not share these behaviors or attributes with the NVIDIA OpenGL driver, this resulted in incorrect behavior from applications 
<tseliot> "Please contact the vendors of any applications that are not compatible with GLVND to ensure that their applications be updated for compatibility with GLVND."
<tjaalton> har har
<tseliot> mamarley: "We have heard back from NVIDIA. They have confirmed this is a driver bug impacting the libglvnd-enabled driver (nobody but Archlinux at the moment). The driver bug will be fixed in a future release. For now, they recommend setting __GLVND_DISALLOW_PATCHING=1 as a workaround, although also setting __GL_THREADED_OPTIMIZATIONS=0 will work (although potentially more perf impact)." https://github.com/ValveSoftware/Dota-2/issues/756
<tseliot> (that's in Steam, I suppose)
<mamarley> Thanks!
<soee> mamarley: will you be able to rebuild the package to make it work ?
<soee> or do we have to wait for next release ?
<mamarley> soee: NVIDIA confirmed it is a bug in the driver.  There is a workaround, however, which is to launch the application with the __GLVND_DISALLOW_PATCHING=1 environment variable set.
<soee> mamarley: how can i set his variable ?
<soee> *this
<mamarley> soee: It might work to do "export __GLVND_DISALLOW_PATCHING=1" in a terminal window before launching Steam from that terminal window.  Like I said, I don't have Steam, so I can't test it.
#ubuntu-x 2016-02-13
<karolherbst> is there a way to tell lightdm/X/failsafe/wahtever to not create a xorg.conf file for my laptop?
<karolherbst> something sets intel to modesetting and wants to drive the screen through nvidia
<karolherbst> and when I delete the xorg.conf file and restart lightdm, it reappears
<karolherbst> even my alternative settings gets overwritten
<karolherbst> seriously, why is something overwriting my xorg.conf file before lightdm is even started and moves some totally messedup file in there?
#ubuntu-x 2016-02-14
<tjaalton> karolherbst: prime-select intel, or nvidia-settings
<karolherbst> tjaalton: I found the issue, /var/lib/lightdm had the wrong access rights so gpu-manager was invoked :/
#ubuntu-x 2017-02-08
<tseliot> mamarley: where is your patch for 4.10? I don't see it in the 378 driver
<mamarley> tseliot: https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages
<mamarley> Also, I think I mentioned it before, but the patch disables CPU hotplugging support in the driver because I don't know enough about it to actually fix it.  It does run, but you probably won't want to actually release it like that.
<tseliot> mamarley: oh, staging. It's ok, I'll work on a fix
<vlt> Hello. On our working Ubuntu 12.04 install there seems to be at least an xserver-xorg-video-sis pkg installed. This is not available on 16.04.
<vlt> Any idea what I have to use instead of that now to make my video hardware work?
<vlt> Or xserver-xorg-video-ati
<tjaalton> -ati is available
<ogra_> sis is dead upstream since years iirc
<tjaalton> yep
#ubuntu-x 2017-02-09
<alkisg> tjaalton: hello, regarding https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1625540, would it be possible for a user to self-build xserver-xorg-video-sis in 16.04 with a simple apt-get source, debuild; or would it also involve fixing a whole lot of incompatibilities with the newer xservers?
<ubottu> Launchpad bug 1625540 in xorg (Ubuntu) "There is no video server for SiS chipsets" [Undecided,Won't fix]
<alkisg> Are there any chances of success with a plain apt-get source/debuild?
<tjaalton> alkisg: sure
<tjaalton> oh
<tjaalton> not for that gpu
<alkisg> tjaalton: thanks, I'll probably need it in a few schools here...
<alkisg> (like, 500 schools :()
<tjaalton> create a ppa, put it there
<alkisg> They have some onboard sis, pentium 4's
<tjaalton> maybe that's old enough
<tjaalton> newer SiS were never supported
<alkisg> It worked in the patched 12.04 package
<alkisg> (the one that initially had the segfaults, and then was fixed)
<alkisg> ty tjaalton, you give me hope :D
<alkisg> tjaalton: would I need to rebuild it on every xorg update, within the 16.04.1 cycle? Or just on point updates, like 16.04.2 etc?
<tjaalton> you have no reason to use point-releases
<tjaalton> on obsolete hw
<alkisg> True, but they have mixed-client labs, and they're all netbooted from a single image
<tjaalton> so use .1
<alkisg> But my main question is, if a xorg security update or something comes out, will I need to rebuild xserver-xorg-video-sis to match?
<tjaalton> no
<alkisg> Cool
<tjaalton> you probably need at least 0.18.0 from upstream
<tjaalton> which has build-fixes for 1.18
<tjaalton> 0.17 from trusty doesn't build
<tjaalton> 0.19 is for 1.19
<tjaalton> with a single commit
<tjaalton> no, two commits
<alkisg> Ah, ok, thank you, that should save me quite some time in debugging the build :D
<alkisg> (the bad thing when booting from a single image, is that you have those -sis clients, and also skylake clients, and it's difficult to find one release that supports both of them...)
<alkisg> 14.04.1 supports -sis, and I think skylake is supported from 14.04.3 onwards or something...
<tjaalton> right
<tjaalton> understood
<tjaalton> so if you want to use 16.04.2 with -hwe-16.04 stack then you'd need to modify the source and rename it to x-x-v-sis-hwe-16.04 or sth
<alkisg> No no I'll stick with 16.04.1
<alkisg> If some school needs > 16.04.1 for newer hardware, and also has -sis, I'll tell them to exchange the old clients with some other school :D
<tjaalton> ricotz: can you add me to the gfx team? I'd upload mesa 13.0.4 for xenial
<tjaalton> tseliot: or you
<tseliot> tjaalton: sure
<ricotz> tjaalton, 13.0.4?
<ricotz> I would expect 17.0.0~rc3 ;)
<tseliot> tjaalton: done
<ricotz> tjaalton, please give some more info on what you want to upload
<tjaalton> ricotz: all the build-deps
<tjaalton> 13 is ready now
<tjaalton> 17 isn't even in zesty yet
<ricotz> I assume wayland, llvm, libdrm, ...
<tjaalton> it just needs libdrm and llvm-3.9
<tjaalton> tseliot: thanks!
<tseliot> wait a second, though, isn't the PPA just for binary drivers?
<ricotz> tseliot, isnt wayland 1.11 required?
<tseliot> ricotz, tjaalton: maybe support for wayland can be disabled
<ricotz> tseliot, no
<tjaalton> tseliot: the description should be changed
<tseliot> oh
<tseliot> tjaalton: so what's the difference between edgers and this PPA?
<tjaalton> this is not edgers
<tseliot> I think the idea was to make binary drivers available without having to pull in anything else
<tseliot> (e.g. mesa or X)
<ricotz> exactly
<tseliot> tjaalton: so what's the purpose of the upload?
<ricotz> although mesa and libdrm will be update unconditionally afaik
<ricotz> so not hwe package renames anymore
<tjaalton> the team name is too generic then if it's just for nvidia
<tjaalton> :)
<tseliot> true
<tseliot> with fglrx gone, it's just nvidia now
<ricotz> tjaalton, point me to the things you want to copy, and I can take a look
<ricotz> preferred are proper version suffixes to indicate their origin
<tjaalton> ricotz: https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging/+packages
<ricotz> xedgers can be called prerelease currently ;)
<tjaalton> I can happily create a ppa under canonical-x too and call that official
<tjaalton> just for mesa
<mamarley> tjaalton: I noticed that in canonical-x/x-staging you are working on getting Mesa to use glvnd.  Are we going to make the NVIDIA binaries work with that too?
<tjaalton> mamarley: eventually
<mamarley> In Zesty, or at some point after that?
<tjaalton> compiz crashes within a minute of idling, so it's not going in zesty anytime soon
<ricotz> tjaalton, currently I would be more comfortable with ppa:graphics-drivers/mesa
<tjaalton> ricotz: then it would need to carry vulkan as well?
<ricotz> tjaalton, vulkan is already in since nvidia requires i
<ricotz> t
<tjaalton> you didn't answer my question ;)
<ricotz> tjaalton, carry where?
<tjaalton> mesa ppa
<tjaalton> or would both need to be enabled
<ricotz> tjaalton, all those different builds are a pita
<ricotz> also those different version schemes :\
<tjaalton> easily fixed
<tjaalton> jorge is not here..
<tjaalton> we've been discussing mesa with feral and paulo
<ricotz> and you want this for xenial only?
<tjaalton> no
<ricotz> good
<ricotz> so xenial and later
<ricotz> or even trusty?
<tjaalton> no way
<ricotz> ok
<ricotz> might be good to stage all of this in a separate ppa which proper versioning?
<tjaalton> there would be a separate beta ppa for "oibaf" mesa
<tjaalton> these are not beta versions though
<tjaalton> and so far anyone using this are on nvidia
<ricotz> yeah, like mesa in edgers now
<ricotz> don't ignore optimus/prime users
<tjaalton> nothing changes there
<ricotz> huh?
<tjaalton> how do you stage nvidia releases? in edgers?
<ricotz> intel gpu would be driven by mesa, no?
<tjaalton> sure
<ricotz> in private ppas
<ricotz> and/or local builds
<ricotz> nvidia doesnt consist of multiple source packages ;)
<ricotz> ok, so better have a separate staging ppa for get those packages aligned and built?
<ricotz> bbl
<tjaalton> oh, padoka ppa mesa has an epoch..
<tjaalton> ricotz: beta ppa is fine
<Sarvatt> tjaalton: was the -backports idea a no go?
<tjaalton> Sarvatt: no, but it's harder to use than a ppa
<tjaalton> and more paperwork
<tjaalton> harder for the user I mean
<tjaalton> ricotz: actually, these don't need a staging ppa. they've already been tested. I'd upload llvm first
<tjaalton> 3.9.1-3ubuntu1~gpu16.04.1, a proper version number too
<tjaalton> hmm not that
<tjaalton> -4u1
<ricotz> tjaalton, ok, better -0u0~ and pass -V3.9.1 for llvm?
<tjaalton> why -0u0 if the packaging is based on newer?
<tjaalton> -0u0 says nothing
<ricotz> to avoid possible conflicts with archive uploads or the like
<tjaalton> ~ already means it's older
<ricotz> I know, although the versioning of some archive uploads can be a mess ;)
<tjaalton> there won't be llvm-3.9 in xenial
<ricotz> just to be sure it won't override any future official uploads
<tjaalton> sorry but I don't agree :)
<ricotz> really, I though mesa 13/17 will land in xenial at some point?
<ricotz> thought
<tjaalton> they will
<ricotz> llvm-4.0
<tjaalton> llvm-4.0 is a separate source
<tjaalton> mesa 13 won't
<ricotz> I know, so there must be some official llvm backport?
<tjaalton> yes and it's based on the latest version
<tjaalton> once it's backported
<ricotz> you are making it hard to understand
<tjaalton> zesty has 1:4.0~+rc1-1 right now
<tjaalton> it'll have 4.0.1 or something when 17.04 is released
<tjaalton> say, 4.0.1-1ubuntu1
<ricotz> ok, so why not use llvm-4.0 already?
<tjaalton> that will be officially backported as -1ubuntu1~16.04.1
<tjaalton> eh
<tjaalton> mesa 13 doesn't work with it
<tjaalton> llvm-3.9 doesn't upgrade to -4.0
<ricotz> ok, so use mesa 17? which will be released this week?
<tjaalton> no
<tjaalton> I thought you were concerned about forcing a new mesa to folks using this ppa ;)
<tjaalton> I wanted to give stable mesa 13
<tjaalton> now
<ricotz> I am, still is seems weird not to use/test what will actually be backported in the end
<tjaalton> once it's at .1 or something
<tjaalton> it's not even in zesty yet
<tjaalton> and the mir egl patch is being worked on, I'm not allowed to touch it before it lands
<tjaalton> well, I won't touch it before..
<ricotz> I see
<ricotz> why is this mir patch not upstreamed?
<tjaalton> because it was not ready
<tjaalton> apparently it will be after this
<tjaalton> still waiting for new xmir..
<tjaalton> for two months now
<tjaalton> which is why xserver 1.19 isn't in zesty yet, and which will block any libglvnd work from happening in the archive
<ricotz> hmm, ok
<tjaalton> anyway, llvm versions; I'm the one doing official backports
<tjaalton> so you can count on having proper versioning there
<tjaalton> same goes for libclc, libdrm, mesa
<ricotz> alright, use numbers instead of release-names ;)
<tjaalton> yeah that's for sure
<tjaalton> needed for hwe-16.04 too, because release names won't sort anymore, after zesty
<ricotz> exactly
<tjaalton> 1:3.9.1-4ubuntu1~gpu16.04.1
<tjaalton> -4u1 is in zesty-proposed, fixes some regression on radeonsi
<ricotz> how will the archive version look like for xenial?
<tjaalton> hmm
<tjaalton> well, in this case there won't be any
<tjaalton> but you're right
<ricotz> 0u0 is useful!
<tjaalton> it'd be ~16.04.1
<tjaalton> hehe
<tjaalton> ~0gpu
<tjaalton> :P
<ricotz> no
<ricotz> "llvm-toolchain-4.0 - 1:4.0~+rc1-0ubuntu0~xedgers16.04.1"
<ricotz> better do it like that
<tjaalton> loses too much informatino
<tjaalton> -on
<ricotz> as I said create the package with -V...
<tjaalton> you're putting "gpu" in the wrong place! :)
<tjaalton> -V does what?
<ricotz> to include previous changelog entries in the dsc/changes
<ricotz> which will then appear on launchpad as well
<tjaalton> you mean -v?
<tjaalton> for debuild at least
<ricotz> yeah
<ricotz> "backportpackage" would append "~ubuntuXX.XX.1" too afaik
<tjaalton> oh right
<tjaalton> actually it would be -4ubuntu1.16.04.1
<tjaalton> if zesty had -4 it would be -4~ubuntu16.04.1
<ricotz> I don't think so
<tjaalton> err
<tjaalton> -4~ubuntu0.16.04.1
<tjaalton> I've done those
<ricotz> anyway, the version in the ppa *must* be lower than any possible official upload
<ricotz> this is getting cumbersome
<tjaalton> yes, unlike padoka :)
<tjaalton> it's unfortunate you chose to version them like that
<ricotz> things like that are really bad
<tjaalton> -4ubuntu1.16.04.1 was wrong of course
<mamarley> Lots of people don't seem to understand the difference between -, ~, and + in those version numbers.
<tjaalton> dpkg --compare-versions is your fried
<tjaalton> uh, friend
<tjaalton> ~16.04.1~gpu1 would solve it
<tjaalton> or just ~16.04~gpu1
#ubuntu-x 2017-02-10
<tjaalton> i've pushed mesa 13.0.4 to x-swat/updates
#ubuntu-x 2017-02-12
<ricotz> tjaalton, hi, dropping libgles1 seems like a bold move
<ricotz> although it seems only vlc gets hit by it 
<tjaalton> fedora hasn't had it
<tjaalton> for four years or so
<ricotz> seems to get problematic with backporting, since vlc is quite important, I guess
<ricotz> and yeah, it is quite overdue to do so
<ricotz> tjaalton, btw, let me if about the progress for the xenial ppa packages
<tjaalton> ricotz: i put them in x-swat/updates for now
<ricotz> tjaalton, ok, make sure to built all required archs (amd64/i386/armhf), or let me known which should be enabled addtionally
<ricotz> also whether to enable dbgsym support
<tjaalton> yeah i'll enable those from the ppa options
<ricotz> tjaalton, what about arm64?
<tjaalton> that too
<tjaalton> looks like new archs will build only new uploads, not the old ones
<ricotz> tjaalton, you can binary-copy them to "this ppa"
<ricotz> tjaalton, I did it for llvm to begin with
<tjaalton> ah, ok
<tjaalton> cool
<soee> nvidia drivers work with kernel 4.10?
#ubuntu-x 2018-02-06
<mamarley> ricotz: We just got a message on the graphics-drivers-testers PPA about the libnvidia-egl-wayland.so being in the wrong place.  It looks like what the guy says is correct, but I just wanted to get your opinion before I make any changes.
<ricotz> mamarley, the mail is about the location of 10_nvidia_wayland.json ?
<mamarley> ricotz: Yes.
<mamarley> (I am not able to test this directly because I don't have Wayland set up on any of my PCs.)
<ricotz> but this seems correct while glvnd support has not landed yet
<mamarley> I thought so too, so I should go ahead and move the file?
<ricotz> I guess I would prefer a symlink
<mamarley> OK, will do.
<ricotz> tseliot, hi, https://lists.launchpad.net/graphics-drivers-testers/msg00098.html
<tseliot> ricotz: I didn't put the file in the right place because the NVIDIA installer doesn't do that. I've just read this, though:
<tseliot> The NVIDIA EGL driver uses a JSON-based loader to load all EGL External platforms available on the system. If this library is not installed as part of a NVIDIA driver installation, a JSON configuration file must be manually added in order to make the library work with the NVIDIA driver. The default EGL External platform JSON configuration directory is: /usr/share/egl/egl_external_platform.d/
<mamarley> tseliot: The poster did say that the .run file exhibited the same issue.
<tseliot> I wonder why they don't install something the worked on
<tseliot> *they
<mamarley> Beats me.
<ricotz> mamarley, I assumed non-PPA means ubuntu archive
<mamarley> There is no nvidia-390 in the main archive yet.
<mamarley> But yes, the wording was a bit confusing.
<ricotz> right, would be the same with 384
<mamarley> True.  So what do you guys think we should do?
<tseliot> they even have this in the nvidia installer code:
<tseliot> #define DEFAULT_EGL_EXTERNAL_PLATFORM_JSON_PATH "/usr/share/egl/egl_external_platform.d"
<tseliot> actually, I got that right in the new nvidia packaging. Too bad it's not ready yet
<mamarley> So should I move the file or symlink it?
<tseliot> mamarley: you can move it. This is how I install it in the new packaging
<tseliot> NVIDIA-Linux/10_nvidia_wayland.json                                  usr/share/egl/egl_external_platform.d
<mamarley> OK, great.  I will do that this afternoon for all the NVIDIA drivers we package that have the file.
#ubuntu-x 2018-02-09
<tjaalton> ls -l
<tjaalton> uh
#ubuntu-x 2019-02-04
<ricotz> mamarley, hi, I didn't forget about 418, it will require some updates
<ricotz> tseliot, hi, 410.93-0ubuntu1 doesn't ship libnvidia-egl-wayland.so anymore, but the new egl-wayland packages are not installable due to unversioned breaks/replaces on libnvidia-gl-410
<tjaalton> ricotz: I'll handle that then
<tjaalton> ricotz: hmm wait, so it's a bug in nvidia?
<tjaalton> no
<tjaalton>  libnvidia-gl-410 (<< 410.93-0ubuntu1),
<tjaalton> should do it
<ricotz> correct
<ricotz> libnvidia-gl-410 (<< 410.93) would be better though
<ricotz> tjaalton, ^
<ricotz> assuming this fits debian too
<tjaalton> they have their own thing
<tjaalton> libnvidia-egl-wayland1 was a pkg built by nvidia
<ricotz> ok, I see
<tjaalton> so src:egl-wayland has an epoch
<ricotz> still make it libnvidia-gl-410 (<< 410.93)
<tjaalton> k
<ricotz> thanks
<tjaalton> merged new upstream too
<ricotz> :)
<tseliot> good :)
#ubuntu-x 2019-02-06
<alkisg> Hi, in Ubuntu 18.04, several schools reported having black screen with i915 after recent updates. With a quick look, I couldn't pinpoint anything, and booting with an older kernel didn't fix the issue. Has anyone reported this?
<alkisg> systemctl --failed shows gpu-manager and lightdm as failed; but Xorg.0.log doesn't show any errors.
<ricotz> alkisg, maybe the mesa hwe update?
<ricotz> (and libdrm)
<tjaalton> kernel
<tjaalton> 4.15.0-44 was buggy
<alkisg> ricotz: all my schools are using 18.04.1 fully updated, which means no hwe stack,
<alkisg> tjaalton: they have the issue with -45 as well
<ricotz> alkisg, mesa 18.2.2-0ubuntu1~18.04.1 is basically an hwe update
<alkisg> Ah, that goes to people without the hwe stack too? That might be it, then
<alkisg> I even tried with 4.15.0.20.23 and it didn't make any difference
<ricotz> yes, together with libdrm
<ricotz> https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1798597
<ubottu> Launchpad bug 1798597 in xserver-xorg-video-vmware-hwe-18.04 (Ubuntu Bionic) "Backport packages for 18.04.2 HWE stack" [Undecided,Fix released]
<alkisg> Nomodeset did seem to workaround the problem; I'm not sure what this does to i915-based cards
<tjaalton> disables everythign
<tjaalton> doesn't even load i915
<tjaalton> try 18.2.8 from the x-updates ppa
<alkisg> Thank you, will do tomorrow, when I'll be able to contact one of those schools again
<tjaalton> https://launchpad.net/~ubuntu-x-swat/+archive/ubuntu/updates
<tjaalton> it's on the sru queue
<tjaalton> as well
<ricotz> alkisg, may I ask which intel gpu fails?
<alkisg> Let me see if I kept the model in the irc chat...
 * ricotz didn't update ltsp systems to bionic yet, but is planning to
<alkisg> From? 16.04?
<alkisg> 18.04 is much more stable than 16.04, if you use the greek schools ppa
<ricotz> yes, currently on xenial
<alkisg> I think this was the xorg log, booted with nomodeset: https://termbin.com/vz2e
<alkisg>  srv-6gym-chalk, yes, that was the one
<tjaalton> doesn't show anything
<alkisg> Ugh yeah nomodeset hides the model :(
<tjaalton> about the hw
<tjaalton> lspci would
<alkisg> (unfortnately I don't have that now), PCI:*(0:0:2:0) 8086:1912:1462:7996 rev 6, => https://pci-ids.ucw.cz/read/PC/8086/1912 => Name: IntelÂ® HD Graphics 530 
<tjaalton> skylake
#ubuntu-x 2019-02-07
<tjaalton> I have a hybrid i+n AIO with nvidia installed, and upgraded to disco but the nvidia driver is still on 390, should it have upgraded to 410?
<tseliot> tjaalton: 390 is a legacy series, and we cannot migrate users to 410, because it dropped support for some GPUs
<tjaalton> tseliot: hmm ok, i'll check what's on that machine
<tjaalton> 930mx or something
<tseliot> tjaalton: ideally, software update would check that, and migrate drivers (or ask users), but it is not the case
<tjaalton> right, 410 should support it
<ricotz> tjaalton, hi, by any chance, did you made a backport of llvm-toolchain-7 to xenial?
<tjaalton> ricotz: no
<tjaalton> bionic
<ricotz> tjaalton, ok
<tjaalton> tseliot: so, I'd like to test the serverside glxvnd thing but can't figure out how to take nvidia-prime out of the picture
<tjaalton> it's either intel or nvidia, not both that are enabled
<tjaalton> hmm, could be nvidia doesn't support prime offloading yet
<tjaalton> yep
<tjaalton> so right now it's only useful for xwayland
<ricotz> tjaalton, is it worth to try prime with sandybridge?
<tjaalton> ricotz: what do you mean?
<tjaalton> why would intel be the blocker there
<ricotz> tjaalton, I mean, is the support of sandy bridge still properly done for those kind of features like working with nvidia prime?
<tjaalton> why wouldn't it be?
<tjaalton> it's just one intel gpu
<tjaalton> thing is that you need to use nouveau
<ricotz> ok, I assumed there are some hardware internals involved for proper support
<tjaalton> or just nvidia
<ricotz> I see
#ubuntu-x 2019-02-08
 * alkisg got access to one of the schools with black screens, let's see... i5-6400, HD Graphics 530 [8086:1912] (rev 06)
<alkisg> Updating from ppa: libegl-mesa0 libegl1-mesa libgbm1 libgl1-mesa-dri libgl1-mesa-glx  libglapi-mesa libglx-mesa0 libosmesa6 libwayland-egl1-mesa libxatracker2  mesa-va-drivers mesa-vdpau-driver
<alkisg> tjaalton: sorry for the direct ping; I updated to the mesa from the PPA, and lightdm still fails. Anything else I can try? Any logs to keep, while the server is booted without nomodeset?
<tjaalton> boot an earlier kernel
<alkisg> .44 or .29?
 * alkisg tries with this first: vmlinuz-4.15.0-44-generic
<tjaalton> -44 is broken
<alkisg> OK, 29 then, from the repositories
<alkisg> 4.15.0.20.23 500
<alkisg> Sorry I meant that one, that is available from the stock repositories
<tjaalton> that's the metapackage
<alkisg> apt install linux-image-4.15.0-20-generic linux-modules-4.15.0-20-generic linux-modules-extra-4.15.0-20-generic
<tjaalton> that should do it
<alkisg> GRUB_DEFAULT='gnulinux-advanced-00d0b350-2f42-4574-8abe-b53ede7da033>gnulinux-4.15.0-20-generic-advanced-00d0b350-2f42-4574-8abe-b53ede7da033'; update-grub; reboot
<alkisg> tjaalton: the same. `uname -r` = 4.15.0-20-generic, gput-manager, lightdm ==> failed
<alkisg> Xorg.log reports success even though it fails: https://termbin.com/6l2b
<alkisg> Plain `xinit` reports: i965: Failed to submit batchbuffer: Invalid argument
<tjaalton> downgrade mesa then
<alkisg> I'll need a bit of help on that, which packages does it involve, any handy commands? Trying...
<tjaalton> you just mentioned the list of packages that got updated..
<tjaalton> apt install foo=ver
<alkisg> That was the updates from the ppa, not the whole list
<alkisg> echo $(dpkg -l '*mesa*' | awk '/^ii/ { print $2 }')
<alkisg> libegl-mesa0:i386 libegl1-mesa:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 libglx-mesa0:i386 libosmesa6:i386 libwayland-egl1-mesa:i386 mesa-utils mesa-va-drivers:i386 mesa-vdpau-drivers:i386
<tjaalton> apt-cache policy libgl1-mesa-dri for instance will show that the original version is still there
<alkisg> Are those enough, to downgrade?
<tjaalton> maybe, and it'll complain if there are more dependencies
<alkisg> Ty, trying
<alkisg> I'll try 18.0.0~rc5-1ubuntu1
<tjaalton> that's what main has
<tjaalton> and bionic shipped with
<alkisg> I have those available: 18.2.8-0ubuntu0~18.04.1~ppa1,  18.2.2-0ubuntu1~18.04.1, 18.0.0~rc5-1ubuntu1
<alkisg> Which one should I try? I think the first 2 failed
<tjaalton> the last
<alkisg> So I guess, try with the stock bionic? Yup.
<alkisg> apt install libegl-mesa0:i386=18.0.0~rc5-1ubuntu1 libegl1-mesa:i386=18.0.0~rc5-1ubuntu1 libgl1-mesa-dri:i386=18.0.0~rc5-1ubuntu1 libgl1-mesa-glx:i386=18.0.0~rc5-1ubuntu1 libglapi-mesa:i386=18.0.0~rc5-1ubuntu1 libglx-mesa0:i386=18.0.0~rc5-1ubuntu1 libosmesa6:i386=18.0.0~rc5-1ubuntu1 libwayland-egl1-mesa:i386=18.0.0~rc5-1ubuntu1 mesa-va-drivers:i386=18.0.0~rc5-1ubuntu1 mesa-vdpau-drivers:i386=18.0.0~rc5-1ubuntu1 libgbm1=18.0.0~rc5-1ubunt
<alkisg> u1 libegl1-mesa=18.0.0~rc5-1ubuntu1 libegl1=1.0.0-2ubuntu2 libglvnd0=1.0.0-2ubuntu2 libgl1-mesa-glx=18.0.0~rc5-1ubuntu1 libgl1=1.0.0-2ubuntu2 libglx0=1.0.0-2ubuntu2
<alkisg> ...a long list there, probably cut by irc :D
<tjaalton> why would it want to downgrade libegl1 et al
<alkisg> Version mismatches
<tjaalton> huh?
<tjaalton> ah ok
<tjaalton> nevermind
<tjaalton> doesn't matter
<alkisg> I build all this list slowly, because each one complained about some other package version mismatch,
<alkisg> now it wants to remove vlc and kio etc, but I don't know how else to do it
<alkisg> The following packages will be REMOVED:  kinit kio kolourpaint libgles2 libkf5kdelibs4support5  libkf5kdelibs4support5-bin libkf5notifications5 libkf5parts-plugins  libkf5parts5 libkf5sane5 libkf5wallet-bin libkf5wallet5 libkwalletbackend5-5   libwayland-egl1 phonon4qt5 phonon4qt5-backend-vlc vlc   vlc-plugin-video-output
<alkisg> I can put them back on after we test, shall I continue?
<tjaalton> downgrade wayland
<tjaalton> too
<alkisg> They're using MATE, so I hope it won't even load wayland
<tjaalton> and libgles2
<alkisg> apt install libgles2=1.0.0-2ubuntu2 ; reboot
<alkisg> tjaalton: that worked
<tjaalton> downgrade fixed it?
<alkisg> Yes
<tjaalton> ok, file a bug upstream and on lp
<alkisg> Thank you, doing so
<tjaalton> wondering if it's lightdm which is triggering it
<alkisg> Maybe MATE as well
<alkisg> But plain xinit doesn't work either
<alkisg> I.e. it's possible that ubuntu gnome users don't even see that, I don't know
<tjaalton> how did you run xinit if it didn't have any display?
<alkisg> From something like ssh
<alkisg> (epoptes, remote control)
<tjaalton> k
<tjaalton> does xubuntu use the same bits?
<tjaalton> probably not
<alkisg> Unfortunately I don't have a hardware that fails locally, and it's very hard to test other distros than mate remotely
<alkisg> I'll try to find some affected hardware tomorrow
<tjaalton> ubuntu mate
<tjaalton> I'll try that on snb
<alkisg> I file it in https://bugs.freedesktop.org/enter_bug.cgi under Drivers/DRI/i915? It warns "that's the old driver"
<tjaalton> i965
<alkisg> Ty
<tjaalton> unless it's migrated to gitlab, not sure
<alkisg> They also have a 18.3 there, can I try that in Ubuntu?
<alkisg> xorg-edgers or something?
<tjaalton> I can push that to x-swat updates
<alkisg> lspci => 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) 	Subsystem: ASUSTeK Computer Inc. HD Graphics 530 [1043:8694] 	Kernel modules: i915
<tjaalton> does dmesg have anything btw?
<tjaalton> it's sandybridge
<alkisg> tjaalton: i915?
<tjaalton> yes
<alkisg> And I should report it under i965?
<tjaalton> the dri driver is i965
<alkisg> ty
<alkisg> dmesg is clean
<alkisg> https://termbin.com/ip4e
<tjaalton> hmm
<tjaalton> it's skylake actually
<alkisg> A mail was just sent to ltsp-discuss, "black screen on cinnamon"
<alkisg> I think they're using lightdm too
<tjaalton> k
<alkisg> https://bugs.freedesktop.org/show_bug.cgi?id=109583
<ubottu> Freedesktop bug 109583 in Drivers/DRI/i965 "Black screen on skylake after 18.0 => 18.2 update" [Normal,New]
<alkisg> Filing in launchpad now...
<tjaalton> check lightdm logs btw
<tjaalton> if they have the same error
<alkisg> I don't think systemd even starts lightdm as it depends on gpu-manager
<alkisg> Ah, I can try restarting gpu-manager, I think that allows systemd to start lightdm and let it fail there..
<tjaalton> so how does it fail then?
<tjaalton> and what's failing..
<tjaalton> so you're running 32bit on skylake?
<alkisg> gpu-manager, with some error message about not able to initialize the cards etc
<alkisg> Yes. Hmm, I'll try to see if 64bit installations are affected
<alkisg> Let me update mesa so that I see the errors again
<tjaalton> just run full dist-upgrade
<alkisg> Yeah that's the easy one :)
<alkisg> Launchpad bug: https://bugs.launchpad.net/mesa/+bug/1815172
<ubottu> Launchpad bug 1815172 in mesa (Ubuntu) "Black screen on skylake after 18.0 => 18.2 update" [Undecided,New]
<tjaalton> great
<tjaalton> i wonder if that xinit is doing the right thing, or if it's trying to use remote x somehow
<alkisg> tjaalton: nah I use it a lot of times, it works great for troubleshooting
<tjaalton> ok then
<alkisg> I can even get remote access after that, I know that step
<alkisg> *remote xorg, with vnc
<alkisg> systemctl status gpu-manager: https://termbin.com/kkix
<tjaalton> 18.3.3 test build on cosmic fine, now bionic
<alkisg> Thanks
<alkisg> gidarakos: could you tell the school to leave the server open for the whole weekend?
<alkisg> *running
<tjaalton> tseliot: ^
<tjaalton> tseliot: the gpu-manager error
<alkisg> systemctl status lightdm: https://termbin.com/ybev
<tjaalton> check it's logs then
<tjaalton> tseliot: probably nothing
<alkisg> Clean lightdm.log, after doing: systemctl start gpu-manager; systemctl start lightdm: https://termbin.com/ssrb
<alkisg> gpu-manager runs for a bit, and allows the lightdm service to run without dependency issues, then enter the failed state
<tjaalton> then look at the x log
<tjaalton> [+0.18s] DEBUG: XServer 0: X server stopped
<tjaalton> it was respawning every 0.2s
<alkisg> Last xorg.log: https://termbin.com/92rx
<tjaalton> huh
<alkisg> I never see any issues in xorg log in these tests
<tjaalton> so it's a client crashing that takes the server down without leaving a trace in the log
<tjaalton> enable apport, check /var/crash
<alkisg> Isn't xinit a simpler test there?
<tjaalton> maybe
<alkisg> As it doesn't involve lightdm and anything?
<alkisg> xinit again gives a clean xorg.log, with just this in stderr: i965: Failed to submit batchbuffer: Invalid argument | xinit: giving up | xinit: unable to connect to X server: Connection refused | xinit: server error
<tjaalton> ok
<alkisg> Apport is enabled afaik, but nothing in /var/crash
<alkisg> https://wiki.ubuntu.com/Apport#How_to_enable_apport
<tjaalton> alright
<tjaalton> uploaded 18.3.3 to ppa:ubuntu-x-swat/updates
<alkisg> Ty, adding...
<tjaalton> not built yet
<gidarakos> alkisg: Ok, I'll ask for it and I'll let you know..
<alkisg> 18.2.8-0ubuntu0~18.04.1~ppa1 500 for now, waiting
<alkisg> Thank gidarakos
<gidarakos> alkisg: you are welcome! :)
<alkisg> Another school that has the issue, said: 64bit installation, Intel Corporation HD Graphics 530 [8086:1912] (rev 06)Â Â Â Subsystem: Dell HD Graphics 530 [1028:06b7]
<alkisg> So fortunately it doesn't just happen on 32bit systems :)
<tjaalton> k
<alkisg> Upgrading to 18.3..
<alkisg> Same issue
<tjaalton> cool
<tjaalton> no need to bisect
<alkisg> Eh, unless we end up needing to bisect between 18.0 and 18.2, to pinpoint the issue :D
<tjaalton> nah
<tjaalton> what does xinit try to run, btw?
<alkisg> tjaalton: would it make sense to try with a -hwe kernel, something newer than 4.15?
<alkisg> xinit runs xterm
<tjaalton> k
<alkisg> When not provided any params
<tjaalton> right
<tseliot> tjaalton: is that a hybrid system?
<tjaalton> no
<alkisg> Debug log: https://termbin.com/6n12
<tseliot> then I doubt the error is fatal
<alkisg> After: echo 0xf > /sys/module/drm/parameters/debug; xinit; dmesg
<tjaalton> right, it didn't prevent lightdm from starting
<tjaalton> alkisg: chris (ickle) is also on #intel-3d
<tjaalton> hum, should ubuntu mate support efi boot?
<tjaalton> probably not
<tjaalton> doesn't have an EFI dir
<tjaalton> trying it on a kabylake
<tjaalton> seems to hang
<tjaalton> hmm no, it was probably respawning the desktop and didn't accept any input other than power button
<tjaalton> yep, works with nomodesest
<tjaalton> -set
<tjaalton> oh right, 32bit doesn't support efi..
<tjaalton> alkisg: try with the hwe kernel
<tjaalton> linux-image-4.18.0-14-generic
<tjaalton> and the modules
<tjaalton> alkisg: try the kernel from proposed
<tjaalton> alkisg: nevermind
<tjaalton> but try hwe kernel
<tjaalton> 64bit daily image seems to work fine here
<tjaalton> alkisg: I'm running 64bit mate with stock bionic kernel & X and things work fine :/
<alkisg> Back
<alkisg> tjaalton: AFAIK all ubuntu CDs have the EFI dir, but in the fat special file system, not in the iso9xx noe
<alkisg> *one
<alkisg> I do have MATE installed under EFI
<alkisg> Ah 32 bit, ok, yeah
 * alkisg tries with -hwe
<alkisg> apt install linux-generic-hwe-18.04
<tjaalton> I'll install 32bit version next
<alkisg> tjaalton: Does it run with 4.15 for you?
<tjaalton> 64bit did
<alkisg> Which card, the same as the schools?
<tjaalton> kabylake, same gen9 as skylake
<alkisg> Maybe it depends on the specific model?
<alkisg> Rebooting with 4.18...
<alkisg> 4.18.0-14-generic => failed
<tjaalton> k
<tjaalton> skl gt2 is pretty much the same as kbl gt2, which this is
<alkisg> A school did report failure with their 64bit installation, so I don't know what  to say
<tjaalton> could be something else
<tjaalton> meh, installing 32bit messed up grub/efi
<alkisg> Do you get the rescue prompt?
<tjaalton> yes
<alkisg> set root=(hd0,gpt1)
<alkisg> configfile /boot/grub/grub.cfg
<alkisg> I think this should work...
<alkisg> Point it to your 64bit instalaltion
<alkisg> After it boots, run grub-install /dev/sda
<tjaalton> so what after configfile?
<tjaalton> it just clears the screen
<alkisg> Ouch, it should have displayed the grub menu
<alkisg> set root=(hd0,gpt  ==> tab there for autocompletion
<alkisg> If you installed in 2 partitions, select the other one
<tjaalton> nah
<alkisg> Eh, then manually load linux/initrd
<alkisg> linux /boot/vmlinuz root=/dev/sda1
<alkisg> initrd /boot/initrd.img
<alkisg> boot
<alkisg> And if grub.cfg was empty,you'll need `update-grub` as well, to generate a proper one
<tjaalton> i'll just fix it from a live session
<tjaalton> ha, was able to boot the 32bit install after all, and it works fine
<alkisg> Another affected school has a slightly different card: 
<alkisg>  root@pc02:~# lspci -nn -k | grep -A 2 VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 [8086:5912] (rev 04)         Subsystem: ASRock Incorporation HD Graphics 630 [1849:5912]         Kernel driver in use: i915
<tjaalton> that's kbl gt2, which I have
<alkisg> Hrm. Stranger and stranger.
<alkisg> Should I mention in the bug report that we're using modesetting instead of the intel driver? (the Ubuntu defaults)
<tjaalton> no
<tjaalton> it's seen on the X log
<alkisg> OK, ty
<alkisg> tjaalton: you can boot an efi installation from grub-rescue-cd, by typing that "configfile" command above, if you feel like spending the time to test that...
<tjaalton> yeah I fixed it already
 * alkisg tests with linux-image-4.20.7-042007-generic_4.20.7-042007.201902061234_i386.deb ...
<tjaalton> oh right, I was about to push mesa 19.0rc2 somewhere..
<alkisg> They're asking me for the output of `/usr/bin/glxinfo -B`, how should I provide that, with nomodeset or with AccelMethod=none?
<alkisg> I don't have a display without those, and I guess no glx in either case?
<tjaalton> you should probably get the hw on your desk
<tjaalton> otherwise it'll be painful
<tjaalton> as it is
<alkisg> I only have one so far in my city, and it's the school  server... I'll see if I can replace the server with something else, and keep the disk maybe...
<alkisg> The others are in other cities
<tjaalton> you don't have skylake?
<tjaalton> I guess legacy bios is the key
<tjaalton> but I can't wipe my machines
<alkisg> I only have this in my office: 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)
<tjaalton> these machines
<alkisg> Wait, I think it works fine with 4.20
<alkisg> Let me reboot without xorg.conf...
<tjaalton> that's a haswell
<tjaalton> gen7 gpu
<alkisg> I don't have anything more recent here :(
<alkisg> But I tried 4.20 in the remote school, and I think it works, I'll be sure after the reboot
<tjaalton> cool
<alkisg> Not sure how that will help us for a "real" solution, but it's surely progress
<alkisg> Yup, it seems to work ifne
<alkisg> fine
<tjaalton> it's a kernel bug then
<tjaalton> fixed between 4.18..4.20
<tjaalton> ickle might have ideas.. post to the upstream bug
<tjaalton> looking at changes to i915_gem_execbuffer.c gives some hints
<alkisg> So, mesa=18.0 works, mesa=18.2 breaks, yet it's a kernel issue? :D
<alkisg> Meh these programmers! :P
 * alkisg has been a programmer / sysadmin for 25 years now...
<tjaalton> needs a newer kernel :)
<tjaalton> alkisg: you could bisect the kernel by using mainline builds between 4.18 and .20
<tjaalton> alkisg: if you're still around, boot v4.19.0, then .3
<tjaalton> .3 has plenty of changes for i915
<alkisg> tjaalton: thanks, will do
<alkisg> tjaalton: so the end result will probably be a kernel cherrypick for 4.15 in bionic?
<tjaalton> es
<tjaalton> yes
<alkisg> ty
<alkisg> tjaalton: if you do build a kernel, please build both 32bit and 64bit, so that schools test both of them...
<tjaalton> alkisg: need to push to a ppa
<tjaalton> but can do
<tjaalton> ppa with tons of space, I have that
<alkisg> Great, even better than wget
<tjaalton> could probably cross-build locally, but meh
<tjaalton> I'll verify the build first as 64bit
<tjaalton> locally, then upload
<tjaalton> alkisg: maybe I'll just revert softpin support from mesa, as ickle suggested.. more likely to get in the release
<alkisg> Sure, whatever is easier
<alkisg> I can test mesa then,if you want me to
<tjaalton> yes, getting late, maybe not today, we'll see
<tjaalton> I'll check the code first how to disable it
<alkisg> np, take your time, thanks for all the help
<tjaalton> must be this https://pastebin.com/tAeRSD1v
<tjaalton> so I'll revert that
<tjaalton> alkisg: I've pushed it to https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging
<tjaalton> and closed the upstream bug
<alkisg> tjaalton: thanks, will test when it builds. It's 18.2 with that line reverted?
<tjaalton> yeah
<alkisg> Great, ty
<tjaalton> the kernel patches will be backported later
<tjaalton> alkisg: i386 seems to be built
<alkisg> ty,testing...
 * alkisg hopes he didn't mess up grub this time :D
<tjaalton> mesa doesn't touch it
<tjaalton> kernel update does
<alkisg> The hard part is configuring grub to boot an older kernel
<alkisg> From 4.19 back to 4.15
<tjaalton> uninstall 4.19
<alkisg> Not good when it's running, apt refuses
<tjaalton> complains
<alkisg> Hmm maybe that changed from the last time I tried
<alkisg> tjaalton: success!
<alkisg> Can I copy this to the schools ppa, for everyone to get?
<tjaalton> sure
<janesma> tjaalton: Mesa i965 was hitting consistent deadlocks with userptr, so we switched entirely to softpin recently
<alkisg> I assume it'll be overriden by the next stable update, right?
<tjaalton> it'll be in proposed soon
<janesma> alkisg: you reported that this happened with 64bit systems too?  
<tjaalton> janesma: well, changing the kernel takes more time than rolling a revert via mesa
<alkisg> janesma: yes, a school said it saw it on a 64bit system
<janesma> yep
<tjaalton> and kernel won't get changed for 18.04.2 image which is next week
<janesma> why wouldn't see the same thing with upstream mesa 18.3.3 and linux 4.18.2, on a 64bit system?
<alkisg> The same card?
<alkisg> tjaalton didn't see it either, I don't know why
<tjaalton> beats me, but this was with legacy bios
<janesma> it was a skylake machine...  I think all of this should be the same for gen9
<tjaalton> which might or might not play a part
<tjaalton> I tested on a kbl laptop
<janesma> yeah, gen9 has the same feature set (skylake kabylake coffeelake)
<janesma> 100% symmetry in the mesa regressions
<janesma> we don't test different boot configurations (legacy/uefi), and I can't see how that would affect graphics....  but if it does then we have a new validation problem.
<tjaalton> I'll test next week on hw that I can wipe clean
<janesma> I'm hoping that this is down to running a 32bit kernel.
<tjaalton> I managed to boot that too, still worked
<janesma> I'd like to figure out how to reproduce this and make sure we aren't missing something in Mesa CI.
<janesma> I think disabling softpin will cause intermittent hangs under load for ubuntu users.  Not nearly as bad as a black screen.
<tjaalton> that's a good tradeoff for now
<alkisg> It's not configurable by kernel cmdline or xorg.conf, right?
<janesma> mesa 19.0 has the switch to softpin, in 731c4adcf9b11
<janesma> not sure what that will do to oibaf/padoka users.  I guess they will be getting newer kernel and mesa, so they won't suffer.
<tjaalton> alkisg: bionic will get 18.2.2 + the revert soon, 18.2.8 will follow after 18.04.2 is released
<tjaalton> alkisg: are you still able to verify this build?
<alkisg> tjaalton: I only have access to one server now, and it works with this build, yes
<tjaalton> remove 18.2.8 with ppa-purge, then enable proposed and install the new update from there, then verify bionic for the bug
<alkisg> Schools will need it on monday anyway, so if it'll get the build until then, I can do the verification done step
<alkisg> Will do
<tjaalton> it just got accepted, so the build takes a while again
<alkisg> Tomorrow is fine
<tjaalton> https://launchpad.net/ubuntu/+source/mesa/18.2.2-0ubuntu1~18.04.2
<tjaalton> already building
<tjaalton> yeah tomorrow is fine I guess
<tjaalton> thanks for everything so far
<tjaalton> almost 2100, time to grab a beer
<alkisg> Thank you too!
<tjaalton> too late to go out for a run
<alkisg> Oh, same timezone, where are you?
<tjaalton> espoo, finland
 * alkisg ran 10 km earlier
<alkisg> Ah, greece here, so yeah same timezone
<tjaalton> yup, I remember
 * alkisg sends a virtual beer to tjaalton :)
<tjaalton> hope we'll get to crete again next year
<tjaalton> though it's a tourist trap but we like it
<alkisg> Here's a nice trick I found to revert to the stock versions, even when ppa-purge can't do it; google translate needed: http://alkisg.mysch.gr/steki/index.php?topic=7370.0
<alkisg> Yeah I spent 5 of my best months in crete
<tjaalton> what happened ?-)
<alkisg> Nah, just talking in general, nothing happened here
<alkisg> I had to research it for schools with veeery broken installations
<alkisg> that were installing .debs from wherever they could find them
<tjaalton> I mean in crete, why only 5mo :)
<alkisg> Haha
<alkisg> I was in the army then
<tjaalton> ah right
<alkisg> For 23 months, 5 in crete
<alkisg> And even though the army generally isn't a good period.... crete was soooo nice....
<tjaalton> I remember f-16 flyovers
<alkisg> and many tourist women too :D
<tjaalton> yes yes, very receptive
<tjaalton> I assume
<janesma> tjaalton: if you find a way to reproduce this locally, can you update me?
<alkisg> So to only update mesa from proposed, I guess this will do it (after apt sources + pinning):
<alkisg> apt update libegl-mesa0:i386 libglapi-mesa:i386 libxatracker2:i386 libegl1-mesa:i386 libx11-6:i386 libgbm1:i386 libwayland-egl1-mesa:i386 libx11-data:i386 libgl1-mesa-dri:i386 libosmesa6:i386 libgl1-mesa-glx:i386 mesa-vdpau-drivers:i386 libx11-xcb1:i386 mesa-va-drivers:i386 libglx-mesa0:i386
<alkisg> I don't know why these libx11 things were in the upgraded-from-the-ppa list previously though...
<alkisg> tjaalton, janesma: apt policy libegl-mesa0:i386 => 18.2.8-0ubuntu0~18.04.1 from bionic-proposed/main
<alkisg> How can you upload 18.2.2 when it has 18.2.8?
<alkisg> Ah, maybe standard repository rules don't apply to the proposed queue :)
<tjaalton> alkisg: 18.2.8 got removed
<tjaalton> janesma: hope I can, next week
<alkisg> yup, proposed works, i'll comment in launchpad
<alkisg> Hmm it'll be hard to do the cosmic verification
<tjaalton> don't worry about that
<tjaalton> thanks for testing
<alkisg> :)
<alkisg> Thanks for the package :)
<tjaalton> alkisg: and released to updates :)
<tjaalton> now 18.2.8 back in
<alkisg> Yey!!!! :)
<tomreyn> is there a change to get vega20 fimwares from agd5f into disco before release?
<tomreyn> *chanCe
#ubuntu-x 2019-02-09
<tjaalton> tomreyn: via linux-firmware upstream
<tomreyn> tjaalton: yes, just upstream. i was working with someone in #ubuntu+1 yesterday who had a Radeon VII, which failed https://paste.ubuntu.com/p/RntsGxtNDS/ on anything including 5.0 until they installed vega20_sos.bin from upstream
<tomreyn> oh i get it now, your point is that those firmwares aren't in https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git yet, which is upstream for ubuntu's packages
<tjaalton> tomreyn: yes
<tomreyn> ok, i'm not sure how they get there, but asked in #amdgpu
<tomreyn> either way, it's probably too late for 18.04.2?
<tjaalton> yes
<tomreyn> a pity. thanks for your feedback.
<tjaalton> there's no driver support anyway
<tomreyn> oh 4.20+ only, i see
<mamarley> I have a user complaining about how the graphics drivers PPA version of 380.87 for Bionic will not install while the HWE Xorg packages are installed because the NVIDIA package depends on xserver-xorg-core and not xserver-xorg-core-hwe-18.04.  I was going to add an "or" to the dependency so either one would work, but then I looked at the official package of 390.77 and saw that it doesn't seem to be installable while the HWE packages are installed
<mamarley>  either.  Is that correct?  What should be done about this?
<alkisg> tjaalton: why again "verification-needed-bionic"? https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1815172
<ubottu> Launchpad bug 1815172 in linux (Ubuntu) "Black screen on skylake after 18.0 => 18.2 update" [Undecided,Confirmed]
<tjaalton> alkisg: yeah, don't worry about it
<tjaalton> couldn't be avoided
<bad-player> Just a noob trying to figure out which PPA is best for mesa updates on Ubuntu 18.04.  is the X PPA planned for the forseaable future? Looking for stable but updated
<bad-player> OpenGL version string: 4.4 (Compatibility Profile) Mesa 18.2.0-rc3
<alkisg> tjaalton: ah ok so no need for me to test, ty
#ubuntu-x 2019-02-10
<tjaalton> dunno what bad-player was talking about, but the updates ppa has 18.3.3 now
#ubuntu-x 2020-02-03
<ricotz> tseliot, hi, did you push a 440.59 package somewhere already?
<ricotz> never mind
#ubuntu-x 2020-02-04
<tseliot> ricotz, yes, packages for bionic and eoan should be available soon too https://launchpad.net/~oem-solutions-group/+archive/ubuntu/nvidia-driver-staging
<ricotz> tseliot, I found the package yesterday, thank you
<tseliot> good
<mamarley> ricotz: tseliot: I just wanted to let you guys know that I don't have any NVIDIA graphics cards anymore, so I'm not going to be packaging drivers any longer.  Since I don't play games anymore, the trouble of dealing with opaque bug reporting and difficulties supporting new kernel versions just wasn't worth it to me anymore, so I only use Intel graphics now.
<tseliot> mamarley, ok, no problem, I understand. Thanks for your help ;)
<ricotz> mamarley, hey, don't worry, thanks for your work! :)
<mamarley> You're both welcome!
#ubuntu-x 2020-02-05
<alkisg> Hi, has anyone heard of any bugs, where "AMD Ryzen 3 2200G with Radeon Vega Graphics [1002:15dd]" won't start Xorg on 18.04.4, kernel 5.3 etc,...
<alkisg> ...but only on the 32bit kernel, while it works on 64bit?
<tjaalton> no
<alkisg> Thank you; I'll tell the school to install amd64 for now, and revisit this later if any other school reports it again
#ubuntu-x 2020-02-06
<tjaalton> tseliot: will nvidia 340 stay in focal? the one risk I see is if there's no renamed hwe stack anymore it'd get removed once the abi is broken
<tjaalton> when src:xorg-server is synced from a newer release
<tseliot> tjaalton, new X abi means no nvidia-340. When are we going to get the new X ABI?
<tjaalton> no idea
<tjaalton> probably not before 20.10
<tjaalton> so maybe keep it as is and let people to freeze xserver at 1.20 if they need the legacy blob
<tjaalton> even if xserver 20 would be released this month, I wouldn't put it in focal
<tseliot> tjaalton, we need something to inform users. I don't want them to end up with a broken system if the try to install a new -hwe stack in 20.04, or in 18.04, for that matter
<tjaalton> 18.04 won't change
<tjaalton> as I said, there might not be a separate hwe stack
<tjaalton> for focal
<tseliot> tjaalton, oh, I missed that
<tjaalton> but I'm not sure how to inform users in that case
<tjaalton> besides, they might not notice if nouveau has improved
<tjaalton> which it better had with a newer mesa
<tjaalton> which already is a rolling update
<tseliot> tjaalton, I think this needs a little planning with the desktop team
<tseliot> (informing users)
<tjaalton> sure, in six months :)
<tjaalton> I mean, there's time
<tjaalton> more than that in fact
<tseliot> that's good
