#ubuntu-x 2006-09-25
<Ubugtu> New bug: #62002 in xorg (main) "Installer X server startup fails" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/62002
<Ubugtu> New bug: #59237 in xserver-xorg-video-mga (main) "Xubuntu login screen shows flashback of previous session after logout." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59237
<Ubugtu> New bug: #58382 in Ubuntu "Restore from Suspend creates problems" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58382
<Mithrandir> rodarvus: I have a patch to the X mouse driver which disregards button presses when you move the mouse (x,y,z or w); this is needed for my mx510 since otherwise the "scroll up" button (not the wheel) generates a button 6 (which is mapped to "back" in firefox) press as well as a button 4 press.
<Mithrandir> rodarvus: I can give you the patch, but does my solution sound good?
<rodarvus> hmm, to be sincere, I don't have much of an opinion on the subject. I'm not aware of any applications that actually use buttons 6 or 7.
<rodarvus> disabling button 6 completely would not be an ideal situation, though
<rodarvus> anyhow, feel free to add your patch and upload it - I really don't feel that strongly about it, and I guess it bothers other people with such featureful mouse too :)
<Mithrandir> button 6 isn't disabled, I've merely disabled drag with it.
<Mithrandir> (more or less
<Ubugtu> New bug: #62341 in linux-restricted-modules-2.6.15 "ndiswrapper crashes when laptop is unplugged" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/62341
<Ubugtu> New bug: #62352 in linux-restricted-modules-2.6.17 (restricted) "Kernel Update removes Intel Pro Wireless 3945" [Untriaged,Needs info]  http://launchpad.net/bugs/62352
#ubuntu-x 2006-09-26
<Ubugtu> New bug: #62093 in xserver-xorg-driver-via (main) "Computer locks up" [Untriaged,Confirmed]  http://launchpad.net/bugs/62093
<Ubugtu> New bug: #62465 in xserver-xorg-driver-nv "No X11/Xv support (X11 error: BadAlloc (insufficient resources for operation) ??,?% 5 0)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62465
<Ubugtu> New bug: #62472 in xorg "Horizontal scroll wheel generates incorect events" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62472
<Ubugtu> New bug: #62484 in xorg "Monitor frequencies not collected" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62484
<Ubugtu> New bug: #62492 in firefox "firefox crashes/freezes X with nvidia on some pages" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62492
<Ubugtu> New bug: #62510 in libdrm "problem in i915 driver hangs libdrm causing system freeze" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62510
#ubuntu-x 2006-09-27
<Ubugtu> New bug: #62534 in linux-restricted-modules-2.6.17 (restricted) "nvidia module load should be conditional on nvidia driver being used" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62534
<Ubugtu> New bug: #62537 in Baltix (main) "Font rendering glitches with radeon, known bug, patch exists" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62537
<Ubugtu> New bug: #62538 in xorg "No direct rendering for ATI Radeon Xpress 200M" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62538
<Ubugtu> New bug: #62574 in xserver-xorg-video-i810 "Xorg/GDM restart randomly with i810" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62574
<Ubugtu> New bug: #62575 in xserver-xorg-video-i810 "Impossible to get console login with ctrl+alt+F1 and video sucks" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62575
<Ubugtu> New bug: #62626 in xserver-xorg-input-synaptics "Random synaptics mouse input lockups" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62626
<Ubugtu> New bug: #62628 in xserver-xorg-video-nv "Desktop CD fails to initialize graphics device (regression to 6.06 LTS)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62628
<Ubugtu> New bug: #62647 in xorg "Random "Failed to start x server" on Dapper LTS" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62647
<Ubugtu> New bug: #62678 in xorg "In gdm or an X term, I can't use alphanumerical symbols in my password" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62678
<Ubugtu> New bug: #61103 in usplash "console fails to display after X starts" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61103
<Ubugtu> New bug: #61718 in usplash "Usplash breaks vesafb" [Undecided,Fix committed]  http://launchpad.net/bugs/61718
<Ubugtu> New bug: #61724 in usplash "usplash does not work with sisfb" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61724
<Ubugtu> New bug: #62686 in xkeyboard-config "ca(fr) layout is not included in /etc/X11/xkb/rules/base.xml" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62686
#ubuntu-x 2006-09-28
<Ubugtu> New bug: #62230 in xorg (main) "[edgy]  Corrupt graphics on boot" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62230
<Ubugtu> New bug: #59927 in xorg (main) "Edgy Knot 2 install crashes when configuring X." [Undecided,Unconfirmed]  http://launchpad.net/bugs/59927
<Ubugtu> New bug: #61140 in xkeyboard-config (main) "edgy knot-3 ignores keymap setting from boot" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61140
<Ubugtu> New bug: #61050 in xkeyboard-config "[Edgy]  Knot-3 Live CD sets up keyboard in English instead of Spanish" [Undecided,Confirmed]  http://launchpad.net/bugs/61050
<Ubugtu> New bug: #60248 in xorg (main) "[knot2]  LiveCD Fails on Dell Inspiron 5100" [Undecided,Needs info]  http://launchpad.net/bugs/60248
<Ubugtu> New bug: #59841 in xorg (main) "Knot2: Live CD improperly detects widescreen monitor." [Undecided,Needs info]  http://launchpad.net/bugs/59841
<Ubugtu> New bug: #59827 in xorg (main) "Bug with X Server and Ubuntu Installation" [High,Unconfirmed]  http://launchpad.net/bugs/59827
<Ubugtu> New bug: #59567 in xkill (main) "Firefox stops responding, and claims to be running even after killing it by xkill" [Undecided,Unconfirmed]  http://launchpad.net/bugs/59567
<Ubugtu> New bug: #58839 in xorg "Xorg.conf - driver set to ATI instead of NVidia - upgrade-report" [Undecided,Unconfirmed]  http://launchpad.net/bugs/58839
<Ubugtu> New bug: #59595 in xorg "X is unusably distorted when booting from Edgy knot 2 LiveCD on macbook pro" [Undecided,Confirmed]  http://launchpad.net/bugs/59595
<Ubugtu> New bug: #58534 in linux-restricted-modules-2.6.15 (restricted) "LT Modem not working properly" [Undecided,Confirmed]  http://launchpad.net/bugs/58534
<Ubugtu> New bug: #58637 in xorg (main) "Screen Resolution doesn't work" [Undecided,Unconfirmed]  http://launchpad.net/bugs/58637
<Ubugtu> New bug: #58587 in xlsfonts (main) "xlsfonts reports scalable fonts which don't seem to exist." [Undecided,Unconfirmed]  http://launchpad.net/bugs/58587
<Ubugtu> New bug: #58655 in xorg (main) "screen detection problem (edgy knot 2)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/58655
<Ubugtu> New bug: #62413 in xorg (main) "Black screen with a ATI graphic card" [Undecided,Needs info]  http://launchpad.net/bugs/62413
<Ubugtu> New bug: #62747 in xorg "Random system freeze at window operations" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62747
<Ubugtu> New bug: #62743 in Ubuntu "US keyboard on the livecd when selecting german in the boot-menu" [Undecided,Rejected]  http://launchpad.net/bugs/62743
<rodarvus> that must be a record of most bugs in a 12 hours period
<rodarvus> 26 new bugs for X
<Ubugtu> New bug: #62768 in xserver-xorg-video-ati "Very bad performance with X600 in Edgy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62768
#ubuntu-x 2006-09-29
<Ubugtu> New bug: #59609 in libxft (main) "Best font rendering suggestion" [Undecided,Confirmed]  http://launchpad.net/bugs/59609
<Ubugtu> New bug: #62794 in linux-restricted-modules-2.6.15 (restricted) "kernel updated but no linux-restricted-modules-2.6.15-27" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62794
<Ubugtu> New bug: #62928 in xserver-xorg-driver-nv "Instability, rendering problems" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62928
<Ubugtu> New bug: #62862 in network-manager "Atheros w-lan card doesn`t work on edgy live!" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62862
<Ubugtu> New bug: #62941 in xorg "many programs do not start due to missing fonts" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62941
<Ubugtu> New bug: #62985 in xorg-server "Blank screen on Toshiba Portege R200 with Edgy Beta 1" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62985
<Ubugtu> New bug: #63006 in linux-restricted-modules-2.6.17 (restricted) "linux-restricted-modules not installed on edgy-beta-alternative after detecting madwifi card" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63006
<Ubugtu> New bug: #63011 in xorg "opera breaks dapper->eft upgrade" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63011
<Ubugtu> New bug: #63017 in xorg-server (main) "In 3DFX (Voodoo3 3000, for example) cards, Ubuntu cannot form the resolution of screen to any more of VGA to 60 Hertz." [Undecided,Unconfirmed]  http://launchpad.net/bugs/63017
<Ubugtu> New bug: #63020 in xorg "MacBook native screen resolution not available by default" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63020
<Ubugtu> New bug: #63030 in xserver-xorg-video-via "support for non power of two texture missing" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63030
<Ubugtu> New bug: #63049 in xserver-xorg-video-trident "Upgrade from Ubuntu 6.06 to 6.10 beta breaks X" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63049
<Ubugtu> New bug: #61247 in Ubuntu "Instalation CD kubuntu edgy knot-3 problem" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61247
<Ubugtu> New bug: #63046 in Ubuntu "Installation of Edgy Eft Beta crash" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63046
<Ubugtu> New bug: #63053 in kubuntu-default-settings "Upgrade from dapper drake to edgy beta breaks X" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63053
<Ubugtu> New bug: #63051 in xserver-xorg-video-trident "Dragging and scrolling garbles window content (edgy beta)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63051
#ubuntu-x 2006-09-30
<Ubugtu> New bug: #63068 in xorg "Xorg occassionaly crashes after resuming" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63068
<Ubugtu> New bug: #63050 in x11proto-xinerama (main) "xinerama broken on upgrade dapper to edgy beta" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63050
<Ubugtu> New bug: #63015 in xorg (main) "Edgy: Matrox G400 OpenGL "hangs"" [Undecided,Needs info]  http://launchpad.net/bugs/63015
<Ubugtu> New bug: #63072 in xserver-xorg-video-ati "[R128]  Dapper ppc install cd SIGSEGV initializing X on iMac" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63072
<Ubugtu> New bug: #63097 in xorg "xserver-xorg-video-* did not get installed during upgrade from dapper" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63097
<Ubugtu> New bug: #62587 in xkeyboard-config (main) "The Arabic Write error !" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62587
<Ubugtu> New bug: #63063 in xorg (main) "Screen Resolution/Hz wrong" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63063
<Ubugtu> New bug: #63182 in linux-restricted-modules-2.6.17 (restricted) "fglrxinfo returns mesa drivers in edgy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63182
<Ubugtu> New bug: #61656 in gok "gok doesn't work" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61656
<Ubugtu> New bug: #63227 in gok "[edgy]  gok crash at startup" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63227
#ubuntu-x 2006-10-01
<Ubugtu> New bug: #63258 in xserver-xorg-driver-i810 "Mouse cursor goes invisible after return from suspend" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63258
<Ubugtu> New bug: #63197 in linux-restricted-modules-2.6.17 (restricted) "There is no linux-restricted-modules-2.6.17-10-powerpc64-smp" [Medium,Confirmed]  http://launchpad.net/bugs/63197
<Ubugtu> New bug: #63269 in mesa "Broken dependencies for libglu1-mesa-dev" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63269
<Ubugtu> New bug: #63285 in linux-restricted-modules-2.6.15 (restricted) "firegl_strub_register failed" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63285
<Ubugtu> New bug: #63310 in xkeyboard-config "Arabic Typing Error" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63310
<Ubugtu> New bug: #63320 in xorg "XServer don't detect Display Resolution (not a driver problem)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63320
<Ubugtu> New bug: #62943 in xserver-xorg-video-ati "desktop not being redrawn with EXA" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62943
<Ubugtu> New bug: #63365 in xserver-xorg-input-keyboard "(Edgy) Right Alt Key generates ISO_Level3_Shift instead of Alt_R on Logitech Keyboard" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63365
<Ubugtu> New bug: #63295 in xkeyboard-config (main) "A bug within my BG Phonetic support?" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63295
<Ubugtu> New bug: #61094 in linux-restricted-modules-2.6.17 (restricted) "network manager is not able to use zd1211rw with WPA" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61094
<Ubugtu> New bug: #63397 in xkeyboard-config (main) "No layout preview in Keyboard Preferences - edgy 6.10 beta" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63397
<Ubugtu> New bug: #63409 in xorg-server "beryl-manager (under Dapper with ati radeon 9600) refuses after some time to obtain/refresh configuration changes" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63409
<Ubugtu> New bug: #63427 in linux-restricted-modules-2.6.17 "Running bzflag results in xorg lockup/Xid" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63427
#ubuntu-x 2007-09-24
* Starting logfile irclogs/ubuntu-x.log
<tepsipakki> bryce_: yes, I reopened that
<tepsipakki> ok, so I'll merge nv and ati.. lets hope they'll make it in beta :)
* bryce_ crosses fingers
<ubotu> New bug: #51421 in gtk-qt-engine (main) "GTK applications leading Xorg to huge memory usage" [Undecided,Confirmed]  https://launchpad.net/bugs/51421
<ubotu> New bug: #134370 in xserver-xorg-video-ati (main) "Video dosen't play correctly in Totem" [Low,New]  https://launchpad.net/bugs/134370
<mvo> bryce: do you think there will be anything we can do about bug #133118 ? if not I will blacklist it for compiz 
<ubotu> Launchpad bug 133118 in xserver-xorg-video-intel "very corrupt X after suspend/resume" [High,Confirmed]  https://launchpad.net/bugs/133118
<ubotu> New bug: #144382 in xserver-xorg-video-ati (main) "FFe: a new upstream version" [Undecided,New]  https://launchpad.net/bugs/144382
<ubotu> New bug: #144387 in xserver-xorg-video-nv (main) "FFe: a new upstream version" [Undecided,New]  https://launchpad.net/bugs/144387
<tepsipakki> hmm, no new ati/nv for beta
<ubotu> New bug: #105822 in xorg-server (main) "special chars mangled after switch to graphical console" [Undecided,New]  https://launchpad.net/bugs/105822
<tormod> bryce: is /etc/gdm/failsafeInstall in use? it looks broken. do you know who wrote it?
<bryce_> tormod, I wrote it, and it's no longer in use; we can drop it now.
<tormod> bryce, fine. the sed regexps were pretty broken.
<mvo> bryce_: have you seen my earlier question about -intel and the texture problem after resume on i855?
<bryce_> mvo, no I didn't
<bryce_> mvo, I'll look into it
<bryce_> tepsipakki: think we'll be able to get them in post-beta?
<tepsipakki> bryce_: yes, hopefully so
<bryce_> do you have the debs available?  we may as well put them up for testers
<tepsipakki> I haven't built them, because our gutsy installations break on first boot for some reason
<tepsipakki> I mean, they don't boot :)
<tepsipakki> I think tormod has made a deb already
<tepsipakki> of ati
<bryce_> arg
<bryce_> mvo, I don't know of anything simple we could do for 133118
<mvo> bryce_: ok, I will blacklist it then for compiz I think
<bryce_> you're blacklisting just that particular piece of hardware, or all of -intel?
<mvo> bryce_: just the pci-id of that card
<bryce_> ahh, ok sounds good
<mvo> bryce_: it should also be only for intel
<mvo> I think i810 works
<bryce_> mvo, I didn't see it reported upstream.  If we can get logs and confs, I'll go ahead and report it upstream.
<mvo> bryce_: ng and soren can reproduce it, it should be no problem to get good logs :)
<bryce_> awesome
<bryce_> tepsipakki: do you know if tormod has the .debs posted somewhere I could point to?
<tepsipakki> bryce_: yes, the link is on the XorgOnTheEdge (or similar) wikipage
<tepsipakki> right, https://wiki.ubuntu.com/XorgOnTheEdge
<bryce_> thanks
<bryce_> testing... brb
<bryce_> huh, that definitely changed multi-head detection
<tepsipakki> bryce_: the new ati?
<ubotu> New bug: #144103 in xserver-xorg-video-ati (main) "window title is white when window is maximized" [Undecided,New]  https://launchpad.net/bugs/144103
<ubotu> New bug: #139726 in xorg (main) "[Gutsy} GDM is missing menu items" [Undecided,New]  https://launchpad.net/bugs/139726
<tepsipakki> bryce_: still testing?-)
<bryce_> yeah
<tepsipakki> bryce_: was that last comment about the new ati?
<bryce_> yup
<tepsipakki> for better?
<tepsipakki> +changed the multihead
<bryce_> well, I'm testing dual-cards (i.e. triple-head), and it doesn't work yet
<bryce_> dual-head works ok
<bryce_> although I had to tweak my xorg.conf a little
<tepsipakki> yes, static rules need that
<bryce_> overall it's better, but there's still room to improve
<bryce_> I've also gotten hit by the tiny font issue
<tepsipakki> somewhere it was said that multicard support is indeed not there yet..
<bryce_> well, tiny fonts in firefox at least
<bryce_> http://bryceharrington.org/Photos/X/
<bryce_> the first photo is after booting with two Screen sections
<bryce_> the second is what happened after I went to tty1 and back
<bryce_> third is kdm
<tepsipakki> so the second photo looks good?
<bryce_> yeah
<bryce_> hmm, no compiz
<bryce_> heya tormod
<tormod> hi bryce
<bryce_> tormod, I'm playing with your -ati debs :-)
<tormod> just testing out 6.7.194 now
<bryce_> I almost got 3 monitors - http://bryceharrington.org/Photos/X
<tormod> wow that's some desktop :)
<bryce_> I'm not sure exactly how you'd use xrandr to arrange the monitor on the other card, since it's got the same name as one of the other monitors
<jcristau> from the reports we got it seems that multi-card setups are broken in xserver 1.4
<bryce_> one other issue I've noticed since after 6.6.3 is that one monitor's display is "fainter" than it used to be.  
<bryce_> hard to describe, but it's like the contrast is turned up too high
<bryce_> unfortunately, fiddling with the contrast and other monitor controls has no effect
<ubotu> New bug: #144558 in xorg-server (main) "Mouse pointers corrupted" [Undecided,New]  https://launchpad.net/bugs/144558
<tepsipakki> bryce_: 
<tepsipakki> 06:57 < benh> it still does something weird mucking with the backlight intensity
<tepsipakki> 06:57 < benh> I suppose I'll have to fix that at one point :-)
<tepsipakki> 07:02 -!- ctyler [n=chris@global.proximity.on.ca]  has joined #xorg-devel
<tepsipakki> 07:05 < agd5f> benh: i have code in the driver to control the backlight, but it seems not all  oems use the built in controls
<tepsipakki> 07:05 < agd5f> so it's disabled at the moment
<tepsipakki> maybe that has something to do with it
<bryce_> hmm, maybe
<bryce_> although the brightness isn't an issue; it's just like all the gray got taken out
<tepsipakki> ah
<bryce_> anyway, fortunately for xterm you don't need gray ;-)
<bryce_> launchpad looks really weird without it though
<tormod> bryce, I used ppa so now there's amd64 debs as well :)
<bryce_> nice
<bryce_> hey, does -nv have xrandr 1.2 support?  I forget
<jcristau> bryce_: for g80, yes
<ubotu> New bug: #144574 in xserver-xorg-video-intel (main) "xserver crash with screens and graphics admin tool" [Undecided,New]  https://launchpad.net/bugs/144574
<Matir> man building a driver from git is a pita
<ubotu> New bug: #144590 in xorg (main) "blank screen after start ubuntu live daily build 20070924" [Undecided,New]  https://launchpad.net/bugs/144590
<tormod> matir, I was just trying to make a script that does all that. Unfortunately it's not finished.
<jcristau> tormod: as in git-clone ...; cd xf86-video-foo; autoreconf; ./configure --prefix=/usr; make; sudo make install?
<tormod> Matir: anyway the ati 6.7.194 has everything from git.
<tormod> jcristau: no, with debian patches on top like in wiki.debian.org/XTips
<tormod> jcristau: at least make a .deb out of it.
<jcristau> ah. yeah, that's a bit more tricky.
<tormod> I guess I have to pull debian-experimental and not debian-unstable
<jcristau> for testing, just building the driver and installing the _drv.so in /usr/lib/xorg/modules is usually good enough though
<tormod> jcristau: having versioned debs is a must for letting other people do testing
<jcristau> tormod: on your side, sure :)
<Matir> tormod: so it's still nicely broken :)
<tormod> Matir: you mean the ati driver?
<Matir> yeah
<Matir> I'm just wondering how the driver detects modes... and why it sees a mode that's unusable
<tormod> if anyone is interested, I attached the almost-working-but-not-yet-there script to https://wiki.ubuntu.com/XorgOnTheEdge
<bryce_> tormod: cool
* tormod goes to bed
<tormod> good night
<Matir> night\
#ubuntu-x 2007-09-25
<bryce_> brb; more xorg multihead testing to do
<ubotu> New bug: #144603 in xserver-xorg-video-ati (main) "resolution stuck at 640x480 with radeon driver" [Undecided,New]  https://launchpad.net/bugs/144603
<bryce_> ahaha, triple screen works
<bryce_> buggy but works
<bryce_> http://people.ubuntu.com/~bryce/triple-head/100_1153.JPG
<bryce_> got triple head on ati sort of working
<bryce_> got a lot of corruption bugs, and lock ups now and then, and other issues
<ubotu> New bug: #144666 in xserver-xorg-video-ati (main) "Failure to start X on PowerPC Mac Mini G4, ATI Radeon 9200." [Undecided,New]  https://launchpad.net/bugs/144666
<ubotu> New bug: #19711 in xorg-server (main) "[dri]  constant bus activity due to DMAing everything" [Wishlist,Confirmed]  https://launchpad.net/bugs/19711
<rawler> is bug #19711 known upstream? even if it's no bug for Ubuntu ATM (working by design), it probably is a major blocker for laptop-users
<ubotu> Launchpad bug 19711 in xorg-server "[dri]  constant bus activity due to DMAing everything" [Wishlist,Confirmed]  https://launchpad.net/bugs/19711
<ubotu> New bug: #144694 in xserver-xorg-video-intel (main) "xorg with intel driver SIGSEGV, subsequent bulletproof X fails" [Undecided,New]  https://launchpad.net/bugs/144694
<ubotu> New bug: #144640 in ubuntu "middle mouse button will not scroll (dup-of: 107876)" [Undecided,New]  https://launchpad.net/bugs/144640
<ubotu> New bug: #144726 in xresprobe (main) "weird display during gutsy installation just after xresprobe" [Undecided,New]  https://launchpad.net/bugs/144726
<ubotu> New bug: #144760 in xorg (main) "Login fails, X crashes[Gutsy daily-live 20070925, AMD64] " [Undecided,New]  https://launchpad.net/bugs/144760
<ubotu> New bug: #144594 in xresprobe (main) "Alternative install gets nvidia resolution wrong" [Undecided,New]  https://launchpad.net/bugs/144594
<ubotu> New bug: #144777 in xorg (main) "xinerama xserver crash" [Undecided,New]  https://launchpad.net/bugs/144777
<ubotu> New bug: #144802 in vte (main) "random image pixmaps in background (dup-of: 120858)" [Undecided,Invalid]  https://launchpad.net/bugs/144802
<bdmurray> The Radeon Xpress 200M should work with a Live CD right?
<tepsipakki> I think compiz should be disabled on it?
<tepsipakki> hmm, no
<tepsipakki> sorry, it is.. rs480
<tepsipakki> but only a subset of them
<tepsipakki> mvo: the list of pciid's on the compiz-wrapper seems to be incomplete. Grepping Xpress from the pci.lst shows a couple more
<tepsipakki> mvo: ..blacklisted Xpress 200 pci-id's that is :)
<mvo> tepsipakki: we started wit the rv480 iirc, I'm not sure about the others and if those are problematic
<mvo> too little test hardware and feedback :/
<tepsipakki> mvo: true..
<ubotu> New bug: #144865 in xserver-xorg-video-ati (main) "freeze when setting GARTSize to "64"" [Undecided,New]  https://launchpad.net/bugs/144865
<bryce_> rawler: it looks like it was recently reopened by Jan Gyselinck.  It would definitely be good to look in the upstream bug trackers (debian and xorg) to see if it's known there
<bryce_> rawler: if not, then it would be good to get lspci, logs, conf files, etc. from Jan, and then take it upstream
<rawler> bryce_: seems to be some buzz going on about it both in the kernel and in Xorg..
<bryce_> got a link?
<bryce_> tepsipakki: any ideas on 127008?
<rawler> bryce_: added them to the bug.. (bug#19711)
<bryce_> rawler: excellent
<rawler> :)
<rawler> I'll let someone else figure THAT out.. :)
<rawler> I'm pondering bug #139726 though.. 
<ubotu> Launchpad bug 139726 in xorg "[Gutsy} GDM is missing menu items" [Undecided,New]  https://launchpad.net/bugs/139726
<bryce_> yeah I've wondered on that one too
<rawler> the problem as far as I understand, is X runs under a larger virtual resolution than physical resolution..
<rawler> is it a good idea to simply ask the user to regenerate their xorg.conf using dexconf, and see if that solves the problem?
<rawler> what is usually used by ubuntu to generate the xorg.conf?
<bryce_> there is a postinst script in the xorg package which handles most of the configuration
<rawler> ok, so it's no a bad guess that John have altered the default xorg (either himself, or some script) which caused this?
<bryce_> it uses dexconf but I notice that when I manually run dexconf, I get a slightly different result than what I get from the fresh install
<bryce_> e.g., sometimes the bus id's are incorrect
<rawler> oh, I see..
<bryce_> so generally I don't ask people to run dexconf; instead we typically have them rerun apt reconfigure
<rawler> oh, and that produces different result than dexconf?
<bryce_> it seems to, but just slightly
<rawler> interesting.. you'll have to explain why, some day.. :)
<bryce_> heh, some day I plan to rip all this out ;-)
<rawler> but now, will you ask John to regenerate the conf, or shall I?
<bryce_> anyway, I'm not sure regenerating the xorg.conf will have any effect for him
<rawler> I can imagine.. ;)
<rawler> how so?
<bryce_> if I understand gdm correctly (and I probably don't), it does not use xorg.conf but manages its own x session
<bryce_> I *think* it uses the framebuffer, but I'm not sure
<rawler> no GDM uses xorg.conf.. :)
<bryce_> in any case, it's quite common to see completely different results when in gdm from when in x
<tepsipakki> bryce_: could those xresprobe problems relate to the new intel driver? was it enabled for other chips other than those known to be broken?
<bryce_> tepsipakki: it's possible...
<bryce_> tepsipakki: we basically switched to -intel for everything
<rawler> what COULD be the case, though (since John says nothing about problems while RUNNING the system) is that Xorg.conf has bad resolutions.. when gnome launches, though, it reads it's own config (some gnome-tool to change monitor resolution and orientation), and invokes XRandr, setting a useful resolution..
<rawler> I experience a similar problem in a rotated-monitor-setup at work
<tepsipakki> bryce_: right
<rawler> btw, if you want to have fun for a couple of minutes, take a cheap widescreen lcd-tv (I hear plasma is even funnier for this), and flip it 90 degrees, and let it hang there for a year or so.. ;)
<tepsipakki> bryce_: also, are all of those laptops? I have a desktop with i965 which doesn't suffer from this (and it has always used -intel)
<bryce_> rawler: heh
<bryce_> tepsipakki: it sounds like it...  I just got a 965gm board myself, and plan to check it once the system's put together
<bryce_> tepsipakki: there's different kinds of 965 so possibly only the laptop variants of the chip have it or something?
<tepsipakki> now sopranos -> (final season just started here, no spoilers please :)
<bryce_> someone gets killed
<bryce_> oops sorry
<bryce_> heya tormod!
<tormod> hi bryce :)
<rawler> bryce_: running dpkg-reconfigure xserver-xorg gives me the (lengthy) dialog of all the settings etc.. am I missing something, I tought dexconf gave defaults without asking?
<bryce_> that's correct
<rawler> so, why am I getting the dialog? is that the expected behaviour? (confused)
<bryce_> rawler: yes that's expected behavior.  (which is one of the reasons I usually just have users hand-edit the xorg.conf)
<tormod> rawler: -phigh help a bit
<rawler> hehe.. me to, I usually look over xorg by hand (which is why I know nothing about dexconf and friends), but I'm a bit unsure of what John should be looking for in his xorg?
<rawler> tormod: ?
<tormod> dpkg-reconfigure -phigh xserver-xorg  only asks a few questions
<rawler> tormod: *ahh* I see.. :)
<tormod> but the obscure thing is that it picks old values from the dexconf database - dexconf doesn't, IIRC
<rawler> lovely.. sounds like all this needs a cleanup..
<bryce_> dexconf also pulls from the debconf database
<bryce_> rawler: indeed
<tormod> so that "dpkg-reconfigure -phigh xserver-xorg" does not reconfigure from scratch...
<rawler> what is done at installation, then?
<tormod> bryce, you're right (of course)
<tormod> rawler: dpkg-reconfigure -phigh xserver-xorg, but with an empty debconf I think.
<rawler> but high still demands resolutions?
<tormod> rawler: hmm I think I have seen that, yes.
<rawler> oh, well.. I've given John a reply now, atleast.. let's see how it goes.. :)
<tormod> on the Desktop cd, the X configuration is done in casper, at the "break=bottom" phase xorg.conf is done.
<rawler> now I'm off for some REAL slacking, before going to bed.. (gotta get up at 03:45 tonight to perform a server-upgrade while our customers are asleep)
<bryce_> no, at installation time, the xserver postinst script populates the debconf database
<bryce_> if you're in the mood for a scare, some day apt-get source xorg and look at the xorg-server.postinst.in script
<bryce_> it's a 2108-line bash script full of poorly maintained heuristics that "guess" at all sorts of things
<rawler> bryce_: thank you, but I would like to keep my food in my stomach.. ;)
<tormod> search for "resolution hell" (sic) :)
<rawler> actually, I've seen worse.. ;)
<rawler> well, actually, i saw worse RIGHT NOW: http://it.slashdot.org/article.pl?sid=07/09/24/2339203&from=rss
<seb128> bryce_: do you need any data about that wrong intel resolution detection?
<seb128> bryce_: I can change to the correct one with the gnome display tools (the simple one using xrandr), the resolutions are correctly listed
<seb128> it's just using 1024x768 where is should use 1280
<bryce_> seb128: I suspect it's just bug 49827 popping its head up again, but if you have earlier tribes available and can determine with which one it started failing, I could check into it from that angle
<ubotu> Launchpad bug 49827 in xorg "Available resolutions incompletely set to 1024x768, 800x600, 640x480" [High,Confirmed]  https://launchpad.net/bugs/49827
<seb128> not I don't
<bryce_> seb128: often the source of the problem is xresprobe failures, you could run that and see if it gives proper output
<seb128> I can download them but my dsl is no really fast so it'll take me some days
<bryce_> ok, well no worries - as long as it can be fixed up properly in S&G, then for Gutsy I think that's an semi-okay approach for users
<seb128> you mean that's not going to be fixed before gutsy?
<bryce_> right
<seb128> that's quite an ugly regression
<bryce_> hmm, I'm not sure; we used i810 in feisty
<seb128> from an user point of view that's a regression
<bryce_> in fact I just booted a new 965gm board on a feisty cd and it came up with i810 in 640x480
<seb128> this laptop used to work correctly with previous versions of Ubuntu
<seb128> any reason it could not be fixed before gutsy, there is still some weeks
<seb128> ?
<bryce_> well, mostly just that I'm trying to focus on bugs that are preventing users from being able to complete an install, as the highest priorities.  We've several of these issues with intel chips and -ati
<seb128> k
<bryce_> however if it can be pinpointed when this issue started occuring, I could start looking from there
<seb128> xresprobe indeed list 1024x768 only
<seb128> what package is to downgrade?
<bryce_> yeah I think a fix for this particular issue is going to require a good bit of C/asm hackery on xresprobe or lower tools
<seb128> it's easier for me to downgrade something that to spend 1 week downloading iso for that
<bryce_> I would suggest first testing i810 to see if it detects right
<seb128> no it doesn't
<seb128> that's weird
<bryce_> there haven't been any changes to i810 for gutsy, so that would rule out driver issues
<seb128> I've a gutsy installation on this laptop which is a feisty upgrade and has the right resolution
<bryce_> which means either xserver or (maybe) xresprobe
<seb128> though I didn't update it for some weeks
<bryce_> you could compare the xorg.conf's of the two machines
<seb128> that's the same machine ;)
<bryce_> my guess is that the xorg xorg-server.postinst.in script in feisty generated a correct xorg.conf, but the one in gutsy did not
<seb128> but yeah, will compare the installations
<bryce_> if that's the case, then it would be interesting to see if xresprobe gives the same output on both (partitions? vmimages?)
<seb128> partitions
<seb128> the upgraded version list a bunch of 1280x800 modes in the xorg config
<seb128> it lists those for Depth 1 4 8 15 16 24
<seb128> xresprobe lists 1280x800 on the installation which is working correctly
<seb128> let me update the installation
<bryce_> yeah that's what I suspected
<bryce_> interesting; I wonder what caused xresprobe to fail here?  perhaps this is related to the other general xresprobe failures we're seeing elsewhere?
<tepsipakki> bryce_: you were right, some punk had it coming :)
<bryce_> tepsipakki: hehe
<seb128> bryce_: does xresprobe uses the xorg.conf?
<bryce_> seb128: no
<bryce_> seb128: it attempts to probe the hardware directly.  I think it uses the monitor edid to figure out resolutions
<seb128> what could make it not work on the new install like it does on the upgrade?
<tepsipakki> bryce_: re: xorg-server.postinst; it's going to be reduced dramatically in debian soonish, since their goal is to get rid of discover and xresprobe (and looking at the past discussions, should be ours too :)
<seb128> I'm upgrading xserver-xorg-core at the moment
<bryce_> seb128: there's a couple of things I can think of
<bryce_> first, xresprobe is a wrapper around a few other lesser tools; possibly one of those went missing or became broken for some reason
<tepsipakki> and that postinst is available on every system in /var/lib/dpkg/info/xorg-server.postinst
<bryce_> second, this also uses some fairly low level platform-dependent code, so I could imagine that changes to like libc or the kernel might have affected that
<bryce_> tepsipakki: awesome, that's exactly what I'd planned
<tepsipakki> oops, make that /var/lib/dpkg/info/xserver-xorg.postinst
<bryce_> tepsipakki: is there anything we could do to assist with that, or should we just cheer them on and wait?  :-)
<tepsipakki> bryce_: I think jcristau can answer that :)
<tepsipakki> also, I hope to get in touch with gravity while in Boston :)
<bryce_> cool
<seb128> bryce_: upgrading xserver-xorg-core makes no difference
<bryce_> mmm, interesting
<seb128> ah
<seb128> intel is buggy now
<bryce_> is xresprobe still working then?
<seb128> it lists 1024x768 now for intel
<seb128> still 1280x800 for i180 though
<seb128> I just upgrade xserver-xorg and xserver-xorg-core
<seb128> upgraded
<seb128> let me downgrade
<bryce_> the one change to xresprobe is that mjg added support for -intel about 6 weeks ago
<bryce_> but that was just adding "intel" into a switch statement, nothing elaborate
<bryce_> seb128: is your system a laptop, crt, or lcd?
<seb128> laptop
<bryce_> do you have laptop-detect installed?  does it return true when run?
<bryce_> seb128: the tool xresprobe uses to get the resolutions is ddcprobe
<seb128> bryce_: it's not installed on the beta installation, it is on the working upgrade
<bryce_> aha
* bryce_ ponders
<bryce_> ddcprobe is not on the beta installation?
<bryce_> hmm, it should have been included in the xresprobe package
<seb128> no
<seb128> not installed
<seb128> ok
<bryce_> ok so that would be the problem
<seb128> the bug happens when upgrading xserver-xorg-core
<bryce_> weird, how can that even happens
<seb128> no
<seb128> with an uptodate xserver-xorg-core intel is wrongly detected on the upgrade
<seb128> so that's not it
<seb128> I'm looking for the version creating the issue now
<seb128> 6ubuntu3 works correctly
* bryce_ is confused
<seb128> xresprobe list correctly 1280x800 using xserver-xorg-core 3.0.0-6ubuntu3
<seb128> it doesn't when I update to the current package
<bryce_> ahh
<bryce_> can you try 12ubuntu2?  that was the version immediately prior to the backports
<seb128> downloading it
<bryce_> if that works, then it is likely that either 12ubuntu3 or 12ubuntu4 caused the breakage
<seb128> yes, this one works
<seb128> let's try ubuntu3
<bryce_> aha
<seb128> works
<seb128> let's try the next one ;)
<seb128> bryce_: ok, upgrading from 2:1.3.0.0.dfsg-12ubuntu3 to 2:1.3.0.0.dfsg-12ubuntu4 creates the bug
<bryce_> hmm, could be patch 136
<bryce_>     - 136_fedora_xserver-1.2.0-honor-displaysize.patch:  Fixes issue if monitor
<bryce_>       width and height have been specified, xserver would override them
<bryce_>       with the hsize/vsize detected from DDC.
<bryce_> 
<seb128> dccprobe doesn't list 1280x800
<bryce_> maybe 143
<bryce_>     - 143_fedora_xserver-1.3.0-randr12-config-hack.patch:  Adds check to use
<bryce_>       the screen's xrandr modes if a preferred mode was not specified.
<seb128> k
<seb128> it's getting late here
<bryce_> none of the other patches jump out at me
<seb128> but I can try tomorrow to rebuild without 136 and see if there bug is still there
<seb128> and same for the 143 one
<bryce_> ok cool, let me know how that goes
<seb128> ok
<bryce_> wow I think we got this tracked down pretty close
<bryce_> damn fedora ;-)
<seb128> ;)
<seb128> maybe it'll be fixed for gutsy :p
<bryce_> if it's just a matter of dropping a patch, we can count on it
<ubotu> New bug: #125904 in displayconfig-gtk (main) "random crash (dup-of: 126561)" [Undecided,New]  https://launchpad.net/bugs/125904
<bryce_> tormod or tepsipakki, -nvidia does not support xrandr, right?
<bryce_> I notice in bug 144777 there's an error in -nvidia complaining about xinerama not being there; however I don't know why that'd break unless they'd switched to xrandr
<ubotu> Launchpad bug 144777 in xorg "xinerama xserver crash" [Undecided,New]  https://launchpad.net/bugs/144777
<tepsipakki> bryce_: it has it's own twinview-thingy
<tepsipakki> besides, that's 1.0-9639
<bryce_> tepsipakki: hmm, I could swear I used to run xinerama on -nvidia
<tepsipakki> surely it supports that as well
<tepsipakki> I guess twinview is comparable to the mergedfb-cruft that ati had?
<bryce_> sounds like it
<tepsipakki> btw, ati now defaults to 1280x1024 on my crt
<tepsipakki> noticed the discussion on #u-d
<bryce_> is that what it should be?
<tepsipakki> well, it can do 1600x1200 just fine, but I don't think that's critical
<tepsipakki> since the resolution can be changed by the user
<tepsipakki> =me
<tepsipakki> so maybe it's randr-1.2 enabled drivers that have these, ie. intel and ati?
<tepsipakki> +issues
<bryce_> maybe
<seb128> bryce_: that's not the patch 136
<seb128> bryce_: it's due to 143_fedora_xserver-1.3.0-randr12-config-hack.patch
<seb128> bryce_: what is this one supposed to fix?
<bryce_> aha
<bryce_> it changes how x selects a default mode
<seb128> right, I got that from the description and behaviour
<seb128> but when is a preferred mode specified?
<bryce_> you'd put in something like,  Option "Preferred Mode" "1680x1050_60.00"
<bryce_> I don't expect users need to do that often, so am comfortable dropping the patch since it causes this breakage
<bryce_> I gather the preferred mode allows you to specify what happens when issuing xrandr --auto
<Matir> does anyone know of a way to modify xorg.conf to force -VSync -HSync
<bryce_> Matir, you mean other than adding HorizSync       28-80  and   VertRefresh     48-75?
<seb128> bryce_: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/144956
<ubotu> Launchpad bug 144956 in xorg-server "incorrect screen resolution on gutsy beta using intel" [Undecided,New]  
<Matir> bryce, that will make it use Negative polarity?
<bryce_> seb128: ok thanks
<seb128> you're welcome
<bryce_> Matir, replace the numbers with whatever is appropriate for your monitor
<tepsipakki> Matir: you want to set a custom Modeline
<tepsipakki> ?
<Matir> I suppose.... right now I'm having to use xrandr every time the machine starts to get X working... and I added the Modeline, but it will still using a built-in autodetected line
<tepsipakki> http://www.intellinuxgraphics.org/dualhead.html
<tepsipakki> doesn't Option PreferredMode help?
<tepsipakki> Matir: umm, which driver?
<Matir> ati
<tepsipakki> so you are hit with the same bug that was just discussed :)
<ubotu> New bug: #144956 in xorg-server (main) "incorrect screen resolution on gutsy beta using intel" [Undecided,New]  https://launchpad.net/bugs/144956
<Matir> possibly... not sure
<Matir> There's an outstanding bug for my issue, that I've been trying to help debug as best as I can.... https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/132716
<ubotu> Launchpad bug 132716 in xserver-xorg-video-ati "ATI Driver Gets Black Screen on Radeon 7500 Mobile (Regression)" [High,Confirmed]  
<tepsipakki> ah
<tormod> just to make it clear: matir means the -VSync option to the modeline, not any ranges.
<Matir> yes, i guess i may have been vague, sorry
<bryce_> ah, yes I misinterpreted that, sorry
<tormod> good night
#ubuntu-x 2007-09-26
<ubotu> New bug: #144011 in xserver-xorg-video-ati (main) "GUTSY. No video output firing up X." [Undecided,Incomplete]  https://launchpad.net/bugs/144011
<ubotu> New bug: #145097 in xorg (main) "Live session directly go to black screen" [Undecided,New]  https://launchpad.net/bugs/145097
<ubotu> New bug: #145128 in xorg (main) "LiveCD No intel video" [Undecided,New]  https://launchpad.net/bugs/145128
<ubotu> New bug: #145186 in xorg (main) "mouse pointer disappears when using external display" [Undecided,New]  https://launchpad.net/bugs/145186
<ubotu> New bug: #145198 in xserver-xorg-video-ati (main) "[gutsy] [9700]  analog output on DVI-I broken" [Undecided,New]  https://launchpad.net/bugs/145198
<Q-FUNK> seb128: exactly how did you reach the conclusion that the broken gtkprint was caused by libcups?
<seb128> Q-FUNK: what is the bug number? the backtrace calls are in libcups if I remember correctly
<ubotu> New bug: #145211 in xorg (main) "OS won't shutdown after certain video usage; memory corruption?" [Undecided,New]  https://launchpad.net/bugs/145211
<Q-FUNK> bug #135832
<ubotu> Launchpad bug 135832 in cupsys "evince: libgtkprint support is broken" [Low,New]  https://launchpad.net/bugs/135832
<seb128> #1  0xb71b5478 in connect () from /lib/tls/i686/cmov/libc.so.6
<seb128> #2  0xb476513c in httpAddrConnect () from /usr/lib/libcups.so.2
<seb128> #3  0xb47639e6 in httpReconnect () from /usr/lib/libcups.so.2
<seb128> ^
<seb128> that looks like it's hanging while connecting to cups
<seb128> and it's a hang in libcups
<seb128> maybe you have a firewall blocking it or something
<Q-FUNK> definitely not
<seb128> ok, so maybe the cupsys config is broken
<seb128> or libcups has a bug
<seb128> or you have a network issue
<seb128> I'm not sure, and I don't know cups enough to figure
<Q-FUNK> besides, gtkprint is the only thing that fails. gnomeprint, OOo, firefox, all work.
<Q-FUNK> so that tells me that cupslib works fine, given how apps that directly access it and gnomeprint both work.
<seb128> does it happen in other applications use gtkprint? yelp, epiphany, gtk-demo
<Q-FUNK> I can try yelp.  just a sec.
<Q-FUNK> yelp also buggers.
<Q-FUNK> same symptoms
<seb128> k, so it looks like gtkprint, libcups, cupsys issue
<seb128> having a backtrace with dbgsym package for those would be useful
<Q-FUNK> gtkprint, definitely.
<seb128> how do you know?
<seb128> the backtrace indicates it's hanging in a connect made by libgnomecups
<seb128> libcups rather
<Q-FUNK> and yet gnomeprint doesn't hang during connect.  it just works.
<seb128> do you know it's internel?
<seb128> does it uses the same libcups functions than gtkprint?
<seb128> that's not because some part of libcups is not buggy that there is no bug
<Q-FUNK> well, that's rich.
<seb128> re
<seb128> Q-FUNK: you know, trying to change bug setting over a maintainer is not the way to get it resolved
<Q-FUNK> seb128:  neither is changing it without justification.
<seb128> Q-FUNK: I told you my justification
<seb128> the stacktrace indicates it's blocked on a libcups listen
<Q-FUNK> "looks like a libcupsys bug. reassigning." that's not a justification.
<seb128> Q-FUNK: I gave you details on this chan
<seb128> looks at http://launchpadlibrarian.net/9211483/gdb-evince.txt
<seb128> connect, httpAddrConnect, httpReconnect, httpConnectEncrypt
<seb128> it's clearly hanging on a call from libcups
<seb128> why do you think it's a GTK bug?
<seb128> might be a httpConnectEncrypt() libcups bug, which is something libgnomeprint maybe doesn't use
<Q-FUNK> you'd need to write that in the bug as a justification, for this to be usefull to pitti or anyone else. then they can decide for themselves if they agree with your assessment.  right now, the one-liner your wrote is useless as an explanation.
<seb128> I explain it to you on this chan
<Q-FUNK> that could be.
<seb128> you could have asked that instead of just reassigning
<Q-FUNK> I already asked.
<Q-FUNK> you had already reassigned
<seb128> from now I'll just ignore this bug since you don't want to work in the right way
<Q-FUNK> you thus didn't get copy of the question.
<Q-FUNK> seb128:  reassigning the bug with such a laconic justification helps nobody, so please work in the right way and provide details for that sort of action.
<Q-FUNK> on the bug, where it belongs.
<seb128> it was assigned to evince which was clearly wrong
<seb128> I reassigned to libcups what is the most likely place according to the backtrace
<seb128> what about letting the maintainer make calls?
<seb128> bug tracker should not allow users to change settings over maintainers
<seb128> anyway could you get a debug backtrace?
<Q-FUNK> nothing more than what I already attached to the bug.
<seb128> libcupsys2-dbgsym libc6-dbg libgtk2.0-0-dbgsym are installed?
<seb128> http://launchpadlibrarian.net/9211483/gdb-evince.txt has no debug functions
<ubotu> New bug: #145244 in xft (main) "[gutsy]  libXft library - undefined symbol FT_Library_SetLcdFilter" [Undecided,New]  https://launchpad.net/bugs/145244
<bryce_> tepsipakki: on bug 136783, what do you think of forcing TV off in dexconf?  Is there a better way we can address this?
<ubotu> Launchpad bug 136783 in xserver-xorg-video-intel "not using whole widescreen" [High,Triaged]  https://launchpad.net/bugs/136783
<Q-FUNK> /querry bryce_ ah :)
<Q-FUNK> ...
<bryce_> hi Q-FUNK
<Q-FUNK> bryce_: did the strace that Scott provide made any sense to oyu?
<bryce_> bug#?
<Q-FUNK> bug #140051
<ubotu> Launchpad bug 140051 in xserver-xorg-video-amd "amd driver fails to autoconfigure" [Medium,Confirmed]  https://launchpad.net/bugs/140051
<ubotu> New bug: #145276 in xorg (main) "xorg.conf multiple monitor failure" [Undecided,New]  https://launchpad.net/bugs/145276
<ubotu> New bug: #145283 in kde-guidance (main) "[gutsy]  When Driver in xorg.conf is set to  "openchrome"  X fails to start. Changing it manually to "via" works." [Undecided,New]  https://launchpad.net/bugs/145283
<bryce_> Q-FUNK: interesting
<bryce_> Q-FUNK: it looks like its segfaulting while trying to load vgafb
<bryce_> er, s/vgafb/vgahw/
<bryce_> Q-FUNK, ok left my interpretation of the strace.  I have no idea what's going on, but hopefully that should give you some new stuff to test
<tepsipakki> bryce_: well, that's one option.. but maybe first ask upstream?
<bryce_> tepsipakki: who would be best to ask?
<tormod> hi, I am building new ati drivers in PPA now, with the post-194 git commit.
<bryce_> tepsipakki: also see discussion on #ubuntu-desktop about -ati's xrandr and multi-screening
<bryce_> I sense that glatzor would favor sticking with -ati 6.6.3 since displayconfig-gtk does not support xrandr yet
<tepsipakki> uh
<tepsipakki> ok
<tepsipakki> that's better than skip dualhead with intel&ati?
<tepsipakki> in displayconfig-gtk
<jcristau_> &nv
<tepsipakki> right
<tepsipakki> well, dunno
<tormod> stick with 6.6.3? omg we have to reopen many a bug then. like my favorite 22985...
<tepsipakki> i'll check the discussion soon
<tormod> hmm #ubuntu-desktop is not logged
<tepsipakki> hmm, the reason why xresprobe fails for so many is probably that laptop-detect fails
<bryce_> that's what I'm wondering
<tepsipakki> it's easy to check..
<tepsipakki> ask the reporters to run that
<tormod> laptop-detect fails? again?
<tormod> last time it failed during casper, but would work in installed, which was quite confusing. (#40503)
<tormod> and I remember initial resolution detection would also fail. bug # anyone?
<bryce_> bug 127008
<ubotu> Launchpad bug 127008 in xresprobe "Alternate install of Tribe-4 corrupts video display when installing packages (affected hardware includes Santa Rosa)" [High,In progress]  https://launchpad.net/bugs/127008
<bryce_> tormod: btw, when you start a discussion with a user, and esp. after asking a question, could you set the state of the bug from New to Incomplete (or Confirmed)?
<tormod> bryce_: ok, I do it sometimes :)
<bryce_> tormod: this'll help the bug triagers a lot
<tormod> sure. It's just that I then feel compelled to assign it to myself, which I sometimes don't want to.
<bryce_> like bug 145097, can probably be set to incomplete
<ubotu> Launchpad bug 145097 in xorg "Live session directly go to black screen" [Undecided,New]  https://launchpad.net/bugs/145097
<tormod> in that bug I am not at all sure I am on the right track, would be nice if someone else takes a look.
<bryce_> tormod, brian murray says the incomplete state should always be set when someone has at least taken a preliminary look, even if it's not clear what's going on
<tormod> ok, will do that every time then.
<bryce_> cool thanks
<bryce_> yeah I looked at this one too, and it seemed odd
<bryce_> I wonder if it really is the screensaver coming on
<bryce_> it sounds very familiar; I think I ran into something similar once
<bryce_> however there the issue was that the clock got reset, so the screensaver *thought* a lot of time had passed and came on
<bryce_> doesn't sound like this is happening here
<tormod> yes I saw that earlier when coming back from hibernation, but that's fixed (I think).
<tormod> if he could change the screensaver and then restart X we would see. But at this point I am not sure he and I understand each other.
<tormod> screensaver on/off is that logged somewhere? I guess not.
<bryce_> I don't think it's logged, but it could be tested for using 'xset q'
<bryce_> so something like xset q | grep -A 2 "Standby:" could be useful
<bryce_> if those values are not 0, then it means a screensaver may be active
<tormod> you mean the built-in xorg screensaver, ok
<tormod> I built an ati driver with verbose dpms messages, I could get him to try that. However, the blanking doesn't call dpms functions I guess, only when it's time to shut off the screen.
<tormod> btw the new ati packages (with more "mode" fixes) are done building in my ppa
<bryce_> awesome
<bryce_> Brice Goglin mentioned the multi-board multi-head bug on the xorg list (ATI + MGA)
<bdmurray> Looking at an Xorg.0.log I saw "(--) Chipset ATI Radeon XPRESS 200M 5A62 (PCIE) found" is 5A62 the product part of the pci id?
<bryce_> I think almost certainly
<bryce_> I notice ATI Radeon XPRESS 200M 5955 (PCIE) has pciid 1002:5955, so expect 5A62 would be similarly so
<bdmurray> I'm pretty sure too and was trying to figure out if lspci wasn't always necessary.
<bdmurray> I understand that ideally we would like it but instead of bothering a reporter for the umpteenth time.
<bryce_> it's extremely rare that the device name would include the pciid like in this case
<bdmurray> That is the device name?
<bdmurray> Okay, I see now.
<tormod> there are probably so many versions of 200M they had to put in a unique ID
<bdmurray> It seems ATI specific my laptops just says "Chipset 945GM found"
<bryce_> bbiab
<tormod> bryce_: I suggest making a Gutsy/Xrandr page and link to it from the release notes. Otherwise it will be too much with links and workarounds.
<tormod> good night
#ubuntu-x 2007-09-27
<ubotu> New bug: #145288 in xorg (main) "[Gutsy Tribe 5]  blank screen on live cd bootup, x doesn't load" [Undecided,Incomplete]  https://launchpad.net/bugs/145288
<bdmurray> Has anyone heard of a bug with fglrx and too much memory? approximately 3GB?
<bryce_> too *much*?  nope
<ubotu> New bug: #145403 in xorg (main) "after upgrade from feisty, image distorsioned on screen with resolutions lower than 1024x768" [Undecided,New]  https://launchpad.net/bugs/145403
<bdmurray> bryce_: it is bug 141439
<ubotu> Launchpad bug 141439 in linux-meta "Laptop nc8430, 4GB Ram and fglrx" [Undecided,Confirmed]  https://launchpad.net/bugs/141439
<bryce_> bdmurray: sounds kernel-ish
<bryce_> bdmurray: fglrx (and -nvidia) are such black boxes, though, god only knows what they're doing to cause this issue
<bdmurray> I'd need to go shopping to test it
<bryce_> I just ordered 6G more mem for my new intel box :-)
<bdmurray> 6G more?
<bryce_> total 8G
<ubotu> New bug: #145439 in xserver-xorg-video-via (main) "xserver-xorg-video-via does not show tooltips properly" [Undecided,New]  https://launchpad.net/bugs/145439
<ubotu> New bug: #145501 in xserver-xorg-video-intel (main) "laptop screen remains on with external monitor and lid closed" [Undecided,New]  https://launchpad.net/bugs/145501
<ubotu> New bug: #145620 in xorg (main) "[gutsy]  X crashes when 2nd monitor is attached to Notebook" [Undecided,New]  https://launchpad.net/bugs/145620
<ubotu> New bug: #126635 in xserver-xorg-video-nv "Cycling through display modes fails with nv driver and NVIDIA 8400M GS" [Undecided,New]  https://launchpad.net/bugs/126635
<ubotu> New bug: #126995 in xserver-xorg-video-nv "Logging out displays garbage on screen, with nv driver and NVIDIA 8400M GS" [High,Fix released]  https://launchpad.net/bugs/126995
<ubotu> New bug: #145646 in xorg (main) "gutsy beta: xserver failed on laptop with ati radeon 9700" [Undecided,New]  https://launchpad.net/bugs/145646
<ubotu> New bug: #145715 in xserver-xorg-driver-ati (main) "Ati Radeon 9200 extremely slow in Gutsy" [Medium,Incomplete]  https://launchpad.net/bugs/145715
<ubotu> New bug: #145670 in xorg (main) "Gutsy Beta does not recognize ATI Radeon Xpress 200G Series" [Undecided,Incomplete]  https://launchpad.net/bugs/145670
<ubotu> New bug: #145621 in xserver-xorg-video-nv (main) "nVidia 7400 GO not detected by failsafe X" [Undecided,New]  https://launchpad.net/bugs/145621
<bryce_> awesome, albert got a fix for 127008
<bryce_> tweaked version of my patch
<ubotu> New bug: #145779 in xserver-xorg-video-vesa (main) "tvout not working with radeon 9200" [Undecided,New]  https://launchpad.net/bugs/145779
<jcristau_> haha. tvout not working with vesa. who would have thought
<tepsipakki> :)
<tepsipakki> bryce_: yep, that should do for gutsy..
<bdmurray> bryce_: Is 133824 fixed?  I didn't notice it with dailies earlier this week.
<bdmurray> Rather do you know if it is fixed.
<bryce_> yup, should be fixed
<bryce_> have them test against -beta to be sure
<bdmurray> I have the same chipset so will give it a whirl
<ubotu> New bug: #57525 in xresprobe (main) "fails on ATI Mobility X700 (Acer TravelMate 8100)" [Undecided,Incomplete]  https://launchpad.net/bugs/57525
#ubuntu-x 2007-09-28
<ubotu> New bug: #48106 in xresprobe (main) "Dapper Install Problem with Dell LCD Displays (dup-of: 127008)" [Medium,New]  https://launchpad.net/bugs/48106
<ubotu> New bug: #15076 in xresprobe (main) "xresprobe drops highest resolution when lcd is detected as analog" [Medium,Confirmed]  https://launchpad.net/bugs/15076
<ubotu> New bug: #23408 in xresprobe (main) "Problems with xorg, autodetection of MGA 200 and SDM-M51 (dup-of: 15076)" [Medium,Confirmed]  https://launchpad.net/bugs/23408
<bryce_> tepsipakki: what was the fix you did for bug 40422?
<ubotu> Launchpad bug 40422 in xresprobe "Dell 2405FPW and resolution 1920x1200" [Medium,Confirmed]  https://launchpad.net/bugs/40422
<ubotu> New bug: #21206 in xorg (main) "Xorg should use 1920x1200 as default for Dell 2405FPW (dup-of: 27667)" [Medium,Invalid]  https://launchpad.net/bugs/21206
<ubotu> New bug: #21873 in xorg (main) "Dell 2405FPW not automatically configured, ugly display (dup-of: 27667)" [Medium,Invalid]  https://launchpad.net/bugs/21873
<ubotu> New bug: #40338 in xresprobe (main) "amd64-live - 1920x1200 screen detected as 1600x1200 (dup-of: 27667)" [Medium,New]  https://launchpad.net/bugs/40338
<bryce_> bdmurray: bug 27667 is one well worth studying and understanding, to be able to triage resolution detection bugs
<ubotu> Launchpad bug 27667 in xresprobe "Problems with xresprobe & Samsung 243T LCD" [Medium,Confirmed]  https://launchpad.net/bugs/27667
<bryce_> essentially, if someone reports that ubuntu is giving them a resolution exactly one step down from the maximum available rez, it's a dupe of 27667
<bryce_> you can get the correct resolution list via either ddcprobe or xrandr
<bryce_> it occurs for LCD's that are detected as analog units
<bryce_> yay, knocked xresprobe bugs from 33 down to 24 after identifying a ton of dupes
<ubotu> New bug: #145897 in xorg (main) "Gutsy beta: RED (!) screen of apathy after resume from suspend" [Undecided,New]  https://launchpad.net/bugs/145897
<bryce_> yay, today's been a good bug squash day.  I've got fixes in the hopper for 127008 (+many dupes), 144956, and 27667 (also +many, many dupes).
<bryce_> will upload tomorrow
<ubotu> New bug: #146138 in xserver-xorg-driver-ati (main) "full gnome session hangs with ATI driver and gutsy BETA" [Undecided,New]  https://launchpad.net/bugs/146138
<tepsipakki> bryce_: it used a list of monitors with buggy edid.. a solution which really doesn't scale :)
#ubuntu-x 2008-09-22
<wgrant> Hmm, I see that there are significant changes to the server's XI property support...
<tjaalton> wgrant: what where?
<wgrant> tjaalton: Configure/Query gone, more return values... Peter posted the patches to the list a few hours ago.
<tjaalton> wgrant: oh right, reading now
<wgrant> I wonder if we want those in Intrepid.
<wgrant> As otherwise nothing will build post-release.
<tjaalton> what do you mean?
<wgrant> If we don't have those patches in Intrepid, people building XI-property-using apps on Intrepid will get annoyed.
<wgrant> Because the API differs.
<tjaalton> oh right
<wgrant> And we'll probably be the only people with the ABI we have.
<wgrant> *API
<tjaalton> well, we also need the rest of the stuff before those can be pushed
<tjaalton> but I'll update the server
<wgrant> The g-s-d and g-c-c patches will also need alteration since XQueryDeviceProperty vanished.
<tjaalton> hum, the patches are for master
<tjaalton> hardly surprising, but maybe I'll wait until he backports it for 1.5
<wgrant> Ah, right.
<tseliot> tjaalton: I have put that fix for the nvidia driver in the postinst instead of the preinst since DKMS removes and adds directories in the postinst. It works well and removes those obsolete directories
<tseliot> I have also updated the driver to the latest beta. I'll upload the source and post the links
<tjaalton> tseliot: ok, cool
<tseliot> tjaalton: the source for the 2 drivers are here: http://albertomilone.com/ubuntu/newlrm/pitti/lista_ia.txt
<tseliot> can you upload them, please?
<tjaalton> tseliot: done
<tseliot> tjaalton: thanks a lot
<tjaalton> np
<mvo> tjaalton, tseliot: any idea about the following error: http://rafb.net/p/ElfRoh20.html ?
<mvo> this happend after mvg upgraded to intrepid
<tseliot> mvo: I haven't written a patch for kernel 2.6.27 since the driver would only build but wouldn't load because of the xorg ABI
<tseliot> mvo: are you trying to use the driver with the old xorg and the new kernel?
<MvG> tseliot: A patch to make do without asm/semaphore.h?
<MvG> Completely upgraded intrepid, kernel and xorg, afaict.
<mvo> tseliot: oh, so this nvidia packages does not work on intrepid at all? then I should remove it from update-managers nvidia detection?
<tseliot> MvG: usually I can get rid of compilation errors. Making it work with the new xorg ABI is a different thing though
<MvG> If there is another nvidia package likely to work instead of that one, you might.
<mvo> tseliot: which of the nvidia drivers are affected by this?
<MvG> -93 iirc, checking...
<tseliot> mvo: I have worked on nvidia-common so that we can blacklist certain drivers and suggest/force the use of open drivers if necessary
<MvG> nvidia-glx-96
<tseliot> mvo: it's not finished yet since it lacks the support for x-kit
<tseliot> mvo: it affects 96 and 71
<tseliot> and fglrx
<MvG> So you'd suggest switching to open nv drivers for the time being?
<tseliot> MvG: yes
<MvG> Have you checked whether other distros might have done work migrating to new X abi?
<MvG> (As I'm running an nvidia driver on Gentoo testing as well, though probably a different version)
<tseliot> MvG: that's something that only NVIDIA can do
<jcristau> MvG: that would only be doable if we had the source
<MvG> It's in the closed part of the code? Too bad!
<tseliot> yep
<mvo> tseliot: thanks for this information. should I just wait then for nvidia-common or modify the update-manager code to do something if those drivers are detected
<jcristau> MvG: there's pretty much no open part
<MvG> jcristau: Well, at least they do have enough iopen source code to be compiuled on the client to cause the compiler errors mentioned in my paste... :-/
<jcristau> MvG: that's the kernel part
<MvG> jcristau: True. Point taken.
<jcristau> which, indeed, has a small sourceful wrapper
<tseliot> mvo: I'll preserve nvidia-common's current behaviour so that it doesn't break Jockey and Update Manager
<MvG> I guess one could technically tweak the symbol table of the closed source driver in order to replace official X interfaces with compatibility wrappers. I don't know the overhead for this, and neither the legality.
<tseliot> mvo: however, when the new nvidia-common is finished you'll have to modify Update Manager a bit so that it can use the new blacklisting functionality
<jcristau> MvG: changes are big enough that a compat wrapper would be a lot of work, if at all feasible
<tseliot> MvG: the symbol itself is not the main problem. AllocatePrivateScreenIndex is the problem
<tseliot> after all we're talking about an ABI which was changed
<MvG> I notice that nvidia offers 96.43.07 for download, dated July 16, 2008. Ubuntu installed 96.43.05-0ubuntu10.
<MvG> I can see no obvious ChangeLog, though.
<tseliot> believe me, if it had solved the problem I would have updated the driver in July.
<MvG> OK.
<tseliot> tjaalton: did you upload my patch? https://bugs.launchpad.net/bugs/271823
<ubottu> Ubuntu bug 271823 in xfree86-driver-synaptics "[intrepid] touchpad less responsive and top/bottom-right corner tapping disabled" [Undecided,Confirmed] 
<tseliot> it works for another user too
<mvo> tseliot: I'm slightly worried that we currently have 3 (closed source) video drivers that will fail to upgrade and give the user a bad expeience and beta freeze is just three days ahead. I imagine a lot of users will upgrade at beta time and I would really like to transition them autoamatically to free drivers if the closed-source drivers can not be fixed. what do you think about it? I would (naturally) do it in update-manager, but if its done in
<mvo>  nvidia-common or via fallbacks somwehre else that is fine with me of course 
<mvo> (well, not fail to upgrade but fail to work after the upgrade :)
<tseliot> mvo: I was thinking that you could use nvidia-common as a library and pass it the driver which you would like to blacklist
<tseliot> mvo: I will try to finish it in time, ok?
<tseliot> in time for the freeze, I mean
<mvo> tseliot: it seems to me that is "selectDriver()" would just not return the two that do not work, then we are done, or am I missing something?
<tseliot> mvo: but if a user is using a driver with the old name scheme that wouldn't be removed and will cause problem during the update
<tseliot> s/problem/problems/
<tseliot> mvo: I have written a method which returns the driver which should be used in the xorg.conf
<mvo> tseliot: how is that called?
<tseliot> so that if a driver is blacklisted, a free alternative will be returned
<mvo> is that not "selectDriver()" ?
<mvo> (because that is what I use in update-manager) 
<tseliot> mvo: currently it's filterDrivers() but I haven't uploaded the new release yet
<tseliot> mvo: selectDriver() is ok and returns the right package to install
<tseliot> I know, filterDrivers sucks as a name
<mvo> ok, thanks. so currently it will return nvidia-glx-96 for example but if nvidia-common gets updated it would return xserver-xorg-video-nv ?
<mvo> will xorg.conf rewriting (if one exists) be hanlded by nvidia-common then too?
<tseliot> mvo: not exactly. You can pass the constructor a dictionary with the proprietary (e.g. nvidia) and the free driver ('nv') for a certain kind of driver together with the version you would like to blacklist (e.g. 96)
<tseliot> then filterDrivers() would return either the proprietary (nvidia) or the free (nv) driver
<tseliot> while selectDriver() will still return the nvidia package with the new name scheme
<mvo> wouldn't it be better to put the blacklist into nvidia-common too? so that we have the information in one place what drivers do not work? otherwise both update-manager and jockey would have to have the blacklist information (two places instead of a single one)
<tseliot> but of course if filterDrivers() returns what you passed as the free driver then you shouldn't install the new driver but simply remove the old one (in self.oldpackages)
<tseliot> mvo: yes, sure I can do it in nvidia-common. Furthermore I'll add another module so as to deal with the xorg.conf with x-kit
<tseliot> but then the debconf message will have to be updated (so that users are informed about what's going to happen)
<mvo> tseliot: ok, thanks. keep me updated, I will modify update-manager then to use the new interfaces
<tseliot> mvo: ok, I'll work on it and get back to you as soon as it's ready
<mvo> tseliot: debconf> I was thinking that we may want to put a custom message in update-manager so that users who do not want to loose desktop effects get a warning before the upgrade about the fact that they will loose the nvidia/fglrx drivers
<jcristau> they can has compiz with radeon though, at least on r500
<tseliot> mvo: sure, it's a good idea. I was referring to debconf because I was thinking about the users who will dist-upgrade from the command line
<mvo> right, its good to have both I think
<tseliot> mvo: in any case the proprietary driver should be removed otherwise the open source counterpart won't be able to use mesa properly
<mvo> jcristau: yeah, that is very cool (I have a r500 myself and I'm pretty impressed with the new ati)
<mvo> tseliot: right
<soren> A bit of help? I'm trying to figure out why I don't have any dead keys anymore?
<soren> I used to be able to press Â´a and get an accented a, but now I just get the accent straight away.
<soren> "setxkbmap -print" doesn't say nodeadkeys anywhere.
<maco> when compiz is in use and gstreamer's video playback is buggy, is that a gstreamer bug, a compiz bug, or a driver bug?
<bryce> morning
<tseliot> maco: what do you mean by buggy? Which card/driver do you use? Can you reproduce the problem using xine?
<maco> tseliot: not my bug, just triaging. bug 270723  i marked it for xserver-xorg-video-intel but i wanted to check
<ubottu> Launchpad bug 270723 in xserver-xorg-video-intel "Movies don't move with Compiz" [Undecided,Incomplete] https://launchpad.net/bugs/270723
<jcristau> probably expected if you're using the overlay.
<jcristau> the textured adaptor should work fine
<tseliot> jcristau: ah, textured video
<jcristau> tseliot: hmm?
<maco> i assume that's somewhere in totem's preferences? i use totem-xine for better dvd support, so idk how the gstreamer one works
<jcristau> maco: what's the first adaptor listed by xvinfo?
<tseliot> jcristau: there was an option to tell X (explicitly) to use Textured Video in the xorg.conf
<maco> jcristau: should i ask that of the bug reporter?
<tseliot> jcristau: aah, we had a patch thanks to which we could enable/disable textured video in ubuntu > Option "TexturedVideo" "true"
<tseliot> but it should be used automatically now
<tseliot> maco: I have added a comment to the bug report with the instructions to configure gstreamer
<tseliot> oh, you have replied too
<maco> tseliot: yours is better. i dont know where the settings are and what the options are in totem-gstreamer
<maco> though this does make me want to ask what to do about that thing where video goes blue with xine+compiz
<tseliot> maco: have a look at what I suggested here: http://ubuntuforums.org/archive/index.php/t-456842.html
<tseliot> or here: http://ubuntuforums.org/showthread.php?t=532976
<maco> tseliot: alright, thanks
<tseliot> maco: thanks for dealing with these bug reports
<maco> tseliot: the file you pointed to in that forum post doesn't exist
<tseliot> maco: the configuration file?
<maco> right
<maco> i would assume there's some syntax beyond typing in the word xshm and saving it
<tseliot> maco: try with ~/.xine/config
<maco> also doesn't exist
<maco> er, should say i'm using hardy
<maco> in case that makes a difference
<tseliot> maco: in Hardy I have both .gnome2/Totem/xine_config and ~/.xine/config
<tseliot> but I guess you'll have to install and use (at least once) totem-xine and xine
<maco> i do use totem-xine
<maco> because gstreamer doesn't do dvd menus
<maco> what's the syntax for those files?
<tseliot> try .config/totem/xine_config
<maco> tseliot: ah yeah that one exists
<tseliot> maco: ok, replace #video.driver:auto with video.driver:xshm (yes, without #)
<tseliot> and see if it solves the problem
<maco> tseliot: thanks. i'll test it when i'm not in class :-X
<tseliot> maco: ah, ok, have fun then ;)
 * tseliot > off for a bit. Bbl
<tjaalton> tseliot: sorry, I'll add it tomorrow
<bryce> superm1: I've sorted out that gradient banding problem
<bryce> superm1: turned out to be more difficult than I'd bargained for to enable dithering, but it looks pretty good now.  Not perfect, but you really have to look to see the banding now.
<superm1> bryce, ah great to hear
<bryce> superm1: apparently the registers on this hardware were moved around to make room for the display port stuff
<superm1> bryce, so it's a special case of the 3670, or this will help all 3670's?
<bryce> all 3670's
<superm1> ah very good.  that will help some other platforms coming out too then
<bryce> superm1: actually, I'm not sure if 3670 == rv635, or is more or less inclusive, but I structured this patch to target rv620, rv635, rs780, rv770, all of which have the register change as I understand it
<bryce> in any case, if the issue crops up again, I know how to fix it better now :-)
<superm1> awesome
<bryce> however I think it may require a deeper fix to make it perfect - the banding is still there if you look really closely
<bryce> most people probably won't care, but hardcore Inkscape users would probably freak out ;-)
<superm1> how is the card looking otherwise?
<bryce> great, haven't seen any other major problems, although I've not pushed it too hard.  I'll do some power management and xrandr trickery
<bryce> runs kinda hot
<tseliot> tjaalton: no problem ;)
<bryce> patch uploaded
<superm1> tseliot, is python-xkit adding Disable "dri2" to xorg.conf?
<superm1> when enabled via jockey
<tseliot> superm1: yes
<tseliot> is it a problem?
<superm1> tseliot, yes it causes amdcccle to crash
<superm1> because it doesn't think disable is a valid keyword
<superm1> is it still necessary that it be there?
<tseliot> superm1: no, I can remove it
<superm1> tseliot, yes please do
<superm1> thanks
<tseliot> superm1: I'll have to do that in jockey
<superm1> tseliot, i'll file a bug in jockey about it so that pitti is aware of it coming then too
<tseliot> superm1: ok, great. BTW that would only require the fglrx handler to be modified
<tseliot> superm1: feel free to assign the bug to me
<superm1> tseliot, okay will do
<tseliot> good
<superm1> tseliot, i'm assuming the no reboot dialog popup is affecting all drivers not just fglrx?
<superm1> or is there a quirk needed for that too?
<tseliot> superm1: it will affect all drivers
<superm1> tseliot, okay then i'm sure pitti is aware of that
<tseliot> superm1: yes, we have talked about that. I'm working with him on jockey
<superm1> other than this dri2 thing, and needing to depend on fglrx-modaliases when it works with xorg 1.5, i dont see any other things standing out as bugs particularly with fglrx and jockey then
<tseliot> superm1: great. Furthermore thanks to my recent work jockey removes the fglrx-kernel-source package too
<superm1> tseliot, yeah i saw that in the bug mail, but i've not been able to test it since the upload was a FTBFS
<tseliot> superm1: you refer to fglrx, right?
<superm1> tseliot, no i mean jockey was FTBFS
<superm1> the latest upload that pitti sent up
<tseliot> I didn't know that
<superm1> https://edge.launchpad.net/ubuntu/+source/jockey/0.5~alpha1-0ubuntu3/+build/721114
<superm1> pitti should have gotten some build mail about the FTBFS, so he should be aware
<tseliot> superm1: I bet he's aware of it. Either way I'll have a look at the code tomorrow.
#ubuntu-x 2008-09-23
<kees> say, when including X11/extensions/XTest.h, it now includes X11/extensions/XInput.h, but libxi-dev isn't a depend of x11proto-ext-dev
<bryce> that's probably a packaging oversight
<bryce> kees: how did you run into that?
<kees> bryce: I was recompiling synergy to test some small changes, and hit a configure failure.  tracking it to config.log, I saw the "XText.h: cannot find XInput.h" error
<kees> a trivial fix would be to have x11proto-ext-dev depend on libxi-dev, but I have no idea if that's the "right" fix.
<bryce> it probably is; xinput is new and gradually is getting folded in to various things.  
<bryce> x11proto-xext-dev, right?
<bryce> hmmm
<bryce> kees: weird, the version we have of that is 7.0.2 which was released in like Dec 2005
<kees> bryce: maybe XInput.h moved from something that was a long-time Depend of x11proto-ext-dev into a separate libxi-dev package?
<bryce> yeah... checking the debian patches first tho
<bryce> no patches :-)
<bryce> hmm
<bryce> well, x11proto-xext depends only on x11-common
<kees> I was poking at x11proto-xext-dev
<bryce> right, I meant in general x11proto-xext* only has a single dependency
<kees> ah
<bryce> (well, plus debhelper)
<bryce> crap no I'm wrong
<bryce> Depends: ${shlibs:Depends}, ${misc:Depends}, x11proto-input-dev, libxau-dev
<bryce> Pre-Depends: x11-common (>= 1:7.0.0)
<bryce> was looking only at the latter line
<kees> oh, I bet libxi-dev should be a depend of x11proto-input-dev
<bryce> http://packages.ubuntu.com/search?searchon=contents&keywords=XInput.h&mode=exactfilename&suite=hardy&arch=any
<bryce> that says that XInput.h is provided by x11proto-input-dev
<bryce> aha
<kees> http://packages.ubuntu.com/search?searchon=contents&keywords=XInput.h&mode=exactfilename&suite=intrepid&arch=any
<bryce> so in intrepid this has changed
<kees> and in intrepid it moved.  :P
<bryce> http://packages.ubuntu.com/search?suite=intrepid&arch=any&mode=exactfilename&searchon=contents&keywords=XInput.h
<bryce> mm
<kees> this is pretty recent, too.
<bryce> okay so guess we just need to update the Depends 
<kees> it wasn't like that a few weeks ago
<bryce> kees, mind filing an LP on this?  I'll forward it up from there
<kees> sure
<bryce> and I'll have the upload ready in a jiff
<bryce> oh and please indicate if installing libxi-dev is sufficient for fixing synergy's compilation issue
<kees> bryce: https://bugs.edge.launchpad.net/ubuntu/+source/x11proto-xext/+bug/273386
<ubottu> Ubuntu bug 273386 in x11proto-xext "libxi-dev may be missing as a Depend" [Undecided,New] 
<bryce> thx
<bryce> http://bryceharrington.org/ubuntu/x11proto-xext_7.0.2-6build2.debdiff
<kees> typo'd: libx1-dev vs libxi-dev
<bryce> http://www.pbs.org/cgi-registry/poll/poll.pl
<kees> also, maybe the dep should go into x11proto-input-dev ?
<bryce> good catch; strange that pbuilder accepted and built it ok
<bryce> hmm, not sure whether it should go into x11proto-input-dev.  But I'll mention that when forwarding to debian.
<bryce> kees: ok filed with debian.
<kees> cool, thx
<bryce> deb bug #499858
<ubottu> Error: Launchpad bug 499858 could not be found
<bryce> jesse says he'll try to be more careful in the future
<tjaalton> bryce: the XInput.h change was made by me, so it doesn't affect debian
<tjaalton> not yet anyway
<tjaalton> that was needed for the input properties
<soren> Does anyone know why I don't have any dead keys anymore?
<tjaalton> soren: look at /etc/default/console-setup
<tjaalton> are the XKB* same as in your old xorg.conf?
<soren> tjaalton: Looks like it, yes.
<tjaalton> ok, what's in there?
<soren> XKBMODEL="pc105"
<soren> XKBLAYOUT="dk"
<soren> XKBOPTIONS="lv3:ralt_switch"
<soren> XKBVARIANT=""
<tjaalton> no nodeadkeys there either
<soren> No "nodeadkeys".
<soren> Nope.
<soren> Not in setxkbmap -print either.
<tjaalton> hmm ok, so what did you want again?-)
<tjaalton> dead keys work here though
<tjaalton> what does setxkbmap -print output?
<tjaalton> put out, whaeva
<tjaalton> bryce: btw, don't use -Xbuild* versions if the package has real changes, since they would be lost when packages are being autosynced
<soren> tjaalton: Sorry, had a phone call. I'll pastebin the setxkbmap -print output.. Just a sec.
<soren> tjaalton: http://pastebin.com/m69f31be7
<soren> "setxkbmap dk nodeadkeys" doesn't help either (in case it somehow got inverted or something)
<soren> What I want is dead keys. Â´a, ~n, and  Â¨a just don't look right :)
<tjaalton> soren: ok, so that's identical to mine except I have fi instead of dk.. I'll have a look at xkb-data
<soren> tjaalton: "setxkbmap fi" doesn't give me back my dead keys either.
<tjaalton> m
<tjaalton> hm'
<tjaalton> uh
<tjaalton> try the guest-user
<soren> Can I log in from GDM as "him"?
 * soren doesn't run GNOME
<tjaalton> ok, dunno
<soren> ...so I don't have the user-switch applet
<tjaalton> create a dummy user then
<tjaalton> do they work on the console?
<soren> Yes. Console is fine.
<soren> The new dummy account doesn't work either.
<tjaalton> hrm
<soren> To make things even more fun, my original X session is now just a black screen with my mouse cursor on it. It happened after I switched to the dummy user's session and back. :/
<soren> Er.. Ok, scratch the "console is fine" line.
<tjaalton> intel?
<soren> Yes.
<tjaalton> hm, works here (965)
<tjaalton> but I've seen that
<tjaalton> if console is broken as well, I'm out of ideas :)
<soren> No, the console seems to be fine again.
<soren> It was just acting really strangely for a bit there. Instead of deleting characters when I pressed backspace, it just put two diamond shaped characters where the cursor was.
<soren> That was at the login prompt. WHen I'm actually logged in, it works fine.
<tjaalton> soren: and dead keys with dk work here
<soren> I'm not sure where to begin to look. I don't have an xorg.conf.
<tjaalton> do you have gnome installed?
<soren> tjaalton: Yes, the dummy user logged into GNOME. No luck.
<tjaalton> bah
 * tseliot starts bugging tjaalton
<tseliot> tjaalton: can you upload my patch for touchpads, please?
<tseliot> https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/271823
<ubottu> Ubuntu bug 271823 in xfree86-driver-synaptics "[intrepid] touchpad less responsive and top/bottom-right corner tapping disabled" [Undecided,Confirmed] 
<tjaalton> tseliot: done
<tseliot> tjaalton: thanks a lot. Where shall I send that crate of beer I promised you? :-P
<tjaalton> tseliot: Ristihaantie 8 C 34, 02750 Espoo, Finland. Thanks! :)
<tseliot> ;)
<tjaalton> sigh.. https://bugs.edge.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/261573/comments/45
<ubottu> Ubuntu bug 261573 in xkeyboard-config "Intrepid: No "AltGr" key defined -> e.g. no "@" symbol with MacBook Pro" [Undecided,Confirmed] 
<Kano> hi
<Kano> why has ubuntu 8.10 a different (1 line) xorg.conf than lenny
<Kano> Monitor section
<Kano> Device          "Configured Video Device"
<Kano> is there but not in lenny or sid
<Kano> wouldnt it be nice to write the _same_ config file?
<tjaalton> look at /usr/bin/dexconf, they are not the same
<Kano> i would prefer to write both times the same, because otherwise i need a workaround to remove or add that line...
<tjaalton> then you edit dexconf to suit your needs
<Kano> thats not possible
<Kano> but nice to know that file...
<tjaalton> btw, that line is there in sid
<tjaalton> in the sid version of dexconf
<Kano> but not in lenny
<Kano> would you add or remove that line
<tjaalton> sure is in lenny too
<Kano> well it is in 2 positions in ubuntu
<Kano> i mean the MONITOR section
<Kano> the one with device in front
<Kano> the one with indentifier is in both
<tjaalton> those sections are identical in all three versions
<tjaalton> lenny/sid/intrepid
<Kano> sorry screen section
<Kano>         Identifier      "Default Screen"
<Kano>         Monitor         "Configured Monitor"
<Kano>         Device          "Configured Video Device"
<Kano> thats written in intrepid
<Kano> the device line is not present in lenny, just installed yesterday
<Kano> very curious that you say it is in all of em...
<tjaalton> because you weren't talking about the Screen section before
<tjaalton> it is there alright
 * wgrant wonders why that would need to be worked around.
<Kano> wgrant: well the "new" style xorg.conf is really small
<Kano> therefore i added a patch code to my scripts
<Kano> that makes am slightly larger to be used to change to nvidia/fglrx later
<tjaalton> bryce: btw, better use "-I".git" next time for xorg ;)
<tjaalton> um, '-I".git"'
<Kano> and what i dislike is when that patch does not apply when i set it for one of those
<Kano> as i need to change the screen section...
<Kano> i prefer 1 code for all,but it seems i need a workaround
<Kano> removeing a line is usually more easy than adding
<tseliot> Kano: what's the problem with having a reference to the Device section in the Screen section?
<tseliot> it's perfectly legal to do so
<Kano> there is no problem, just differnt to debian
<Kano> and that difference makes my script to not apply for one of em without mod
<jcristau> and why does that matter?
<Kano> therefore i wanted to know WHY it is different
 * wgrant suggests that it is because they're not the same.
<tseliot> Kano: why don't you use X-Kit to modify the xorg.conf? It would take only few lines of Python code
<tjaalton> oh right; "dexconf: Bring Device back to Screen-section"
<Kano> i dont know phython
<tjaalton> "nvidia-settings and aticonfig need that. (LP: #181405)"
 * jcristau uses sed to modify xorg.conf
<tjaalton> Kano: so there, fix nvidia-settings and aticonfig first ;)
<Kano> tjaalton: ok, then i will add that line for debian
<tjaalton> although I wouldn't be pissed if those broke again
<jcristau> (and i get scared i'll break something every time i have to do that)
<tjaalton> since that's all they do anyway
<Kano> aticonfig is really unimportant for 8.10 as fglrx does not work anyway *g*
<jcristau> tjaalton: how did you handle the i810 -> intel and via -> openchrome stuff, btw?
<jcristau> (if at all)
<tjaalton> jcristau: with cruelty
<Kano> i810 -> intel is trivial
<tjaalton> jcristau: ie. no mangling like you've done, although we might want to merge to get the code it
<tjaalton> *in
<Kano> debian just uses a wrapper module
<jcristau> tjaalton: okay
<jcristau> Kano: well, no.
<Kano> jcristau: the i810 package has it
<Kano> which would be there on update
<tjaalton> there is no i810 package
<jcristau> the i810 package is empty in sid, and doesn't exist in experimental. so no.
<Kano> well it was there before..
<jcristau> and that's besides the point anyway
<tseliot> tjaalton: BTW I had to change a handler in Jockey because amdcccle crashes if you put something like Disable "dri2" in the Module section of the xorg.conf.
<jcristau> so fix amdcccle?
<tseliot> jcristau: if it were open source I would fix it myself
<tjaalton> it's silly to break because of that
<tseliot> :_/
<jcristau> it seems there's all kinds of silly xorg.conf parsers all over the place
<tseliot> hehe right
<jcristau> Kano: the point is, 'Driver "i810"' in xorg.conf doesn't work with xserver 1.5, so it has to be changed to intel.
<Kano> jcristau: most easy way: remove the line
<jcristau> Kano: you're useless, thanks.
<Kano> ;)
<Kano> xorg can find the driver automatically
<Kano> just not nvidia or fglrx
<jcristau> tell me something i don't know
<Kano> well you know everything it seems, then you surely have got fglrx working with xserver 1.5
<tjaalton> Kano: for the record, jcristau is the head of Debian XSF ;)
<Kano> well then he should write the same configfile for all ;)
<tjaalton> but ubuntu messes things up, so no
<Kano> bbl
<jcristau> we should probably not write an xorg.conf at all in squeeze.. at least in the common case.
<tjaalton> yeah
<Ng> no xorg.conf ftw \o/
<jcristau> i'll write to debian-boot, to see what their plans are re: console-setup
<Ng> except the emulatescrollwheel bit ;)
<tjaalton> jcristau: \o/
<tjaalton> Ng: just use xinput :)
<Ng> tjaalton: hmm? all I saw on it was mvo's blog post about building his own evdev or something and using xinput properties - is that properly in intrepid now?
<tjaalton> Ng: sure is
<Ng> suh-weet
<Ng> should I just pinch the config bits from said blog post?
<tjaalton> xinput list, xinput list-props $id etc
<tjaalton> man xinput too
<tjaalton> but the blog post might help too
<Ng> win
<Ng> two xinput commands seems to do the trick
<tjaalton> nice
<tjaalton> in time there'll be gui support for it
<tjaalton> now you need to run those on every session start..
<Ng> yeah, for now a session startup script will do :)
<Ng> thanks very much :)
<tjaalton> my pleasure
<Ng> the pleasure is mine, I have my scrolling back ;)
<Ng> I added a comment to mvo's post about it with the commands I ran
<mvo> thanks Ng
 * jcristau also pesters the xcb folks about the libxcb buffer size
<Kano> btw. what could be the problem with ubuntu 8.10 that my nvidia 8800 gts 512 only runs with binary driver? the driver detected does not show any errors in the log but there is no pic (vga via dvi adapter)
<bryce> tjaalton: is there a way we can set things to use that switch automatically?
<jcristau> alias dpkg-buildpackage='dpkg-buildpackage -i -I'
<tjaalton> something like that ;)
<superm1> bryce, make a file named ~/.devscripts
<superm1> that contains this:
<superm1> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/RCS|/\.svn|/\.deps|\{arch\}|\.arch-ids|\.arch-inventory|\.bzr|\.bzrignore|\.shelf)(?:$|/)' -ICVS -I.svn -I\{arch\} -I.arch-ids -I.arch-inventory -I.bzr -I.bzrignore -I.shelf"
<bryce> thanks
<superm1> I'm not sure where, how, or from whom i got it, but it works
<jcristau> you don't need all that
<superm1> if you use debuild it works at least
<jcristau> dpkg-buildpackage has default regexps for -i and -I
<superm1> they weren't catching bzr stuff for me ever until I started to use  that
<bryce> maybe DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I.bzr -I.svn -I.git" is enough?
<jcristau> bryce: those should be taken care of by -I afaict
<jcristau> superm1: dpkg's changelog says it added bzr stuff in 1.13.14
<jcristau> hmm. only for -i. although tar_ignore_default_pattern contains .bzr and friends here.
<bryce> jcristau: I'd assumed so too but timo said at least -I".git" is needed
<jcristau> oh.
<jcristau>   * Allow dpkg-source -I without a pattern which will load a default
<jcristau>     list of pattern similar to -i without regexp. Patch by
<jcristau>     Jari Aalto. Closes: #440972
<jcristau> that's 1.14.7
<jcristau> a year ago
<tjaalton> I've seen that changelog entry, but for some reason it doesn't seem to work..
<bryce> tjaalton: btw, Intel says that Q3 final release of -intel will be Oct 14th
<bryce> tjaalton: they asked if we could include it at that date.  I said we'd need to see the list of changes
<tjaalton> bryce: does it work without GEM?
<bryce> tjaalton: yeah, they're not shipping this one with GEM enabled yet
<tjaalton> oh
<bryce> they found too many serious stability issues
<tjaalton> hehe
<mnemo> hey guys, I just bought a new machine with intel G45 chipset (integrated GMA X4500GD card).. Xorg goes bonkers after gdm, flashing for a while and then shows me unreadable dialog (due to corrupted graphics, kernel still live though)
<mnemo> im getting this X.org stacktrace from the intel driver:
<mnemo> http://launchpadlibrarian.net/17890192/Xorg.0.log
<mnemo> any ideas on how I can work around it? already tried disabling compiz, still crashes though
<tjaalton> mnemo: use the vesa driver?
<mnemo> how can I configure it to do that?
<tjaalton> man xorg.conf
<tjaalton> Device section
<mnemo> is that the same thing as saying AccelMethod XAA ?
<tjaalton> no
<mnemo> which one would be better intel in XAA mode or VESA?
<mnemo> because I just noticed that it doesnt crash in XAA mode
<tjaalton> oh
<tjaalton> sorry I misread, yes it's the same section where you put that option
<tjaalton> intel probably is better
<tjaalton> bryce: we probably need to put the beta version in a PPA
<mnemo> i'd be happy to help you out with testing the intel driver
<jcristau> 2.4.2 has known problems on the new platform
<tjaalton> yep
<bryce> mnemo: if you actually want to help with testing, join the ubuntu-x@ mailing list; that's where we announce testing opportunities generally 
<mnemo> im on it ;>
<tjaalton> intel 2.5-branch still needs libdrm >=2.4.0, so won't build
<tjaalton> bryce: ^^
<pwnguin> there's an ubuntu-x mailing list?
<bryce> pwnguin: yup
#ubuntu-x 2008-09-24
<tjaalton> bryce: btw, I filed a sync request for libx11-1.1.5, bug 273471
<ubottu> Launchpad bug 273471 in libx11 "Please sync libx11 1.1.5-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/273471
<bryce> tjaalton: great, I've +1'd it
<tjaalton> bryce: nice, thanks
<tjaalton> I'll subscribe -archive since it's a bugfix release
<tjaalton> pop your champagne bottles open, we got 2000 bugs!
<tseliot> \o/
<Ng> tjaalton: do you know if anyone is working on xinput config gui stuff? is it just going to go into the existing gnome capplets?
<tjaalton> Ng: no I don't know of anyone doing that, and yes, it should go in the existing capplet I think
<Ng> well that rules me out, those things will be in C. I was just pondering hacking something up in python which would discover the devices and their properties and let you twiddle them, but it should really be a nice interface that hides all the scary numbers ;)
<tjaalton> yeah the xinput interface isn't that friendly
<Ng> I dunno what the underlying xinput API is like, but the commandline tool doesn't seem to expose enough information - like for an int value it doesn't tell you how large an int it is, but to set it you need to know
<tseliot> Ng: I would like to write a UI for xinput stuff
<tseliot> I can do it for GNOME and KDE
<tseliot> I hope to be able to do it in time for Ubuntu 9.04
<Ng> cool :)
<Ng> a quick look at the existing gnome input capplets suggests to me that they are entirely unsuitable for this
<Ng> in a world of multiple input devices and per-device properties, a single capplet for setting things for a single mouse no longer makes sense
<Ng> I'd suggest that things have global defaults, but be overridable for individual devices, and some part of the desktop would receive events for these devices being connected and apply the appropriate settings the user had previously chosen
<tseliot> if I complete input support for X-Kit we can configure devices with FDI files too
<Ng> (e.g. I'm thinking about acceleration - a single value can't possibly hope to make sense for a laptop with a touchpad, trackpoint and USB mouse)
<tseliot> yes, that's the idea
<Ng> :)
<Ng> I'll keep quiet now, I'm sure that more capable brains than mine will get it right :)
<bryce> Ng:  would you be interested in rigging up a prototype UI?  I think part of the problem is no one is sure what the tool should look like, and we need to start gathering some conceptual stuff (regardless of language) so people have something to stimulate ideas
<Ng> bryce: perhaps. Is there a way to send the appropriate X calls from python? :)
<Ng> for some reason I have a weird enjoyment of auto-generating UIs in python
<bryce> there probably isn't a python binding for libxi-dev
<bryce> but you could probably review its api
<bryce> but even if the prototype didn't consider how it hooks to the backend and just focused on conceptualizing the UI, that'd help
<Ng> yeah I figured there would be no bindings, I was kind of hoping there was a generic way to request this stuff via some X binding ;)
<tseliot> I was planning to use swig or something similar to access xinput from python. We'll see
<Ng> "This section provides information about the XInput API, which allows applications to interact with the Xbox 360 Controller when it is connected to a Windows"  dear google.... fail
<jcristau> i thought someone did a python binding generator from xcb protocol descriptions
<tseliot> jcristau: that would help
<tseliot> Ng: /usr/include/X11/extensions/XInput.h perhaps?
<Ng> tseliot: yeah, I was actually just googling to see if there are any nice pages which have more of an overview of xinput
<Ng> the output of "xinput list" shows a bunch of stuff which I would guess has no place in a user config system
<tseliot> Ng: aah, some proper docs
<Ng> e.g. "Video Bus" - I have no idae why that appears twice in a list of input devices ;)
<jcristau> Ng: because it appears twice in /proc/bus/input/devices
<jcristau> and claims to have keys
<Ng> so I immediately wonder how on earth a configuration GUI is going to eliminate all of the clearly bogus entries in there
<Ng> macintosh mouse button emulation is not bogus on certain hardware, but it seems to appear everywhere
<jcristau> don't try to solve that in the configuration gui. find a way to detect these cases, and don't load evdev for them.
<Ng> maybe I'll stick to UI mockups or go with my earlier plan of leaving this for smarter brains ;)
<tseliot> Ng: UI mockups are more than welcome ;)
<Ng> I almost wonder if talking directly to xinput for the list of devices is a mistake and that hal should have an addon which puts their properties into its tree
<Ng> but I'm really not very familiar with that kind of thing, so I could be talking nonsense ;)
<jcristau> talking to hal would be a mistake
<Ng> I'll take your word for that, but out of interest - why?
<jcristau> because you're configuring your X server, and you already have a way to talk to it, it's the X11 protocol
<jcristau> talking to hal on the machine where the X client is running achieves nothing, since the x server might live somewhere else entirely, and even if not you'd need some kind of authorization mechanism. which you already have with Xauth if you communicate via X11
<Ng> that's a good point
<tjaalton> ie. don't try to build a gui for xinput-the-command, but XInput the API
<tjaalton> just like wgrant did for synaptics ;)
<tjaalton> although, the API will soon change a bit
<tseliot> tjaalton: of course I'll wait for the new API ;)
<tjaalton> bryce: I'll prepare mesa-7.2 and xserver-1.5.1 for upload
<bryce> tjaalton: ok; is mesa 7.2 mainly bug fixes?  I suspect the last mesa (or else kernel) broke compiz on one of my machines
<tjaalton> bryce: yes, 7.1 was a devel version, 7.2 is the stable one
<tjaalton> bryce: what hardware was it where compiz failed?
<bryce> tjaalton: http://bryceharrington.org/ubuntu/lspci.txt
<bryce> tjaalton: erf, 255008 has reopened
<tjaalton> "Eaglelake".. never heard
<tjaalton> bryce: should be closed again
<bryce> tjaalton: ok, what should I tell them?
<tjaalton> muelli is the only one with the problem
<tjaalton> I'll explain him
<bryce> ok great thanks
<bryce> yay, ok I think all intrepid targeted X bugs are closed now
<bryce> oops maybe not
<bryce> 247376 is our fglrx one we can't do anything for yet.  179797 is fix committed.  hmm...
<superm1> any updates from AMD regarding the libstdc++5 business?
<bryce> superm1: never got a reply to my email :-/
<superm1> -shrug-
<bryce> next call is in a week; I'll re-raise it then
<bryce> I suspect they've read it and (hopefully) added to their todo list, but maybe didn't think a reply was needed
<bryce> I went to dinner with them once and noticed they are major blackberry junkies there
<bryce> but because the keyboards are so tiny and hard to use, they tended to read waaaay more than they write ;-)
<superm1> yeah 90% of the mail i see from mtippet is from BB
<superm1> (that's a bit rude for them to be using them during dinner though)
<bryce> (that was my take too...)
<bryce> tjaalton: the compiz issue I mentioned earlier is #261080
<bryce> tjaalton: (which is a private bug)
<bryce> upstreamed at http://bugs.freedesktop.org/show_bug.cgi?id=17384
<ubottu> Freedesktop bug 17384 in Drivers/DRI/i965 "X hangs up if turning on the virtual effect of gnome" [Major,Reopened] 
<bryce> tseliot: btw, on bug 220563, you should file a new bug with those patches, since that bug is already closed
<bryce> tseliot: I think you'll need to get seb128's approval on them to go in, since they're a fairly substantial amount of code
<tseliot> bryce: ok, thanks, I'll do it
<tseliot> oh seb128 has just entered
<bryce> tseliot: I'd be happy to sponsor the upload if he is okay with the changes
<bryce> oh, one note is in the screen-resolution-extra diff, it appears you stepped on james_w's changelog entry; perhaps that could be cleaned up better
<tseliot> bryce: great. Ok, I'll open another report, attach the patches and bug seb128 again to review them
<tseliot> bryce: sure, I will fix it
<tseliot> right, James' entry is missing
<seb128> tseliot: where are the changes to review?
<tseliot> seb128: https://bugs.launchpad.net/gnome-control-center/+bug/220563
<tseliot> see the last posts
<tseliot> seb128: and thanks in advance :-)
<Ng> tjaalton: is it expected that xinput properties are lost across a suspend/resume?
<tjaalton> Ng: I'm not sure, sounds like a bug
<Ng> I've not checked if it's entirely reproducible yet, but I've noticed it twice today and afair I've suspended twice so far
<tjaalton> mine fails to resume, so can't really test it myself :)
<Ng> erk
<Ng> your X61?
<Ng> I read a bug earlier on one of the 14 bajillion BTS I'm poking around in since this damn e1000e bug appeared, about some variant of e1000 breaking resume. It definitely used to break suspend for me, so I generally unload it on suspend
<Ng> although I think intrepid has lost the script we put in for hardy to do that
<seb128> tseliot: +    - bump Standards-Version to 3.8.0
<seb128> why?
<seb128> I'm wondering why many people do that, we have no reason to create diff over debian on this number and we make no use of it
<seb128> did you verify it conforms to the new standards-version or just updated automatically?
<seb128> tseliot: I've to admit I don't like those changes
<seb128> that doesn't seem the right way to me
<tseliot>  seb128: ok, I can revert that change
<tseliot> seb128: don't you like the other changes either?
<seb128> tseliot: several things
<seb128> - displaying an error saying to edit the virtual xorg.conf, no
<seb128> that's not something user will understand and not something to recommend
<seb128> you should rather display a "you need to install this software for that" and maybe add an "install now button"
<tseliot> seb128: shall I change the message to "sorry, it wasn't possible to apply your settings"?
<tseliot> ah
<seb128> similar to how samba is installed when required for example
<tseliot> seb128: ah, ok, so I should call APT to install screen-resolution-extra if the user accepts
<tseliot> good point
<seb128> right, or rather synaptic
<seb128> maybe ask mvo about it
<tseliot> yes, I know how to do it
<tseliot> I can call that stripped down progress dialog
<tseliot> I did it in another app too
<seb128> otherwise I'm not sure to understand why you need a copy of the settings
<tseliot> seb128: because otherwise you would have to log in and set up screens again as you did before 
<tseliot> why should users do the same thing twice?
<seb128> why? can't you write directly the config?
<seb128> it'll not be used before next login anyway
<tseliot> yes but then you will have to restart the xserver
<seb128> you have to restart it anyway
<tseliot> yes but my point is
<tseliot> that you don't have to set up your screens again after restarting X
<tseliot> since you have already selected how you would like to have your screens arranged
<tseliot> and that determines the framebuffer size
<tseliot> seb128: maybe I'm missing your point. If so, please explain it again
<seb128> why would writting the new config directly not work?
<seb128> well you write an alternate config now
<tseliot> ah
<seb128> and try to load this one first at next login right?
<seb128> why don't you writte directly the normal config, it'll not be applied before the next login anyway
<tseliot> no, it wouldn't work as the current app won't do anything. It will only try to apply settings without writing anything
<tseliot> I prefer not to touch the main xml file
<tseliot> so that if previous settings worked
<tseliot> we should use them instead
<tseliot> we should keep using them, I mean
<tseliot> otherwise, if all the conditions are good
<tseliot> we apply the desired xml
<tseliot> for example
<tseliot> if a certain setup used to work, say, with 2 screens,
<tseliot> we let the system fallback to that
<seb128> alright, it seems a bit weird but why not
<seb128> did you discuss that upstream already?
<tseliot> I sent an email to Soren
<tseliot> and attached two partial patches
<seb128> anyway feel free to get the changes sponsored by somebody once you fixed the "change your xorg virtual setting configuration" thing ;-)
<tseliot> in the GNOME bugzilla
<tseliot> seb128: ok, great, I will change it as you suggested
<tseliot> thanks a lot
<seb128> thank you
<tseliot> :-)
<jcristau> Ng: the device might be removed by the kernel on suspend, so you'd get a new one on resume
<Ng> jcristau: is that logged or traceable somehow?
<Ng> it does seem to be happening every time
#ubuntu-x 2008-09-25
<Ng> well going by Xorg.0.log it does seem like the trackpoint device appears again after resume
<bryce> tjaalton: do you know of any other major issues we absolutely must sort out before the beta freeze tonight?
<bryce> tjaalton: when you do the mesa upload, would you mind checking these fedora patches and mark them 'reviewed' if we don't need them?  http://daniel.holba.ch/harvest/handler.py?pkg=mesa
<DBO> hey all
<bryce> hi
<DBO> mind giving a bit of help trying to get a more recent i915.ko?  suspend is broken on my system when the drm module is loaded
<DBO> so I am trying to get things a bit more up to date (I should mention I am already on intrepid)
<bryce> sorry, pretty busy atm (beta-freeze is tonight).
<DBO> =/ does that mean that suspend bugs will not be fixed?
<bryce> if you have a patch ready, I can look at putting it in
<DBO> unfortunately no, I am only just now figuring out what is causing the problem
<DBO> but it seems to be somehow related to DRM not suspending pretty
<bryce> although most suspend bugs are kernel issues so you'd probably need a kernel engineer to approve your patch
<DBO> it is a kernel module bug
<DBO> drm.ko
<bryce> you probably need the kernel guys then
<DBO> bryce, do you know what version of X i need for GEM?
<pwnguin> bryce: hope you get better luck working with linuxwacom than i did =/
<bryce> pwnguin: do tell?
<pwnguin> well, ive tried forwarding bugs to their tracker, but they basically said not to use the bug tracker.
<pwnguin> (should it come with a INTERNAL USE ONLY notice?)
<bryce> huh
<bryce> so why don't they disable it?
<bryce> *boggle*
<pwnguin> maybe i'm just extra stupid
<pwnguin> http://sourceforge.net/tracker/index.php?func=detail&aid=1987565&group_id=69596&atid=525124
<tjaalton> bryce: I already uploaded it :)
<tjaalton> bryce: but i'll have a look at those patches
<tjaalton> bryce: also, wacom is busted for some weeks now
<tjaalton> since the 0.8.1.3 upload (which was requested by many..)
<tjaalton> kernel support is lacking
<tjaalton> but I'll package 0.8.1.4
<tjaalton> maybe we can get the kernel driver synced to that
<tjaalton> bryce: should we just drop -unichrome from the archive?
<tjaalton> upstream has ported it to libpciaccess, but still..
<soren> tseliot: you said you sent me an e-mail.. I don't think I see it. To which address did you send it?
<tseliot> soren: sorry, I meant Soren Sandmann, the maintainer of the Screen Resolution capplet
<soren> tseliot: Oh. haha!
<tseliot> ;)
<soren> tseliot: I'm just so used to being the only one called Soren around these parts.
<soren> No worries :)
<tjaalton> pwnguin: wacom-tools uploaded, and a patch being sent for kernel-team
<tseliot> soren: I can understand you. I bet there aren't many people named Alberto around either ;)
<soren> tseliot: :)
<Ng> so whoever writes the xinput thing is going to be my newest hero, losing the scrolling after each suspend is starting to really annoy me, and I was only just getting used to not having the scrolling at all ;)
<tjaalton> soren: https://bugs.freedesktop.org/show_bug.cgi?id=17468
<ubottu> Freedesktop bug 17468 in General "combining diacritics broken, became deadkeys" [Normal,New] 
<soren> GTK_IM_MODULE=xim doesn't help.
<soren> Also, my problem is the opposite (I have no dead keys at all).
<soren> ..but I understand that the problems might have been related.
<tjaalton> hum, ok
<soren> tjaalton: Heh..
<soren> xev says "dead_acute", when I press the dead acute button.
<soren> I'm not entirely sure what to make of that. :)
<tjaalton> that's what I get as well, so.. really strange that it doesn't work for you
<MacSlow> yo there
<tjaalton> wazzup?
<MacSlow> hopefully not much (at least bug-wise)
<tjaalton> MacSlow: oh, I thought you had a problem ;)
<MacSlow> tjaalton, I used to have (Xorg didn't come back after gnome-screensaver blanking) but after yesterdays update it didn't happen again
<tjaalton> MacSlow: with intel? that was fixed before alpha6
<MacSlow> tjaalton, oh yeah sure it was on X3100/G965
<tjaalton> MacSlow: yep, vblank broke it
<MacSlow> i see
<MacSlow> bryce, you know if cworth can or cannot come to FOSScamp/UDS?
<Ng> seb128: fyi, I don't appear to be able to reproduce bug #173350 in intrepid, but I was definitely getting it on this machine in hardy
<ubottu> Launchpad bug 173350 in xorg-server "Caps lock LED changes state even when caps lock is mapped to ctrl" [Unknown,Fix released] https://launchpad.net/bugs/173350
<seb128> Ng: good, close the bug maybe then ;-)
<Ng> yeah, I thought just after I hit enter "wtf am I telling him on IRC" ;/
<seb128> ;-)
<Kano64> hi, just tested latest daily with my nvidia 8800 gts and without binary driver i get just black screen
<Kano64> http://paste.ubuntu.com/50492/
<Kano64> thats the logfile, i see basically no error,but i see nothing.
<Kano64> monitor is just black, 19" crt
<tjaalton> a CTX from '98?
<Kano64> yes, it is pretty old
<Kano64> i guess the card tries to use digital port not the vga one
<Kano64> (II) NV(0): Output DVI1 connected 
<Kano64> but i use a dvi->vga connector
<Kano64> i can install binary drivers and then i see something
<tjaalton> they probably have some quirks for such monitors
<Kano64> http://paste.ubuntu.com/50495/
<Kano64> thats with binary driver
<Kano64> (II) NVIDIA(0): Assigned Display Device: CRT-1 
<Kano64> the old crt is detected as dvi with the oss driver
<tjaalton> nv is crap
<Kano64> it should be fixed...
<jcristau> Kano64: bugs.freedesktop.org is ----> that way
<tjaalton> you could try a newer driver.. .12 available
<tjaalton> we have .10
<Kano64> is there a deb
<tjaalton> no
<Kano64> so packaged .12, will try now
<Kano> tjaalton: nv .12 does not help
<Kano> have to go,bbl
<mvo> so what happens if a driver (say "ati") does understand options in the "device" section (because this section was e.g. switched from fglrx to ati) - does the driver just ignore the unknown options (my tests indidcate this is the case)
<jcristau> yes
<mvo> excellent, thanks! 
<Le-Chuck_ITA> Hi all. Do you think git://git.freedesktop.org/git/xorg/driver/xf86-video-intel is the correct git master for xserver-xorg-video-intel? I am a bit confused by the "xf86" at the beginning of the module name
<Le-Chuck_ITA> I need to test that to complete a bug report against 
<Le-Chuck_ITA> X
<jcristau> use anongit.fd.o rather than git.fd.o, but otherwise yes
<Le-Chuck_ITA> I used "git.fd.o" and it worked :) should I redownload or is it just a matter of resource usage?
<jcristau> it's ok
<Le-Chuck_ITA> aargh. I installed build-deps but it requires librdm 2.4. Am I going into a hell of unsatisfied dependencies? If so I have to decline the request
<jcristau> libdrm should be all you need
<jcristau> git clone git://anongit.freedesktop.org/git/mesa/drm
<Ng> isn't there some magic you need to do to build current libdrm without GEM?
<tjaalton> Ng: apart from patching the source, doubtful
<tjaalton> configure checks that you have >= 2.4.0
<jcristau> libdrm doesn't have any build-deps...
<Ng> hrm, ok, I did vaguely give it a try and didn't get very far, but that may have been my fault ;)
<tjaalton> superm1: hey, I uploaded a new fglrx-installer earlier today, and added the Provides: xserver-xorg-video-2, which should prevent upgrades hosing the machine
<superm1> tjaalton, yeah i saw.  that's a good solution for now
<superm1> i was thinking about another thing here
<tjaalton> ie. it should be removed on upgrade from hardy
<tjaalton> ok, shoot
<jcristau> the hardy version provides -video-2 too?
<superm1> tjaalton, bryce tseliot would it be possible to ship an fdi file that set xorg.conf options for enabling the nvidia driver instead?
<superm1> and fglrx when it's fixed
<tjaalton> jcristau: yes, it does
<jcristau> ok :)
<superm1> since so many other things can be turned on/off via fdi files, it seems like it should be sensible enough to do for X proprietary drivers too
<tjaalton> superm1: unfortunately driver properties aren't supported yet
<superm1> tjaalton, oh i see
<tseliot> too bad
<tjaalton> er, video driver properties
<jcristau> superm1: xorg only uses hal for input devices
<superm1> jcristau, ah i see
<tjaalton> I asked about it a couple of weeks ago, and it's WIP
<jcristau> maybe you could ship /usr/share/xserver-xorg/nvidia.ids though
<jcristau> with the pci ids of the supported chips for the driver, if you have that
<superm1> perhaps that'd be something that can be something that should be looked at UDS this winter again then, see where it's at and if there is anything that can be helped from this level to push it along
<superm1> jcristau, i tried to do that with fglrx at one point a couple of months ago, and it didn't work as gracefully as you'd hope
<tjaalton> there's a commit in xserver master (and in our package too..) that allows to use a list of drivers to try for a given hw vendor
<tjaalton> too bad that it's useful only if there's no xorg.conf at all
<tseliot> too bad we have 4 versions of the same nvidia driver
<tseliot> the module is named "nvidia" in all cases
<superm1> what's the game plan for those 2 non functional versions?  they stay in the archive?
<superm1> tseliot, well for that idea of nvidia.ids, it would be included in each of the packages for the nvidia driver 
<superm1> so you'd only have that functionality working when the driver was to be installed
<tseliot> I was planning to blacklist those 2 drivers in jockey
<superm1> well you don't really have to blacklist, can't you just not install their modaliases?
<tjaalton> jcristau: actually, there are some bugs that suggest that the ids are not used at all with 1.5..
<tseliot> superm1: ah, right
<jcristau> tjaalton: that's quite possible...
<tjaalton> jcristau: and instead the vendor id and the driver is loaded even if it doesn't support it
<jcristau> oh well.
<tjaalton> there's one annoying bug where it loads nv and it fails miserably
<tseliot> superm1: I can change the dependencies of nvidia-common
<tseliot> tjaalton: that might be because the nvidia module gets loaded first?
<tseliot> not that it makes any sense
<jcristau> or it might be because it's a card that's not supported by nv, and they would be better off with vesa
<tjaalton> even the fallback-patch won't help there, since vesa can't initialize after nv has poked it
<tjaalton> tseliot: no, nvidia supports it fine
<jcristau> tjaalton: uh. i thought you aren't allowed to touch the hardware in preinit...
<tseliot> tjaalton: which bug is it?
<tjaalton> bug 261977
<ubottu> Launchpad bug 261977 in xorg-server "nv is chosen even if it doesn't support the card" [Medium,Incomplete] https://launchpad.net/bugs/261977
<tjaalton> it's quite messy
<tjaalton> the log in https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/261977/comments/23
<ubottu> Launchpad bug 261977 in xorg-server "nv is chosen even if it doesn't support the card" [Medium,Incomplete] 
<tjaalton> it might be something different though
<tseliot> maybe it relies on the fact that the card id begins with 10de?
<tseliot> I haven't read the code that does autodetection
<tjaalton> yes, that's with the patch
<tjaalton> so the detection part works ok, but vesa doesn't work
<jcristau> tjaalton: looks like we're not setting PCI_TXT_IDS_DIR?
<tseliot> so if it's an NVIDIA card the nv driver is loaded even if the card is not supported???
<jcristau> tseliot: correct
<jcristau> which makes sense, if you're able to fall back to vesa
<jcristau> if you're not, then it leads to epic fail
<tseliot> are we sure that the fall back mechanism works?
<jcristau> timo says it doesn't
<tseliot> tjaalton: can I see the patch, please?
<tjaalton> tseliot: it's in xorg-server
<tjaalton> patch 141 IIRC
<tjaalton> it's only functional if there's no xorg.conf
<tjaalton> so even without it the autoloading is busted
<tjaalton> what we had already in hardy
<jcristau> i'll unbreak the .ids stuff for -2..
<jcristau> this is brown paper bag material
<tjaalton> heh, ok
<jcristau> (testing now to make sure...)
<tjaalton> I'll also drop that patch since it didn't prove to be that useful
<jcristau> should be easy to change autoConfigDevice to add new device sections for the fallback drivers, in addition to the chooseVideoDriver() one
<jcristau> too much stuff on the todo list :/
<mvo> will fglrx be loaded automatically if it is instaleld and no xorg.conf is provided?
<superm1> mvo, no not at this point 
<bryce> mvo, don't think we're there yet
<bryce> but tjaalton put in a patch a few weeks ago that moves us towards being able to do that
<mvo> thanks, makes my life easier :)
<bryce> mvo, btw did you get my patch for blacklisting compiz on eaglelake?
<jcristau> tjaalton: pushed the fix.
<mvo> bryce: yes, thanks, I haven't put it in yet though
<bryce> mvo, great thanks
<bryce> Freeze is in effect
<federico1> hmm, what's mpt's email?
<Kano> hi tjaalton , do you have got the 2 pastebins with the xorg log files of my nv card?
<Kano> or somebody else
<superm1> Kano, if you posted them here, they should have been caught by the log bot
<superm1> !logs | Kano 
<ubottu> Kano: Official channel logs can be found at http://irclogs.ubuntu.com/ - For LoCo channels, http://logs.ubuntu-eu.org/freenode/
<Kano> thx
<bryce> federico1: mpt@canonical.com maybe?
<bryce> federico1: yep.  matthew.thomas@canonical.com and mpt@myrealbox.com shoudl work too
<federico1> bryce: great, thanks
<tjaalton> jcristau: heh, that was simple
<tjaalton> bryce: actually, currently it only works when there's no xorg.conf, but if jcristau is right that should be fixable
<bryce> tjaalton: which what?
<tjaalton> bryce: the autoconfig patch
<bryce> ahh
<tjaalton> hum, so tdfx doesn't like xserver 1.5 either
<superm1> tjaalton, did you say you have a solution for when nv is getting selected when it shouldn't?
<superm1> i've got hardware exhibiting such a problem..
<superm1> makes it quite difficult to boot up intrepid alpha6 live disk :)
<Kano> add S
<superm1> S?
<Kano> single mode
<Kano> or does forcevesa still work
<superm1> well i hand modified it - but the point is that it tried to use nv when it shouldn't have
<superm1> nv doesn't support this device yet
<tjaalton> superm1: yes, merge the latest commit to xorg-server in experimental
<tjaalton> which jcristau did a couple of hours ago
<superm1> tjaalton, it's not critical (i can work around it for now), so i'll be glad to test it when it's in a package form
<tjaalton> superm1: will be in for beta
<superm1> i added my log to the bug, but i suppose not necessary anymore
<superm1> okay :)
<tjaalton> looks like libx11 also has a memory leak that's fixed, so that should be synced again :)
<superm1> tjaalton, given that beta freeze is active, you might want to make sure you remember to milestone bug 261977 so that it gets put in place
<ubottu> Launchpad bug 261977 in xorg-server "nv is chosen even if it doesn't support the card" [Medium,Confirmed] https://launchpad.net/bugs/261977
<tjaalton> superm1: sure
<Kano> usually nv is chosen when the vendor is nvidia
<superm1> Kano, but if the nv driver doesnt support your card yet, your only option will be vesa
<Kano> yes, that should be better. or let the fallback handle it. i have got a differnt problem
<Kano> nv card 8800 gts 512, edid is correctly read out, xorg logfile is fine, but dvi is selected not vga. only binary driver handles it correctly
<Kano> maybe it is the same case for your card? what says the log?
<superm1> (WW) NV: Ignoring unsupported device 0x10de0866 at 03@00:00:0
<Kano> and fallback is not used?
<superm1> well it goes into the failed graphics, do you want to reconfigure
<superm1> but reconfiguring just rewrites out an xorg.conf that doesn't specify the driver, so it will boot nv the next time still
<Kano> no vesa force mode?
<superm1> i didn't see that on the list of options in the failed graphics screen
<superm1> but i can of course switch to a vt, hand write in vesa and get things up
<Kano> did you try the old forcevesa option
<superm1> and that's what i did
<Kano> i think that also does not work
<superm1> i haven't tried xforcevesa in a long time 
<superm1> i'm not sure 
<Kano> i dont think it works
#ubuntu-x 2008-09-26
<bryce> tjaalton: are you around?  Do you have this bug on your X60?  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407188
<ubottu> Debian bug 407188 in acpi-support "Laptop gets stuck after sleep" [Grave,Closed] 
<tjaalton> bryce: yes, but it's a fairly recent regression, and tracked in bug 269884
<ubottu> Launchpad bug 269884 in linux "thinkpad x61 intermittently hangs on resume with 2.6.27-3" [High,Triaged] https://launchpad.net/bugs/269884
<Ng> bah, just had an X lockup unlocking the screensaver. I thought that was gone :(
<tjaalton> my kernel crashed during the session, after a successful resume
<Ng> erk
<Ng> I really hope the intel situation settles down at some point soon, there seems to be way too much changing for it to remain remotely stable :/
<tjaalton> we need intrepid users ;)
<Ng> tjaalton: the only people I can encourage to upgrade are all thinkpad users ;)
<crevette> tjaalton, Ng what do you want to test ?
<crevette> I'm a thinkpad user in intrepid
<crevette> s/in/on/
<Ng> I don't have anything specific, and I'm running Intrepid on a thinkpad - I meant that I don't know anyone else I can encourage to upgrade for testing purposes, who isn't on basically the same hardware as tjaalton or me ;)
<Ng> but I would like the X wedge on screensaver unlock to be fixed
<Ng> tjaalton: do you think this could be the same thing as the vblank thing which crashed it when activating the screensaver?
<crevette> I had my thinkpad recently, so Iwas always ion intrepid
<crevette> I just disable splash because irt caused problem
<Ng> by the point it crashes the display is on, I've typed my password and it's drawn the background, so it's kinda surprising that it gets stuck at all
<tjaalton> wgrant: see bug 274728, anything missing?
<ubottu> Launchpad bug 274728 in xserver-xorg-input-synaptics "Update the input properties API to current version" [Undecided,New] https://launchpad.net/bugs/274728
<wgrant> tjaalton: The only other things I can think of are g-c-c and g-s-d.
<tjaalton> wgrant: right, thanks
<wgrant> tjaalton: Did you also see that somebody replied that the new MaxTapMove default didn't fix multi-finger tapping for them?
<wgrant> But that my package did... I'm very, very confused.
<wgrant> Because the MaxTapMove change did fix it for me.
<tjaalton> wgrant: no, I've ignored synaptics for a couple of days :)
<wgrant> tjaalton: Probably a good policy.
<tjaalton> hehe
<tjaalton> wgrant: I think I found out why some synaptics users got errors from xinput.. the patch for xserver looks incomplete
<wgrant> tjaalton: Ah, that would do it! RAOF suffers from the problem, if you need a sane tester.
<wgrant> What's missing?
<tjaalton> wgrant: I'm not sure though, since the code is a mystery to me :) but it's in Xi/extinit.c. SProcIDispatch doesn't add the same stuff as ProcIDispatch does
<tjaalton> I'm backporting the changes and noticed that
<tjaalton> wgrant: hm, same thing with SReplyIDispatch
<wgrant> tjaalton: I'll be interested to see if this fixes it... do you have an ETA for porting the infrastructure?
<wgrant> And do we know how those bits were missed?
<tjaalton> wgrant: inputproto & libxi done, xserver WIP
<tjaalton> I've asked whot if they were left out on purpose
<tjaalton> waiting for a reply
<wgrant> tjaalton: Ah, excellent. I'll fix g-c-c and g-s-d tomorrow.
<tjaalton> wgrant: it's unclear if they get in beta
<tjaalton> but.. sooner the better
<wgrant> True.
<Kano> hi, which package is used to map the volume and other media keys to the XF86Audio symbols?
<tjaalton> in gnome? gnome-control-center
<wgrant> Doesn't that just map them to actions?
<seb128> tjaalton: no, GNOME doesn't map keysym to symbols
<tjaalton> oh right
<seb128> that's an xkeyboard-config thing rather
<tjaalton> I thought he asked about the shortcuts
<seb128> the GNOME dialog justs associations actions to those
<tjaalton> yep
<tjaalton> trust me, I've looked at x-c enough for the week ;)
<Kano> well i can do similar things with xmodmap, but where is it done with ubuntu or the lenny
<tjaalton> it's a complicated issue and no-one has the right answer :)
<tjaalton> but if the keys produce events, then xkeyboard-config just needs to support them
<Kano> well they are already supported, just the keys are not mapped by default in etch
<Kano> xmodmap -e "keycode 160 = XF86AudioMute" -e "keycode 174 = XF86AudioLowerVolume" -e "keycode 176 = XF86AudioRaiseVolume"
<Kano> these are the audio keys
<Kano> when i do that with etch the keys work
<tjaalton> ok
<Kano> in #nvidia the devs seem to sleep, nobody answered about my problem
<Kano> i guess they only test with tft...
<seb128> tjaalton: btw there is plenty if gnome-control-center keyboard bugs which are probably xkeyboard-config issues and could use a somebody having a clue to triage those
<Kano> ati x700 (rv410) is pretty bad supported too, but at least there is a pic
<tjaalton> seb128: ok, now we only need someone having the clue ;)
<seb128> tjaalton: you? ;-)
<tjaalton> <whistle>
<tjaalton> seb128: I believe all the "error activating XKB configuration" bugs are fixed in intrepid
<tjaalton> seb128: I'll have a quick look at them
<seb128> tjaalton: thanks
<jcristau> Kano: set the appropriate xkb model and the keys will work
<Kano> in etch? which one
<jcristau> the one that maps the keycodes to the right keysym for your keyboard
<Kano> why is the same config different when using lenny?
<jcristau> because it's not the same version of stuff
<jcristau> duh
<Kano> is it possible to backport it?
<Ng> hmm, I think it would be nice if X kept more than two log files
<Ng> if you end up bouncing into failsafe it seems like you can lose the log which might have useful information in it
<jcristau> failsafe may want to start with a different display number
<Ng> unless there are lots of vt changing bugs that might make that break more, it sounds sane, but even so i think keeping 5 or 6 would be a good idea
<Ng> it's not like they're huge files. other stuff in /var/log/will be much bigger and hang around for much longer
<Ng> (I say this because I just had it wedge on unlocking again and I had to ssh in from my phone to make sure I keep a copy of the log)
<tjaalton> if it could use syslog (with a nice prefix to distinguish different servers), then it would be trivial to use logrotate
<tjaalton> and some wrapper to filter the logfile out
<Ng> tjaalton: I think syslog is too old and broken for that to be much fun ;/
<tjaalton> Ng: syslog-ng then?-)
<Ng> tjaalton: I hate that thing
<Ng> mainly because it has "-ng" in the name, and so triggers irssi highlighting ;)
<Ng> but also it's still not all that great
<tjaalton> heh, ok
<tjaalton> I liked the syslogd in Tru64
<jcristau> i think debian switched to rsyslog as default for lenny. no idea how good it is though.
<Ng> it is a typical piece of unix idiocy that we have a central logging system that's unused by so many things :/
<Ng> because the thing is 800 years old and really stupid ;)
<seb128> did anybody there broke xvfb in intrepid?
<seb128> there is some uploads which ftbfs on "Xvfb failed to start" errors now
<seb128> hello, anybody around?
<mvo> tseliot: I get a debconf note about "obsolete NVIDIA driver" on my system that tells me that I need to install nvidia-glx-177 (also that one is installed already) - is that expected behaviour?
<tseliot> mvo: yes, we have to deal with the case in which users dist-upgrade from the command line
<tseliot> I'm always open to better solutions though
<tseliot> mvo: and of course the debconf warning will bug you only if you have a driver with the old name scheme installed
<mvo> tseliot: aha, ok. so I just ensure in update-manager that the oldnames get removed?
<tseliot> e.g. nvidia-glx, nvidia-glx-{new| legacy}
<tseliot> mvo: yes, right
<mvo> tseliot: thanks, adding that
<tseliot> mvo: ok, let me know if you need help with, say, X-Kit or nvidia common
<mvo> tseliot: I hope its all more or less ready, real-world testing is going to be the important next thing
<tseliot> yes, right
<jcristau> seb128: looks like Xvfb gets in an infinite loop trying to open swrast_dri.so which doesn't exist
<seb128> jcristau: likely something easy to fix? or should we rather disable the xvfb use for now?
<jcristau> don't know yet
<jcristau> seb128: you could pass -extension GLX, or build-dep on libgl1-mesa-dri, to work around it
<jcristau> hah. the client runs fine, then when it exits Xvfb tries to regen and loops.
<bryce> 274234 - wow, first evidence of the new failsafe-X usefulness
<jcristau> seb128: other option, have xvfb-run pass -terminate to Xvfb
<bryce> Ng: are you testing Intrepid?  the new failsafe mode writes its X session to Xorg.failsafe.log now
<seb128> bryce: could you look at fixing xvfb-run? it breaks build which are blocker fix for intrepid beta
<Ng> bryce: that's an exceptionally good point. The thing is I'm sure I've managed to hit a situation on my machine at home where it failed to start X on boot and eventually fell into failsafe, but when I rebooted and it started X properly, the original failure log was lost
<jcristau> seb128: looks like i tracked it down. not sure what the correct fix is, but.
<seb128> jcristau: me neither, and I would prefer to somebody who has a clue about xorg to decide about that ;-)
<Ng> bryce: will it try failsafe the first time the server fails to start, or could it have tried X a few times before running failsafe-X?
<seb128> I mean I would prefer having somebody fixing it rather than applying a workaround
<bryce> Ng: well if you can reproduce it I can take a look.  The change I made was about a week or so ago, so if your machine was running an older Intrepid, it might not have had the new feature
<Ng> bryce: I'll upgrade the machine over the weekend, but it's really hard to reproduce its problems, they're very random :/
<bryce> Ng: gdm normally tries to boot X three times in a row, and invokes failsafe only after that
<bryce> Ng, failsafe mode can be forcibly triggered by setting your driver to "foobar"
<jcristau> i'll try to talk to krh
<Ng> bryce: so if the first run failed and wedged the graphics card such that any further attempts failed for different reasons, you'd lose the original log?
<bryce> seb128: can it wait until monday?  I'm actually off work today and will be going away to the beach for the weekend
<bryce> Ng: hmm, possibly so
<Ng> bryce: I'm suspecting that's what happened, it seems to be very unhappy about running X again after it's screwed up once
<seb128> bryce: well, that means intrepid will not be installable until monday, bad timing, I'll workaround the issue in the applications using xvfb-run by commenting the calls
<bryce> Ng: well what you might do is shut down gdm and run it via startx, so it runs just once; then you can reproduce the problem and capture the log directly
<Ng> bryce: sure, this was more about the potential for losing valuable X logs than the particular brands of madness which infect the X4000 driver ;)
<Ng> bryce: I think it should rotate them a bit more and keep 5 or 6 :)
<bryce> hmm
<bryce> well, this seems like a pretty rare corner case, but probably wouldn't be hard to implement - mind filing a wishlist bug against xorg-server?
<Ng> ok :)
<seb128> jcristau: a build-dep on libgl1-mesa-dri would workaround the xvfb issue for sure? just pondering between doing that or commenting the call ;-)
<jcristau> yes, it would. as would passing -extension GLX, or -noreset, to Xvfb
 * seb128 read the xvfb-run manpage
 * mvo grumbles about the nvidia driver
<tjaalton> bryce: enjoy the beach :)
<mvo> oh, beach
<tjaalton> mvo: what now?-) (about nvidia)
 * mvo wants a beach as well - and icecream!
<mvo> tjaalton: it make my life difficult, I think I had both nvidia-glx-new and -177 installed, then I removed -new and I think that caused my kernel module to disappear (but I'm not sure about this, but the X log claimed it could not laod the nvidia module)
<tjaalton> mvo: urgh
<mvo> yeah, fglrx does not like me either, I have it removed (but not purged) and when I try to purge it the diverts fall all over
<mvo> but I'm too tired today to debug it further
<tseliot> mvo: weird, nvidia-glx-177 conflicts with/replaces nvidia-glx-new
<tjaalton> nothing a dash of Bowmore couldn't cure
<mvo> tseliot: strange, maybe it was nvidia-glx-legacy? I can't quite remember, but I can check the logs
<tjaalton> I'm still struggling with the properties backport for our xserver.. some bits missing
<tseliot> mvo: it's still weird. Have a look at nvidia-glx-177 Conflicts and Replaces
<tseliot> http://pastebin.com/d92c28be
<mvo> hm, right
 * mvo scrachtes head
<mvo> tseliot: aha! I think I have the reason, I purged nvidia-glx-new (when it was already removed) 
<mvo> hm, at least that is my theory
<tseliot> mvo: and what did that cause?
<tseliot> or where did it remove the module from?
<tseliot> mvo: the kernel module is not supposed to be in the lrm any more. Have a look  at /var/lib/dkms/nvidia/177.76/2.6.27-4-generic/i686/module/
<tseliot> or something similar
<mvo> I just looked at the postrm of nvidia-glx-new and there is nothing in it that could have caused this afaics - so maybe it was something different. I will try to reporduce it tomorrow or later tonight I think
<tseliot> ok
<tjaalton> oh cool, the xorg-server with current properties backported built successfully
#ubuntu-x 2008-09-27
<pwnguin> any ideas where to look for bug #155743
<ubottu> Launchpad bug 155743 in xorg "Gnome doesn't detect monitor rotations and rotate screen automatically" [Wishlist,Incomplete] https://launchpad.net/bugs/155743
<pwnguin> input-events on the lid device doesn't seem to offer much
<jcristau> pwnguin: hdmi spec, maybe..
<pwnguin> jcristau: ah, i was thinking in more general terms
<pwnguin> i have a tablet that might expose an acpi event
#ubuntu-x 2008-09-28
<Ng> pwnguin: acpi events should be logged to /var/log/acpid aiui
<alex_mayorga> hello, anyone that can help me get video back on this bug #146706
<ubottu> Launchpad bug 146706 in xserver-xorg-video-nv "[Hardy] Live cd graphics fail with nvidia geforce4 440 go " [High,Triaged] https://launchpad.net/bugs/146706
#ubuntu-x 2009-09-21
<tormod> tseliot, can you please sponsor bug 410058?
<ubottu> Launchpad bug 410058 in xserver-xorg-video-ati "Black screen with radeon KMS" [High,Fix committed] https://launchpad.net/bugs/410058
<tseliot> tormod: I would if I could. I'm not a core-dev yet. Sorry
<tormod> tseliot: I see. I thought you were stepping in for Bryce while he's away... tjaalton maybe?
<tseliot> tormod: yes, I'm filling in for Bryce but I have no upload privileges
<tormod> must be a bit frustrating :) you get all the complaints but can not fix it
<tseliot> yes, it is but I'm working on it ;)
<tormod> good luck!
 * tseliot hopes to become core-dev soonish
<tseliot> thanks
<tseliot> superm1: are you still awake?
<superm1> tseliot, i most definitely shouldn't be, but i am
<tseliot> superm1: can you sponsor tormod's fix, please?
<superm1> tseliot, sorry, can't right now, i dont have my gpg key with this machine
<tseliot> superm1: no problem, thanks anyway
<tseliot> mvo, seb128: can either of you sponsor tormod's fix, please?
<tseliot> http://launchpadlibrarian.net/32121459/xserver-xorg-video-ati_6.12.99%2Bgit20090825.fc74e119-0ubuntu2.debdiff
<tormod> tseliot: maybe try pitti
<tseliot> ok
<mvo> sure
<tseliot> ah
<tseliot>  thanks mvo
<mvo> does this needs to go into git too?
<mvo> I guess not :)
<mvo> but I want ot make sure
<tormod> I am not sure git is updated anyway
<mvo> ok
<mvo> uploaded
<tormod> thanks! btw there is no git tree for it
<mvo> cool, even better
<tormod> to what package should closed-source nvidia bugs be assigned?
<tjaalton> tormod: depends on the driver used, but nvidia-graphics-drivers-*
<tormod> ok, I just gave it to the -180 driver. Is there no common package, just to get it out of the way?
<tormod> tjaalton, btw, you haven't forgot that savage upload?
<tjaalton> nope. the "latest" driver should be renamed to just n-g-d for lucid
<tjaalton> tormod: hehe, not forgotten, just didn't get to it yet
<tormod> tjaalton, I thought you were not here, because your name is grayed out :)
<tormod> was
<tjaalton> I just happened to be "around"
<tjaalton> I do check this irssi-instance once in a while
<tormod> good to know :) are you in Portland?
<tjaalton> nope, Fin-
<tjaalton> :)
<tjaalton> tormod: savage uploaded
<tormod> tjaalton, thanks
#ubuntu-x 2009-09-22
<Ng> do we load i915.ko in initramfs? (my actual question is do we default to modesetting being enabled now, I just don't see anything for that in /etc/modprobe.d)
<Ng> (and would modesetting jump to the native mode of my laptop's panel, vs grub's 640x480 setting)
<tormod> Ng, yes see bug 392039. and yes it should pick the panel native mode
<ubottu> Launchpad bug 392039 in initramfs-tools "initramfs scripts hard-coded to load i915; blocks loading non-intel drm modules" [High,Confirmed] https://launchpad.net/bugs/392039
<Ng> k
<tseliot> Ng: no, we don't. Loading fbcon in the initramfs seems to be enough for me
<Ng> ah
<jcristau> loading fbcon without an actual fb driver won't do anything though
<Ng> so is modeset=1 just the default?
<tseliot> jcristau: hence the black screen on boot. KMS works well otherwise
<tseliot> Ng: yes, that's the default AFAIK
<Ng> ok
<tseliot> (At least in ubuntu)
<Ng> k
<tormod> tseliot, the above bug is not fixed, so the initrd does load i915, right?
<tseliot> tormod: if I load fbcon, then yes, I think it does. The resolution changes and KMS works
<tseliot> dmesg showed something about KMS but I should check again
<tormod> I am more thinking of what it does by default in karmic
<tseliot> currently it's not loaded in karmic by default
<tseliot> bug #431812
<ubottu> Launchpad bug 431812 in sysvinit "i915: black screen on boot---fbcon loading (screen powers off); breaks (recovery mode), fsck, usplash, crypt password" [Critical,Confirmed] https://launchpad.net/bugs/431812
#ubuntu-x 2009-09-23
 * bryce_ waves
 * virtuald do the helicopter
<mac_v> hi... is anyone noticing Xcrashes with the latest updates from xprg edgers.... in the past 2 days i have had ~10 crashes
<mac_v> it happens while switching workspaces by selecting the window from a cairo-dock window list
<mac_v> In ATI X1400 card
<mac_v> i use compiz and the desktop cube plugin , with the behavior set to Inside cube
<mac__v>  hi... is anyone noticing Xcrashes with the latest updates from xprg edgers.... in the past 2 days i have had ~10 crashes..In ATI X1400 card, it happens while switching workspaces by selecting the window from a cairo-dock window list...[ i use compiz and the desktop cube plugin , with the behavior set to Inside cube]
<mac__v> i havent yet noticed any crashes while using the workspace switcher... 
<diverse_izzue> mac__v, i have the same card and use the xorg-edgers ppa as well. no crashes here, but i'm not using cairo dock
<mac_v> diverse_izzue: i have this problem only since yesterday's xorg update... 
<mac_v> and there were no cairo-dock updates
<diverse_izzue> mac_v, i'll keep my eyes open, but i update my machine daily so i guess i have that update as well
<mac_v> libgl1-mesa-dev (7.7.0~git20090919.b8477f07-0ubuntu0tormod) to 7.7.0~git20090921.972e995b-0ubuntu0tormod
<mac_v> libgl1-mesa-dri (7.7.0~git20090919.b8477f07-0ubuntu0tormod) to 7.7.0~git20090921.972e995b-0ubuntu0tormod
<mac_v> libgl1-mesa-glx (7.7.0~git20090919.b8477f07-0ubuntu0tormod) to 7.7.0~git20090921.972e995b-0ubuntu0tormod
<mac_v> libglu1-mesa (7.7.0~git20090919.b8477f07-0ubuntu0tormod) to 7.7.0~git20090921.972e995b-0ubuntu0tormod
<mac_v> libglu1-mesa-dev (7.7.0~git20090919.b8477f07-0ubuntu0tormod) to 7.7.0~git20090921.972e995b-0ubuntu0tormod
<mac_v> xserver-xorg-video-ati (1:6.12.99+git20090919.da7487f6-0ubuntu0tormod) to 1:6.12.99+git20090920.97a4e747-0ubuntu0tormod
<mac_v> xserver-xorg-video-intel (2:2.8.99.901~git20090918.33f98e40-0ubuntu0tormod) to 2:2.8.99.901~git20090921.b4d29452-0ubuntu0tormod
<mac_v> xserver-xorg-video-radeon (1:6.12.99+git20090919.da7487f6-0ubuntu0tormod) to 1:6.12.99+git20090920.97a4e747-0ubuntu0tormod
<mac_v> xserver-xorg-video-savage (1:2.3.0-1) to 1:2.3.0-1ubuntu1
<mac_v> something from that messed it up ... :(
<diverse_izzue> same here
<diverse_izzue> i mean same versions here
<mac_v> diverse_izzue: could you install cairo-dock and test it out? :) [since you use ati too]... the crash happens at random, but only while selecting a window from a different workspace , the cube freezes midway during the switch and Xrestarts.
<diverse_izzue> mac_v installed it, so far cannot reproduce
<diverse_izzue> it doesn't paint transparently for me, but with black background
<diverse_izzue> are you using it with dri2/kms?
<diverse_izzue> besides it's ugly like hell :-)
<diverse_izzue> mac_v, ping
<mac_v> yeah thats the problem  , since ATI doesnt have proper OpenGL support
<mac_v> diverse_izzue: use the non-OpenGL version
<diverse_izzue> mac_v, but not even with the cairo setting it looks ok
<diverse_izzue> oh it does, sorry
<mac_v> it does crash?
<diverse_izzue> no it doesn't, all works fine
<diverse_izzue> are you running the new ati kms/dri2 stack or not?
<mac_v> diverse_izzue: it doesnt crash X at ever switch , but at random
<mac_v> but the crash is only during the workspace switch
<diverse_izzue> i'll let you know if it crashes for me
<mac_v> i'm not using KMS , since it has slower FPS 
<diverse_izzue> i know kms is quite a bit slower, besides resuming doesn't work for me
<mac_v> aw , crashed again!
<cwillu> what's up with gnome-power-manager asking for xorg patches? :p
<cwillu> is that actually going to happen, or is it just political intrigue?
<tjaalton> cwillu: there are no known patches that we don't have. the two are applied already
<tjaalton> as was replied on the bug..
#ubuntu-x 2009-09-24
<tseliot> jcristau: any plans to include libdrm 2.4.14 in Debian soon?
<jcristau> i haven't seen an announcement for that
<jcristau> pointer?
<tseliot> jcristau: http://cgit.freedesktop.org/mesa/drm/tag/?id=libdrm-2.4.12
<jcristau> i was more looking for an announce mail
<tseliot> I don't know why they haven't announced it yet
<tormod> macv, did you find out more about your crash yesterday?
<mac_v> tormod: i still get the crash , for now i'm using a workaround and not selecting the windows from cairo-dock
<mac_v> btw i'm using the cairo dock weekly ppa , that has optimizations for OpenGL stuff.... maybe that is causing this :(
<tormod> if Xorg is crashing you should get some backtrace in Xorg.0.log or the gdm logs
<tormod> but Xorg should not crash anyway, ideally...
<tormod> and since you know a good and a bad mesa version, it should not be too difficult to track down
<tormod> but now is mesa 7.6 testing time, so try that first :) in x-updates PPA
<mac_v> the edgers ppa has it or...?
<mac_v> oh x-updates... /me checking
<mac_v> tormod: will there be any conflicts with the x-updates and edgers ppa? , if i just disable the edgers and use x-updates , i should be good to go  ,right?
<tormod> mac_v, would be nice if you revert xorg-edgers using ppa-purge since the mesa 7.6 is built against stock karmic. see my post on the ubuntu-x ML
<mac_v> ah.. thought so... 
 * tormod waves to bryce
<tormod> what is exactly the mesa upload plan?
<bryce> heya tormod, what's up?
<bryce> tormod, btw been experimenting a tad with -ati+kms lately
<bryce> seems still a touch too buggy to switch on imho
<bryce> however quite a bit better than it used to be
<tormod> bryce, sorry I was out
<tormod> I have been running only ati w/kms for quite some time, I felt it was solid
<tormod> now only on a "dogfood diet", I realized that it is not on by default :)
<bryce> kees found an issue on r3xx where backlight does not work after doing suspend/resume
<bryce> I found an issue where if you vt switch, it doesn't show the console, just a static image of the X display, until you go back to vt7
<tormod> anyway, there is currently no huge advantage with dri2 (except all the redrawing fixes, and glxgears on the cube)
<bryce> but we need to come to a decision soon about go/no-go for kms on -ati if we want it in beta
<bryce> what are your thoughts?
<tormod> the flickerfree experience is not so much better I feel, at least on my card, the mode switching is pretty smooth on non-kms
<tormod> I am worried about suspend/resume as well. since this is broken anyway on my laptop, I haven't been able to test it
<tormod> but it is quite ugly how the redrawing is failing with compiz and dri1, like for instance moving glxgears window around
<tormod> I have to switch virtual desktop back and forth to redraw
<tormod> but I would prefer working suspend over such cosmetics
<tormod> I am not a gamer, so my testing is mostly compiz, gears :) and googleearth
 * bryce nods
<tormod> I have the feeling dri1 is smoother than dri2 on googleearth, but I have no metrics
<bryce> I imagine most hard core gamers will want -fglrx, and probably r6xx/r7xx anyway
<tormod> but again the flickering windows and failing redraws on dri1 looks really bad to anyone you'd ask on the street (who hasn't lived with mesa betas through the years)
<tormod> so dri2 can really be seen as a bug fix
<tormod> dri1 and compiz, that is (again)
<tormod> the real plus for dri2 is that it is worked on :) like in actively maintained
<bryce> does dri2 depend on kms though?  Can't we ship with dri2 with or without kms?
<tormod> but since we are so careful with post-release updates in Ubuntu that does not help us
<virtuald> tormod, do you know if they recompiled the radeon drivers yet? i don't want to run edgers until karmic is out
<tormod> virtuald, yes this was fixed
<virtuald> ok should i run ppa-purge something?
<virtuald> ppa-purge drivers-only?
<tormod> virtuald, thanks for reminding us of that bug, it is embarrassing how long radeon was partly broken
<tormod> blame it on us running xorg-edgers instead of dogfood
<virtuald> yeah
<jcristau> bryce: for radeon kms and dri2 come together
<tormod> ppa-purge <name of ppa> (rinse and repeat)
<bryce> jcristau, ah
<tormod> bryce, it will of course help us that we can cherrypick crititical dri2 fixes, whereas dri1 bugs will probably not get high priority upstream
<bryce> true
<bryce> tormod, will you be able to help with identifying patches we should pull?
<bryce> if we go forward with kms+dri2?
<tormod> there should have been a little applet where people can switch kms/not and it would update grub.cfg...
<bryce> I just worry my own time is going to be insufficient to stay atop bugs
<bryce> tormod, yeah that would have been sweet
<virtuald> is the radeon ddx in kramic som kind of stable branch?
<tormod> I do follow the git commits to a certain degree and hang out on the phoronix forum, so I guess I can help out some
<tormod> but I have no ambitions on spending more time on bug triaging than I do
<jcristau> virtuald: it seems to be a snapshot from master, so no.
<virtuald> ok
<bryce> hm
<tormod> it's a pretty old snapshot yes
<tormod> bryce, what about mesa?
<tormod> for ~ upstream support, I guess fedora is all kms/dri2?
<tormod> so we would not be alone going for dri2
<virtuald> will it be changed to a newer snapshot or something else?
<bryce> tormod, I liked your post you did a few days ago calling for testers.  I do think shooting for 7.6 is still in the cards
<bryce> although so far things have been a touch rougher than expected when we've updated, so we may have to make some tough choices there
<tormod> I am just vaguely insinuating that ati bugs in fedora get fixed faster than other stuff
<tormod> bryce, IMO we should have updated the snapshots more regularly
<bryce> tormod, yeah 
<bryce> tormod, me being off for the month hasn't helped I guess
<tormod> now we're in a situation of making a big change, or be stuck with a half-cooked non-release that upstream would hate us for
<tormod> but I mostly heard good things from people running xorg-edgers and 7.6 should be more safe than that
<tormod> so I don't see much risk with mesa 7.6
<tormod> for -ati, we should also update, but maybe not to head
<tormod> but if you look at the last month's git log, there is not much and nothing scary
<tormod> except "Merge branch 'r6xx-cs'"
<tormod> one tactic would be to take a snapshot just before that commit, and merge in the stable branch
<tormod> OTOH this merge only covers r600 so if we do not enable r600 3D it would not matter so much for us
<tormod> note that I have no experience/technical backing for calling it "scary", it is just one big change, and cs is in general scary :)
<tormod> on the whole, ati trunk can be considered "stable" ATM, very few commits the last 14 days
<diverse_izzue> my two cents on -ati with KMS and DRI2: i feel it's not ready for prime time. the issues i have is that resuming from standby is completely broken and that performance is quite a bit reduced. evolution for example is very sluggish with the new stack, so somehow 2D performance is quite affected.
<tormod> diverse_izzue, what card?
<diverse_izzue> radeon mobile x1400 on a thinkpad t60
<tormod> hm evolution should not be GPU-intensive. not good
<diverse_izzue> maybe i should run a gtkperf or something?
<diverse_izzue> the whole system feels sluggisher. also gnome-do's docky for example
<diverse_izzue> the suspend/resume thing has been filed as a bug on both launchpad and b.f.o but nothing happened so far
<tormod> yes, if s/r issues are common that would be a no-go IMO
<diverse_izzue> how much data do we have?
<diverse_izzue> as in, for how many users it works and for how many it doesn't
<tormod> I think we only have those "doesn't work" bug reports :)
<diverse_izzue> in a way, the situation is similar to -intel in jaunty. going forward makes people angry, but increases the changes that  by the next release things will be really solid
<tormod> if it was easy to switch it wouldn't be the biggest issue, just pick one and tell people they can try the other
<tormod> for kms or not, we can ship exactly the same code - just one setting to do
<tormod> so we're better off than in the -intel/jaunty case
<diverse_izzue> good point, though switching should be as easy as possible
<diverse_izzue> how responsive is upstream in fixing stuff and helping with debugging? if things bet bad during beta that might be an important point
<bryce> upstream is quite helpful, but they're limited in manpower (compared with -intel)
<diverse_izzue> also, how bit a part of the fixes would need patches to the kernel? i'm still confused about which parts of the stack are in the kernel and which are not...
 * tormod quickly reboots to check some ubuntu-boot updates
<tormod> from hanging out in #ubuntu+1, there seems to be a lot of -intel issues
<tormod> another day, 3 guys at the same time had stability issues (freezes)
<tormod> now there's one without drm loaded (known issue)?
<diverse_izzue> tormod, around?
<diverse_izzue> remember i said 2D performance with the KMS/DRI2 stack was much reduced for me? I have numbers for that now: gtkperf without kms takes 9 seconds for 100 tests, it's 30 seconds with the KMS stack.
<tormod> diverse_izzue, interesting!
<diverse_izzue> for the progress bar it's 20-fold
<diverse_izzue> that's the worst one
<diverse_izzue> text view scroll 10x
<tormod> what about we make a wiki table with the numbers and the card id?
<diverse_izzue> good idea, but not tonight - gotta sleep. i'll be around tomorrow and will happily contribute my numbers
<tormod> bryce, thinking about the dri1/2 switch: this would probably fit nicely and easily in jockey. now if someone wants a little project...
<tormod> diverse_izzue, what are the command lines you run?
<diverse_izzue> just installed gtkperf from the repos
<diverse_izzue> then it's all GUI
<diverse_izzue> ran all tests 100 times, then it outputs numbers
<diverse_izzue> see what it does for you
<tormod> ok
<tormod> how long does it take ca?
<diverse_izzue> 30 seconds total for kms
<diverse_izzue> 9 secs for non-kms
<diverse_izzue> all right. guet nacht!
<tormod> thanks, 12 second non-kms (M26). gn8
<tormod> versus 16 seconds for kms
<tormod> "/usr/lib/xscreensaver/glblur -fps" gives 0.7 fps, yay
<tormod> https://wiki.ubuntu.com/X/RadeonKMS
#ubuntu-x 2009-09-25
<mac_v> tormod , tseliot i get the crash with the x-updates package too
<tseliot> mac_v: with -ati and the new mesa?
<mac_v> yeah
 * mac_v checking logs
<mac_v> tseliot: what/where am i supposed to look for?
<mac_v> the xorg log has no time :(
<tseliot> can you ssh into that machine from another one, reproduce the crash and have a look at the log and at dmesg?
 * mac_v has only 1 linux system 
 * mac_v also not an ssh noob ;)
<mac_v> also a*
<cwillu> tjaalton, sorry, I did that thing where I ask a question and then drive around rural saskatchewan for two days
<cwillu> re: power management patches, I lost track of the bug number, as the notification stopped showing up even though the display still went in and out of power saving just like it has been.
<cwillu> The laptop had been on for a while though, I'll update and reboot again; basically ignore me until I post back on that bug saying it's still not working :p
<tjaalton> we know it's not working
<Turl> hi
<Turl> Do you currently see some splash on karmic shutdown?
#ubuntu-x 2009-09-26
<Duke`> hum I see a performance regression with the latest mesa xorg-edgers packages (intel i945)
<Duke`> I lose about 1/3 of fps on simple OpenGL applications
<Duke`> what happened to Sarvatt? I haven't seen him here for weeks
<bryce> Duke`, he seems to have disappeared; I've not seen him in a long time
<Duke`> :(
#ubuntu-x 2009-09-27
<lool> bryce: Can you push your latest xorg-server upload to git please?  :-)
#ubuntu-x 2010-09-27
<Sarvatt> bryceh: i think i found your dream video card - http://www.engadget.com/2010/04/30/powercolor-hd5970-eyefinity-12-makes-six-screens-yesterdays-new/
<Sarvatt> crossfire 2 of those bad boys :)
<RAOF> How many non-DP monitors can it drive?
<andrewaclt> RAOF, the issue I'm having is worse in the vanilla kernel, rather than unfreezing after 2-4 minutes, it stays frozen...left it for 30 minutes before rebooting.
<RAOF> Ok.
<RAOF> andrewaclt: I'd suggest popping up in #intel-gfx.
<andrewaclt> I'm more than happy to debug it and try and write a patch for it, but I'm over my head when it comes to xorg/gfx drivers.
<andrewaclt> RAOF, thanks
<RAOF> ickle's the man to talk to.
<andrewaclt> thanks
<ScottK> RAOF: I just accepted a kdebase-workpace upload the has some kwin fixes in it.  They are limited to fixes inside the blur effect, so I don't think it will have any impact on the changes you all have been pursuing, but FYI.
<RAOF> Ta.
<RAOF> ScottK: Want to test the new -intel that doesn't segfault on logout and actually works when you log in the second time?
<ScottK> RAOF: Yes, but probably not until my morning.
<RAOF> Cool.
<nigelb> g32
<RAOF> Anyone feel like some mesa & intel DDX sponsorship?
<mvo> RAOF: where is the diff?
<mvo> RAOF: I can do that
<RAOF> mvo: http://cooperteam.net/Packages/
<mvo> RAOF: looking now
<RAOF> Thanks muchly!
<mvo> RAOF: that "e30f0338" is directly applied and not a quilt patch is intentional, right? because you maintain the thing full-source in git?
<RAOF> mvo: Right.  That's the pkg-xorg way.
<mvo> ok, thanks. its fine, I upload now
<tseliot> mvo: are you migrating nvidia-173 and -96 to nouveau on dist-upgrades? Or are you only doing it for -71?
<mvo> tseliot: it will only migrate if no /usr/lib/xorg/modules/drivers/nvidia_drv.so is there anymore after the upgrade
<tseliot> mvo: that would work, as long as nvidia-173 and nvidia-96 are removed by the upgrade as they won't provide xserver-xorg-video-8. Can you confirm that this is what happens?
<mvo> tseliot: I can run a test upgrade with them, sure
<tseliot> mvo: that would really help. I just want to make sure that X is not removed
<OwaisL> hello X people... what is the state of Intel GM 965 and clutter? Anyone know?
<Sarvatt> that should be the most supported chipset with regards to clutter, but it is clutter.. :)
<OwaisL> so the bug is in clutter not the drivers..?
<Sarvatt> i'm not aware of any issues with that combination at the moment
<Sarvatt> what bug?
<OwaisL> well, mutter apps don't run on 965
<OwaisL> Unity, Shell
<OwaisL> they work if CLUTTER_VBLANK=none
<Sarvatt> do you have a bug on launchpad? 
<OwaisL> i think yes
<OwaisL> it's almost a year old
<OwaisL> there is another issue on Unity
<OwaisL> with 965
<Sarvatt> what distro? because 965 is well tested on current maverick
<Sarvatt> err what release rather
<OwaisL> the launcher crashes on a mouseover... but someone is working on it
<OwaisL> I'm on maverick.. with lastest updates
<Sarvatt> its most likely something odd with your specific setup, can you file a new bug on launchpad with ubuntu-bug xorg so we can see your logs?
<Sarvatt> the launcher crashing on mouseover is most likely a unity bug, but needing CLUTTER_VBLANK=none to start shouldn't still be happening at the moment..
<OwaisL> I don't think so.. I think lots of people have it.. I'll look for a bug on LP and file it if it is not there
<Sarvatt> RAOF: looks like your KDE problem has been around for a long time now.. http://ubuntuforums.org/showthread.php?p=9517771
<OwaisL> Sarvatt: while file should i attach? Xorg.log ?
<Sarvatt> OwaisL: if you just run ubuntu-bug xorg in a terminal it'll attach everything for you
<OwaisL> ok
<OwaisL> Sarvatt: Your gdm log files may help developers diagnose the bug, but may contain sensitive information.  
<OwaisL> what could it contain
<OwaisL> my login pass at most
<OwaisL> right?
<Sarvatt> no, thats not really true anymore, it contains your /var/log/Xorg.0.log as well as any console error output for GDM
<Sarvatt> it used to have ~/.xsession-errors that could have like the names of the mp3 files you were playing in it
<OwaisL> ahh
<OwaisL> not a problem
<Sarvatt> those logs are really helpful though, they have a deeper history of previous xorg.0.log's than x stores
<OwaisL> Sarvatt: here you go https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/648928
<ubot4> Launchpad bug 648928 in xorg (Ubuntu) "Cannot use Unity or Shell with Intel 965GM (affects: 1) (heat: 6)" [Undecided,New]
<Sarvatt> thanks OwaisL 
<Sarvatt> chrisccoulson: you're on gm965 right? are you having any problems starting unity with current maverick?
<chrisccoulson> Sarvatt, i've not tried it today
<chrisccoulson> one second
<Sarvatt> looks like https://bugs.edge.launchpad.net/ubuntu/+source/mutter/+bug/648625 is similar for the right click crash, people want to blame mesa but thats not mesa..
<ubot4> Launchpad bug 648625 in unity (Ubuntu) (and 2 other projects) "mutter crashed with SIGSEGV in g_strconcat() (affects: 1) (heat: 12)" [Undecided,New]
<chrisccoulson> Sarvatt, yeah, unity just crashes here
<Azelphur> Hi, someone told me it's possible to join 2 Twinview sessions together with xrandr to create one big screen without xinerama, is this possible? :)
<victorp> RAOF - been told by tseliot that you are the person to ask about a monitor problem I am having with 10.4
<tseliot> or Sarvatt (RAOF lives in Australia, therefore I think it's a little late there)
<victorp> ah ok!
<victorp> no ofense meant Sarvatt :)
<victorp> back in a sec
<jcristau> might be useful to say what the problem is rather than hope people will guess
<tseliot> he has a dell vostro 3300 with intel graphics, running 10.4 - and connected to an external monitor (via VGA) the external monitor is flickering/wavering constantly
<tseliot> I thought of a pipe underrun but there's no trace in the logs
<tseliot> dmesg: http://pastebin.com/nrNe7rQS
<tseliot> Xorg.0.log: http://pastebin.com/vZ3LNVvs
<jcristau> i don't think you'd get anything in the log if you don't enable some sort of debug option
<jcristau> even if it was pipe underrun
<victorp> back now
<tseliot> victorp: I have explained what kind of problem you are experiencing
<tseliot> jcristau: I thought he would have had something like this in the log: (EE) intel(0): underrun on pipe A!
<jcristau> tseliot: not on kms
<tseliot> jcristau: aah, right, kms. What level of drm debugging do you suggest?
<tseliot> 1 may be a bit excessive
<Sarvatt> 4 would have the equivalent
<tseliot> victorp: can you type the following command, please?
<tseliot> echo 4 | sudo tee /sys/module/drm/parameters/debug
<tseliot> as Sarvatt suggested
<tseliot> then "echo 0 | sudo tee /sys/module/drm/parameters/debug"
<Sarvatt> trying to find any bugs with the same issue
<victorp> tseliot - done, and now?
<tseliot> victorp: please pastebin your dmesg again
<tseliot> victorp: it should be more verbose now
<victorp> ok - so restart first then :)
<tseliot> victorp: why?
<victorp> tseliot - ok
<tseliot> victorp: it should be fine as long as you did as I told you while the external monitor was connected and flickering
<tseliot> I mean, the current dmesg
<tseliot> (without rebooting)
<victorp> http://pastebin.com/bQBZeU9b
<victorp> flickering all the time
<victorp> non-stop wave
<tseliot> victorp: maybe disable the external screen, then "echo 4 | sudo tee /sys/module/drm/parameters/debug", enable the external screen and let it flicker and finally "echo 0 | sudo tee /sys/module/drm/parameters/debug" and post your dmesg again
<Sarvatt> victorp: can you try with a newer kernel to be sure the problem isn't fixed upstream already and help narrow it down if so? http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc5-maverick/
<Sarvatt> found some upstream bugs - https://bugs.freedesktop.org/show_bug.cgi?id=28306
<ubot4> Freedesktop bug 28306 in DRM/Intel "[Arrandale] VGA output buggy (wavering/out-of-phase-ness)" [Major,New]
<victorp> Sarvatt - I am running 10.4 at the moment but I will upgrade to maverik today - then I can also try rc5
<tseliot> I think you can try that kernel in lucid too
<victorp> cant see it in the mainline
<victorp> you mean just use the same kernel build in lucid?
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=28858
<ubot4> Freedesktop bug 28858 in Driver/intel "[Arrandale] external monitor flicker" [Normal,Resolved: duplicate]
<Sarvatt> yeah you can just install the kernel there on lucid, the maverick part means its using the maverick kernel config options
<victorp> ok - I will try that now
<Sarvatt> victorp: Hmm, can you try running at a 75hz refresh rate resolution to see if it goes away?
<Sarvatt> oh he's gone
<victorp> sarvatt I tried the kernel you suggested and also Maverick beta from a CD still have the continous flicker
<Sarvatt> victorp: do you have any 75hz+ refresh rate resolutions available on the vga output? can you see if they work properly?
<victorp> they dont on 2.6.32  - would need to try 2.6.36 would that make a difference?
<Sarvatt> nah thats ok, saw someone in another bug saying 75hz+ worked fine on the lucid kernel so its not the same at least
<victorp> seem that 28858 was closed as a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=28306
<ubot4> Freedesktop bug 28306 in DRM/Intel "[Arrandale] VGA output buggy (wavering/out-of-phase-ness)" [Major,New]
<victorp> which seems still open?
<Sarvatt> yeah dupe isn't really closed, its still tracked on the open bug
<victorp> any thought? it seems that the bug has plenty of logs already
<Sarvatt> i'm at a loss, asking over in #intel-gfx, you may want to join there in case someone responds
<bryceh> Sarvatt, good god man
<bryceh> Sarvatt, 12 monitors?  drool...
<victorp> Sarvatt - any luck?
<Sarvatt> no nothing yet, I'm sorry
<victorp> no worries, let me know if something comes up
<Sarvatt> would anyone be willing to take a look at https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/649137 to see if it is sane? 
<ubot4> Launchpad bug 649137 in compiz (Ubuntu) "Compiz Sandybridge blacklist is no longer needed. (affects: 1) (heat: 6)" [Undecided,New]
<Sarvatt> sorry for all of the compiz uploads, we didn't decide to just disable DRI completely on them until recently in hopes it would be working in 7.9 like we were told
<bryceh> Sarvatt, what got blacklisted?
<Sarvatt> all sandybridge GPU's
<Sarvatt> i just blacklisted them in compiz so the desktop would come up but that only fixed ubuntu-desktop, intel was saying 3D would be working for the Q3 release (mesa 7.9) but it isn't going to happen so we disabled DRI completely on them
<Sarvatt> mesa 7.9 rc1 released
<Sarvatt> final due october 4th
#ubuntu-x 2010-09-28
<Sarvatt> RAOF: yay new one, Xv is completely broken on sandy bridge too :) I didn't know totem/rhythmbox render visualizations as a video
<RAOF> I thought they did it as GL calls? :)
<Sarvatt> me too!
<Sarvatt> http://sarvatt.com/downloads/totem.xtrace3.txt
<RAOF> Adapters generally don't support RGB inputs to Xv, though.  Is totem generating YUV data and throwing it through the Xv adaptor?
<Sarvatt> textured video sure as heck should support RGB formats? there's no overlay on these things
<Sarvatt> the desktop freezes but the cursor still moves when you try to use Xv and a reboot is required to recover, no hang though. disabling Xv in gstreamer-properties fixes it
<Sarvatt> would be nice if i could get intel-gpu-tools going on the things
<Sarvatt> Couldn't map MMIO region: No such file or directory when I run intel_reg_dumper, there's almost nothing in debugfs
<RAOF> You might expect that having the debugging tools work would be a high priority :/
<Sarvatt> I swear it worked at one point and stopped recently, because I remember looking at the IPS stuff and realizing it was all done in hardware now and those IPS drivers are only for arrandale/clarkdale
<Sarvatt> but that was on a different system, hmm
<Sarvatt> yeah that system is busted now too, will have to figure out where it was broken
<RAOF> Fun fun fun!
<bryceh> mm new -ati
<RAOF> Hm.  I see that âmake firefox less slowâ patch series landed.
<Sarvatt> ok I feel stupid, was looking in /proc/dri/0/ and of course stuff isn't there :)
<Sarvatt> mmm, juicy new 7.9-sandybridge updates to test. it looks like they might hold back Q32010 until sandybridge is in better shape going by #intel-gfx..
<RAOF> Yah.
<RAOF> I hope that makes your life easier ;)
<Sarvatt> rc1 released about 30 minutes after the 0924 snapshot got approved :)
<RAOF> Yeah, but there's not much new in theer.
<RAOF> â¦and rc1 doesn't build from the tarballs, anyway :)
<Sarvatt> oh man
<Sarvatt> nothing like reading a commit log for 5 minutes and looking back at the terminal to see mesa done building
<RAOF> You and your hex-core mega-systems :P
<Sarvatt> 260 package upgrades, that's some cramming for one day!
<RAOF> It's gnome release time!
<lulu> Hi, can someone help me to resolve the problem I have since updating to MM:visual effects in compiz cannot be enabled and the fan is louder.My graphic card is an ati 3200 and I run all the latest updates from MM.Thank you in advance.
<dandel> Sarvatt, any possibilities of packaging the new ati open source driver in x-swat testing repo?
<Sarvatt> dandel: thanks for the reminder, will get it up there today
<dandel> does not look like a lot of fixes in the driver from what i can see.
<Sarvatt> Dear Clutter, I can't possibly despise you any more. Love, Sarvatt
<Sarvatt> nothing clutter based is working on my 945 again after yesterday's updates, yay!
<bryceh> what got updated yesterday?
<Sarvatt> about 350 packages
<bryceh> ouch
<bryceh> isn't maverick in final freeze?  why so many updates?
<bjsnider> it's working well on nvidia though, so it ain't clutter
<Sarvatt> if nvidia used the same glx the rest of us do i might agree
<Sarvatt> freeze exceptions + all of gnome updated
<Sarvatt> yesterday the deadline for RC
<bryceh> ah
<Sarvatt> and yet again CLUTTER_VBLANK=none fixes it, it's just the apps I was trying dont pass that env var when launched on the command line
<Sarvatt> :\
<bjsnider> does that then result in desktop tearing?
<Sarvatt> CLUTTER_VBLANK=dri also works, just the default glx backend broken
<Sarvatt> * Users of Intel video cards should find that disabling sync-to-vblank  is no longer necessary. In case Clutter applications take really  long times for redrawing and appear stuck and unresponsive, the  sync-to-vblank feature might still be the culprit; in that case, use  "export CLUTTER_VBLANK=none" to disable it and file a bug reporting the  video card model, the driver version and the X server version.
<Sarvatt> i like how that was in the clutter 0.3 release notes and its still broken if you so much as sneeze in 1.4
#ubuntu-x 2010-09-29
<RAOF> Sarvatt: You say setting CLUTTER_VBLANK=none fixes it?
<Sarvatt> yup
<Sarvatt> has to be exported, quadrapassel and unity launched from a terminal dont accept clutter env variables
<Sarvatt> DISPLAY=:0 CLUTTER_VBLANK=dri mutter --replace --mutter-plugins=libunity-mutter works too
<RAOF> Whatâ½
<RAOF> My unity's working just fine, though.
<Sarvatt> tried your netbook?
<RAOF> Ah.  But there's a unity update installing now.  Are you suggesting that if I restart, I'll kill unity?
<Sarvatt> i upgraded everything last night and saw this this morning
<Sarvatt> about 24 hours hours ago
<RAOF> Ok.  Let's see if the new unity works here, thenâ¦
<RAOF> Yup.  Unity runs fine here.
<RAOF> Or is this only on nouveau that you find Unity fails to start?
<Sarvatt> netbook 945
<Sarvatt> i totally wouldn't be surprised if it was something local here screwing it up
<RAOF> Boo.
<RAOF> That would mean I'd need to restart my irc bouncer in order to get the i945 un-hidden.
<RAOF> Ah, ok.  That's why unsetting vblank would do something; it's dying in DRI2GetMSC, which I don't think clutter does if it can't vsync.
<Sarvatt> 0 luck figuring this out
<Sarvatt> if it wasn't made into such a big deal before it was fixed last i'd even start to believe it never worked at this point.. :)
<Sarvatt> anyone know if there is an archive of daily livecd's anywhere?
<Sarvatt> watch it be something wacky like a conf file that was exporting CLUTTER_VBLANK only getting cleaned up recently
<RAOF> Well, there _was_ that, as a part of the OMG! UNITY'S BROKEN firedrill.
<RAOF> I'm poking into the â(quadrapassel:3513): ClutterGLX-CRITICAL **: Unable to make the stage window 0x4800006 the current GLX drawableâ code; I think that's likely where the problem is.
<Sarvatt> that error has been spewed since the dawn of time though
<RAOF> I think there might be more of them than when it worked :/
<Sarvatt> quadrapassel has always done 3 for me
<Sarvatt> at least since early lucid when i started screwing with it
<RAOF> The problem *appears* to be that clutter calls GetMSC before there's a valid drawable bound to the context.
<Sarvatt> what I don't get is that mesa 20100909-0ubuntu3 doesn't work with it now
<Sarvatt> oh I should try 20100909-0ubuntu2
<RAOF> That would be interesting.
<RAOF> There's a plausible mechanism for that being useful.
<Sarvatt> phew, still debs up - https://edge.launchpad.net/ubuntu/+source/mesa/7.9~git20100909-0ubuntu2/+build/1962349
<Sarvatt> you wont want to hear this :)
<Sarvatt> oh not all rosy
<Sarvatt> 20100909-0ubuntu2 works with quadrapassel, and I'm wrong, theres 2 errors
<Sarvatt> gnibbles still needs CLUTTER_VBLANK=1 to start a new game
<Sarvatt> err CLUTTER_VBLANK=none
<Sarvatt> oh boy, mesa 7.9 rc2 pulled in all the sandybridge stuff
<RAOF> That's the sort of changes *I* like to see between rc1 and rc2!
 * RAOF was looking forward to pointing at a very small diff between what we've got an 7.9 final.  BA BAW!
<Sarvatt> you and me both! :(
<Sarvatt> time to break on dri2_bind_context and step through what happens between the second and the third ClutterGLX-CRITICAL message
 * Sarvatt goes insane holding enter again for hours
<RAOF> Does that sandybridge stuff work reasonably, at least?
<Sarvatt> hah!
<Sarvatt> actually it almost tries to work now
<Sarvatt> neverball plays, but the reflections on the ball are screwy
<bjsnider> why not just use less bleeding edge code if you are worried about it working with clutter?
<Sarvatt> swrast being 10x faster aside
<Sarvatt> because we're worried about stuff working at all too! :)
<RAOF> Because it (a) appeared to be working with clutter, (b) made unity work on radeon *at all*, (c) fixed KDE.
<bjsnider> is any of this an issue on nvidia?
<RAOF> No, of course not.  Nvidia doesn't use any of mesa.
<RAOF> There may be *different* problems on nvidia, but none of this will affect them.
<bjsnider> i don't think there are different problems, because i'm using clutter and it works fine
<bjsnider> are you saying mesa is a piece of garbage?
<RAOF> No?  Mesa has bugs; as does the nvidia driver code, and all other code.
<bjsnider> well, there are bugs, and then there are bugs
<RAOF> It's also possible that there's a bug in *clutter*.  After all, that was the problem with Unity.
<Sarvatt> what I've found with clutter is that if you aren't using the same mesa/xserver versions that are in moblin/meego when it's released you're going to have problems :) the glx/dri2 stuff is so volatile
<Sarvatt> well when an intel quarterly release comes out i should say. speaking of which i see clutter 1.4 just released
<RAOF> Yup.
<RAOF> Hm.  I think it's unlikely that 7244406093056108580 is going to be a valid X drawable...
<RAOF> Yeah.  That __GLXDRIdrawable's just garbage.
<RAOF> So, why is it still in the hash table?
<palhmbs> so the Numlock bug - has been fixed in Maverick?
<Sarvatt> http://sarvatt.com/downloads/quadrapassel.good.txt (git20100909-0ubuntu2) vs http://sarvatt.com/downloads/quadrapassel.bad.txt (current) from the X side of it
<RAOF> Hm.  Is it GetBuffersWithFormat that's dying?
<RAOF> Oh, no.  It died in CreateDrawable.
<Sarvatt> wow I implemented a lot more of DRI2 in xtruss than I remember - http://sarvatt.com/downloads/qpl-xtruss-bad.txt
<Sarvatt> ahh yeah i stopped messing with it because i couldn't wrap my head around how to extend it to add new events, wasn't designed for it from the start
<RAOF> Right.  So, the difference is that something's now trying to call DRI2CreateDrawable on an invalid drawable.
<RAOF> Bah!  glxHashDestroy != glxHashDelete
<RAOF> Ok.
<RAOF> So, what's happening appears to be: clutter calls glXMakeCurrent with the same context, and a different drawable.  This triggers MakeContextCurrent to call dri2_unbind_context, which treats oldGC == newGC specially by destroying the current draw & read drawables.
<RAOF> Now when clutter tries to bind those drawables to the context again, mesa doesn't have them and calls CreateDrawable on the GLXDrawable.  But the GLXDrawable isn't an X drawable, so this fails.  And thus we get our BadDrawable.
<RAOF> That's why reverting the new glx drawable GC fixes quadrapassel, at least.
<RAOF> Now.  What part of ^^^ isn't according to spec? :)
<RAOF> Let's see if this mesa build fixes it.
<RAOF> Sarvatt: http://pastebin.com/yqj5sKzr is a fix for mesa, and http://pastebin.com/nWqFiTRc is a piglit testcase for the problem.  I'm trying to stare myself into confidence that this won't introduce a memory leak, and talk to krh when he's around.
<mvo> tseliot: so I was trying to test the nvidia-173 upgrade, but I get "postinst failure with status 1" in the lucid image already :/ 
<mvo> tseliot: aha, so with the ubuntu desktop test profile I get further, lets see what it outputs
<tseliot> mvo: maybe it's failing to build the kernel module
<tseliot> and that's expected
<Sarvatt> RAOF: http://cgit.freedesktop.org/mesa/mesa/commit/?id=4b70fe8421f5132c585ff1dfb8d90229be26e71f
<Sarvatt> \o/ fixes quadrapassel and unity
<mvo> tseliot: both -96 and -173 upgrade in my test system. but I just noticed that the test is not that useful as nvidia-173 provides x-x-video-7, but x-s-core only breaks -6 and smaller (looks like a oversight)
<mvo> that -7 is not there
<tseliot> mvo: ah
<tseliot> Sarvatt: ^^
<tseliot> Sarvatt: maybe we should add xserver-xorg-video-7, as mvo suggests?
<Sarvatt> tough call, video 7 was only in maverick for a short time period, having the breaks on the video abi did *really* stupid things to the package manager like have it upgrade some metapackages but hold back X which made the next upgrade remove all of X
<tseliot> mvo: ^
<Sarvatt> but I guess it needs to be done to get those nvidia packages that dont work removed since they were never updated for ABI 8?
<tseliot> yep
<mvo> Sarvatt: I can test what will happen in a vm if that helps - ie. if the added breaks breaks the world
<Sarvatt> yeah that'd be a huge help because I never could work out why it was so broken and didn't add the breaks on purpose this time to not have a repeat of xserver 1.8 screwing everyone with the blob's X. want me to upload it to a PPA?
 * Sarvatt doesn't know how to override packages during a release upgrade to simulate what would really happen
<Sarvatt> the funny thing was having the breaks: actually made it decide to install nvidia-current with the old abi on non-nvidia machines too
<Sarvatt> there's a lot less impact now because its just nvidia-173, nvidia-96, x-x-v-glide and x-x-v-dummy providing that abi
<Sarvatt> surprised I haven't heard about fglrx being broken in x-updates from anyone if it is, just realized the 10.10 betas in maverick ship a x760 directory and lucid would need the ones from x750
#ubuntu-x 2010-09-30
<RAOF> Now.  Does this *still* crash X?  Who knows!
<RAOF> No!  Cool!
<RAOF> Oh, that does :(
<RAOF> Ensuring X doesn't crash would be more fun if testing didn't mean that X crashed :(
<ajmitch> at least when you find that X doesn't crash, you know you've done something right
<RAOF> Well, yeha.
<RAOF> Doesn't make the failure mode any less obnoxious :)
<RAOF> I'm looking for a sponsor for a tiny mesa upload to fix crashes in clutter apps with multiple stages like Quadrapassel - http://cooperteam.net/Packages/mesa_7.9~git20100924-0ubuntu2.dsc
<tjaalton> RAOF: check
<tjaalton> uploaded
<andrewaclt> hi, when I try and watch a movie (vcl or Movie player) xorg crashes it seems and it returns me to the login screen. The only thing funny in Xorg.log.old is "intel(0): drmDropMaster failed: Bad file descriptor." This started happening overnight :/
<andrewaclt> http://ubuntuforums.org/showthread.php?p=9907713#post9907713 describes my issue, if anybody is willing to take a look :)
<Sarvatt> andrewaclt: it's because you have drm_kms_helper.poll=N, that only works on a newer kernel and prevents the module from loading on the older one unfortunately
<Sarvatt> because the module parameter didn't exist back in 2.6.32
<andrewaclt> I see
<andrewaclt> So it's loading the wrong module?
<Sarvatt> it's not loading the module at all, if you remove that it should work again
<andrewaclt> I see, thanks.
<Sarvatt> no problem, sorry for not mentioning that when you were testing the newer kernel
<andrewaclt> Sarvatt, Thanks, I'm glad a asked here, otherwise that would of taken me forever to figure out :)
<Sarvatt> ugh, need to go through this mess of patches for xorg-server in maverick and see if one of them is the cause of server-1.9-branch failing to pass the tests now - http://launchpadlibrarian.net/56814698/buildlog_ubuntu-maverick-amd64.xorg-server_2:1.9.0%2Bgit20100930%2Bserver-1.9-branch.4d2542a1-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<ricotz> Sarvatt, hi, what do you think about adding kernel 2.6.36 to edgers?
<Sarvatt> would be much appreciated if you want to put it in there
<Sarvatt> are amd64 kernels building in PPA's again yet?
<ricotz> would takes some time to upload it for me, but the current natty kernel runs fine here
<ricotz> there is a commit which should solve this space issue
 * Sarvatt nods
<ricotz> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commit;h=2a96002816aec5f2dae290d473ee3620090088b0
<Sarvatt> it could get hairy for external module users since they aren't going to bump the ABI till natty opens
<ricotz> right, hmm
<Sarvatt> wont be that long though and its not installed by default unless we do a meta package too anyway
<ricotz> ok, i will upload it
<Sarvatt> hmm maybe http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.9-branch&id=d4ef63f602325a9920dc1cbf64e3969dfa394d5f really did break the xserver tests
<jcristau> there's a bugzilla about it regressing some stuff
<jcristau> https://bugs.freedesktop.org/show_bug.cgi?id=30267
<ubot4> Freedesktop bug 30267 in Input/Core "openarena mouse faliure since dix: don't create core motion events for non-x/y valuators" [Normal,Reopened]
<achiang> hello, which library provides this API - XkbChangeTypesOfKey() ; is it libxkbfile?
<vish> gah! why does something in stock always not work for me :( 
<vish> if i use the mainline kernels, i dont have problems with X :(
<jcristau> achiang: libX11
<achiang> jcristau: thank you. i have a bug with a test case
<achiang> jcristau: it's present in lucid and still present in maverick. i haven't gotten around to testing upstream yet, because i haven't figured out how to test the latest upstream
<vish> when did the drm changes land ? was that in .32-16 ?
<Sarvatt> vish: yeah but there have been quite a few updates since then with drm bits from .34 and .35 stable even. what's wrong now?
<jcristau> achiang: that function hasn't changed in years, it's either a server bug or it's not fixed upstream
<jcristau> achiang: so best to file your bug there imo.
<vish> Sarvatt: remember i had shown a video, of /only/ the guest session flickering?
<achiang> jcristau: i don't know much about this actually; i'm passing the bug along for a customer who discovered it. would you like to see the test case?
<vish> its been the same issue since then
<Sarvatt> radeon? the new_pll problem?
<vish> yup, thats the one
<jcristau> achiang: i wouldn't know what to do with it :)
<achiang> jcristau: or, i can just file an upstream bug, that's easy enough
<jcristau> xkb scares me.
<Sarvatt> they disabled new_pll on rv515 but i think you had a rv530?
<vish> i have RV515
<Sarvatt> oh maybe i had those backwards, or the proposed kernel with the fix isnt out yet
<vish> well, i'm on maverick :)
<Sarvatt> mainline .35.x works?
<Sarvatt> they ripped out new_pll completely in .36 afaik
<vish> i was using mainline maverick kernel on a lucid system, but now i'm fully on maverick stock
<vish> and still the same ol issue
<Sarvatt> sounds like the fix only got backported to lucid, and will come down from the next .35 stable update, let me make sure
 * vish files a bug again .. 
<vish>  i think the last one got duped to some other bug with the flickering..
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0d9958b18e10d7426d94cc3dd024920a40db3ee2
<Sarvatt> there it is  upstream, dont see it in ubuntu/ubuntu-maverick.git
<vish> Sarvatt: should i file the bug in kernel? or in -ati ?
<Sarvatt> its in 2.6.35.5
<Sarvatt> vish: it shouldnt even be needed, we'll get it free whenever the kernel can get updated next
<vish> Sarvatt: hehe, i tried waiting for this lucid last time :D , and maverick is here.. 
 * vish crosses fingers this time ;)
<Sarvatt> i know there's a 2.6.35-23 kernel in a kernel team ppa somewhere..
<Sarvatt> https://edge.launchpad.net/~leannogasawara/+archive/kernel-ppa
<Sarvatt> pretty sure thats intended to go in maverick before the release, or on the same day
<vish> cool!
<Sarvatt> at least you dont have an rv530, the need the same quirk and dont have it yet :)
<vish> :)
<vish> i need to check the new_pll quirk too! iirc, the last time what it did was delay the problem much longer..
 * vish tries ppa and makes sure.. ;)
<Sarvatt> wow people weren't kidding about the conservative governor being a lot better than ondemand in recent kernels
<achiang> Sarvatt: hm, where's a link to that train of thought?
<Sarvatt> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-September/012168.html
<achiang> Sarvatt: interesting thanks
<Sarvatt> it seems more willing to go into higher p-states for shorter periods of time and chrome feels more responsive because of it, of course it could be all in my head :)
<Sarvatt> things have been unbearably slow all throughout maverick here
<achiang> Sarvatt: but if you read through to the end of the thread, you see this: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-September/012176.html
<achiang> Sarvatt: well, mjg59 says "conservative takes longer to drop back to lower frequencies; So it's just about plausible; Depending on the workload..."
<mrooney> hey all, I'm testing Maverick and getting frequent X restarts when using the proprietary nvidia drivers, is there value in debugging the issue and filing a bug?
#ubuntu-x 2010-10-01
<achiang> is there something else i need to do while testing X clients inside a chroot? i've exported my DISPLAY=localhost:0.0, and issued an xhost + in the host as well
<achiang> ah, my X server is launched with -nolisten tcp
<RAOF> Right.
<RAOF> Because it is, by and large, a bad idea.
<achiang> RAOF: agreed but... i'm a developer? :)
<RAOF> You could bind-mount /tmp into your chroot (or just /tmp/.X0.whatever)
<achiang> RAOF: hm, and that means i don't have to restart my X server?
<RAOF> Indeed.
<achiang> thanks
<RAOF> That should allow apps in the chroot to access the local transport.
<achiang> ok, i'll try that
<achiang> RAOF: hm, i don't think that actually worked for me
<RAOF> Ah.  Sorry, it's been a while since I actually tried to run an X client in a chroot.
<achiang> http://pastebin.ubuntu.com/503617/
<RAOF> How about just DISPLAY=:0?
<achiang> ah ha!
<achiang> thank you
<RAOF> localhost:0.0 says âlet's go over TCPâ :)
<achiang> indeed, you're right.
<achiang> dinnertime
<jcristau> RAOF: bind-mounting /tmp shouldn't even be needed these days, since Xlib (well, libxcb) will try the abstract domain socket first
<RAOF> Oh, funkyi.
<RAOF> And now I know :)
<vish> Sarvatt: nope,  2.6.35-23-generic #34~pre201009220900-Ubuntu  , doesnt solve it either.. :(
 * vish tries with matching mainline..
<kamstrup> is there any way I can get the i945 driver to output some debugging info somewhere?
<kamstrup> i am debugging what seems to be a leak in Unity which may or may not be driver related
<tseliot> kamstrup: "echo 4 | sudo tee /sys/module/drm/parameters/debug" or, if you want an extremely verbose output in dmesg use "1"
<kamstrup> tseliot: awesome, thanks!
<Sarvatt> tseliot: http://www.nvnews.net/vbulletin/showthread.php?p=2326225 \o/
<Sarvatt> "@luk1don: I haven't forgotten about 96.43.*, I just haven't had much time to work on it lately. I'm hoping to get started on xserver 1.8 support soon, and xserver 1.9 support shortly thereafter."
<tseliot> Sarvatt: yes, we're discussing that over the phone
* You're now known as ubuntulog
<seb128> tormod, federico1: hey
<tormod> seb128, hi
<seb128> federico1, http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=67958ef6faab5797d5c5ad939db36f393706984a
<seb128> tormod wonders why that was required rather than letting xorg handle screen configs
<seb128> it seems some drivers are buggy and don't like xrandr calls
<tormod> that is not the problem I think
<seb128> why do you think it's not the problem?
<tormod> rather that g-s-d picks modes poorly
<seb128> hum, at least one of the bugs you replied to had correct modes
<seb128> but the radeon drivers just seems buggy
<seb128> tormod, well you are not coherent
<tormod> in bug 643118 xorg chooses the "preferred" mode but xrandr picks another one
<seb128> in your email you wrote 
<ubot4> Launchpad bug 643118 in gnome-settings-daemon (Ubuntu) "[RV350] Desktop corruption â Screen only shows vertical bands (dup-of: 640807)" [Undecided,Confirmed] https://launchpad.net/bugs/643118
<ubot4> Launchpad bug 640807 in gnome-settings-daemon (Ubuntu) "Forces low refresh rate on CRT monitor (affects: 6) (dups: 2) (heat: 38)" [Undecided,Confirmed] https://launchpad.net/bugs/640807
<seb128> "So IMO g-s-d should just leave it as
<seb128> it is or read out correctly what xorg has set up."
<tormod> that's not coherent?
<federico1> tormod: hey
<tormod> hi federico1
<federico1> tormod: I put in that patch to let OEMs tweak the RANDR configuration when the user first logs in
<federico1> so that they don't have to mess with xorg.conf, or patch g-s-d in strange ways
<tormod> federico1, but there should be a don't-touch option :)
<federico1> tormod: what do you mean?
<federico1> ah
<federico1> like
<seb128> federico1, they argue that the default should be "let xorg be smart"
<tormod> or alternatively, that patch is fine, but something else must be fixed
<seb128> because g-s-d is often buggy
<federico1> what is the exact problem?
<seb128> g-s-d seems to not know about xrandr preferred mode
<federico1> yes, it doesn't use that anymore
<seb128> federico1, well basically https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/640807
<ubot4> Launchpad bug 640807 in gnome-settings-daemon (Ubuntu) "Forces low refresh rate on CRT monitor (affects: 6) (dups: 2) (heat: 38)" [Undecided,Confirmed]
<seb128> https://bugzilla.gnome.org/show_bug.cgi?id=572502
 * federico1 reads
<ubot4> Gnome bug 572502 in libgnome-desktop "gnome-display-properties should pick the preferred xrandr mode" [Normal,Unconfirmed]
<seb128> I think is the same issue
<tormod> so there are two independent logics and sometimes xorg's work better than g-s-d's, right?
<seb128> well I'm not sure to understand why g-s-d picks the wrong one
<seb128> but I would be of the advice to let xorg alone by default
<seb128> ie not do any change from g-s-d if there is no config on disk
<seb128> or we could try to fix g-s-d
<federico1> ugggh, too many variables
<federico1> they are using nvidia's drivers
<tormod> there are also a lot to be fixed in xorg and drm :)
<federico1> and they are using a monitor with bogus EDID values
<seb128> federico1, I guess the first question is "why g-s-d needs to touch the video config after xorg by default"
<seb128> I understand that we want the option to apply a config
<seb128> or to force a mode with gconf keys
<seb128> but if we are not in those case it seems safer to just let xorg pick the config
<tormod> sounds sane
<federico1> seb128: because we don't know what xorg will give us, so we'd rather go to a known-good mode
<federico1> hmmmmm
<federico1> seb128: maybe you'd like a boolean use_boot_time_configuration meta-key
<federico1> or something
<tormod> doesn't xrandr tell you what xorg has set up?
<seb128> well why would you know better than xorg if there is no config on disk?
<seb128> you being g-s-d
<tormod> let's have a role play here :)
<federico1> because I don't trust xorg's startup values
<seb128> if those are wrong shouldn't we fix xorg?
<federico1> fixing xorg takes too long ;)
<federico1> so
<federico1> I'll happily include a patch that makes the boot-time configuration conditional
<federico1> with some use_boot_time_configuration key or something reasonably-named
<seb128> ok
<seb128> I was not sure if we should add a key or change the current one to be an int
<seb128> like 0 = let xorg alone
<seb128> 1 = force external monitor on
<seb128> 2 = force those off
<federico1> well, we have two keys right now; it gets a bit hairy to think what would happen with the 3x3 combinations
<tormod> are "we" upstream or ubuntu-specific?
<seb128> upstream
<federico1> upstream
<seb128> federico1, ok thanks, seems reasonable to me
<seb128> so add a key use_boot_time_configuration
<federico1> (it's not hard to think what *should* happen with the 9 combinations, but I'd rather spare the admin from having to think about that)
<federico1> seb128: yeah, that would be best, I think
<seb128> and then we can fix the g-s-d bugs which lead to pick wrong mode as well
<federico1> hmmm
<federico1> use_boot_time_configuration or use_xorg_configuration (the reverse)?
<federico1> I'd like it to be obvious from the key name that it's an either/or thing
<seb128> I'm not sure right now what you call boot time
<seb128> I think use_xorg_configuration is easier to understand
<tormod> but does it "use" any xorg conf, or just refrains from reconfiguring?
<seb128> it's not meant to be xorg.conf
<seb128> but as I understand it if the key was set it would do what g-s-d was doing before
<tormod> I did not mean "xorg.conf"
<seb128> ie letting the display config as xorg set it
<seb128> federico1, ^ right?
<federico1> yeah, correct
<federico1> i.e. by not touching the randr setup at all
<tormod> so is it a question of  "do-not-touch" or "do-initial-configuration" ?
<federico1> tormod: I'm leaning toward a do-not-touch kind of name now, with False by default - if you need to make it True, it means that you have a special case due to your X setup anyway
<tormod> I think use_xorg_configuration implies that g-s-d configures stuff actively
<jcristau> eww.
<seb128> let_xorg_configuration? ;-)
<tormod> but how do we solve these cases when this new default False makes it impossible for people to boot the Desktop CD?
<seb128> by debugging why g-s-d apply a wrong config
<tormod> is there any case where xorg is wrong and g-s-d is right?
<tormod> I would have left do-not-touch default to True, and switch it if the user reconfigures his settings
<jcristau> tormod++
<tormod> I think "special cases" is more widespread than you might think, ask any xorg developer
<tormod> well, we'll see now that the RC is out :)
<seb128> seems fine to let xorg alone by default 
<seb128> that's what I suggested in my email
<seb128> let xorg alone if no config is on disk or key set
<bryceh> seb128, agreed
<seb128> tormod, I will let you reply to the bug or email
<seb128> I think that's a plan of action
<seb128> doing a patch to add this "let_xorg_config"
<seb128> which we can set to true by default
<seb128> upstream can decide to set to false if federico1 disagrees
<seb128> I need to run, I'm already late
<bryceh> heya federico1
<seb128> see you later
<tormod> thanks seb128
<jcristau> sadly monitor resolution is not the only place gnome does that. :(
<tormod> I am sure we can make federico1 agree :)
<federico1> hey mister bryceh
<federico1> tormod: well, xorg has fed us such shitty defaults in the past that I don't want to lose the client-side workarounds
<federico1> not that *anything* is well-documented, though...
<jcristau> you don't know whether something is the default or what the user explicitly set up in xorg.conf
<tormod> federico1, optional workarounds are fine, but trashing all the work that went into xorg logic would be stupid
<jcristau> so if you don't have an explicit config imo you should leave things alone
<bryceh> federico1, I've been thinking what we need is a big huge truth table of expected behaviors for different situations
<jcristau> and it's not like fixing things up in the right place is hard
<jcristau> xorg takes patches..
<bryceh> federico1, so for instance, if a user boots an unconfigured system with two identical external monitors, it should do dual head.  but a lvds + projector would behave differently
<federico1> jcristau: I'm sure they do; the problem is getting the patches written :)
<federico1> like
<jcristau> federico1: if you can write them for g-s-d you can put the same logic in X..
<federico1> in RANDR 1.3 the spec was updated to say that all drivers should export a ConnectorType property
<federico1> but as of today, only radeonhd actually exposes that property
<federico1> I filed bugs for each driver independently - none are fixed yet
<federico1> bryceh: sounds interesting!
<bryceh> federico1, I mean, regardless of where its implemented, the expectations are going to be consistent
<federico1> bryceh: hmm, do we have a way to actually detect projectors vs. monitors?
<federico1> maybe "if $output can only do 1024x768, it's probably a projector"?
<bryceh> federico1, physical dimensions = 0mm x 0mm?  ;-)
<federico1> could be
<federico1> bryceh: if you play with it, I'd be very happy to see that
<federico1> I wonder what projectors say for the vendor in EDID
<bryceh> anyway, several times now I've seen where there has been an undocumented assumption about how two monitors should be automatically laid out, and it doesn't account for some corner case
<bryceh> but having both xorg and gsd trying to be smart seems to result in weird results, maybe some toe stepping such as in this case, etc.
<bryceh> federico1, another perhaps better example is whether LVDS should be blanked if there is an external monitor
<bryceh> i.e., is that what we expect to happen when we connect an external monitor, or a bug?
<federico1> bryceh: yeah, that needs some connection with external policies... if you close your lid while an external monitor is connected, does that mean "I only want to use the external one" or "suspend the laptop and let me turn off the monitor by hand"?
<federico1> (plus, docking stations are a bucket of fail)
<federico1> someone needs to sit down and write down all the cases
<bryceh> federico1, exactly... so many questions for all these different configs, and I don't know if it's documented anywhere what the *expected* behavior is for those. 
<federico1> there *is* missing infrastructure for lids and docking stations; I was talking to mjg59 the other day about this
<bryceh> regardless of where the configuration is actually done, having that written down would do a lot to help to ensure it gets implemented right, and would enable testers to be more effective at reporting discrepancies
<federico1> yeah
<tormod> should I mark the bug in progress and/or assign it to someone?
<federico1> tormod: no idea; is seb128 writing the patch or something?
<federico1> bryceh: if you blog about this, I'll link it from my blog - it's important stuff and we need testers
<federico1> (or people with funky setups)
<tormod> federico1, it sounded like he would do it, no?
<federico1> yeah, that's what I thought
<tormod> I'll assign him so he does not forget ;)
<tormod> d*mn I can't, where did my lp superpowers go :)
<bryceh> oh yeah, assigning to others was disabled in launchpad.
<bryceh> was too much abused
<bryceh> tormod, but I should be able to do it, what was the bug #?
<tormod> 640807
<bryceh> done
<bryceh> I think you have to be a member of the team that is driver for the package or something
<vish> Sarvatt: hi, that patch seems not need for the guest session flickering bug..
<vish> Bug 652934
<ubot4> Launchpad bug 652934 in xserver-xorg-video-ati (Ubuntu) "[RV515] Guest session causes screen to flicker violently and session is unusable (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/652934
<vish> Sarvatt: i'm using the older mainline kernel Â»  2.6.35-02063504-generic #201008271919  and it seems to not give the issue
<vish> will test for longer â¦ :)
<vish> needed*
<Sarvatt> sheesh, the kubuntu plymouth splash blows the ubuntu one out of the water :)
<Sarvatt> vish: ugh, so its broken on the ubuntu kernel but working on the mainline one?
<vish> Sarvatt: yup
<Sarvatt> and that was the case even back in .33? so it's something we've carried over breaking it..
<vish> yea, even with .33 mainline i never had problems
<vish> Sarvatt: kubuntu plymouth is better??
<Sarvatt> no comparison, it looks so much better
 * vish oh googles for videos!
<Sarvatt> background behind the logo is a nice gradient
<vish> oh! no videos up yet ;p
<Sarvatt> kay, trying to view it in a VT isn't a good idea :)
#ubuntu-x 2010-10-02
<BUGabundo> evening
<BUGabundo> or mid night
<BUGabundo> having a bunch of probs with video playback
<BUGabundo> across all video players
<BUGabundo> seems to have gotten worse around 2 weeks ago
<bjsnider> has to be a nouveau issue if it's all players
<BUGabundo> audio / video gets out of sync, and I experience lots of slowdownds
<BUGabundo> using nouveau with 3D experimental support, as indicated by Sarvatt
#ubuntu-x 2010-10-03
<gzed> any how-to to activate gallium nouveau on maverick? xorg-edgers ppa doesn't contain the libgl1-dri-gallium package for maverick...	
<tjaalton> gzed: aiui it's in maverick already, libgl1-mesa-dri-experimental package
<gzed> ok, gonna try it out, thanks
<gzed> hmmm
<gzed> ls /usr/lib/dri/gallium/
<gzed> i915_dri.so  r600_dri.so  swrast_dri.so
<gzed> no nouveau in there
<tjaalton> it's in /usr/lib/dri
<gzed> aren't those the classic mesa drivers?
<tjaalton> not necessarily
<tjaalton> hmm
<gzed> I think you're wrong
<tjaalton> maybe
<gzed> I used to have a /usr/lib/dri-gallium directory under lucid
<tjaalton> the packaging has probably changed since
<gzed> not until yesterday
<gzed> I upgraded to maverick this morning...
<tjaalton> well maverick has been in development since may
<tjaalton> checking the packaging now
<tjaalton> ..which is slow since a lot has changed since I touched mesa last :)
<gzed> :)
<gzed> never mind, I think I'll have to build from git to get to play with it again
<tjaalton> it is the gallium driver btw
<tjaalton> just installed in /usr/lib/dri so it's actually used by default
<gzed> running the closed blob right now... :(
<knittl> hey. i don't see any drivers in jockey
<knittl> can i help troubleshoot?
<tjaalton> you don't have nvidia-*-modaliases installed?
<tjaalton> or the hw is too old
<knittl> tjaalton: modaliases are installed, hw is 2 years max
<knittl> now i can see drivers
<knittl> but i bet it fails
<knittl> like everytime
<knittl> :(
<knittl> i will paste the logfile, gimme a minute
<knittl> tjaalton: http://paste2.org/p/1016479
<knittl> i emptied it before logging in and starting jockey
<tjaalton> fails how?
<tjaalton> it got installed
<knittl> what's the last error then?
<knittl> it also says now in jockey: a different version of this driver is in use
<tjaalton> dunno
<knittl> i try to restart, brb
<knittl> there's no xorg.conf though. is that ok?
<tjaalton> there's 256.53-0ubuntu3 available btw
<tjaalton> yes
<tjaalton> well, no
<tjaalton> not with nvidia
<knittl> so why doesn't jockey create it?
<tjaalton> no idea
<knittl> so maybe it is failing?
<tjaalton> the error is because it's trying to create an alternative link for a file which only the 64bit package includes
<tjaalton> which itself is a bug in the package, but shouldn't be fatal
<knittl> also
<knittl> does not currently work with xserver 1.9
<knittl> is an interesting error
<tjaalton> but why doesn't your mirror have the latest files?
<tjaalton> no
<knittl> line 10 â 16
<tjaalton> thats for the old driveres
<tjaalton> -e
<tjaalton> -96 and -173, which don't support the new abi
<knittl> installing nvdia-current by hand, then nvidia-xconfig works
<knittl> so i only have problems getting jockey to work
<tjaalton> xconfig should work just the same if it was installed via jockey
<knittl> and since jockey is the recommended way it's sad :(
<tjaalton> then file a bug
<tjaalton> maybe the error is fatal for jockey
<knittl> maybe, i don't know
<tjaalton> so it doesn't create the conffile when installing on a 32bit system
<knittl> but then it would be fatal on every non-64bit system
<tjaalton> file a bug against nvidia-current..
<tjaalton> yes
<knittl> jockey even says it failed installing, i should see the log
<tjaalton> this wasn't the logfile?
<knittl> the paste? it was /var/log/jockey.log
<marcog> hey, i just upgraded my netbook to maverick and got the exact same problem as this: http://ubuntuforums.org/showthread.php?t=1587153
<marcog> any ideas on how to fix?
<knittl> also, standby does not work on my system with nouveau
<knittl> i'd use it instead of nvidia, but no standby is a no-go
<marcog> anyone? to summarise, i get a blank white screen after logging in
<knittl> using gitk, vlc, blender, ding (i guess xlib) applications will crash my xserver, when using xinerama â¦
<knittl> any pointers?
<tjaalton> buggy nvidia?
<knittl> probably
<bjsnider> knittl, the errors listed on lines 779 and 780 are supposed to happen on i386. there is no way around it because dpkg doesn't support multi-arch yet
<knittl> hmmm
<knittl> well, it still fails while installing
<knittl> and i cannot remove it using jockey
<knittl> using nouveau now
<knittl> no standby <<< xserver crashes
<tjaalton> bjsnider: it's still a bug that it tries to add an alternative for a file that doesn't exist
<tjaalton> and seems like it breaks jockey
<bjsnider> the messages in that log specificaly say that the nvidia alternatives are being used and the kernel module is installed
<bjsnider> so it worked
<tjaalton> the install yes, but jockey still fails
<bjsnider> i don't understand the distinction
<bjsnider> if hte user rebooted it would work fine
<tjaalton> it's not the nvidia install that creates xorg.conf
<bjsnider> i mean maybe it didn't create the correct xorg.conf file?
<tjaalton> but jockey
<tjaalton> exactly
<bjsnider> well then it's been broken the same way going back to lucid
<tjaalton> maybe, or maybe jockey is being more picky in maverick
<knittl> jockey says it failde
<knittl> bjsnider: no it doesnt
<knittl> rebooting will not work properly, because no xorg.conf is generated
<bjsnider> that should be listed as a jockey bug if anything
<tjaalton> it's a packaging bug in nvidia..
<tjaalton> at least
<bjsnider> how would you suggest it be ffixed?
<tjaalton> not add             --slave #VDPAUDIR32#/libvdpau_nvidia.so.1 libvdpau_nvidia.so.1_lib32 #PKGVDPAUDIR32#/libvdpau_nvidia.so.1 \
<tjaalton> ..for the 32bit package
<bjsnider> the nvidia-current postinst script specifically says that error message will occur on i386 and it is inconsequential
<bjsnider> so it's not like it's a suprise that it's happening
<tjaalton> well, maybe mvo will decide which one is wrong ;)
<tjaalton> I don't see why including known(!) errors in a package is desired
<bjsnider> it may be impossible to get around
<tjaalton> no it's not
<bjsnider> i don't see why you can't just do i arch=i386 then
<bjsnider> you can always test for the arch
<tjaalton> that's the .in file, with a lot of variables that are replaced with real values, so there's no reason it couldn't check the build architecture too
<bjsnider> but it's been in there going back to lucid and it wasn't stopping i386 installs. so why is it a showstopper now?
<tjaalton> like I said, jockey probably got changed
<knittl> it didn't work in lucid for me either
<bjsnider> for the same reason?
<knittl> i guess. i don't know the reason
<knittl> that was when nvidia-current was introduced
<bjsnider> were you trying to use it on i386 then as well?
<knittl> yes
<knittl> it's the same system, only upgraded
#ubuntu-x 2011-09-26
 * ara hugs RAOF for working on bug 824099 :)
<RAOF> It's not so much a fix as a "please don't do that, use Unity 2D if you want to span your displays". :/
<alkisg> Hi, I've a lab of computers where the graphics card uses the pm2fb.ko module. The videoram is 4 MB, but only 512 KB are detected.
<alkisg> I tried forcing VideoRam in xorg.conf, but it made no difference
<alkisg> Would trying a newer kernel help? What else can I try?
<RAOF> alkisg: Is that permidia?
<RAOF> Old school!
<alkisg> RAOF: yes, and yes
<alkisg> Too old, but unfortunately that school can't afford the change
<alkisg> I'm trying to install the backported natty kernel (using lucid)
<RAOF> xorg.conf isn't going to have any effect; that's a kernel framebuffer driver - there is no X driver involved.
<alkisg> If anyone has some other ideas I could try...
<alkisg> Ah
<RAOF> Or, rather, there's an X driver involved, but it's just a dumb FB driver.
<alkisg> Isn't there any way to force X to use a particular mode even though it thinks there's not enough videoram for it?
<RAOF> No.  X isn't setting the mode at all.
<alkisg> (the school had windows previously, cards worked fine there)
<jcristau> you can try playing with fbset
<ara> RAOF, good to me. Right now it is: do what you want but your display will look awful 
<jcristau> or hacking up your kernel driver
<RAOF> You *might* be able to pass some kernel module parameters to that module.
<RAOF> alkisg: parm:           mode_option:Initial video mode e.g. '648x480-8@60' (charp)
<alkisg> I tried `modinfo pm2fb` but I didn't see any options... ah that one
<alkisg> Let's see if it can use it even though it thinks it doesn't have enough ram
<RAOF> ara: Yeah.  Or, in my case, be software rendered on the *super fast* atom processor, for a blazing 30 seconds per frame performance.
<RAOF> Let's see if this works...
<alkisg> jcristau: I tried `fbset` and it says "cannot open /dev/fb0"
<alkisg> trying to pass mode_option in the command line...
<jcristau> err
<jcristau> if you're using pm2fb.ko surely you have a fb device...
<alkisg> I'm using LTSP, and that's a thin client, but I don't think ltsp would interfere with that... :(
<alkisg> Is this a correct syntax?  initrd.img ...  mode_option:1024x768-16@60 
<jcristau> no
<alkisg> Here are some files from the client: http://paste.ubuntu.com/697123/
<alkisg> xorg.log, cmdline, modinfo etc
<alkisg> ls -l /dev/fb* says file not found
<jcristau> well pm2fb is not loaded
<jcristau> so clearly you're not using that
<alkisg> I'm reporting what `lspci -nn -k | grep -A 2 VGA` told me: Kernel modules: pm2fb
<jcristau> yes, that means pm2fb could drive that hw
<jcristau> otherwise it would tell you Kernel driver in use: $something
<alkisg> Ah. modprobe pm2fb indeed loaded the module now
<alkisg> And I have an /dev/fb0 now
<alkisg> jcristau: a big improvement, thanks. After manually loading pm2fb, I got X at 640x480
<alkisg> Any advice on how to force that to 1024x768?
<alkisg> Will running `fbset params` before loading X help?
<jcristau> i don't know.
<alkisg> Thank you though. Could you help me for the correct syntax on the mode_option parameter?
<alkisg> (11:12:41 ÏÎ¼) alkisg: Is this a correct syntax?  initrd.img ...  mode_option:1024x768-16@60 
<alkisg> (11:14:33 ÏÎ¼) jcristau: no
<alkisg> *could someone help me...
<tjaalton> http://www.linuxdoc.org/HOWTO/Framebuffer-HOWTO/x168.html
<tjaalton> see the part about permedia
 * alkisg reads, ty...
<alkisg> Phew that was a difficult one to do via VNC! After all the troubleshooting, I solved the problem by putting the following in my LTSP lts.conf configuration file:
<alkisg> MODULE_01="pm2fb mode_option=1024x768-16@75"
<alkisg> Thank you all for your help, yet another school just moved to Ubuntu/LTSP. :)
<mdeslaur> Hi X hackers...any known workaround for bug 858450 ?
<tjaalton> bug 858450
<tjaalton> huh, no bot
 * mdeslaur is saddened by bot's suicide
<tjaalton> mdeslaur: uh, I understand how annoying the bug is..
<tjaalton> as a quick test I can only suggest trying a 3.1rc mainline kernel
<mdeslaur> tjaalton: do we have a mainline ppa somewhere?
<tjaalton> mdeslaur: yes http://kernel.ubuntu.com/~kernel-ppa/mainline/
<mdeslaur> tjaalton: ah, thanks!
<tjaalton> mdeslaur: i don't have working ati-gear here, so haven't seen bugs like that myself. maybe others on this channel have though
<mdeslaur> tjaalton: thanks
<kamstrup>  I almost assume that it's a known issue, but I can't find it in LP: my integrated intel graphics hd 3000 (sandybridge) no longer works (no glx). This worked smoothly ~1 month ago... ?
<kamstrup> I am not 100% sure where the regression happened because I normally use the discrete nvidia card on my laptop, but decided in a fit of adventurousness that I wanted to try the integrated intel again yesterday...
<kamstrup> (so just to make it clear optimus is disabled in the bios, so it's not running hybrid, just pure old intel graphics hd 3000)
<Sarvatt> you have to remove the nvidia driver
<tjaalton> right
<kamstrup> ah, ok
<kamstrup> thanks Sarvatt, tjaalton that helped :-)
<Sarvatt> kamstrup: you can do it without removing it if you plan on doing it a lot also
<Sarvatt>  sudo update-alternatives --config gl_conf (pick mesa instead of nvidia)
<Sarvatt>  sudo ldconfig
<Sarvatt>  sudo update-initramfs -u
<kamstrup> Sarvatt: yeah, it might be helpful for testing out Unity performance
<Sarvatt> (then reboot)
 * kamstrup stores a note
<Sarvatt> same thing picking nvidia again to go back
<tseliot> kamstrup: if you're using oneiric you might want to replace "gl_conf" with  either "x86_64-linux-gnu_gl_conf" (on Ubuntu 64bit) or "i386-linux-gnu_gl_conf" (on 32bit) 
<kamstrup> tseliot: ah, that's also way easier mnemotechnically ;-)
<tseliot> kamstrup: I'm on Ubuntu 64bit and simply type update-alternatives --configure x86 and then I press TAB for autocompletion since I can't remember the whole string
<kamstrup> Long live tab completion :-)
<tseliot> :)
<alkisg> Yeah I started using it on norm<tab> senten<tab> too. Unfor<tab> it doesn't work :(
<kamstrup> yeah, i kn
<bjsnider> since when does optimus work on linux?
<kamstrup> bjsnider: it "works" if you disable it in the bios ;-)
<bjsnider> no, you said you normally use the nvidia chip exclusively
<tjaalton> ironhide works somewhat
<kamstrup> bjsnider: exactly
<kamstrup> bjsnider: disable optimus, using only the discrete card
<bjsnider> i see
<bjsnider> you're lucky your craptop gives you that option
<bjsnider> a lot of them don't let the user have that much control over the graphics setup
<kamstrup> bjsnider: wow, I'd actually expect one to be able to deactivate the hybrid mode in the bios, and at least use the integrated card in a dedicated way
<kamstrup> even on cheap hardware
<kamstrup> ignorance is bliss
<bjsnider> i've talked to people recently who say they've been through the bios and there is no such option
<bjsnider> i would think that would make it very hard to buy a laptop if you intend to put linux on it
<shadeslayer> hey, anyone have a idea how to get my intel i915 kernel module working? I get : *ERROR* drm/i915 can't work without intel_agp module!
<shadeslayer> i have a seprate discrete graphics card, but i'd like to power that down and just boot using the intel agp
<ricotz> Sarvatt, hi, are you ok with if i just copy the cairo packages with its current version string to edgers?
<Sarvatt> ricotz: yup!
<ricotz> Sarvatt, done ;)
#ubuntu-x 2011-09-27
<cnd> bryceh, where did the sun go?
<cnd> this wasn't the weather I was promised...
 * cnd wonders if the sky has a 30-day return policy on weather
<bryceh> cnd, hey you'll recall I've been promising rain!
<bryceh> cnd, really it'll mostly be cloudy with occasional rain here on out through the end of the  year
<bryceh> jan-apr is when the rain gets really intolerable
<Sarvatt> cnd: have you tried edgers xserver 1.11 by any chance? unity hasn't worked in a few weeks, compiz segfaults in libutouch-geiss
<tjaalton> because the server lacks multitouch?
<Sarvatt> going to be broken bad when we pull it in as soon as 12.04 opens, is there something I should be doing with the input stack? building against whats upstream of xi2.2?
<Sarvatt> GEIS_DEBUG=3 doesn't do anything
<tjaalton> does edgers have the multitouch patches after all?
<Sarvatt> nope
<Sarvatt> if unity really requires that.. not a pretty situation for any other distro? :P
<tjaalton> hehe
<Sarvatt> http://paste.ubuntu.com/697955/
<cnd> Sarvatt, I didn't realize that was still a blocker
<cnd> Sarvatt, you're up to date on geis in oneiric?
<Sarvatt> blocker? nah I'm ok with unity being broken in the PPA but its going to hit 12.04 right when it opens and break the world :P
<Sarvatt> http://paste.ubuntu.com/697958/ is slightly better
<tjaalton> doubt we'll put 1.11 without the multitouch patches 
<tjaalton> rebased for it
<cnd> tjaalton, if someone on the ubuntu-x side of things is willing to rebase, then that would be great
<tjaalton> cnd: still plenty of time :)
<cnd> but it's ok if 1.11 is uploaded without MT, imho
<cnd> I think the touch team will still develop on oneiric, and I'll be working with xorg upstream on getting MT support in there
<tjaalton> but yes, it'll get done in a few weeks if not before
<cnd> tjaalton, Sarvatt: actually, you don't really need to forward port the xi 2.1 multitouch patches for now
<cnd> you can merely forward port the gesture patch
<cnd> which should be trivial
<Sarvatt> cnd: ahh ok thats MUCH easier
<cnd> heh
<cnd> Sarvatt, are you up to date on libutouch-geis1 in oneiric?
<cnd> we fixed a bug or two about geis crashing when utouch wasn't available
<Sarvatt> up to date with whats in the archive yeah
<cnd> ok
<cnd> maybe that fix hasn't landed in oneiric
<Sarvatt> making sure, ii  libutouch-geis1                        2.1.2-0ubuntu4
<cnd> actually, I think we didn't push it because we fixed it this past week and it's not an issue on oneiric so we decided not to upload it
<cnd> Sarvatt, can you install libutouch-geis1 from ppa:utouch-team/daily and retest?
<Sarvatt> sure thing, if thats all it takes that'll be awesome and i'll just throw it in the PPA for now
<cnd> hrm, this would be the bug: https://bugs.launchpad.net/utouch-geis/+bug/825359
<ubot4> Launchpad bug 825359 in utouch-geis (Ubuntu) (and 1 other project) "Geis crashes when it fails to connect to XCB gesture service (affects: 1) (heat: 6)" [Undecided,Fix released]
<cnd> but it's already fix released for oneiric
<cnd> Sarvatt, it's a unity bug
<cnd> geis_init returns NULL, as it should, because there's no utouch instance
<cnd> but unity must not be checking it
<cnd> Sarvatt, can you file a bug against unity with the stack trace?
<Sarvatt> yup will do
<Sarvatt> was just about to say, no change with daily
 * Sarvatt goes to dig that machine out from under 6 other laptops to file it :P
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/860707
<ubot4> Launchpad bug 860707 in unity (Ubuntu) "Unity crashes when started in an environment without utouch support (affects: 1) (heat: 6)" [Undecided,New]
<Sarvatt> gesture proto looks pretty intertwined with the multitouch patch now that i fixed up all the build system bits of it, go figure :)
<Sarvatt> gesture extension patch I mean, sorry
<Sarvatt> ricotz: dang, thanks for catching the wacom problem
<bryceh> Sarvatt, wacom problem?
<Sarvatt> wacom got updated in the archive and was newer than the one in edgers since i just rebuilt the archive one
<Sarvatt> so upgrades would have been broken
<bryceh> ahh
<ricotz> Sarvatt, yw
#ubuntu-x 2011-09-28
<stgraber> RAOF: hey! I've been poking at bug 854967 a bit this week and it seems clear that it's a problem between grub/kernel/nvidia driver
<ubot4> Launchpad bug 854967 in friendly-recovery (Ubuntu) "boot to rescue mode in Oneiric (affects: 2) (heat: 12)" [Undecided,Incomplete] https://launchpad.net/bugs/854967
<stgraber> RAOF: Colin told me about the use of "set gfxpayload=text" that worked fine on my test nvidia system but he seemed to remember a discussion with you regarding it
<stgraber> actually: "<cjwatson> except I vaguely remember looking at that before and deciding against - check ith RAOF to see if he remembers?" :)
<RAOF> Ah, so this is nvidia hardware but nouveau drivers, right?
<stgraber> nope, that was with the blob
<RAOF> I don't recall discussing this with Colin :/
<RAOF> Does this also happen with nouveau?
<stgraber> no idea, the machine I had around (I borrowed it, I only have intel ...) had the binary driver installed
<stgraber> if you have a machine around that's running nouveau, it's pretty trivial to test with up to date oneiric. Just boot in recovery mode and if you can see the menu, you're good
<RAOF> Let me finish some testing and I'll flip the switch on my netbook :)
<stgraber> cool!
<stgraber> would be great if I could have some data by tomorrow so I can talk to Colin about changing the gfxpayload value for recovery mode
<Sarvatt> found your doctoral thesis! http://isotropic.org/papers/chicken.pdf
<Sarvatt> bah wrong channel
<Sarvatt> sorry :)
<RAOF> :)
<RAOF> stgraber: Sorry for the delay.  Tested my netbook with nouveau, it displays the menu fine.  Just installing the blob nowe
<RAOF> stgraber: And, yup, installing nvidia_current breaks the recovery mode in exactly the described fashion.
<Amaranth> Sarvatt: was there any progress with getting the vmwgfx driver going in xorg-edgers?
<apw> when you boot with the lid closed on a laptop who decides that that screen is not to be used
<apw> (in an oniric KMS world)
<apw> Sarvatt, RAOF ^^
<Sarvatt> RAOF: so ia32-libs breaks non mesa 32 bit libGL
<Sarvatt> it's installing a /usr/lib32/libGL.so.1
<Sarvatt> http://people.ubuntu.com/~ricotz/tmp19573/GL
<Sarvatt> ugh
<ricotz> uh
<Sarvatt> oh nevermind!
<Sarvatt> he doesn't have a 32 bit nvidia libGL.so.1 in that, another person in the bug report does though
<Sarvatt> ok i'm going to stop looking at that bug until I'm done doing this other stuff, I'm confusing myself now :)
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/852873
<ubot4> Launchpad bug 852873 in ia32-libs (Ubuntu) "32 bit GL on amd64 is broken on oneiric with nvidia-graphics-drivers (affects: 18) (heat: 82)" [Medium,Confirmed]
<bjsnider> would that bug still exist if they install wine:i386?
<cnd> bryceh, RAOF: a couple weeks ago I pushed three patches from Carlos Garnacho into our xserver
<cnd> they included fixes for the multitouch stuff
<cnd> now I'm finding that one of them regresses behavior
<RAOF> To what extent?
<cnd> now, no one in the world other than Carlos and myself probably hit these code paths at this point
<cnd> because there aren't any released applications that use touch grabs yet
<cnd> ideally, I suppose i would like to revert the patch to make my development easier
<cnd> however, it's not a really big deal, I can always run my own version of the server locally
<bryceh> cnd, I'm fine with them being dropped
<cnd> so I wanted your thoughts on whether I should push the patch in given the oneiric final freeze is less than 48 hrs from now
<cnd> s/push the patch in/drop the patch/
<cnd> will there be another upload before the final freeze?
<cnd> or: any issues if I push another upload with just that change?
<RAOF> I don't have one planned.
<bryceh> me either
<RAOF> What is the regression potential of dropping this patch?
<bryceh> cnd, think it should be fine if you push an upload dropping a patch.  RAOF or I can do a debdiff review if that'd make you more comfortable
<cnd> bryceh, I'm not too concerned with getting the upload right, just wanted to verify it won't hose anything up
<cnd> RAOF, regression potential should be minimal
<cnd> we've been running the same code in natty for quite a while
<cnd> oh, I just reviewed the changes in my tree and realized there's one other *tiny* fix I have
<bryceh> are these patches 505-507?
<cnd> bryceh, just 507 needs reverting
<cnd> and I would add: http://paste.ubuntu.com/698756
<cnd> it fixes touch ownership events not being sent for non-emulated touches that have been rejected by the current owner
<bryceh> do you have a bug# for that one?
<cnd> I don't have a bug for either yet
<cnd> I plan on filing them
<cnd> I'm just running across these bugs today as I am developing the new utouch stack
<bryceh> yeah just for tracking purposes at this stage in the release it's good to have bug #'s
<cnd> yeah, I think uploads are required to have them during any freeze
<bryceh> since 507 was added in this development cycle, I don't think there'd be any issue dropping it.
<RAOF> It's not going to cause regressions from Natty, but it invalidates some testing.
<bryceh> RAOF, certainly; however there's still a couple weeks before release
<RAOF> Yeah.  I'm happy with the patch being dropped, but -release will want some bugs filed :)
<bryceh> now, for the exevents.c patch, it's a different story... but it looks pretty trivial and I guess is an obviously correct change?
<cnd> yeah, it's a very obviously correct change, if XI multitouch spec is obvious to you :)
<bryceh> I don't have a feel for what the regression risk is for that but offhand it doesn't _look_ scary
<cnd> note: that wasn't sarcasm
<cnd> the function DeliverTouchOwnershipEvent does exactly what it says it does
<cnd> and nothing more
<bryceh> cnd, I might suggest breaking these up into two separate uploads.  Do the patch revert first.
<cnd> bryceh, two uploads before the deadline tomorrow?
<bryceh> that way the two changes can be evaluated separately, and if there is any worry/risk  over the exevents.c then just that revision can be reverted
<cnd> bryceh, ok, I can do that
<cnd> bryceh, RAOF: are we in agreement? I'll open two bugs and make two separate uploads for the patch reversion and the touch ownership event fix?
<RAOF> Ack
<cnd> I'm going to assume bryceh is an Ack too
<bryceh> cnd, yep Ack
<cnd> ok, I'll get started after I take the dog out for a walk :)
 * RAOF finishes waking up.
<cnd> bryceh, RAOF: the first server is uploaded
<cnd> I'll wait until it is at least accepted into the archive before doing the second
<cnd> do you know if I need to wait for it to be built and published before uploading the second
<cnd> ?
<RAOF> I don't think you do, no.
<cnd> ok, then I'll upload right after it's accepted
#ubuntu-x 2011-09-29
<bjsnider> ricotz, i'm getting .xsession-errors spammed by a gnome 3-centric message and they told me to talk to you about it
<bjsnider> GConf error: configuration server cant be met: D-BUS error: Method "Set" with signature "s(i(ias))" on interface "org.gnome.GConf.Database" doesn't exist
<ricotz> bjsnider, hi
<ricotz> hmm, i have nothing to do with a non working gcond daemon ;)
<ricotz> *gconf
<ricotz> looks like your org.gnome.GConf service is broken
<bjsnider> yeah but what is it?
<ricotz> /usr/lib/libgconf2-4/gconfd-2 isnt working
<ricotz> use d-feet to look at this dbus interface
<bjsnider> yeah, so it's a session bus, and it has no object paths at all
<bjsnider> when i select it, the console spits out:
<bjsnider> ERROR: Some clever service is trying to be cute and has the same method name in the same interface
<ricotz> ok, then gconf is broken for some reason
<bjsnider> what do you think i should do about it?
<bjsnider> and this ain't just me, by the way. there's a bug against the wrong package, and if you do a search it seems like a lot of people running gnome-shell in oneiric have this issue
<bjsnider> bug 842648
<ubot4> Launchpad bug 842648 in gnome-python (Ubuntu) "Dbus error: Method "set" with signature "s(ib)" on interface "org.gnome.gconf.database" doesn't exist (dup-of: 848198)" [Undecided,Confirmed] https://launchpad.net/bugs/842648
<ubot4> Launchpad bug 848198 in gconf (Ubuntu) (and 1 other project) "Sporadic gconf error messages (affects: 8) (dups: 4) (heat: 54)" [High,Triaged] https://launchpad.net/bugs/848198
<bjsnider> i didn't notice that it was a duplicate of 848198
<bjsnider> i guess this is known
<ricotz> yes, seems to affect at lot of people
<seb128> somebody should get the log upstream asking then
<seb128> king->ked
<seb128> I've added a comment on the bug
<bjsnider> funny because i was in the gnome-shell channel alst night and they didn't know anything about it
<bjsnider> one of them said he didn't have org.gnome.Gconf
<bjsnider> i think evolution might be spamming my .xsession-errors with this stuff:
<bjsnider> (exe:3448): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
<bjsnider> it's got to be a mono app if it's an exe
<jcristau> evo is a mono app now?
<bjsnider> well, i thguth it was
<bjsnider> maybe not
<jcristau> pretty sure not.
<seb128> it's not
<bjsnider> what process could be identifying itself as "exe"?
<seb128> bjsnider, looking which one has the pid 3448?
<bjsnider> thought that number meant something else
<bjsnider> that's chromium
<cnd> bryceh: Sarvatt: I just upgraded my netbook to oneiric, but X crashes as soon as I attempt to login
<cnd> have you seen this before?
<Sarvatt> cnd: only with xorg-edgers where unity is broken and it goes back to the login screen again.. tried another session?
<cnd> hmmmâ¦ that sounds like what's going on
<cnd> but I don't think I'm running xorg-edgers
<cnd> let me check
<cnd> nope, no xorg-edgers
<cnd> it looks like the guest session is working
<cnd> for some definition of working...
<Sarvatt> whats your /var/log/Xorg.0.log.old say?
<cnd> nothing useful
<Sarvatt> why are ya blaming X then? :P
<Sarvatt> sudo apt-get install ubuntu-desktop^ offer to install anything?
<cnd> unity 2d has problems too
<cnd> nothing new for ubuntu-desktop
<cnd> unity-2d seemed to crash lightdm so it stopped runing
<cnd> I had to sudo start lightdm...
<Sarvatt> with the circumflex? darn, that would have been the easy fix if something was removed
<Sarvatt> how about ~/.xsession-errors?
<cnd> I think I figured it out by looking at the lightdm.log
<cnd> somehow my ~/.Xauthority was 600 root:root
<cnd> so it couldn't overwrite it with a new one for the session
<cnd> now I'm into my session, but unity is no where to be seen...
<cnd> I have the menu bar at the top
<cnd> and empathy is helpfully running
<cnd> but that's it :(
<cnd> gah, "Fatal: GLX_EXT_texture_from_pixmap is missing"
<Sarvatt> hmm someone else reported that too, compiz wouldn't start
<cnd> yeah
<Sarvatt> lets see if i can find the bug # in 2 day old chat logs
<cnd> this is on an atom machine
<cnd> unity 2d saves the day :)
<Sarvatt> it should still work fine, thats a pretty nasty bug
<cnd> what happened to the 51-synaptics-quirks.conf file?
<cnd> hmm, the file is still there in the package
<cnd> but I'm betting a change has prevented it from installing
<cnd> my netbook trackpad is pretty useless without the quirk...
<Sarvatt> looks like it was lost in the merge in feb
<Sarvatt> err july
<cnd> I can't even build xserver-xorg-input-synaptics...
<cnd> dpkg-source: warning: the diff modifies the following upstream files: 
<cnd>  autogen.sh
<cnd>  docs/README.alps
<cnd>  docs/tapndrag.dia
<cnd>  docs/trouble-shooting.txt
<cnd>  test/test-pad.c
<cnd>  test/testprotocol.c
<cnd> dpkg-source: error: aborting due to --abort-on-upstream-changes
<tjaalton> oops
<Sarvatt> tjaalton: i blame it on it having been done in dublin :)
<Sarvatt> on a friday
<tjaalton> i haven't checked out where exactly it got dropped
<Sarvatt> debian/rules got switched to dh in the merge and lost the custom install of the quirks
<tjaalton> meh
<tjaalton> ok so I need to fix it then :)
<cnd> and hopefully the accidental (?) upstream changes
<tjaalton> that I don't know
<tjaalton> how they crept in
<tjaalton> but I'll check
<cnd> as it is I don't know how to build the package
<tjaalton> umm, so the tarball doesn't have autogen.sh
<tjaalton> nor the docs dir
<tjaalton> not my fault! :)
<Sarvatt> cnd: package in the archive and the ubuntu branch of git build fine here..
<Sarvatt> cnd: do you have something in ~/.devscripts changing the defaults?
<cnd> hah, I do
<cnd> DEBUILD_DPKG_BUILDPACKAGE_OPTS="--source-option=--abort-on-upstream-changes"
<cnd> good call :)
<Sarvatt> i had to purge xorg-edgers to try it, sorry it took so long :)
<tjaalton> hmm, doubt we need the udev rules anymore
<tjaalton> in synaptics, better use MatchProduct in the conf snippet instead
<cnd> Sarvatt, tjaalton: the njpatel from dx is telling me that's a fairly basic opengl extension
<cnd> and that if it's not supported then there's probably something wrong with the drivers
<Sarvatt> yeah, its supported though
<cnd> Sarvatt, can you double check my glxinfo to see if they are misreading it? :)
<cnd> http://paste.ubuntu.com/699227/
<cnd> glxinfo is voodoo to me
<Sarvatt> cnd: yeah it's there
<Sarvatt> cnd: can you compiz --replace and have it start up fine in another session?
<Sarvatt> fine as in, not throwing that error
<cnd> Sarvatt, you're saying that glxinfo shows the extension is there?
<Sarvatt> cnd: GLX_EXT_texture_from_pixmap is there all 3 times
<cnd> ok
<njpatel> Sarvatt, hey, cnd got this when running "Fatal: GLX_EXT_texture_from_pixmap is missing"
<Sarvatt> yeah
<Sarvatt> its not missing though
<njpatel> so, trying from the guest session might be useful debugging
<cnd> yay, we're all chatting in one room :)
<njpatel> right, glxinfo shows it isn't 
<Sarvatt> i was asking if he could try compiz --replace from another session to see if it throws the same error
<cnd> njpatel, it failed in the guest session too
<njpatel> but something's up
<cnd> I'll try compiz --replace right now
<cnd> hmm, doesn't look promising
<cnd> I seem to have lost all WM functionality
<Sarvatt> did it give that error?
<cnd> but my terminal window is behind my irc window
<tjaalton> cnd: build synaptics git, and see if it fixes your touchpad
<cnd> Sarvatt, njpatel ooo...
<cnd> compiz --replace worked
<cnd> and it seems to have brought unity 3d around
<tjaalton> dbus daemon 100% cpu again..
<tjaalton> sigh
<cnd> tjaalton, I'll attempt it now
<cnd> tjaalton, did you git push?
<cnd> git fetch didn't find anything
<tjaalton> I did
<cnd> still nothing...
<tjaalton> weird
<cnd> oh wait
<cnd> I'm in -evdev...
<tjaalton> :P
<tjaalton> one of those days? :)
<cnd> yeah
<cnd> it's always one of those days when I'm upgrading my main laptop
<tjaalton> hehe
<tjaalton> so what exactly did that compiz --replace do? i guess it's going to cause problems for normal users as well
<cnd> tjaalton, what are you wanting to know?
<cnd> I can pastebin the output
<tjaalton> cnd: yeah, why not
<cnd> tjaalton, pastebin.ubuntu.com/699239
<Sarvatt> cnd: I bet gdm works ok too then..
<cnd> cnd, ?
 * cnd has started talking to himself...
<cnd> Sarvatt, ?
<cnd> I'm using lightdm
<tjaalton> cnd: ok, so the migration didn't happen
<tjaalton> automatically
<cnd> hmm?
<cnd> what migration?
<Sarvatt> yeah he hasns't been able to start compiz to do the migration because glx isn't available when its trying to start for some reason
<tjaalton> "Checking if settings need to be migrated ...yes"
<tjaalton> ahh
<tjaalton> ok
<tjaalton> so it's too fast?-)
<cnd> there was a complication in here
<cnd> that may be throwing you off
<Sarvatt> thats odd, how do you get a glxinfo from lightdm's DISPLAY?
<cnd> I tried it locally
<tjaalton> does a new login work then, and does moving the old compiz configs back in place break it again?
<cnd> but it seemed hung
<cnd> so then I did it over ssh
<cnd> but the first one just hadn't finished whatever it was doing
<cnd> ok, I'm getting lost in all the debugging steps, so I'm going to log out and log back in
<cnd> this will also test if tjaalton's new synaptics package is working properly :)
<tjaalton> good :)
<tjaalton> check your xorg log too that MatchProduct works
<cnd> tjaalton: 
<cnd> [  4593.602] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/event5)
<cnd> [  4593.602] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "evdev touchpad catchall"
<cnd> [  4593.602] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad catchall"
<cnd> [  4593.602] (II) LoadModule: "synaptics"
<cnd> doesn't look like it worked
<tjaalton> so which model is it?
<cnd> hmm, my product isn't listed in ther...
<tjaalton> ha
<cnd> oh wait, yes it is
<cnd> it's the inspiron_1012
<tjaalton> check if the quirks file is installed
<Sarvatt> tjaalton: MatchProduct is for the device's product string not the dmi info it needs to be matched against?
<cnd> ok, unity came up, after a ton of time
<cnd> tjaalton: it's installed
<tjaalton> ok
<Sarvatt> touchpad would have the same product name as one that doesnt need the quirk i'd imagine
<cnd> how can I get the product name so we can verify?
<Sarvatt> dmesg | grep input, xinput --list
<cnd> SynPS/2 Synaptics TouchPad
<jcristau> /proc/bus/input/devices
<Sarvatt> xorg log
<Sarvatt> yeah its generic
<cnd> yep
<tjaalton> crap
<cnd> so the tags still need to be there
<tjaalton> so.. udev rules back
<tjaalton> hmm, I guess there's no reason to not include the quirks files in x-x-i-s.install, since we only support linux
<tjaalton> cnd: ok, try again
<tjaalton> argh
<tjaalton> forgot to change 51-.. back
<cnd> tjaalton: so I'll hold off for a minute?
<tjaalton> yeah
<tjaalton> cnd: now
<cnd> ok
<cnd> tjaalton: still not working
<tjaalton> duh
<tjaalton> hmm you need to reboot
<tjaalton> i thikn
<tjaalton> or not
<tjaalton> no you don't
<cnd> how can I replay udev events so I can see if the tag is right?
<tjaalton> don't remember anymore
<cnd> udevadm export-db it looks like
<tjaalton> udevadm info --export-db
<cnd> yeah
<cnd> so I don't see the tags there
<cnd> should they show up?
<cnd> I can reboot if you think it would work
<tjaalton> ah, run udevadm trigger --subsystem-match=input --action=change
<tjaalton> hmm, maybe I need to bump the version on the postinst, since this is sorta "new" now
<cnd> still nothing in export-db matching my machine
<tjaalton> ok
<tjaalton> dunno, reboot wouldn't hurt I guess
<tjaalton> though put the dump in a file first
<cnd> the export-db dump?
<tjaalton> yes
<tjaalton> and, just to humor me, restart x
<tjaalton> see if it's fixed after all
<cnd> already start the reboot
<tjaalton> ok
<cnd> tjaalton: it worked!
<cnd> the tag shows up in the udev db now too
<cnd> so the reboot changed something
<tjaalton> so the udevadm trigger didn't work ;)
<cnd> tjaalton: I think you still have a few hours to get the fix in before the final freeze :)
<tjaalton> cnd: heh, yep
<tjaalton> uploaded
<Sarvatt> 40 minutes until final freeze, where's the xserver 1.11 upload?!
<jcristau> yeah srsly.
<tjaalton> ooh, synaptics accepted
<cnd> tjaalton: I don't see synaptics having been accepted...
<cnd> oops, nm
<cnd> looked at the wrong page
<Sarvatt> RAOF: any desire for me to bring a pantone huey to UDS? figured you might care for some reason :)
<Sarvatt> was just reading http://libregraphicsworld.org/articles.php?article_id=42 and picked one up since it looks well supported
<Sarvatt> yeesh, article got deleted right after i linked it
<RAOF> Sarvatt: Yeah, that'd be awesome.
<Sarvatt> well gotta make sure i get a working one first, looks like there are lots of screwed up ones that leave your colors too pink
<Sarvatt> http://www.google.com/url?sa=t&rct=j&q=http%3A%2F%2Flibregraphicsworld.org%2Farticles.php%3Farticle_id%3D42&source=web&cd=1&ved=0CB0QIDAA&url=http%3A%2F%2Fwebcache.googleusercontent.com%2Fsearch%3Fq%3Dcache%3ASde4RhGBtm0J%3Alibregraphicsworld.org%2Farticles.php%253Farticle_id%253D42%2Bhttp%3A%2F%2Flibregraphicsworld.org%2Farticles.php%253Farticle_id%253D42%26cd%3D1%26hl%3Den%26ct%3Dclnk%26gl%3Dus&ei=4_uETs-vD6P30gG7yqTSDw&usg=AFQjCNHJv9N8udSV3Pg8jbzCa
<RAOF> Tat
<RAOF> Yeah, seen that.
<RAOF> I was looking at acquiring one myself :)
<Sarvatt> oh fglrx why do you work so good? http://sarvatt.com/downloads/GNOME3_desktop_corruption.jpg
<RAOF> Setting a correct tiling mode is for chumps!
<Sarvatt> one day it might be usable in gnome-shell :)
<RAOF> cnd: Still around, and still having compiz problems?
<cnd> RAOF: I was having problems
<cnd> I guess I still have stacking order issues
<cnd> but those are different
<RAOF> :)
<RAOF> Those problems have gone?
<RAOF> Or, rather, the ?compiz doesn't start, complaining about EXT_tfp? problem has gone?
<cnd> apparently not...
<cnd> yeah, that's gone
<cnd> manually running compiz --replace from an ubuntu 2d session magically fixed things
<cnd> dbarth mentioned that unity --reset may work too
#ubuntu-x 2011-09-30
<Sarvatt> errrrr
<Sarvatt>   * ia32-libs-multiarch also recommends libgl1-mesa-glx (LP: #821100)
<Sarvatt> not installable on amd64?
<Sarvatt> OH libgl1-mesa-glx is but libgl1-mesa-dri isn't, my bad
<Sarvatt> cnd: oh did it?! so doing the 11.04 to 11.10 compiz profile transition worked, but doing it via a lightdm boot wouldn't do the transition properly?
<cnd> Sarvatt: I don't really understand what all you're meaning
<cnd> I don't know much about how unity is supposed to work, especially at upgrade
<Sarvatt> when you did compiz --replace it did the profile transition instead of bailing with the EXT_tfp not available error
<Sarvatt> that log of compiz --replace you posted earlier said it was doing a profile transition
<cnd> one complication: when I upgraded, intel kernel module thought it would be an awesome time to lose the framebuffer
<cnd> so halfway through my upgrade, I lost my graphics output
<cnd> and I of course used upgrade-manager
<cnd> so I had to kill it, run dpkg --configure -a
<cnd> then reboot
<Sarvatt> http://pastebin.ubuntu.com/699239/ that was your first compiz run after the upgrade, starting unity/compiz via lightdm bailed before it could do the transition and it worked after the transition is what i get from what you're saying
<cnd> so I don't know if I missed anything in there
<cnd> Sarvatt: that sounds right
<Sarvatt> oh
<Sarvatt> guess some 11.04->11.10 upgrade tests are in order
<Sarvatt> transition being this from the log: Checking if settings need to be migrated ...yes
<Sarvatt> Compiz Migration Script for Ubuntu 11.04
<Sarvatt> Moving settings from Compiz 0.8.6 to Compiz 0.9.4
<RAOF> Sarvatt: That transition looks to be because cnd was running unity in a VT, which doesn't have access to the dbus session bus, and hence uses a different config backend.
<Sarvatt> here's hoping it was all because of the busted update-manager -d and manua dpkg --configure -a after..
<cnd> my laptop keeps suspending randomly...
<cnd> the one I just updated
<cnd> anyone been having issues with that?
<Sarvatt> RAOF: jbicha's cr48 isn't much different than cnd's system
<Sarvatt> cnd: yeah
<Sarvatt> digging up the bug
<Sarvatt> gnome-control-center bug
<RAOF> Sarvatt: Right; both use the Intel IGD thingy.
<Sarvatt> 945gm
<Sarvatt> well for cnd, pineview for cr48 i guess
<cnd> mine's a gma 3150
<cnd> whatever that means :)
<Sarvatt> oh both pineview then
<Sarvatt> thought you were on a mini9 sorry
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/860227
<ubot4> Launchpad bug 860227 in gdm (Ubuntu) "greeter session puts the host to sleep after 30 minutes idle (affects: 1) (heat: 6)" [High,New]
<Sarvatt> that isnt the bug i'm thinking of though
<Sarvatt> still digging
<cnd> that could be the bug though
<Sarvatt> cnd: https://launchpad.net/bugs/860485
<ubot4> Launchpad bug 860485 in gnome-settings-daemon (Ubuntu Oneiric) (and 2 other projects) "bad default setting: suspend after 30min when plugged in (affects: 22) (dups: 1) (heat: 116)" [High,Triaged]
<cnd> oh, it's a setting...
<cnd> I should have checked...
<cnd> hmmmâ¦ it's set to 30 min on battery, never when plugged in
<cnd> I don't think it knows I'm plugged in though
<cnd> the power indicator says "Battery (charged)"
<bdmurray> cnd: did you say to test with geistest and not gesturetest?
<cnd> bdmurray, I would normally point people to use geistest
<cnd> gesturetest will actually go away in 12.04
<bdmurray> and what would I expect to see from geistest?
<cnd> gesture events?
<cnd> up to two touches when in unity (cause 3 and 4 touch gestures are grabbed by unity)
<bdmurray> okay must not be working, thanks (gotta run)
<cnd> ok
<cnd> bdmurray, if geistest crashes, it is due to a bug we haven't had time to fix yet
<cnd> listen only on the root window instead
<cnd> geistest -w <root window id>
<cnd> which you can get from xwininfo -root
<Sarvatt> ok we have no 32 bit accelerated GL without proprietary drivers now
<Sarvatt> on amd64
<Sarvatt> https://lists.ubuntu.com/archives/oneiric-changes/2011-September/010633.html
<Sarvatt> want to use wine? sudo add-apt-repository ppa:ubuntu-x-swat/x-updates
<Sarvatt> pretty crappy user experience :(
<Sarvatt> is multiarch libpciaccess really that risky?
<RAOF> Mesa's still in ia32-libs, though, right?
<Sarvatt> no DRI libs at least
<Sarvatt> actually that should have removed the /usr/lib32/libGL.so.1 too since thats what the bug its fixing called for
<Sarvatt> i'll file a sync request tomorrow when its not 5 gin and tonics into the night and see where it goes :)
 * Sarvatt started tonight and realized a bug saying it'd be retarded not to do it isn't exactly convincing past final freeze
<bjsnider> i thought the point of multiarch was to get rid of ia32-libs, not to keep using it
<Sarvatt> it is, except libdrm-intel1 grew a libpciaccess0 dependency in 2.4.26 so libgl1-mesa-dri wasn't installable after that, and multiarch libpciaccess just got into debian a few days ago, and was forgotten about until recently because the people that cared had it install already :P
<bjsnider> why did libdrm-intel1 need libpciaccess0 all of a sudden?
<Sarvatt> http://cgit.freedesktop.org/mesa/drm/commit/?id=9d77603d8b95aee4f2408e437c55af15ee05b608
<bjsnider> do ati and nvidia not need it too?
<Sarvatt> is it used in x-x-v-intel 2.5.16 in oneiric? nope
<Sarvatt> 2.16 whoops
<bjsnider> revert?
<bjsnider> sometimes it seems like intel just does whatever it wants and doesn't care about anybody else's schedule
<Sarvatt> its nicer than no release schedule at all though, at least you know mesa/xserver will be released when intel has quarterly performance reviews to complete now :)
<Sarvatt> when is the next mesa/xserver release? go to intellinuxgraphics.com and look at when their quarter ends
#ubuntu-x 2011-10-01
<scoundrel50a> is this the channel to chat about oneiric?
#ubuntu-x 2011-10-02
<noobish> I'm having trouble installing radeon/gallium from xorg-edgers. After all the upgrades I'm missing important things like libGL.so, /usr/lib/dri is empty, and I'm missing some stuff in /usr/lib/xorg/modules.
<noobish> it should be as simple as adding the ppa, updating, and upgrading all right?
<noobish> I do see this as part of the upgrades: dpkg: yes, will deconfigure libgl1-mesa-dri (broken by xserver-xorg-core).
<soreau> Yes.. what command did you use?
<noobish> I used synaptic
<soreau> Try sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade
<noobish> after a ppa-purge or in this weird state?
<noobish> well, nothing needed changing
<noobish> env
<noobish> The partial multiarch stuff smells to me, I'm gonna try reverting before the ppa
<noobish> weird. I can reproduce this endlessly from a working radeon install without the ppa to what I describe above with the ppa
<LLStarks> anyone know their way around touchpad settings? i'm having endless problems.
<LLStarks> hovering above the touchpad is detected and my synaptics always jumps around
<Azelphur> trying out Ubuntu 11.10 with my multi X screen setup. Using unity I just get a white background with a "X" pointer on my second X screen. Any ideas? :)
<Azelphur> seems like some things have been hard coded to open on :0 too, I can't open nautilus on :0.1
<Azelphur> Is there any way to have >2 monitors in Ubuntu any more? or has the functionality just been completely stripped out :(
<bjsnider> Azelphur, sunday is a really bad day to ask anything in here
<Azelphur> bjsnider, I see :p
<Azelphur> bjsnider, I got somewhere though, XFCE seems to give very good first impressions :)
<RAOF_> Azelphur: Multi X screen, meaning multiple cards driven by a single X server, AKA: Xinerama?
#ubuntu-x 2012-09-24
<mlankhorst> morning
<tjaalton> hi
<mlankhorst> back home :)
<tjaalton> potential-fixes-3.6.txt.. sigh
<tjaalton> combing through the diff to drm/i915
<mlankhorst> > still cant remember gpg passphrase :p
<tjaalton> heh
<Saviq> hey, I'd like to point to a smbd bug I've encountered on quantal-backport: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1053414
<ubottu> Launchpad bug 1053414 in samba (Ubuntu) "smbd crashed when trying to connect from Ubuntu" [Undecided,New]
<Saviq> not sure how to mark it so that it doesn't get lost
<tjaalton> Saviq: wrong channel
<mlankhorst> creating a passphrase that was similar yet quite different made me forget it, already forgot it once before. Maybe I can find the inspiration to remember it, else I'll just create a new one again..
<Saviq> tjaalton, https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport is not here?
<tjaalton> Saviq: that's a kernel bug then
<Saviq> tjaalton, it's probably just a combination of smb+the kernel, not sure who should know about it...
<tjaalton> #ubuntu-kernel maybe
<tjaalton> or -server
<Saviq> will try -kernel
<mlankhorst> hard to be productive again after those weeks :s
<AaronCampbell> I found some additional info on my laggy video issue.
<AaronCampbell> Recap: I have an AMD ATI Radeon 6870 video card with 4 1680x1080 monitors attached.  It was working well with the proprietary drivers in 12.04.  I didn't upgrade to 12.10, I did a complete reinstall, and now it uses the open source driver but everything is REALLY laggy (dragging windows, switching desktops, etc, etc). My /var/log/Xorg.0.log - http://pastebin.com/i1RiJnHi
<AaronCampbell> As it turns out, it's only laggy if I show the launcher on all desktops
<AaronCampbell> It's way nicer to have the launcher on all desktops, but for now at least I have a work around
<AaronCampbell> Now that I've got it down to the one issue, does anyone have any ideas what I might be able to do to fix it?
<bryceh> tjaalton_, there's a null pointer deref bug in the 228_autobind_gpu.patch hotplug code:  https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1054051
<ubottu> Error: malone bug 1054051 not found
<bryceh> tjaalton_, guessing it just needs a null pointer check (which I'd be happy to send a patch for), but I see you have a couple followup patches fixing various things so maybe it needs a bit more  study.
<bryceh> mlankhorst, ^^ you might be interested too
<mlankhorst> why does it show as private?
<bryceh> tjaalton_, btw patches 228 and 229 aren't referenced in changelog
<bryceh> mlankhorst, it was private because apport files all crash bugs as private.  I unprivated since there's no core anymore
<mlankhorst> airlied wrote the code so you might want to ask him about it :-)
<mlankhorst> it' s bed time so i dont really awnt to look right now
<bryceh> mlankhorst, it doesn't matter to me; I could just disable the patches and call it good.  But guessing you wanted the patch in there for good reason, so raising for your attention if you want to locate a proper fix.  No hurry, tomorrow's fine.
<mlankhorst> it's really a patch we want in since it binds the optimus devices
#ubuntu-x 2012-09-25
<bryceh> anyone know, are we getting ARM video drivers in the archive for Q?
<bjsnider> bryceh, i have .51 ready to go
<bjsnider> i thought that was the right one
<bjsnider> it says it's a long-lived release
<bjsnider> i've been using my download bandwidth for something else all day but that will be done in a few minutes and i was going to send it in then
<bryceh> bjsnider, awesome thanks
<bryceh> didn't realize there was a .51 already; good to know
<bjsnider> i noticed that ricotz had sent it into xorg-edgers
<bjsnider> he must pay somebody inside nvidia for the info on when new blobs are released
<RAOF> tjaalton: I'd love to try the auto-power-off patch :)
<fubada> hi, is the ppa add procedure under 12.04 still "apt-add-repository ppa:ubuntu-x-swat/x-updates'?
<tjaalton> bryceh: ok thanks, i'll discuss it with airlied
<tjaalton> RAOF: fof the kernel? i could build a paxkage with it/them
<tjaalton> package too
<RAOF> tjaalton: Oh, they're kernel patches? That seems odd.
<RAOF> The kernel already exports all the necessary juju for userspace to do that.
<tjaalton> hmm
<tjaalton> ok, don't know which patch you're referring to then  :)
<RAOF> tjaalton: The one you pinged me about earlier?
<tjaalton> i did?-)
<RAOF> 21:31 <tjaalton> RAOF: I'm adding the patch for dynamic gpu poweroff too, would be fun to test how that works
<tjaalton> wth was that about. probably meant the kernel patches there
<RAOF> Heh
<tjaalton> I was meant to build a kernel for that, but didn't yet
<RAOF> Again, I don't know why that's a kernel patch; X should have all the information necessary to parse /sys/kernel/debug/vgaswitcheroo/switch and turn off any GPU its not using.
<tjaalton> there are a couple of threads on dri-devel about this
<tjaalton> [RFC] drm dynamic power off support
<tjaalton> well, this is _dynamic_!
<ajmitch> so with the q-lts-backports PPA, if I install the renamed packages & then try to upgrade to quantal, will things break? I didn't see any conflicts/replaces or breaks from the quantal X to the renamed packages
<tjaalton> :)
<RAOF> Oh, hey. Evolution's crashed again.
<RAOF> Maybe the OOM killer hit it again.
<RAOF> Ah, ok. I see those. Interesting!
<RAOF> That'll obviously be *more* interesting when powering on the radeon doesn't crash X, of course.
<tjaalton> heh
<tjaalton> btw, push -ati git ;)
<fubada> do you guys know if I need to use jockey-text to switch to nvidia_current from x-swat
<fubada> i dont have x11, using ubuntu-server
<tjaalton> if you already have nvidia enabled then no
<fubada> by defaault it uses the free drive nouveau
<RAOF> tjaalton: Ta for the prod there.
<tjaalton> fubada: yes, so why do you need the blob if it's a server?
<fubada> im going to install xbmc as it is also my htpc
<fubada> it doesnt need any dm
<fubada> but it will be running xbmc
<tjaalton> ok, try jockey-text then
<fubada> ok
<bjsnider> fubada, why use the blob on an x11-free server?
<tjaalton> replied already ;)
<bjsnider> still not sure it makes much sense
<bjsnider> i wouldn't put anything by nvidia in a server
<fubada> its not a real server, its just an ion2 box with 4tb of swraid
<fubada> hooked up to my tv
<fubada> a bunch of private torrents
<fubada> and running xbmc
<fubada> i just dont want the overhead of gdm, etc
<fubada> for music/movies
<bjsnider> oh, i kind of jumped to conclusions when you said server
<bjsnider> just rtorrent i guess
<fubada> transmission with a webui
<bjsnider> ...
<tjaalton> bryceh: btw, the patches are referenced in the changelog, just not with the name
<bryceh> tjaalton, right 228* and 229* are not referenced in the changelog.
<tjaalton> yeah, it's kinda silly to have numbers anyway
<tjaalton> since there are huge gaps that mean nothing :)
<bryceh> tjaalton, the patch names without the numbers aren't mentioned either :-P
<tjaalton> right, but the context should be clear :)
<bryceh> tjaalton, not to the emacs search function :-)
<tjaalton> heh
<tjaalton> right, names should be there
<tjaalton> i just followed mlankhorst's lead! :)
<bryceh> +1 to retaining patch names in changelog comments.  and +1 to context (moar context!)
<tjaalton> thinking about adding new categories to patches/series, so it's more clear what are from upstream, what's never meant there etc
<tjaalton> and drop the numbers
<tjaalton> from our patches
<bryceh> interesting thought.  I'm in favor of file naming consistency, but there's no technical reason why it needs to be a linear set of numbers
<bryceh> having patches grouped together that are interdependent is a good idea, so they can be popped and pushed as a unit
<tjaalton> right
<tjaalton> and no need to review them again and again after rebasing to a new version
 * bryceh nods
<tjaalton> I might do it after this fix, it's a non-functional change but no need to rush it for the beta
<bryceh> then the upstream cherrypicks could all be grouped at the top so they get applied first.  Would cut down on porting work.
<tjaalton> yeah
<tjaalton> although it could mean more churn in the distro patches :)
<bryceh> non-functional but if you change the ordering (as you have to), you might have to rework a few patches
<bryceh> yeah, a bit of churn but that'd happen anyway when we go to the next upstream version
<tjaalton> right, but when backporting patches for a stable release..
<tjaalton> though there should be no conflicts either way
<mlankhorst> maybe do it for xorg 1.14?
<bryceh> I suppose by the time we get to a perfect patch organizational system we'll be switching to wayland or whatnot
<tjaalton> guess so :)
<mlankhorst> unless you can show there is no diff before and after changing the patch order
<bryceh> or maybe trim the numbers and do the easy recategorization now, and leave any tough patch reworks to 1.14?  Timo has a lot of patch-fu I bet he can pull it off.
<tjaalton> I'll try it out, it's easy to see if it fails in horrible ways or not. don't think it should :)
<tjaalton> I'll test this patch first tho..
<mlankhorst> famous last words
<mlankhorst> but.. back to fencing I suppose..
<tjaalton> didn't crash, ship it
<bryceh> http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-quantal-workqueue.svg
<bryceh> first time we've had more -nouveau bugs than -intel
<tjaalton> yeah it's in a bad shape
<tjaalton> crashes in libexa etc
<mlankhorst> I know, bit annoying too when upstream (darktama) doesn't respond :(
<bryceh> yeah I can't get piglit to run on it without the gpu locking up
<bryceh> and that's with 804.  with 802 in precise the kernel OOPSes
<mlankhorst> :>
<mlankhorst> the annoying part is the kernel rework is not complete yet so the maintainer is focusing on that..
<bryceh> mlankhorst, in hindsight do you think we should have stuck with an older version before the rework started?
<tjaalton> older version of?
<mlankhorst> not going to matter, both were broken
<tjaalton> the rework is in the kernel
<bryceh> old version of whatever
<mlankhorst> no it just needs some bugtracking love, we couldn't use the old ddx because of the exa changes
<tjaalton> not really possible
<bryceh> so, nothing really we could have done?  just chalk it up to poor maintainership.  Bummer.
<tjaalton> hmm, wonder if patch 188 is breaking stuff now..
<tjaalton> guess we can drop it with the hotplug stuff now in
<tjaalton> and ask sabdfl to test :)
<bryceh> tjaalton, regardless, it's not relevant if there is better hybrid support now
<tjaalton> yeah I'm pretty sure the current code is good enough
<tjaalton> and handles this case
<bryceh> it was a pretty obvious bug when it happened
<tjaalton> in the future, it would be great if the distro patches had a patch header :)
<tjaalton> git log works most of the time
<tjaalton> but it would be even easier to just look at the header
<bryceh> this patch was from karmic, we were pretty fast and loose back then
<tjaalton> hehe
<bryceh> I've been trying to do the full git format patch stuff these days, when it's something I authored.  At least I always include a preface description.
<mlankhorst> I think some headers might have been lost by my xorg codestyle rebase/update script
<bryceh> doh
<mlankhorst> personally, I prefer patches just have something in git log about them
<mlankhorst> that's what the metadata is for..
<tjaalton> ha, indeed..
 * tjaalton spanks mlankhorst with a giant herring
<tjaalton> http://dep.debian.net/deps/dep3/
<tjaalton> also, git log ceases to work when they are renamed
<mlankhorst> talk about overengineering..
<tjaalton> well, it's usually enough to just have a from tag and a buglink
<mlankhorst> Not really? git log will keep working..
<mlankhorst> Unless you do a rewrite as well
<bryceh> git log works ok for _us_
<tjaalton> ok, not sure about that
<tjaalton> yeah that's a good point
<mlankhorst> git log --follow
<bryceh> but for all our gitless co-workers, or users who only know about apt-get source, having a description in the patch itself can be a big boon
<tjaalton> like ubuntu-release/sru folks
<mlankhorst> seems to pick up on my debian/patches/series rename :-)
<mlankhorst> but nowadays I tend to edit patches manually when updating..
<tjaalton> quilt refresh shouldn't touch the headers
<tjaalton> or dquilt if you have the alias
<mlankhorst> nah I just set quilt to always assume I'm using debian
<bryceh> hey, how do you check that a package is in NEW?  Is there a report for that?
<bryceh> (trying to find nvidia-graphics-drivers-experimental-304 for precise-proposed)
<tjaalton> https://launchpad.net/ubuntu/precise/+queue
<bryceh> aha bingo, thanks.
<tjaalton> no drama after reorganizing the patches
<bryceh> nice
<bryceh> mlankhorst, I agree dep3 as a whole is overkill, but the concept is sound.  Basically the idea is to explain where the patch originated and what it does.  As long as that's clear, that's good, even if it's not dep3 compliant.
<tjaalton> and usually it's enough to list from:, subject:, short description or a buglink, that's it
<mlankhorst> so pretty much what we already do :p
<tjaalton> yeah, when they are not stripped off on rebase :)
<mlankhorst> I don't think there will be more 'change the entire X server coding style' patches, so it should be safe..
<tjaalton> http://pastebin.com/BrDFnAt3
<tjaalton> comments?
<tjaalton> some offsets when patching, nothing more severe
<tjaalton> not that many pure distro patches
<mlankhorst> can you check if the source code before and after is exactly the same?
<tjaalton> should be easy
<bryceh> "waiting for review" -> "waiting for review by upstream" ?  Maybe including a ML url or bug # would facilitate following up?
<tjaalton> took a git diff from both, diff'ing the diffs show no diff :)
<tjaalton> yeah
<bryceh> "from upstream, drop when rebasing"...  anything break if these are placed first instead of last?
<tjaalton> well, I think it's easier to rebase a single backported commit than possible several earlier ones
<tjaalton> usually they don't need any changes
<tjaalton> than just a refresh maybe
<bryceh> hmm
<bryceh> well I'll remain open minded
<mlankhorst> I just don't want to break things so as long as there is no diff I'm fine with it
<tjaalton> is it more confusing to leave the numbers or not?
<mlankhorst> renumber after you have the final sequence
<tjaalton> no numbers anymore :)
<bryceh> tjaalton, I think you're probably right to just drop the numbers
<bryceh> I'm partial to having the numbers myself, but objectively I think the purpose they serve is largely lost with xserver
<tjaalton> bryceh: yeah, it didn't really work out too well trying to use the numbers for different categories
<tjaalton> that was my idea too :)
<tjaalton> this should scale better
<mlankhorst> we should do a better job at dropping unneeded crap in xorg-server though :)
<tjaalton> sure
<tjaalton> this should make it easier
<ricotz> hi, why is there a need to call the package "nvidia-graphics-drivers-experimental-304" instead of just "nvidia-graphics-drivers-304"
<ricotz> and uploading 304.51 is probably the better choice here
<tjaalton> tseliot knows
<tseliot> ricotz: because we're going to use that package for experimental drivers and yes, I know a newer release has been available since yesterday
<tjaalton> and the new one seems somewhat broken
<tjaalton> bug 1056052
<ubottu> Launchpad bug 1056052 in xorg (Ubuntu) "Launcher not showing in auto-hide mode" [Undecided,New] https://launchpad.net/bugs/1056052
<ricotz> tseliot, i see, but including "experimental" and "304" doesnt make sense imo?
<tseliot> ricotz: the technical board decided that for a reason
<tseliot> ricotz: http://ubuntu.5.n6.nabble.com/Minutes-from-the-Technical-Board-meeting-2012-09-17-td4992536.html
<ricotz> tseliot, alright, that makes sense
<bryceh> ricotz, don't get hung up about it being 304, that's just being used to seed things with since we don't have a beta driver yet
<bryceh> ricotz, in practice we'll only be shipping pre-release drivers in -experimental
<ricotz> bryceh, yeah, that is why i was wondering. having "nvidia-graphics-drivers-experimental" and later "nvidia-graphics-drivers-304/ -306" seemed more logical, but it is fine since it was discussed
<czajkowski> elo anyone able to help me, not sure if's a bug or something has happened, I am running 12.10, I close the lid of machine and i come back to it and go to use it again, the screen is black but lit and I can see the cursor but no login prompt
<czajkowski> possibly this thinks laney https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/966744  but it's marked as not affecting 12.10
<ubottu> Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Quantal) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed]
<stgraber> I'm seeing something similar here though not limited to closing lid. For the past few days (3-4 days I think), whenever X shuts down the screen it seems to get stuck. When I get back to the machine, the screen turns back on but all I get is a blank screen with the mouse cursor
<stgraber> for now my workaround is to disable the screensaver completely so the screen never turns off, but that's no really ideal ;)
<stgraber> (intel hd4000 on an ivy bridge system)
<stgraber> I confirmed that it's not gnome-screensaver (killed from another tty), it could be compiz (killing it gets me the wallpaper but nothing else) and I'm not seeing anything in dmesg so if it's kernel, it's not obvious
<stgraber> oh, actually, I just noticed this in my X logfile:
<stgraber> [  7657.397] (WW) intel(0): flip queue failed: Invalid argument
<stgraber> [  7657.397] (WW) intel(0): Page flip failed: Invalid argument
<czajkowski> tjaalton: you about ?
<toabctl> czajkowski, stgraber i have the same issue here (i386, 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07))
<tjaalton> czajkowski: yes it's the same bug
<czajkowski> tjaalton: yes but it's now saying it doesnt affect Q from your latest comment on the bug 
<tjaalton> no, i removed compiz from there
<czajkowski> ah ok
<czajkowski> wel that bug is a bit of a pita right now :/
<czajkowski> although may disable my screensaver thanks to stgraber 
<tjaalton> and i have three intel laptops but can't reproduce it like others..
<czajkowski> tjaalton: :/
<czajkowski> tjaalton: you in the bluefin?
<tjaalton> no, just FI :)
<czajkowski> FI?
<tjaalton> finland
<czajkowski> ah right 
<czajkowski> well I cant send you my laptop 
<czajkowski> I need it for work
<czajkowski> if I can do any debugging and let you know stuff please just ask 
<tjaalton> czajkowski: https://bugs.launchpad.net/ubuntu/precise/+source/xserver-xorg-video-intel/+bug/966744/comments/226
<ubottu> Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Quantal) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed]
<tjaalton> there are a couple of traces attached, but I'm not convinced they're ok..
<tjaalton> so if it hangs on the first lid close, it should be easy to get a good one
<tjaalton> also, boot with 'drm.debug=0xe' and attach dmesg output from the hang
<bjsnider> tjaalton, you're located in finland?
<bryceh> bjsnider, he is
<bryceh> tjaalton, btw curious about your plan of attack for that bug?  Would it be worthwhile to post your directions on what you would do if you had the HW in front of you, so someone else that does have it could try those steps?
#ubuntu-x 2012-09-26
<tjaalton> bryceh: yeah, and I kinda wanted to have a separate bug like the one mdeslaur filed, just for that. but it got duped again :)
<tjaalton> sna would be one thing to try, even though it has backlight issues atm
<tjaalton> looks like sna fixed thumpers bug
<tjaalton> +'
<bjsnider> tjaalton, i've just gotten into the finnish symphonic metal/black metal scene. i'm sure it's commonplace in finland, but it came as a complete surprise to me
<bjsnider> i'm convinced that the best and most interesting music in the world is coming out of finland
<tjaalton> bjsnider: hehe
<tjaalton> yeah quite a few groups on that genre
<bjsnider> and they're genuises, all of them
<tjaalton> czajkowski: ping me when you're around, got something you could try
<mlankhorst> morning
<tjaalton> yawn
<mlankhorst> precisely
<mlankhorst> too early for fencing :(
<tjaalton> bryceh: btw, I find the release targeted buglists (linked from totals-foo-workqueue) hugely useful
<tjaalton> otherwise the bugs would get lost in the noise
<mlankhorst> yeah they are
<tjaalton> especially now as it lists incomplete bugs too
<tjaalton> i think before they were excluded
<bryceh> tjaalton, oh good to hear, yeah I use them a lot too
<bryceh> there's two kinds of incomplete bugs:  "With response" and "Without response".  The list excludes the latter only.
<tjaalton> ahh
<bryceh> that way if you ask a question and someone answers it, it'll pop back up on your list
<bryceh> but be aware if like I ask a Q and set to Incomplete, then you follow up with another question and leave it Incomplete, your comment will result in it turning into "With response"
<bryceh> so, when adding questions to an incomplete bug, just set it to New, then ask your Q and set back to incomplete, and that'll keep it off this list.
<tjaalton> heh, well that doesn't matter much, not much noise there anyway
<tjaalton> yet
<bryceh> tjaalton, did you see someone went through and tested a bunch of obscure video drivers and gave us bugs on each?
<bryceh> well, 3-4 bugs.  still, cute.
<tjaalton> bryceh: on quantal?
<bryceh> yeah
<tjaalton> oh, didn't notice it was the same guy
<tjaalton> ../../src/trident_dga.c:40:13: warning: 'TRIDENT_Sync' used but never defined [enabled by default]
<ricotz> bryceh, hi :)
<bryceh> heya ricotz 
<ricotz> bryceh, i wondering if there is some policy to join the ubuntu-x-swat group?
<ricotz> i am *
<bryceh> ricotz, there's definitely a policy I enforce
<bryceh> ricotz, but you definitely qualify.  :-)
<ricotz> bryceh, i thought about to join, but wasnt sure if i qualify ;)
<tjaalton> ha, ok both trident and mga failures are due to sloppy xaa removal work :)
<ricotz> bryceh, but while i saw the latest joins i got confused a bit
<bryceh> ricotz, you do, go ahead and apply and I'll approve you.  Thanks for asking first though, I appreciate it!
<bryceh> tjaalton, heh
<tjaalton> time to send patches then
<ricotz> bryceh, done
<bryceh> ricotz, yeah I admit the last couple approved members I felt marginal about their qualifications but they seemed interested.  I suspect they'll expire out.
<ricotz> bryceh, i see, dont worry then
<bryceh> I usually tell people what membership in ubuntu-x-swat implies (i.e. packaging work), and ask what they plan to use it for.  That seems sufficient to ward off most people who are just collecting badges or whatever.  The last couple people expressed interest in doing bug triage work.  We definitely need more triagers so I gave them the benefit of the doubt, and hope they do get involved.
<ricotz> bryceh, that is perfectly fine
<bryceh> ricotz, welcome to swat :-)
<ricotz> bryceh, thanks, yeah a new badge ;P
<tjaalton> now filter your email :)
<ricotz> tjaalton, i am already spammed with all kind of things ;)
<tjaalton> oh heh, we've uploaded -mga 1.6.1 as 1.6.0
<tjaalton> by we I mean me
<mlankhorst> the royal we
 * mlankhorst testing vblank on patch
<tjaalton> chrisccoulson: hey, you were able to hang compiz like everyone else?
<tjaalton> on suspend/screensaver
<chrisccoulson> tjaalton, yeah, although i've set "Turn screen off when inactive" to "Never" in the control centre now, to avoid it :)
<tjaalton> chrisccoulson: understood :) was just wondering if you could try the newer acceleration method to verify it doesn't happen there
<tjaalton> though it has issues of it's own, but not this severe
<tjaalton> at least here
<chrisccoulson> tjaalton, yeah, can do. although it'll need to wait a few minutes for some other stuff to finish first
<tjaalton> chrisccoulson: sure thing, you can check out the typo'ed xorg.conf from bug 1043562
<ubottu> Launchpad bug 1043562 in xserver-xorg-video-intel (Ubuntu) "[gm45] GPU lockup EIR: 0x00000010 PGTBL_ER: 0x00000001 IPEHR: 0x60020100" [High,Incomplete] https://launchpad.net/bugs/1043562
<mlankhorst> seems that my vblank patch works, even though that card has no output :x
<tjaalton> chrisccoulson: so comments #4 & 5
<chrisccoulson> tjaalton, yeah, will do
<tjaalton> it'll hit bug 1055987, but a simple vt change will remedy that
<ubottu> Launchpad bug 1055987 in xserver-xorg-video-intel (Ubuntu) "[sna] Need tty switch after screen off to resume display" [Low,Confirmed] https://launchpad.net/bugs/1055987
<tjaalton> hmm, wonder if we should provide a build of -intel with --enable-debug
<RAOF> Sounds like a job for xserver-xorg-video-intel-dbg!
<tjaalton> oh you mean build two versions and ship the other one with -dbg?
<tjaalton> --enable-debug adds debugging output to the logfile
<tjaalton> I was thinking more like putting the other one in a ppa :)
<tjaalton> chrisccoulson: had time to test yet? you can speed it up by changing the screen off timer to one minute, and then go through a couple of cycles
<tjaalton> enough to make sure it would've hung before
<tjaalton> and vt changes in between to wake the backlight :)
<RAOF> tjaalton: I mean build two versions and ship the other one with -dbg, yes.
<RAOF> You know what they say - built twice, ship once.
<tjaalton> yeah, why not
<chrisccoulson> tjaalton, i've got a job running over SSH at the moment. i need to wait for that to finish before i risk anything that might result in me needing to reboot :)
<mlankhorst> guess I'll see if I can fix the quantal stack
<tjaalton> chrisccoulson: ok gotcha :)
<seb128> chrisccoulson, tjaalton: is that the blank screen after dpms issue?
<chrisccoulson> seb128, yeah
<seb128> where is the fix to try?
<tjaalton> seb128: trying if 'Option "Accelmethod" "sna"' works around it
<tjaalton> it would at least narrow it down to the uxa code in the -intel driver..
<tjaalton> heard positive results from it so far
<seb128> tjaalton, you don't have a full xorg.conf I could copy by any chance?
<tjaalton> seb128: hang on
<tjaalton> seb128: can you reproduce it at will?
<seb128> I tried to not run often into it, but I got it the only time I let my screen go to idle the other day
<seb128> and I got it today when I undocked my laptop
<tjaalton> ok, "good"
<seb128> (though the undock could be another issue)
<tjaalton> http://pastebin.com/nb6zhmcE
<mlankhorst> tjaalton: can you upload xxv-nouveau to quantal-proposed? (I guess archive is still frozen)
<tjaalton> mlankhorst: -proposed is reserved for transitions, we can upload to quantal and it'll reopen after the beta
<mlankhorst> hm ok
<mlankhorst> Yeah seems the dpkg-control script creates slightly broken packages
<tjaalton> example?
<mlankhorst> every line with Replaces/Breaks/Provides/Conflicts that has a package name on the same line ends up with those packages being eaten entirely
<tjaalton> oh that
<mlankhorst> now confirmed it with random packages, but need to have this solved :-)
 * mlankhorst tries horrible hack
<tjaalton> seb128: did you get the pastebin link?
<seb128> tjaalton, yes, thanks, did restart yet though, I will try that in a bit
<tjaalton> seb128: ok, good
<tjaalton> ha, reproduced the hang on one of my machines
<tjaalton> finally
<tjaalton> but it took several cycles
<tjaalton> chrisccoulson, seb128: I'll take it back, testing sna isn't worth it. I'll build a test kernel with the crack-of-the-day..
<seb128> tjaalton, ok
 * mlankhorst gives up on gpg key for now, creates new one
<tjaalton> ok, building a drm-dkms package for quantal..
<mlankhorst> uploading ppa5 with the packages fixed :)
<mlankhorst> hopefully the issues I came across with the packages being borked day before the demo are gone now
<tjaalton> cool
<tjaalton> building ubuntu-r git + drm-intel-next-queued..
<tjaalton> hoping to retain overlayfs so sbuild works
<mlankhorst> Hah, you're building on dinq, I'm working on the code that eventually ends up there. :P
<tjaalton> we'll see if it builds
<mlankhorst> With intel qa, that's probably the only thing that works for sure
<tjaalton> heh
<tjaalton> gave up on the drm-dkms idea, not going to work
<tjaalton> crazy changes
<mlankhorst> hard to keep track of all, even..
<tjaalton> yeah, and irreversible changes ouside of drm
<tjaalton> well, not worth the effort anyway
<mlankhorst> wow, new nouveau kernel source.. I just don't get it..
<tjaalton> kernel buil
<tjaalton> t
<tjaalton> let's see if it works at all
<tjaalton> nope :P
<mlankhorst> so many spinlocks just called 'lock' with no clue what it protects
<mlankhorst> which is fun if foo->lock exists and you also have a foo->base.lock
<tjaalton> recorded the kernel oops with my phone, need to slow it down so I can see where it started :)
<tjaalton> need more hurts
<tjaalton> the machine is too fast
<tjaalton> moo, why doesn't shift-pgup work
<mlankhorst> no wonder things were failing, I made it act like work was still being done after it was already completed
<mlankhorst> yay, working now \o/
<om26er> hi, latest nvidia driver breaks autohide in unity we are getting reports
<om26er> 304.51
<om26er> bug 1057000
<ubottu> Launchpad bug 1057000 in Unity "[Ubuntu 12.04.1/12.10][7300GT] nVidia drivers 304.51 make Unity launcher not unreveal in the autohide mode" [Critical,Confirmed] https://launchpad.net/bugs/1057000
<bjsnider> does the .51 driver still support the 7300gt?
<bjsnider> i'd like to know if it happens on present-day hardware
<mlankhorst> probably should
<mlankhorst> hm it's a nv46
<mlankhorst> not going to be supported in the next one at least
<bryceh> RAOF, hey, for the nvidia experimental packages in NEW right now, since you're an archive admin are you empowered to wave them through?  Or can you handle only the SRU approval bit?
<bryceh> I'd like to get the 304 packages all the way to the end of the process prior to a "real" beta driver appearing so we know all the t's are crossed and i's dotted.  But in general I wonder if we need to streamline some of the review policies...
<RAOF> bryceh: I'm not a real archive admin â¹.
<bryceh> RAOF, I've gotten infinity on -devel who is taking care of it.
<bjsnider> RAOF is pretending to be an archive admin. actually he's a british spy under cover, and now he's admitted it
<bryceh> RAOF, the experimental drivers are now in precise-proposed.  Quick question for you with your SRU approver hat on: Since we are expediting this package as per TB, how long will the drivers need to sit in -proposed?
<RAOF> bryceh: I'm hunting the actual TB mail, but generally the answer would be âuntil it's been tested to workâ - we don't necessarily have to have the 7-day cooling off period.
<bryceh> ok
#ubuntu-x 2012-09-27
<bryceh> RAOF, http://ubuntu.5.n6.nabble.com/Minutes-from-the-Technical-Board-meeting-2012-09-17-td4992536.html
<bryceh> RAOF, I've just finished uploading the changes infinity asked for; theoretically it should all be ready for SRU review now, although he may need to push a couple buttons.
<RAOF> bryceh: Either it's waiting for infinity to push some buttons, or he's already done the SRU review. It's not in the precise-proposed queue, at least.
<bryceh> hmm
<bryceh> I did get the Accepted emails for it going into precise-proposed
<bryceh> http://people.canonical.com/~ubuntu-archive/pending-sru.html shows the two experimental-304 packages there
<bryceh> for nvidia-common and jockey those *just* got accepted so maybe the pending-sru.html page needs a little time to update
<RAOF> Yeah, they're all in -proposed. Have the -proposed packages been tested?
<bryceh> RAOF, not yet.  I'm EOD but will test them tomorrow.
<RAOF> Ok. They do need to be tested before promoting them to -updates ;)
<bryceh> yep, I know :-)
<bryceh> kids are at grandparent's tonight, and so wife wants a date
<RAOF> Sounds good!
<bryceh> hmm, found one bug already (but maybe local to jockey)
<bryceh> on a system with proposed already enabled, do apt-get update then try to launch jockey; jockey crashes with error on string "experimental-304"
<RAOF> I thought you were going out? âº
<mlankhorst> morning
<RAOF> Yo!
<RAOF> Hey, apropos nothing: do you have any insight as to when wine's dwrite will not be a huge pile of fail? Or, at least, when it'll render text in Steam? âº
<mlankhorst> No idea, I just disable the dll as soon as possible..
<mlankhorst> I don't really expect any time soon, though. Waiting on the new wine release though :-)
<mlankhorst> With a bit of luck this one won't break my dsound patch series in the series of commits done on the day of release..
<RAOF> Still no joy on getting an upstream pulseaudio backend?
<mlankhorst> RAOF: I gave up, I just help other distros that might want it now instead..
<mlankhorst> although one of the people there expressed interest in my dsound rewriting
<mlankhorst> the part where I ripped out the crappy mixer, at least
<RAOF> Everyone loves crappy mixers!
<mlankhorst> it was mostly ripping out the mixer control code and starting over, it was still based on the old driver model, so it detected underruns as buffered < 0, even though it could no longer happen, other fun stuff too
<RAOF> Ah. Code rot.
<RAOF> Wooo!
<mlankhorst> nah just maintainer not having a clue what that code did :-)
<RAOF> Sounds like code rot to me:)
<RAOF> Just with an imperceptible smell!
<mlankhorst> I mostly take http://repo.or.cz/w/wine/multimedia.git/shortlog and then convert it to a patch series
<RAOF> How did you go from winepulse v12 to winepulse v15 in one commit? :)
<mlankhorst> squashing
<bryceh> RAOF, turns out you can actually get a decent amount of testing done while waiting for your wife to get ready
<tjaalton> ok lets see if vanilla 3.6rc7+dinq boots..
<tjaalton> oh yes
<tjaalton> phew
<tjaalton> silly g-s-d sleep timer, it's actually 30s + the time you've set
<tjaalton> so it's 30s to determine that the machine is idle, and only then start the timer
<tjaalton> chrisccoulson: are you running amd64? got a kernel you could give a go..
<tjaalton> chrisccoulson: kernel from http://kernel.ubuntu.com/~tjaalton/lp966744/
<chrisccoulson> tjaalton, yeah, i can try that in a bit
<chrisccoulson> thanks
<tjaalton> chrisccoulson: also one thing, does it matter how long the screen has been idle (blank)?
<chrisccoulson> tjaalton, i'm not sure about that. i just use the default settings :)
<tjaalton> chrisccoulson: right, but if it hangs even if you try to wake it up right after it has blanked, then it's clear that the time spent while blank doesn't matter
<tjaalton> upload complete
<chrisccoulson> tjaalton, ah, sorry, i misunderstood what you were asking
<tjaalton> yeah, you should be able to lower the sleep timer to one minute in order to speed up the testing :)
<tjaalton> chrisccoulson: also, does it hang with nothing else than the bare unity desktop running
<tjaalton> guess the compiz hanger is related to the blanking that follows the fadeout
<tjaalton> did 50 cycles with the timer she
<tjaalton> *set so short that it didn't fade at all
<tjaalton> now I have two machines, the other with the fadeout hung after maybe five cycles, the other doing ten just fine
<mlankhorst> and then i broke things again somehow, :-(
<chrisccoulson> tjaalton, hi, i tried that kernel and got the same hang :(
<chrisccoulson> i did notice that i don't get it if gnome-screensaver isn't running though
<chrisccoulson> oh
<tjaalton> chrisccoulson: ok, so try setting the idle timeout with dconf-editor
<tjaalton> org.gnome.settings-daemon.sleep-display-*
<tjaalton> set it to, say 5
<tjaalton> chrisccoulson: I can reproduce it as well, but _only_ if I set the timer so low that the fadeout doesn't happen
<tjaalton> err
<tjaalton> if I don't set..
<tjaalton> hmm right, with the timer set below 60 gnome-screensaver isn't running
<chrisccoulson> tjaalton, i'm actually just about to test a build of gnome-screensaver with the fade disabled entirely
<tjaalton> chrisccoulson: ah, nice :)
<chrisccoulson> tjaalton, hmm, it still happens with no fade
<mlankhorst> just realized lockdep was disabled, but it's not the cause things messed up :\
<tjaalton> chrisccoulson: ok
<tjaalton> chrisccoulson: yeah the fadeout just happens to come from g-s, noticed it afterwards that g-s wasn't running
<mdeslaur> chrisccoulson: I don't get the issue if I turn off the dpms screen blanking in the settings
<mdeslaur> (ie: Brightness and Lock/Turn screen off when inactive for: Never)
<tjaalton> right
<tjaalton> mdeslaur: did I already ask you to try the other accelmethod on it? put http://pastebin.com/nb6zhmcE in xorg.conf, enable the timer and see if it hangs when the screen blanks
<tjaalton> sounds like there is a race in the uxa code of -intel
<tjaalton> which is why I can't for some reason reproduce it every time
<mdeslaur> tjaalton: could you give me a complete xorg.conf?
<tjaalton> that's it
<mdeslaur> ok
<tjaalton> you don't need anything else
<tjaalton> currently at 15 cycles myself, before it hung after six
<tjaalton> well, needed 5-10 cycles
<mdeslaur> tjaalton: ok, let me reboot and try it
<tjaalton> logout is enough
<tjaalton> heh, glxgears starts spinning "faster" when the screen is off
<tjaalton> mdeslaur: verify that sna is working; 'grep SNA /var/log/Xorg.0.log'
<mdeslaur> tjaalton: rebooted, closed lid, opened lid, screen was black with no backlight, and I couldn't even VT switch
<tjaalton> oh
<tjaalton> that's new then :P
<mdeslaur> (II) intel(0): SNA initialized with Ironlake backend
<tjaalton> no session running yet?
<mdeslaur> tjaalton: yes, that's after logging in, sorry
<tjaalton> ok
<tjaalton> can you log in remotely?
<mdeslaur> tjaalton: I go for lunch in a couple of hours, I'll see if the dpms/screensaver causes it
<mdeslaur> tjaalton: yes
<tjaalton> you can speed it up by setting the timeout to one minute
<tjaalton> what's in dmesg?
<tjaalton> or X0rg.0.log tail
<mdeslaur> tjaalton: I've rebooted, you want to know what's in there when it failed?
<tjaalton> yes, if possible
<tjaalton> or hmm
<tjaalton> maybe not worth it
<tjaalton> let's concentrate on this one
<tjaalton> the original bug
<mdeslaur> tjaalton: this is my Xorg.0.log.old file: http://paste.ubuntu.com/1230387/
<mdeslaur> nothing interesting I think
<mdeslaur> ok, I'll leave it be for a couple of minutes and see if it does it
<tjaalton> ok so it just failed to dpms on the display
<tjaalton> which is kinda expected, though should work on s&r
<tjaalton> a vt change should revive it
<tjaalton> and does here
<mdeslaur> vt switching didn't work for me
<mdeslaur> ok, attempt #2 of not touching keyboard now :)
<tjaalton> *bitenail*
<tjaalton> heh
<mdeslaur> tjaalton: same thing, dpms switches screen off, and I can't get it back on again, even with a vt switch
<mdeslaur> http://paste.ubuntu.com/1230397/
<mdeslaur> http://paste.ubuntu.com/1230398/
<mdeslaur> so, I've turned SNA back off
<tjaalton> good move
<tjaalton> and thanks
<mdeslaur> tjaalton: np
<tjaalton> didn't really confirm anything, it could be just as hung with sna or the backlight issue is "special" on your machine..
<mdeslaur> yep, could be a different issue
<mdeslaur> *sigh*
<mdeslaur> I have an idea: the kernel and X should only be updated in the dev release if they manage to pass QA on all hardware in the canonical lab
<mdeslaur> (we'll never get a new kernel or a new X again!)
<tjaalton> solid idea :)
<mlankhorst> We could call it ms windows?
<tjaalton> yep
<mlankhorst> Oh wait, I know..
<mlankhorst> "There is no problem in our code, it is an incompatbility between drivers and the version of the code you're running"
<mlankhorst> does that sound good?
<tjaalton> perfect
<mlankhorst> "Please contact your manufacturer for updated drivers, we are sorry we could not be of more assistence"
<mlankhorst> Ok so I'm going to hell, at least it's warm here. :D
<mdeslaur> hehe
<mdeslaur> I would be a lot simpler if canonical made hardware :P
<smartboyhw> ;P
<mlankhorst> In fact we shouldn't leave it at that, we should make our own users
<mdeslaur> mlankhorst: sweet! We could probably get amazon to help :)
<tjaalton> I got three commits from ickle to try, will rebuild -intel and push it to the url for folks to try
<tjaalton> mdeslaur: about? I have a driver to test
<mdeslaur> tjaalton: uh, yeah...not right now though
<tjaalton> ok
<tjaalton> I'll ask someone else then :)
<mdeslaur> tjaalton: I'm in the middle of something, but if you give me a link, i can try it a little later
<tjaalton> there are plenty of victims
<mdeslaur> hehe
<tjaalton> yeah I'll put it in http://kernel.ubuntu.com/~tjaalton/lp966744/
<mdeslaur> tjaalton: ok, restarting with test driver now
<mdeslaur> ooh! lid close didn't reproduce!
<mdeslaur> now to test inactivity
<tjaalton> :)
<mdeslaur> tjaalton: I think we may have a winner!
 * mdeslaur looks around for some wood
<tjaalton> just don't knock it :)
<mdeslaur> tjaalton: ok, I can't seem to be able to reproduce anymore...I'll continue running this test driver, and will let you know if it pops up again
<tjaalton> mdeslaur: great, thanks for testing
<tjaalton> I'll update the bug..
<mlankhorst> should I apply for core dev?
<Sarvatt> mlankhorst: i'm going to ask for an xorg package set here soon
<mlankhorst> Sarvatt: what do you need?
<Sarvatt> i mean you can do PPU for that instead, which might have a chance of getting accepted instead of core dev straight away :)
<mlankhorst> ah :p
<mlankhorst> but I need initramfs-tools and linux too
<Sarvatt> just need to make up a list of all of the packages
<mlankhorst> so dno, doesn't seem that useful
<mlankhorst> especially not if there will be the renamed versions soon as well
<Sarvatt> oh i dont think linux will happen, kernel team does that
<tjaalton> mlankhorst: yes please
<mlankhorst> Sarvatt: it's just I tend to work on some packages outside of xorg too when they get in the way, so I think just the set wouldn't make much sense, since it's so broad you effectively end up with the same
<Sarvatt> need to fill out my info on https://wiki.ubuntu.com/Sarvatt/DeveloperApplication-PPU still, sheesh
<tjaalton> heh, my wife just hit the bug on my primary laptop which doesn't have the fix yet.. saved her work by forcing metacity from a vt
<mlankhorst> is it just me or do I get really bad redraw bugs in quantal + unity?
<tjaalton> I haven't seen much
<mlankhorst> the windows themselves are fine, just the background doesn't get rendered
<mlankhorst> I'll isolate it
<mlankhorst> https://wiki.ubuntu.com/MaartenLankhorst/DeveloperApplication btw
#ubuntu-x 2012-09-28
<bryceh> http://www.bryceharrington.org/files/nv_exp.png
<tjaalton> the parentheses look confusing :)
<bryceh> tjaalton, the ones around (**experimental** beta) ?
<bryceh> they appear traditional
<tjaalton> the double ones
<tjaalton> not just for the new driver
<bryceh> oh, gotcha.  yeah, that is a bit weird.  But yeah, traditional
<tjaalton> right
<bryceh> the first set is part of the title, the second set is added by "something else"
<tjaalton> yeah
<bryceh> the important thing here is *yay* experimental drivers install and work
<bryceh> and, *yay* patched up jockey displays everything properly
<tjaalton> isn't 304 the stable series and not beta?
<bryceh> pretend it's beta
<tjaalton> heh
<bryceh> the important thing is it's getting sorted as *last*.  Currently the sort is random.
<tjaalton> ah
<tjaalton> on another note, the #1 intel bug seems to be fixed now, been surprisingly quiet the past 10h
<bryceh> and actually the version in beta right now is a new version (3.04.48) not otherwise available via jockey in precise
<tjaalton> not in the distro yet though
<bryceh> tjaalton, sweet, what was the bug?
<tjaalton> bug 966744
<ubottu> Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Precise) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed] https://launchpad.net/bugs/966744
<bryceh> oh hells yeah
<tjaalton> there's an additional kernel commit that ickle sent to intel-gfx
<bryceh> tjaalton, good work
<bryceh> btw, I had a call with Intel today in regards to stack updates on 12.04
<tjaalton> most of it was convincing ickle that the bug with suspend & resume is the same one with a normal dmps cycle that people were hitting (as well) :P
<tjaalton> not the backports stuff?
<bryceh> they'll be providing us with new packaged versions of all the various pieces they want updated on 12.04.  ddx driver, mesa, cairo, etc. etc.
<tjaalton> oh
<bryceh> tomorrow I will be hooking them up
<bryceh> with a PPA they will be posting this stuff to for testing.
<tjaalton> -intel 2.20.9, libdrm 2.4.39, mesa 8.0.5.. what else?-)
<bryceh> that, and cairo, intel-vaapi-driver, libva, and...
<bryceh> they're creating a dkms package of i915 kernel module + dependent modules.
<tjaalton> so they'll run the tests and then later ack them for SRU?
<tjaalton> ouch
<tjaalton> that'll be fun :)
<tjaalton> (dkms)
<bryceh> no SRU; ultimate goal will be to get into x-updates.
<tjaalton> ok
<bryceh> tjaalton, so in fact I need to touch base with you, Sarvatt, RAOF, and other folks concerned about x-updates, that updating these pieces in x-updates is going to be acceptable.
<tjaalton> no objections there
<tjaalton> it's opt-in anyway
<bryceh> think I'll post an email to xorg-devel tomorrow
<bryceh> right.
<tjaalton> ubuntu-x you mean?-)
<bryceh> yeah
<bryceh> there might be some concern about changing mesa for x-updates since it's also used for updating nvidia and fglrx
<tjaalton> i've not used x-updates at all.. will take a closer look soon
<tjaalton> bryceh: shouldn't matter
<bryceh> yeah I know.  But I just want to make sure we're all in agreement.
<RAOF> I'm perfectly happy for intel to push updates into x-updates; that seems eminently sensible.
<tjaalton> let's trick their qa folks into subscribing to -intel bugs.. ;)
<bryceh> RAOF, thanks.  Yeah that's my opinion as well.
<bryceh> tjaalton, haha
<tjaalton> gen4 chips seem to be getting gpu lockups on quantal
<tjaalton> more than the others
<tjaalton> bryceh: so it's them pushing the updates there, or they'll suggest the versions and we upload?
<tjaalton> guess the latter would work best
<bryceh> tjaalton, so far it's the  latter
<tjaalton> oh hey, looks like the xserver regression with the previous sru for precise that got reverted is fixed now
<bryceh> tjaalton, tomorrow I'll create a staging ppa for them under ubuntu-x-swat.  Later when they feel things are sufficiently good to go they'll cue us to pull stuff into x-updates
<tjaalton> [PATCH] dix: fix crash on XI 1.x grabs on disabled devices. (#54934)
<tjaalton> unless I'm mistaken
<tjaalton> bryceh: ok
<bryceh> great, what's the bug #?
<tjaalton> bug 1021517 (fixed by reverting the sru)
<ubottu> Launchpad bug 1021517 in xorg-server (Ubuntu Precise) "Xorg-server crashes reproducible with GIMP usage" [High,Fix released] https://launchpad.net/bugs/1021517
<tjaalton> bryceh: you could use x-staging for that
<tjaalton> which reminds me, time to clean it up
<bryceh> tjaalton, ah good idea, I'll consider that
<tjaalton> it's only used once per release
<tjaalton> and now with -proposed not even that
<bryceh> re bug 1021517, good to hear that's finally getting sorted
<ubottu> Launchpad bug 1021517 in xorg-server (Ubuntu Precise) "Xorg-server crashes reproducible with GIMP usage" [High,Fix released] https://launchpad.net/bugs/1021517
<bryceh> tjaalton, they may prefer to have a new ppa just for complete isolation.  But I'll think about it tomorrow.
<bryceh> now that we can fairly easily delete ppas, no harm in creating extras.
<tjaalton> it's empty now
<tjaalton> time to delete x-retro?-)
<tjaalton> oh well, deleted the obsolete packages (for hardy, jaunty, karmic)
<tjaalton> hmm so x-staging & x-testing, what's the difference?
<tjaalton> cleaning up -testing
<bryceh> theoretically x-retro should still have a use, although admittedly there's probably nothing for it now
<bryceh> yeah, x-staging and x-testing are probably redundant.
<tjaalton> they're all clean now :)
<tjaalton> =empty
<tjaalton> sorry, left a couple of packages in retro
<bryceh> we need more community contributors.
<jcristau> bryceh: you had timo, but then you hired him!
<jcristau> :)
<bryceh> jcristau, indeed... sensing a pattern...
<tjaalton> ha
<bryceh> of course, once wayland takes over, we won't have anymore bugs.
<jcristau> rrrright
<mlankhorst> morning
 * bryceh waves
<mlankhorst> bryceh: can you endorse my dev application? Also nice work on that nv_exp screen :-)
<bryceh> mlankhorst, alright
<bryceh> mlankhorst, btw time to start thinking about how we can start getting folks testing the LTS point release X stack.  you probably should get in contact with Jono about getting some attention on it in Oct.
<mlankhorst> I think that's a topic for uds
<tjaalton> there's some oibaf dude doing stuff all on his own: https://launchpad.net/~oibaf/+archive/graphics-drivers
<tjaalton> never heard of him
<mlankhorst> but ok I'll just upload all drivers to the ppa again in a bit
<mlankhorst> I sort of want to have wine-1.5 upgrading properly with the q-lts-backport ppa before I want more widespread testing on it
<bryceh> mlankhorst, good.  Yeah I think UDS may be postponing it too far, you may regret it later.  But if you can get testing started now, you'll be in a much better position when UDS rolls around.
<mlankhorst> well the real challenge IS going to be getting fglrx working, the rest should be fine
<tjaalton> there's a compatible version in quantal now
<tjaalton> 9.000000
<bryceh> yeah I saw there's a new version today
<mlankhorst> ok in that case I'll just re-upload the entire stack
<bryceh> tjaalton, "oibaf" sounds familiar for some reason
<tjaalton> it was on phoronix once, I think
<bryceh> tjaalton, would you mind touching base with him and see if he'd be interested in joining swat?  Looks like a useful fellow.
<mlankhorst> tjaalton/raof: can you endorse my dev application?
<bryceh> might be he's only interested in building a side-empire; of course that's fine too.  We should invite him to be part of the team none-the-less.
<tjaalton> bryceh: yeah, I could
<tjaalton> mlankhorst: sure
<mlankhorst> https://wiki.ubuntu.com/MaartenLankhorst/DeveloperApplication
<mlankhorst> rebuilding q-lts-backports atm :-)
<mlankhorst> weird, my other system has the corrupted bg too
<mlankhorst> oh
<mlankhorst> it was still trying the old background but that one was probably removed
<mlankhorst> so instead it did the insane thing and never drew anything at all :-)
<tjaalton> hehe
<mlankhorst> now I fear that my -all package might not show up in armhf :(
<ogra_> mlankhorst, why wouldnt it ?
<mlankhorst> copied it from a ppa that didn't have it enabled and it didn't list it
<ogra_> oh, yeah, PPAs are spethial
<mlankhorst> so just rebuilding now, just in case
<mlankhorst> trying to get armhf q-lts-backports too
<mlankhorst> https://launchpad.net/~mlankhorst/+archive/ppa armhf enabled version
<ricotz> mlankhorst, you probably want to use the newer wayland snapshot while you are using one
<mlankhorst> ricotz: I just take whatever is going to end up in quantal, it's just to satisfy build-depends
<ricotz> alright
<ricotz> mlankhorst, updating wayland like this will break the current precise mesa if this matters
<mlankhorst> sigh, I guess the solution would be to rename wayland too?
<ricotz> i guess so
<mlankhorst> does weston need updates too in that case?
<ricotz> not sure if this is worth a trouble to prevent runtime breaks but it will break the precise mesa build at least
<ricotz> mlankhorst, yes, if you want to keep it working ;)
<mlankhorst> RAOF: ping?
<tjaalton> lets just update wayland/weston in precise
<tjaalton> not that it's any use, but neither is the old version
<mlankhorst> yeah and have it depend on the renamed packages
<tjaalton> +of
<mlankhorst> it should be possible to just use new mesa with old xorg
<tjaalton> ahh right
<tjaalton> now i see
<mlankhorst> won't be really useful
<tjaalton> damn build-depends
<tjaalton> or just remove the old wayland/weston :)
<tjaalton> maybe not possible, dunno
<ricotz> tjaalton, removing them sounds like a better idea
<tjaalton> hmm, same effect really
<mlankhorst> it's in universe though
<tjaalton> mesa needs newer libwayland-dev, so it has to be updated, and no reason to keep the old one
<tjaalton> really?
<tjaalton> weston maybe
<tjaalton> it doesn't matter
<mlankhorst> oh its not, in main
<mlankhorst> :(
<mlankhorst> however we could probably update it and make it depend on the new stack if needed
<tjaalton> right
<tjaalton> the old one is obsolete anyway
<tjaalton> so just sru whatever ends up in quantal
<mlankhorst> I'll leave it at the new version for now, I think it builds just fine without the new mesa so there shouldn't be an issue
<tjaalton> hmm, there's still the old version in precise, new will end up in -updates
<tjaalton> or is it
<tjaalton> I don't know how that archive s*it works :)
<tjaalton> right, you can use the old one explicitly, -updates will have the new one
<mlankhorst> yeah it's great fun with all those depends
<tjaalton> and mesa is happy
<mlankhorst> could try if old mesa builds against new wayland
<tjaalton> unless the old mesa isn't happy with the new version (in case there'll be bugfixes)
<tjaalton> echo :)
<mlankhorst> :P
<mlankhorst> -EAGAIN really
<mlankhorst> and I didn't even upload xorg-server yet :(
<mlankhorst> although at that part the fun stops since everything is easy from there..
<ricotz> tjaalton, thanks :)
<mlankhorst> I should probably add the renamed linux kernel to recommends as well
<tjaalton> ricotz: the other one needs an ffe first
<tjaalton> libbluray looked more like a bugfix release
<ricotz> tjaalton, libaacs is fine already
<ricotz> tjaalton, hmm, my name doesnt come up as uploaded in launchpad for libbluray
<ricotz> *uploader
<tjaalton> ooh, syncpackage supports fakesync
<mlankhorst> nice
<cos-> hello, ubuntu-bug asks to get technical help first before submitting a new bug but i guess i'll just do it first
<tjaalton> just file the bug
<cos-> i'm a bit confused about how to set up a elo serial touchscreen.
<cos-> i tried to follow these instructions https://help.ubuntu.com/community/EloTouchScreen
<cos-> .. but it says evtouch has been removed from ubuntu
<cos-> the touch screen is detected by xorg (after running inputattach) but i'm not sure how to configure it
<tjaalton> google for peter hutterer's blog
<cos-> should the InputClass definition in xorg work without evtouch?
<tjaalton> there should be instructions for setting it up with -evdev
<cos-> thanks, found it
<cos-> i already filed this, but i suppose evdev is the way to go https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-elographics/+bug/1058109
<ubottu> Launchpad bug 1058109 in xserver-xorg-input-elographics (Ubuntu) "Elographics touch event freezes Xorg" [Undecided,New]
<tjaalton> yeah, iirc
<cos-> i believe i tried everything in this post http://who-t.blogspot.fi/2012/07/elographics-touchscreen-setup.html
<cos-> i don't have the touchscreen here at work so i could verify but i'll try again next week
<cos-> the actual problem is that y-coodrinate is reversed and the evdev InvertY option does nothing
<tjaalton> ok, that's a bug then
<cos-> should i file it?
<smartboyhw> cos-, should
<cos-> if it helps, i can lend the hardware to devs in finland if needed.. and possibly elsewhere unless shipping is very expensive
<tjaalton> heh, i'm in espoo
<cos-> i'm coming to wÃ¤rk:fest in 3 weeks and could bring the hw with me if needed
<cos-> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/1058120
<ubottu> Launchpad bug 1058120 in xserver-xorg-input-evdev (Ubuntu) "InvertY option is ignored on ELO touchscreen" [Undecided,New]
 * mlankhorst wonders if launchpad will time out from simply copying over mesa for 4 archs
<mlankhorst> well my local system is definitely beating the launchpad builders
#ubuntu-x 2012-09-29
<bryceh> RAOF, for the experimental driver testing, I found several bugs, which I've fixed and have new packages to upload.  Should I use the same version numbers as before, or make a new version with new cl entry?
<Sarvatt> RAOF: you can move ~/.local/share/FasterThanLight/prof.sav to ~/My\ Games/FasterThanLight/prof.sav to switch between the linux and steam versions
<mlankhorst> or symlink My\ Games to .local/share *ducks*
<tjaalton> mlankhorst: so how does this pandaboard thingy work? :)
<mlankhorst> just put some image on a sd-card and boot it
<mlankhorst> http://omappedia.org/wiki/Ubuntu_Pre-Built_Binaries
<mlankhorst> needs patience the first time though while it's resizing, you don't get any feedback
<tjaalton> how big should the sd card be?
<mlankhorst> no idea, I think I have a 32g one, since it was cheap-ish
<mlankhorst> and my phone no longer needed it
<tjaalton> heh, I have an extra 1GB
<tjaalton> probably too small for desktop
<mlankhorst> yeah quite
<tjaalton> ok, they are cheap so I'll go and buy one
<mlankhorst> requirements are similar for normal ubuntu
<mlankhorst> sigh panda hates me, time to reinstall it
<tjaalton> mmm.. I'll get a new card reader as well, lexar pro usb 3.0 seems nice
<mlankhorst> any laptop comes with one :p
<tjaalton> slow ones
<tjaalton> and only sd, I need CF too
<tjaalton> for my dslr
<tjaalton> whee, -intel 2.20.9.. I'll push it right away
<mlankhorst> :D
<mlankhorst> it's weekend, do something fun instead
<tjaalton> I just assembled a new bed for one of the kids
<mlankhorst> or add a testimonial to my dev application, that should be fun
<tjaalton> oh right.. I'll save that for monday :)
<mlankhorst> :-(
<tjaalton> sry
<mlankhorst> heh im out for a bike ride anyway
<mlankhorst> :D
<tjaalton> I have floorball tonight, that's fun
<bryceh> RAOF, I went ahead and just created new version numbers.
#ubuntu-x 2012-09-30
<Milos_SD> Hello... Does anyone have an idea how can I purge xorg-edgers packages a revert to default on ubuntu 12.04 64bit?
<Milos_SD> :)
<mlankhorst> Milos_SD: ppa-purge ppa:xorg-edgers/ppa or something
<Milos_SD> mlankhorst, that doesn't work on 64bit :(
<Milos_SD> ppa-purge or aptitute doesn't work with multiarch...
<tjaalton> no reason why they shouldn't
<tjaalton> meh, installing the powervr blob on the panda made it more sluggish
<mlankhorst> uploaded the new stack to my ppa, with armhf so I'm going to test on my panda :p
<mlankhorst> tjaalton: you need to have the ti-omap ppa
<mlankhorst> Currently 12 packages building and 26 packages waiting to build.. poor pandaboard ppa builders
<tjaalton> mlankhorst: ah, ok
<tjaalton> still on precise
<mlankhorst> yeah but you need to remove the mem=... args from /boot/boot.script else the ti kernel will go lockup 
<mlankhorst> and install ubuntu-omap4-extras
<tjaalton> ok
<mlankhorst> if you use unity3d, you need to add option 'hwcursor' 'false' to /usr/share/X11/xorg.conf.d/99-*omap*.conf to prevent massive glitches
<mlankhorst> and I think there was some bug with smp in the 1486 kernel so you might need nosmp too, I'm using that for now.
<tjaalton> what a mess :)
<mlankhorst> well robclark helped me a little with sorting those quirks out
<mlankhorst> wow no launchpad queue, all my non-arm uploads finished \o/
<Sarvatt> tjaalton: ha, go figure i finally hit that black screen bug right after you uploaded the fix and i hadn't rebooted into it yet
<mlankhorst> :-)
<tjaalton> Sarvatt: hehe
<ehoover> Hello, sorry to be a bother - but who would I contact to get an XCB upstream patch applied to the current ubuntu package?  The patch fixes a pretty significant problem for Wine and I'd like to get it fixed before 12.04.2/12.11.
<tjaalton> which bug?
<ehoover> https://bugs.freedesktop.org/show_bug.cgi?id=54671
<ubottu> Freedesktop bug 54671 in Library "Wine locks up when running multithreaded applications that touch both OpenGL and X11" [Normal,Resolved: fixed]
<tjaalton> no I mean on launchpad
<ehoover> I haven't created a bug for it on launchpad, I was working directly with upstream.  Would it help for me to do that?
<tjaalton> for SRU's it's mandatory
<ehoover> I'm sorry, I'm not familiar with your procedures (I've never had to do this before).  Could you point me to what I need to read so that I'm not bothering you unnecessarily?
<Sarvatt> yeah it would help a lot, we're frozen for 12.10 so it has to reference a launchpad bug to upload the fix (and a 12.04 stable release update would absolutely need a launchpad bug), ubuntu-bug xorg will fill out most of the info for you
<tjaalton> just file a bug against libxcb
<tjaalton> or that
<Sarvatt> couldn't figure out the ubuntu-bug invocation for libxcb from a quick try :P
<Sarvatt> oh ubuntu-bug libxcb1
<tjaalton> or the source package
<tjaalton> but lp will map it there if it's filed against the binary package
<Sarvatt> ubuntu-bug libxcb doesn't work
<tjaalton> á¸§uh
<tjaalton> ok
<tjaalton> right, it's apport..
<ehoover> ok, i've filed bug https://bugs.launchpad.net/libxcb/+bug/1059276 and linked it to the upstream bug.  Should I copy the details of the issue to the launchpad bug or is that unnecessary?
<ubottu> Launchpad bug 1059276 in libxcb (Ubuntu) "Wine locks up when running multithreaded applications that touch both OpenGL and X11" [Undecided,New]
<Sarvatt> hmm, i can't nominate for series on that bug
<Sarvatt> ehoover: so what app is hitting that for you? can't say i've noticed the problem ever with wine, going to need some kind of test case for a precise fix to happen
<ehoover> Sarvatt: I've seen it with Borderlands and Silverlight.  Others have reported issues with Skyrim and a few other apps.  Would you like me to link in the Wine bug?
<bryceh> RAOF, when you get in:  I've uploaded new jockey and nvidia-common for bug #1047681.  Mind reviewing/accepting them?
<ubottu> Launchpad bug 1047681 in jockey (Ubuntu Quantal) "Add package nvidia-experimental for tracking nvidia beta drivers" [Wishlist,In progress] https://launchpad.net/bugs/1047681
<mlankhorst> oh
<mlankhorst> well testing on my panda, seems i need some explicit depends on libgl1-mesa-glx-lts-quantal to upgrade things correctly, need to figure out a correct fix for that
<mlankhorst> other than that it works it seems
#ubuntu-x 2013-09-24
<linfeng> hello every X man
<linfeng> Hope I'm not in a wrong chanel :)
<linfeng> I want to seek help about building xorg-server for ubuntu ?
<mlankhorst> apt-get build-dep xorg-server; apt-get source xorg-server; cd xorg-server; dpkg-buildpackage ?
<linfeng> My problem is that I want to backport a patch for xorg 1.6.4, and rebuild it for exactly ubuntu 9.10. I google for a long time but can't find any guidance about this.
<tjaalton> erf
<tjaalton> 9.10 is EOL a long time ago
<mlankhorst> and that^
<tjaalton> without any security support for 2,5y now
<linfeng> yes, I know. I just want to rebuild it, but I can't find the *official* confirue option for u910.
<linfeng> Is there any way that I can find the building options?
<tjaalton> grab the source like mlankhorst advised, then read debian/rules
<tjaalton> and modify, then run dpkg-buildpackage to build a package..
<tjaalton> maybe touch debian/changelog too to change the revision
<linfeng> Hmm, I have got the source by apt-get souce.
<linfeng> Thank you, then I will try to read debian/rules.
<Dandel> Any ideas on when xorg edgers will have test packages for mesa that enable radeon uvd through vdpau? ( This includes some patches for GL_NV_vdpau_interop )
<Dandel> I also know of some alsa patches that 7.1 surround sound on top of a few other features for the radeon hda codec.
<mlankhorst> Dandel: no idea :P
<tjaalton> nice, can't log in after latest updates
<tjaalton> removed a crash file and it works again..
<Prf_Jakob> Hello
<Prf_Jakob> It looks like you guys have the wrong pm-quirk for SVGA, yeilding to suspend hanging the device.
<Prf_Jakob> is this the right place to get that changed or is there a better channel for that?
<Prf_Jakob> http://paste.ubuntu.com/6128545/
<tjaalton> probably #ubuntu-devel material, but first thing to do is file a bug against pm-utils :)
<bjsnider> tseliot, so what's the deal with nvidia-persistenced? referenced in saucy but no package is there
<tseliot> bjsnider: I think it's still stuck in the queue and I've kind of given up on it
<bjsnider> tseliot, the release notes suggest that it's inside the nvidia-installer somewhere, although i haven't unpacked it to check. why not just add it to nvidia-graphics-drivers? why a separate package?
<tseliot> bjsnider: it's the only way to control what happens and to fix things if there are problems
<bjsnider> tseliot, so is there somewhere you can get the code other than the installer, or do you unpack it and grab the code from there, or how does that work?
<tseliot> bjsnider: yes, nvidia has a git repository on github
<Dandel> tseliot, On that repository there is actually one key entry that probably should be expanded for mir/xmir and other things... the vendor independent gl libs.
<Dandel> libglvnd ( https://github.com/NVIDIA/libglvnd ) the GL Vendor-Neutral Dispatch library.
<tseliot> Dandel: that's a proposal but I haven't heard much about its adoption on the mailing lists
<tjaalton> a skeleton package is on pkg-xorg
<tjaalton> didn't build the last time I tried
<Dandel> tseliot, I got the libglvnd compiled without much work.
<tjaalton> there's a presentation about that tomorrow at xdc
<tjaalton> well it's still not that usable atm
<tseliot> exactly my point ^
<Dandel> Of course it's not usable yet... I Think the package is eventually meant to be properly integrated into mesa
<tjaalton> it doesn't need to be a part of mesa
<tjaalton> supported by it, sure
<tjaalton> dunno
<tjaalton> could be wrong
<RAOF> Doesn't need to be a part of mesa, and shouldn't be.
<RAOF> That's part of the point! :)
<tjaalton> right :)
<tjaalton> and morning! everything set up for the presentation? :)
<Dandel> Then how about another good question... How many ubuntu devs actually have a reasonable list of amd/ati ( let alone nvidia ) graphics?
<tjaalton> "list of graphics"?
<Dandel> Ya... It's somewhat important because of certain failures that occur when dealing with specific mixed mode system configurations.
<bjsnider> there ain't no ati no more
<tseliot> do you mean hybrid graphics?
<tseliot> (as in PowerXpress)
<Dandel> I know... ATI/AMD are one in the same... I just list ATI since some may not know that they are the same company now.
<tjaalton> i basically run on 100% intel
<bjsnider> same here
<bjsnider> all inthell
<tjaalton> test nouveau/radeon so they won't break on major upgrades
<tseliot> I have intel, nvidia, amd, intel/nvidia and intel/amd (hybrid) here
<Dandel> I strictly use amd graphics ( and processors )
<bjsnider> that's too bad
<tjaalton> oh i have a hybrid intel/nvidia too, but without PM there's no point in running it hybrid
<tjaalton> and it took two years for nouveau to get somewhat mature on it
<Dandel> Actually I have an AMD/AMD hybrid... only problem is that mesa does not like switching between the two graphics ( I think it's muxless )
<tjaalton> next year there's going to be a laptop refresh, probably the same deal again :)
<bjsnider> tjaalton, you got a bios switch that turns one of them off so you can exclusively use the other?
 * RAOF has an AMD/AMD hybrid in his luggage
<Dandel> I actually plan on a desktop upgrade next year with the hardware refreshes.
<Dandel> RAOF, amd APU with dedicated graphics? ( like a6-3400m cpu with hd6650M gpu )
<RAOF> Indeed.
<tjaalton> bjsnider: yup
<bjsnider> Dandel, are you forced to use amd?
<tjaalton> bjsnider: so I just run it in integrated mode all time
<Dandel> Actually I found that there is some serious problems where a dummy driver may need to be written... It's a driver explicitly written to give AMD and nvidia a bone to stop the need for blacklisting nouveau and radeon
<RAOF> It was the wonderful SUMO that didn't quite do tiled->untiled copies correctly.
<Dandel> bjsnider, no... It's called Intel was always out of budget every time i upgrade.
<tseliot> tjaalton: after my work is done, it will be much easier to switch between the two cards (with intel+nvidia). Only a log out will be required
<tseliot> at least on 12.04.4
<tjaalton> right, but it's still too much :)
<Dandel> tseliot, backend to remove need to log out needs to be added.
<tjaalton> especially as the thing runs two sessions all the time (mine and my wifes)
<bjsnider> a log out would take the same time as a reboot here
<tseliot> I think X is the problem there, unless you do what Bumblebee does
<Dandel> I know that libglnvd is meant to assist with this especially when coupled with drm prime and the drm prime helper patches nvidia added.
<Dandel> I actually have a couple of configurations where I do not have any hardware accelerated video on some video cards due to the blacklisting problems :/
<tseliot> tjaalton: then no, it wouldn't help in your case
<Dandel> example mixture... Ubuntu 12.04 with Radeon X1900GT ( or Radeon HD4550 ) and an radeon HD5770 ( the latter most card is using current binary driver from amd )
<tseliot> I don't think X would let go of the card driving the display, at least not without restarting it
<RAOF> That could be fixed; it watches hotplug events, it could handle hotunplug events.
<Dandel> tseliot, There is some support for that... it's in Xrandr 1.4 ( maybe 1.5 )
<Dandel> I did notice that piglit packages have stopped having daily builds... There is a patch queued up to fix the daily build.
<Dandel> The latest break is due to the added implementation of strndup to piglit.
<tseliot> Dandel: that's offloading rendering using RandR providers (which is only part of the problem), which works as long as both cards are on
<Dandel> I do not think it'll be too much of a problem to expand the power management to allow the lowest power management mode be where the card is off and when it gets used there is a wake up call to the dedicated graphics card.
<Dandel> The actual implementation should be easy to implement if you know where to look. All it takes is adding some code to monitor gpu activity level and whether or not the card has displays attached.
<RAOF> Well, and you need to ensure that nothing has an active GLX/EGL context on the card.
<RAOF> Even if it's not rendering.
<RAOF> Because if  you turn the card off, that context is gone gone gone.
<RAOF> airled was working on something like that at one point
<Dandel> RAOF, gpu activity level includes testing for an active GLX/EGL context.
<Dandel> RAOF, I did spot a bug in the graphics drivers packages where dedicated gpus do not get direct contexts on the multiple fglrx packages.
<Dandel> it's an linker problem causing it
<tseliot> Dandel: do you have a bug number for that?
<Dandel> tseliot, I didn't report it since I ran into the bug with an ubuntu derivitive on lts
<tseliot> ok
<Dandel> I was doing some verification/stability tests and noticed the issue.
<Dandel> fglrx-experimental-9 - versoin 9.010 - very buggy release where even glxinfo didn't work right with standard installation procedures. ( but opengl contexts did work )
<Dandel> fglrx-experimental-12 - No direct contexts on the 12.100 release.
<Dandel> fglrx-12 - also had no direct contexts (12.104 driver release )
<Dandel> I forgot to check the fglrx-experimental-13 :/
<Dandel> however, the fglrx ( 13.200 ) driver did not have this problem.
<RAOF> mlankhorst: Oh, feel free to push that nicely-reviewed linear tiling paranoia patch to xf86-video-ati
<bjsnider> Dandel, how dare you suggest fglrx has any bugs
<Dandel> bjsnider, fglrx has many bugs... it takes being able to identify the problem to be able to fix it.
#ubuntu-x 2013-09-25
<tjaalton> looks like xorg-server has been accumulating a bunch of crashers all over the place
<tjaalton> drivers etc
<tjaalton> uh, how can a system running on nouveau crash with a trace that points to ../src/sna/sna_threads.c?
<tjaalton> ahh hybrid, of course..
<bjsnider> use the bios switch, turn off one of the chips
<bjsnider> if you don't have a switch, that's unfortunate
<tjaalton> nah triaging bugs
<bcurtiswx_> why would .Xauthority file not let me login from lightDM even with the 664 user:user for permissions
<bcurtiswx_> upon removing the file it let me login, but appeared to have the right permissions to allow me to login
<bjsnider> mine is 600 user:user
<bjsnider> maybe it wasn't permissions. maybe the file was corrupt
<bcurtiswx_> bjsnider: so then what was causing it to become corrupt?
<bcurtiswx_> i haven't purposely messed with that file specifically, only done updates in Saucy
<bjsnider> impossible question to answer
<bcurtiswx_> it's happened twice in the past week
<bcurtiswx_> past 2 weeks*
<bcurtiswx_> It's a simple workaround and all, but seems like possibly a bigger issue
<bcurtiswx_> there's no error that says your .Xauthority file is corrupt that would clue even experienced users into why it happens if they see it for the first time
<bjsnider> well, i dunno. i'm not on saucy yet, and i don't log in with lightdm
<bjsnider> file a bug if you want
<bjsnider> should be against lightdm i suppose
<bcurtiswx_> I will next time it arises, that way i can attach my .Xauthority file to the bug report
<bjsnider> bugs don't arise, they manifest themselves
<bjsnider> i don't understand this movie by nvidia. are they saying the blob isn't good enough?
<bjsnider> they'd rather have people using nouveau?
<tjaalton> they want distros to provide better OOTB experience
<tjaalton> which is not happening
<tjaalton> right now
<bjsnider> i see
<tjaalton> you need to read the original announcement, not phoronix ;)
<bjsnider> they want the first boot to be better just before users are prompted to install the blob
<tjaalton> phoronix jumped the gun
<tjaalton> it's a start
<bjsnider> i'm reading ars
<tjaalton> yeah that's more accurate
<tjaalton> actual quotes
<tjaalton> "basic 3d rendering"
<tjaalton> maybe related to libglvnd too
<bjsnider> not sure why all of a sudden after so many years they'd make this decision
<bjsnider> they had their own nv driver for that
<bjsnider> they abandoned it
<tjaalton> maybe it took years to get this far
<tjaalton> behind the curtains
<tjaalton> they abandoned nv because nouveau was already the default on distros and doing kms
<bjsnider> yes but that would have been the time to make this movie
<tjaalton> and nv was obfuscated
<tjaalton> doubt they were just sitting on the docs
<tjaalton> just writing them takes time
<bjsnider> they had to be written down somewhere originally
<bjsnider> they're not keeping everything in their heads over there
<bjsnider> it takes time to redact aspects of them that are patented
<tjaalton> exactly
<tjaalton> and make the lawyers happy
<bjsnider> i don't think it would take this much time
<bjsnider> they could have claimed they were going to do this around the time they abandoned nv
#ubuntu-x 2013-09-26
<tjaalton> huh, since when does xorg-server.pc require atomic_ops.pc?
<tjaalton> since xmir.patch, obviously
<tjaalton> eh no
<tjaalton> no raof
<tjaalton> latest upload not in git
<tjaalton> and it must be xmir.patch changes that changed Require.private
<mlankhorst> tjaalton: yeah xmir still adds a thread, probably requires it for that reason :/
<tjaalton> emailed raof to push git, so that can add libatomic-ops-dev to xserver-xorg-dev deps
<tjaalton> glamor-egl passed MIR review
<tjaalton> with some nagging about the packaging
<tjaalton> pushed those, but it failed to build
<tjaalton> due to the .pc change
<mlankhorst> oh :P
<tjaalton> so I could just add the dep there too for now
<tjaalton> to get it rolling
<mlankhorst> yeah do it :D
<tjaalton> done
<mlankhorst> yeah, now to figure out whether to rename glamor or not for saucy
<tjaalton> so we can drop -sis? good
<mlankhorst> hm I probably will
<mlankhorst> yeah sis can be dropped
<tjaalton> for precise you mean?
<mlankhorst> yeah
<mlankhorst> I'll probably rename it
<tjaalton> why?
<tjaalton> there is no glamor in precise
<mlankhorst> because t might require a newer version of glamor
<tjaalton> let's get a MRE for it :)
<Prf_Jakob> howdy
<mlankhorst> tjaalton: but glamor has broken in the past and nobody knew why, I'd rather not update that component separately
<tjaalton> mlankhorst: ok, if it has then sure
<mlankhorst> besides, it's not like pixman where there's another piece of userspace depending on it.
<tjaalton> yeah, drm race again.. boo
<mlankhorst> tjaalton: where?
<mlankhorst> mir?
<tjaalton> #1205977 
<tjaalton> bug #1205977 
<ubottu> bug 1205977 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in OsAbort()" [High,Incomplete] https://launchpad.net/bugs/1205977
<tjaalton> it was duped with an old bug which was pre-plymouth updates
<mlankhorst> aw no mention of mir
<tjaalton> no, plenty of those bugs already
<mlankhorst> but for the love of.. drm master must die
<tjaalton> triaged 30 xserver now, some valid intel bugs too for ickle to chew
<mlankhorst> want to look at nested mir? it's a can of worms ;)
<tjaalton> â¦
<tjaalton> I probably should enable it on my laptop
<tjaalton> running parallel sessions isn't tested too much, and this seems to have crashers with xmir
<tjaalton> now I see that quite many of these crashers has -mir on ProcCmdline..
<mlankhorst> yeah really annoying :/
<tjaalton> bug #1224907 keeps getting dupes
<ubottu> bug 1224907 in xserver-xorg-video-intel (Ubuntu) "[XMir] Too many unrefs of ScreenPixmap" [High,Confirmed] https://launchpad.net/bugs/1224907
 * mlankhorst can't wait for the return of Xegl
<tjaalton> glamor-egl made it in main
<tjaalton> RAOF: thanks for fixing xorg-server.pc :)
<RAOF> tjaalton: Sorry for breaking it in the first place âº
<tjaalton> heh, it happens
<tjaalton> I'll respin the -ati builds
#ubuntu-x 2013-09-27
<tjaalton> meh, broken focus in unity..
<tjaalton> after suspend
<tjaalton> err, resume
<tjaalton> can open new apps from the dash, but not move any window
<tjaalton> eh, opening the hud fixed it
<tjaalton> mlankhorst: the versions_current page doesn't seem to be working right, doesn't update the debian versions
<tjaalton> libx11 in unstable is 2:1.6.1-1
<mlankhorst> tjaalton: yeah I get a problem with ubuntu-archive-tools :/
<tjaalton> okay
<mlankhorst> endless redirects
<tjaalton> so where did .xsession-errors stuff go?
<mlankhorst> erm systemd init is used for spawning the xsession now
<mlankhorst> no idea where the log went
<stgraber> systemd? don't you mean upstart?
<mlankhorst> oh right upstart :P
<stgraber> tjaalton: anyway, pre-upstart entries are still going to land in .xsession-errors, anything after that, you'll find in .cache/upstart/*.log
<tjaalton> stgraber: ok, so it's gnome-session.log for the generic app spam
<stgraber> that and dbus, yes
<tjaalton> in my case
<tjaalton> thanks
 * mdeslaur wonders if stgraber has a highlight on 'systemd'
<bjsnider> tjaalton, just read your funny comments on 1219908
<bjsnider> "You'd better have what it takes to wait for an additional two weeks" hahaha
<tjaalton> I wrote that?
<tjaalton> rude me
<bjsnider> it's been 3 weeks but yes you did
<bjsnider> the guy was demanding instantaneous blob updates
<tjaalton> yeah that one
<tjaalton> fix released, so don't care anymore :)
<tjaalton> thanks to tseliot
<bjsnider> yeah until the next blob
<tjaalton> nice, unity doesn't recognize a gitk window
<tjaalton> dash shows it, but clicking the icon doesn't bring it to foreground
#ubuntu-x 2013-09-28
<pepee> hi. how could I know if a patch will be merged in saucy? I had this problem:  https://bugs.freedesktop.org/show_bug.cgi?id=60182#c33 , which has been fixed, and I don't know very well about the release cycle in ubuntu
<ubottu> Freedesktop bug 60182 in DRM/Radeon "X.Org Server terminate when I close video player" [Critical,Resolved: fixed]
<bryce> pepee, you'd want to have an SRU bug with that fix filed in launchpad, and targeting saucy.
<bryce> pepee, see https://wiki.ubuntu.com/StableReleaseUpdates
<pepee> hmm, I was asking in the #ubuntu+1 : do I have to use ubuntu-bug? I'm using a custom build + lots of PPAs...
<bryce> using ubuntu-bug is a good idea but you don't have to.  But if you don't, make sure to manually add the tag 'saucy' to the bug.
<pepee> ok, thank you, I will do it manually
<bryce> the main thing is you need the SRU Bug Template (sect 3.1), and link to the upstream bug
<bryce> if you are skilled at packaging, you can also backport the patch to the package; otherwise you'll need to solicit a maintainer (like maybe tjaalton) to help on that part, if it's needed.
<pepee> no, I don't really know how to package things...
<pepee> I just followed instructions to apply the patch
<bryce> ok no prob, that'll be easy for a maintainer.  The test verification you did, and filling in the lp bug with sru bits will be great help.  they can handle the rest when they get a chance.
<pepee_> sorry, I got disconnected :/
<bryce> pepee, I just said, ok no prob, that'll be easy for a maintainer.  The test verification you did, and filling in the lp bug with sru bits will be great help.  they can handle the rest when they get a chance.
<pepee> ok, thanks
<tjaalton> for saucy it'll be easier as it's not released yet
<tjaalton> so no need for the sru stuff imo, just file a bug or search for a dupe
<pepee> ok, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1232557
<ubottu> Ubuntu bug 1232557 in xserver-xorg-video-ati (Ubuntu) "X.Org Server terminates when I close video player or run glxgears" [Undecided,New]
<pepee> should I add/edit something?
<bryce> pepee, looks fine.  follow up next week if you don't see progress made
<pepee> ok, thank you bryce and tjaalton 
#ubuntu-x 2013-09-29
<bjsnider> pepee, know how to make a debdiff?
<bjsnider> if not there's a wiki page for it
<pepee> bjsnider, reading
<bjsnider> coolio
<pepee> bjsnider, what's this for? testing that bug?
<bjsnider> real good way to get them to accept a patch
<bjsnider> i've done it before
<pepee> ah k
<bjsnider> if you attach the debdiff you're doing almost all the work for them
<bjsnider> does the patch apply?
<pepee> isn't easier to just give them the patch?
<bjsnider> no
<bjsnider> well, it's easier on you
<bjsnider> but you're trying to get the patch accepted
<pepee> but this is for binary files, right?
<pepee> wow, that was quick, the fix got released...
<bjsnider> what?
<pepee> I reported this:  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1232557
<ubottu> Ubuntu bug 1232557 in xserver-xorg-video-ati (Ubuntu Saucy) "X.Org Server terminates when I close video player or run glxgears" [High,Triaged]
<pepee> 6 hrs ago...
<bjsnider> well, the importance was critical right?
<pepee> well, not really, but I wanted to report it for people to have a working distro...
<pepee> out of the box
<bjsnider> xorg went down when closing any video player?
<pepee> when using opengl apps I think
<pepee> not sure though, I don't really understand it
<bjsnider> pepee, i misunderstood something you wrote earlier about using a custom build with ppas. thought you were an expert
<bjsnider> more or less
<pepee> ah, heh
<pepee> nah, I barely know how to follow instructions
<pepee> and a bit of programming... but I hate coding
<bjsnider> how did you get to the point where you were running a custom build?
<pepee> looked at the buildlogs, executed the commands shown there
<bjsnider> pardon me?
<pepee> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1232557/comments/15
<ubottu> Ubuntu bug 1232557 in xserver-xorg-video-ati (Ubuntu Saucy) "X.Org Server terminates when I close video player or run glxgears" [High,Triaged]
<pepee> ah, "custom build" = old, patched version of the package
<bjsnider> oh, i misunderstood again
<bjsnider> i thought by that you grabbed a newer git snapshot and so forth
<pepee> nah, I've had bad experiences with that :(
<bjsnider> doing that successfully would be a much bigger meal than patching something
<pepee> someone told me about checkinstall
<pepee> worked fine for one package, but I couldn't build some other ones
<pepee> unknown dependencies is the hardest thing I've hit...
<pepee> but I have a bunch of programs from repos running just fine, just not packaged
<pepee> I don't understand the packaging system... I just know how to use it
<bjsnider> yeah well you can use apt-get build-dep to install dependencies
<pepee> yeah, but sometimes... there are no packages for that :(
<bjsnider> you can use dpkg-buildpackage to build a deb based on the code you get from git
<bjsnider> you've got to have build-essential installed and whatnot
<pepee> for example, a couple days ago I wanted to test the mesa implementation of opencl
<pepee> you have to configure dpkg-buildpackage first, right?
<pepee> make a debian/ folder and so on
<bjsnider> just use the existing one you get by doing apt-get source
<pepee> well, I needed some lib for opencl, libclc which is not in the repos
<bjsnider> you don't have to create your own packaging scripts from scratch
<pepee> hmm, is there anything I could read about this?
<bjsnider> somewhere out there
<bjsnider> apt-get source gets you the package's orig tarball, which is untouched code, and the packaging scripts
<bjsnider> then ytou could grab newer code and try building that version
<pepee> yeah, I mean, I dunno what to do when some deps are not in the repos
<pepee> and I don't like to mess too much with the system
<pepee> I've hed bad experiences in the past, lol
<pepee> *had
<bjsnider> you could look to see if the lib is in debian experimental yet
<pepee> I've been using this same system since like 8.04 I think
<pepee> or 10.04, not sure...
<bjsnider> not sure i understand your point
<pepee> I've upgraded lots of times, and sometimes, old changes lead to... bad things
<pepee> :P
<bjsnider> you're not going to break your system by installing a lib the rest of your system hasn't heard of
<bjsnider> libs just sit there
<pepee> ah k
<bjsnider> if you uninstall upstart and update to the latest systemd, that could cause some issues
<pepee> I could just use VMs or chroots, but it would be a waste of resources..
<pepee> btw, do you know about how mesa is updated in ubuntu?
<pepee> I wish I could try the new directx implementation, and this opencl thing too..
<tjaalton> if xorg-edgers has a newer mesa then just try that
<tjaalton> it's a lot harder pkg to manage than a simple driver
<pepee> well, xorg-edgers mesa package is ~1 month old
<pepee> mesa from oibaf's ppa is the most recent one I think
<tjaalton> ok
<tjaalton> he's trying to monetize the effort, and doesn't help us in any way
<tjaalton> hmm was that right
<tjaalton> and due to that his packages might conflict with official ones, like with glamor now
<pepee> well, he doesn't have packages for saucy..
<tjaalton> ok
#ubuntu-x 2014-09-22
<Azelphur> I attached all my monitors to one single power off switch, and when I use the switch, the system thinks the displays have been unplugged and disables them, so when I turn the monitors back on, everything is fairly messed up. Any ideas on how I can stop that from happening?
#ubuntu-x 2014-09-23
<JanC> Azelphur: a well-designed monitor should consume < 0.5W when you use the standby button; isn't that an option?
<Azelphur> JanC: I managed to solve it, it's the nvidia driver that does it and there's an option in xorg.conf to turn it off
<Azelphur> JanC: the problem was that it's annoying putting 4 monitors one by one into standby :)
<JanC> maybe there should be a standby command that can be sent by the OS  :) 
<Azelphur> JanC: there is, xset dpms force off, but it's annoying to use.
<JanC> anyway, powering down the monitor is probably indistinguishable from unplugging the monitor
<Azelphur> indeed it is, Option "UseHotplugEvents" "Off" saves the day anyway
<Azelphur> I wouldn't really want it disabling any of my monitors under any circumstances anyway
<JanC> does DPMS put the monitor in full standby?
<JanC> if so, it would be as easy as putting a "button" somewhere in your UI  :)
<Azelphur> JanC: yea it does
<Azelphur> so, I could do it like that
<Azelphur> the only problem with it is that the screen gets turned on again if you knock the mouse even slightly, and then it doesn't get turned off again
<Azelphur> which is annoying.
<JanC> then you would have to disable *that*
<JanC> actually, I think you can make it turn off the screen after an amount of inactivity?
<JanC> and maybe you can disable the "mouse move re-enables"
<Azelphur> JanC: or just use my button, which solves all the problems and saves even more power than standby :P
<Azelphur> and plus I can plug other things into it
<JanC> as long as you don't need to add/remove monitors  :)
<Azelphur> JanC: it's a PC, so adding/removing monitors is unlikely :)
<JanC> and I wonder if that option also applies to keyboards, mice, etc.
#ubuntu-x 2014-09-24
<dupondje> HDMI output seems completely broken for me on Utopic :(
<tjaalton> on what
<tjaalton> hw
<dupondje> Intel & Nvidia card (optimus)
<dupondje> 01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT 540M] (rev a1)
<dupondje> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
<dupondje> Image of the screen http://dupondje.be/nouveau/20140923_013459.jpg
<dupondje> I can move cursor over the screen when loggin in. But after everything is loaded, even cursor doesn't display on it anymore
<dupondje> so really don't know where I need to start to debug
<tjaalton> the hdmi is likely owned by the nvidia gpu
<dupondje> It was even worse, HDMI didn't have any signal at first. But was able to track down the bug for that already (reported upstream https://bugs.freedesktop.org/show_bug.cgi?id=84203)
<ubottu> Freedesktop bug 84203 in Driver/nouveau "[NVC1] HDMI gives no more signal since 3.15 (optimus)" [Normal,New]
<dupondje> tjaalton: yes, HDMI is on the nvidia card
<tjaalton> so it's just nouveau being crappy I guess
<dupondje> well in #nouveau they tell me its prolly intel ddx that causes issues
<tjaalton> of course
<dupondje> ;)
<tjaalton> try a later mainline kernel
<dupondje> let me try :)
<dupondje> tjaalton: same issue.
<dupondje> also tries xorg-edgers ppa, but doesn't fix it neither
<dupondje> tested http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/ btw
<dupondje> a quite annoying regression imo :(
<tjaalton> regression since when
<dupondje> worked on 14.04
<tjaalton> well if #nouveau claims it's in the intel ddx then bisect that
<dupondje> xserver-xorg-video-intel then? :)
<tjaalton> yep
<dupondje> quite annoying to bisect no? Cause it depends on some versions of xorg-server ?
<tjaalton> build from source
<tjaalton> trusty had 2.99.910
<tjaalton> utopic has .914
<tjaalton> check the versions in between
<tjaalton> and file a bug
<dupondje> lets bisect :D
<dupondje> tjaalton: ok, already got it working
<dupondje> now 7 steps to go, and we have the commit :D
<dupondje> 975b9798be77b30cbed485583d0ccb48318708f7
<dupondje> 
<dupondje> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=975b9798be77b30cbed485583d0ccb48318708f7
<dupondje> this one
<tjaalton> let ickle know
<dupondje> created a bugreport (https://bugs.freedesktop.org/show_bug.cgi?id=84298)
<ubottu> Freedesktop bug 84298 in Driver/intel "HDMI output broken" [Normal,New]
#ubuntu-x 2014-09-25
<dupondje> tjaalton: ok seems to be an global issue, not driver related
<tjaalton> ok
<dupondje> just hitting that bug because intel activated DRI3 since some versions
<dupondje> so workaround is to disable DRI3
<dupondje> bug: https://bugs.freedesktop.org/show_bug.cgi?id=84298
<ubottu> Freedesktop bug 84298 in Server/General "[present + prime] HDMI output (nouveau) broken" [Normal,New]
#ubuntu-x 2014-09-26
<dupondje> Any idea if the following could be fixes before release ? https://bugs.freedesktop.org/show_bug.cgi?id=84298 and https://bugs.freedesktop.org/show_bug.cgi?id=84203
<ubottu> Freedesktop bug 84298 in Server/General "[present + prime] HDMI output (nouveau) broken" [Normal,New]
<ubottu> Freedesktop bug 84203 in Driver/nouveau "[NVC1] HDMI gives no more signal since 3.15 (optimus)" [Normal,New]
<dupondje> quite an annoying regression if you upgrade from 14.04
<tjaalton> needs patches first
<dupondje> 84203 can be fixed by reverting the commit
<dupondje> and other once can be fixed by disabling DRI3 when configuring xorg driver for intel
<tjaalton> first you need to file bugs on lp
<mlankhorst> dupondje: consiidering it fixes things for other people you want to engage upstream first
<mlankhorst> especisally on the kernel
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1374607
<ubottu> Launchpad bug 1374607 in linux (Ubuntu) "nouveau - HDMI gives no more signal since 3.15 (optimus)" [Undecided,New]
<dupondje> mlankhorst: true, but reverting is not a fix that upstream will do. They will really FIX it. But I guess not in time for Utopic release.
<dupondje> thats why I reported it upstream first :)
<dupondje> same with the other issue. Disabling DRI3 is not preferred ofc. But its the only way to have it working now
<mlankhorst> OR file bugs ssooner
<dupondje> well upgraded to utopic only recently
<dupondje> I wont die if its not fixed ofc :)
<mlankhorst> disabling dri3 breaks DRI_PRIME for example
<dupondje> reverting 975b9798be77b30cbed485583d0ccb48318708f7 is also an option
<mlankhorst> cant check now, can you subscribe me?
<dupondje> to upstream or bug I create on launchpad ?
<mlankhorst> lp\
<dupondje> k
<dupondje> its indeed annoying there is no real fix for it. But just think its a quite annoying regression.
<tjaalton> again I wish we'd have a rolling release between lts's ;)
<dupondje> vote++ :)
<dupondje> or just always :)
<mlankhorst> no we need lts
<dupondje> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1374618
<ubottu> Launchpad bug 1374618 in xserver-xorg-video-intel (Ubuntu) "[present + prime] HDMI output (nouveau) broken" [Undecided,New]
<dupondje> there
<dupondje> you can fork the rolling release at one moment, and create an lts out of it
<mlankhorst> that's not rolling release... means ready to release at any time..
<dupondje> well no, create a fork, and make some changes to that fork so you can work on it for some months, and then release that as lts
<dupondje> but well :) thats another discussion :D
#ubuntu-x 2014-09-27
<tjaalton> 3/win 22
<tjaalton> bah
#ubuntu-x 2015-09-23
<yofel> tjaalton: hi, any news about bug 1492037?
<ubottu> bug 1492037 in mesa (Ubuntu) "Segmentation fault in brw_meta_fast_clear" [Critical,Triaged] https://launchpad.net/bugs/1492037
<tjaalton> yofel: stuck in proposed
<yofel> ok, so it's moving forwared, thanks!
<tjaalton> yw
<tjaalton> yofel: can you check why kwin tests fail? that's the blocker now
<yofel> urgh, yes, will do
<tjaalton> not because of mesa, started failing early yesterday
<tjaalton> actually a few weeks ago
<yofel> fails since 5.4.1, we're looking at it
<tjaalton> ah, looks like the kwin test regression wasn't the blocker after all, mesa 11.0.0 is now in
<ricotz> tjaalton, hey :), don't forget to get libinput 1.0.1 into wily too
<ricotz> same goes for libevdev
#ubuntu-x 2015-09-27
<furkan> is dpms broken in Wily for anybody else? i just noticed it today so i think it might have been a recent update
<furkan> i recall the same thing happened to me with 15.04 and it turned out to be a kernel bug which was fixed in short order
<furkan> so i'll probably try a different kernel but just thought i'd check to see if it's a known bug
#ubuntu-x 2016-09-26
<ricotz> New legacy releases 304.132 and 340.98 are now available. 
<mamarley> ricotz: You take one, I'll take the other?
<ricotz> mamarley, will probably not get it before tomorrow, but I can do 304.132
<mamarley> OK, I will do 340.98 then.  I actually have a piece of hardware where I can test that.
<ricotz> I am curious if they support xorg-video abi 23
<mamarley> Do the 367/370 series even support that yet?
<ricotz> I can test 304 here
<ricotz> not yet, since they were release before the last break
<mamarley> Other than release notes or just trying it, how does one find out?
<ricotz> mamarley, I guess trying it which might be tricky
<ricotz> I have pushed a tweaked vulkan update to have it install the layer files
<mamarley> ricotz: Yeah, I don't have anything set up with xserver 1.19 yet.  I was probably going to try to package it once the stable release was out though.
<mamarley> But only if the NVIDIA drivers support it, leaving a chicken-and-egg scenarioâ¦
<ricotz> mamarley, refreshing the patches is the pain
<mamarley> Indeed.
<ricotz> huh?
<tjaalton> ricotz: tweaked? last i saw it required spir-v
<ricotz> nvidia is the only driver which would block it
<ricotz> tjaalton, uncommenting the lines in rules
<ricotz> tjaalton, they likely should go into the separate package?
<mamarley> ricotz: I had planned to try to package 1.19 only if it would work with NVIDIA, but unless a new driver is released with release notes indicating compatibility, trying would be the only way to know if it was compatible.
<ricotz> tjaalton, https://launchpadlibrarian.net/286736001/vulkan_1.0.21.0+dfsg1-1_1.0.21.0+dfsg1-1ubuntu1~gpu16.10.1.diff.gz
<tjaalton> ah, just the jsons
<ricotz> mamarley, uploading 304.132
 * mamarley is uploading 340.98 right now.
<mamarley> It compiles cleanly against 4.8 with no patches. :)
<ricotz> mamarley, you really want to enable armhf for your ppa ;)
<mamarley> Wait, I can actually do that, I forgot.
<ricotz> yes
<mamarley> Done
 * mamarley head off to get some food while the builds finish.
<ricotz> mamarley, will take a look at the 340 builds before copying them tomorrow
#ubuntu-x 2016-09-27
<pxeguy> hey guys!
<pxeguy> I've been struggling with cpu/graphics related issue on my LTSP fat client for quite a while now and I've scoured the web for answers.
<pxeguy> The problem is that once the client finishes loading grub, the screen blanks out(or my case, the HP shows blue, red and green on the screen)
<pxeguy> it doesn't seem to want to recognize the i915 driver, or Xorg doesn't want to recognize, can anyone shed some light? it's a skylake i3 cpu and the graphics card is a 530 HD intel, unfortunately the only work around is to use nomodeset but that screws up the resolution
<tjaalton> kernel bug, try nightly from mainline ppa
<pxeguy> nightly from mainline ppa?
<pxeguy> is that another irc channel?
<tjaalton> no
<pxeguy> oh sorry the drm nightly kernel
<pxeguy> I see
<tjaalton> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<pxeguy> thanks for the help
<pxeguy> drm-intel-nightly this looks like the one
#ubuntu-x 2016-09-28
<pxeguy> yo guys
<pxeguy> has anyone come across a green, blue and red display on an HP machine after the it finishes loading grub? The kernel doesn't seem to want to pickup the driver
<tjaalton> no, file it upstream
<pxeguy> upstream?
<tjaalton> to intel
<pxeguy> can you point me in the direction where I can report this?
<tjaalton> but what does 'lspci -nn -s 02' tell?
<pxeguy> give me a moment
<RAOF> Whee! -modesetting is a hot mess on my (admittedly weird) machine.
<pxeguy> yes...
<pxeguy> none of these modes are currently working for me
<tjaalton> RAOF: how?
<tjaalton> pxeguy: irrelevant. what's your pciid
<tjaalton> or the hw model
<TemperoR> Hi tjaalton
<TemperoR> it's pxeguy
<tjaalton> k
<TemperoR> 00:02.0 VGA compatible controller [0300]: Intel Corporation Sky Lake Integrated Graphics [8086:1912] (rev 06)
<TemperoR> that's my output
<tjaalton> and what are you trying to use?
<tjaalton> should be well supported btw
<pxeguy> yes
<pxeguy> give me a moment I want to show you something else
<RAOF> tjaalton: Extremely slow, it looks like at least two different framebuffers are fighting over the display (so I get torn updates, can only see the real output when moving the mouse, and so on).
<tjaalton> RAOF: nice
<TemperoR> *-display UNCLAIMED              description: VGA compatible controller              product: Sky Lake Integrated Graphics              vendor: Intel Corporation              physical id: 2              bus info: pci@0000:00:02.0              version: 06              width: 64 bits              clock: 33MHz              capabilities: vga_controller bus_master cap_list              configuration: latency=0              resources: m
<TemperoR> that's from lwhw
<TemperoR> lshw'
<tjaalton> unclaimed because of nomodeset
<pxeguy> correct
<tjaalton> nothing useful there
<tjaalton> and nightly didn't work?
<tjaalton> does the grub menu work?
<pxeguy> I'm very worried about using nightly
<pxeguy> reason being
<tjaalton> why
<pxeguy> I'm putting it on a production LTSP server
<tjaalton> uh
<pxeguy> sorry not production
<tjaalton> just try something
<pxeguy> I'm building it for a client
<tjaalton> don't tell them that you're testing an unofficial kernel..
<pxeguy> yes.....
<tjaalton> i mean
<tjaalton> do you want to see it fixed?
<pxeguy> well to be honest
<pxeguy> I don't think we will end up using this machine
<tjaalton> ok then
<pxeguy> because it is about 12 grand
<pxeguy> I just wanted to see if I could fix it
<tjaalton> I'll continue with xserver backports then
<pxeguy> xserver back ports?
<tjaalton> my work
<pxeguy> okay I see
<pxeguy> thank you for your help
<RAOF> tjaalton: In partial defence of -modesetting, I've got both an AMD and an NVIDIA card in this box, with three display cables connected to two monitors.
<tjaalton> RAOF: hehe
<pxeguy> that is very weird RAOF
<pxeguy> lmao
<RAOF> gnome-shell-wayland works fine* by dint of not trying to drive the nvidia card at all :)
<RAOF> * For values of âfineâ which include Xwayland being reasonably frequently unresponsive.
<tjaalton> modesetting has been working fine for me, though I know there are some corner cases that are known to be broken still
<pxeguy> btw tjaalton, you say i915 is well supported?
<tjaalton> like inverting the 2nd head and looking how the eDP is blanked. testing a backport now..
<tjaalton> pxeguy: skylake is, in 16.04 and up
<pxeguy> then it's so weird that it's not working....
<tjaalton> that's why I asked you to try latest upstream
<pxeguy> the latest upstream in terms of intel?
<pxeguy> or the nightly
<pxeguy> because that is a 4.8 kernel right?
<tjaalton> drm-intel-nightly build has latest of i915
<pxeguy> oh I see
<pxeguy> okay that makes sense
<tjaalton> based on 4.8, that's irrelevant
<pxeguy> okay I see
<pxeguy> I downloaded only 3 of the .deb files
<tjaalton> you just need on
<tjaalton> one
<pxeguy> oh really?
<pxeguy> which one?
<tjaalton> linux-image...generic
<tjaalton> .deb
<pxeguy> okay
<pxeguy> I have that one
<tjaalton> what does uname -a tell you?
<TemperoR> Linux ltsp65 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
<TemperoR> they said it was supported from 4.4 onwards
<tjaalton> ok so it's the latest
<tjaalton> skylake uses i915_bpo on it, which is from 4.7
<TemperoR> okay, so then I need 4.7 onwards
<TemperoR> to get it to work
<tjaalton> no
<TemperoR> or can I dl i915
<tjaalton> if 4.4.0-38-generic is broken then upstream 4.7 is most likely just as broken
<tjaalton> just install the nigthly kernel and boot
<TemperoR> okay what I will do
<TemperoR> is create a replica of this server
<TemperoR> and try what you've told me
<tjaalton> why can't you just install a package
<tjaalton> if it doesn't work, remove it
<TemperoR> you don't think it could break anything indefinitely
<TemperoR> ?
<tjaalton> no
<TemperoR> okay I see
<TemperoR> lemme give it a shot
<tjaalton> oh goddammit
<tjaalton> now that PSR is enabled upstream in 4.8 modesetting is b0rked
<tjaalton> on skylake at least
<TemperoR> borked
<TemperoR> xD
<TemperoR> borked = broked?
<tjaalton> borkborkbork
<TemperoR> you're doing me a real big frighten tjaalton xD
<tjaalton> I was talking to myself, not about your case
<TemperoR> no I know
<TemperoR> was just making a joke
<TemperoR> :p
<tjaalton> looks like I'm just an idiot, had psr enabled locally
<TemperoR> do you also do networking tjaalton
<TemperoR> ?
<TemperoR> networking and linux go hand in hand often times
<tjaalton> no
<tjaalton> pxeguy: so did you test the kernel?
<pxeguy> hi tjaalton
<pxeguy> where can I put the .deb file?
<tjaalton> huh
<tjaalton> install it
<pxeguy> apt-get install and then the whole fiele name?
<tjaalton> no
<tjaalton> dpkg -i
<tjaalton> I assume you're mucking with a chroot?
<tjaalton> that the client boots
<pxeguy> yes....
<pxeguy> yes it boots into the chrooted environment
<tjaalton> so copy the deb there, then run chroot and install it there
<tjaalton> unless you have the booted kernel somewhere else
<tjaalton> can't help you there
<pxeguy> no I don't think so
<pxeguy> yeah I know you wouldn't know where I have the stuff stored
<tjaalton> can you test usb live-image locally?
<pxeguy> it pulls the config from /var/lib/tftpboot/ltsp/amd64/
<pxeguy> I just need to work out where it's pulling the kernel from
<pxeguy> let me ask one of the other guys in my office
<pxeguy> okay I know where to put it
<pxeguy> but I'd need to compile the kernel again right?
<tjaalton> no
<tjaalton> how do you normally update the boot kernel?
<pxeguy> well
<pxeguy> what I have to do is
<pxeguy> put the linux image
<pxeguy> in /opt/ltsp/amd64/boot
<tjaalton> manually?
<pxeguy> that would be in the chroot
<pxeguy> yes
<pxeguy> I think it's pulling the kernel from there
<pxeguy> well that's what makes the most sense to me
<tjaalton> and in /opt/ltsp/amd64/lib/modules you have the kernel modules?
<tjaalton> per version
<pxeguy> let me check 
<pxeguy> 4.4.0-28-generic  4.4.0-38-generic
<pxeguy> that's what in there
<tjaalton> ok
<pxeguy> give me a moment
<pxeguy> I'll tell you which one it's pulling
<tjaalton> so, copy the image in, say /opt/ltsp/amd64/tmp, then run 'chroot /opt/ltsp/amd64/ /bin/bash; dpkg -i /tmp/linux-image....deb'
<pxeguy> btw would booting from a legacy bios affect any of the kernel crap or is a completely seperate story all together?
<tjaalton> no
<pxeguy> okay thanks just wanted to confirm
<tjaalton> well, could be that it'd just work with uefi and local usb live
<tjaalton> but who knows
<pxeguy> btw, where should the i915 module be installed?
<tjaalton> why?
<pxeguy> and does this error "could not create tracefs" mean to you
<tjaalton> no
<pxeguy> I'm just curious
<tjaalton> under /lib/modules
<pxeguy> okay so i915 should actually be in /lib/modules
<tjaalton> of the chroot
<tjaalton> don't install the kernel on the host machine
<tjaalton> but under the chroot, like I said
<pxeguy> okay
<pxeguy> will do
<pxeguy> is this the correct kernel
<pxeguy> linux-image-4.8.0-994-generic_4.8.0-994.201609262201_amd64.deb
<tjaalton> sounds about right
<pxeguy> well that's what I got from the nightly package
<pxeguy> :0
<pxeguy> :)
<tjaalton> 994 means nightly
<pxeguy> okay sweet
<pxeguy> and it won't break anything indefinitely?
<pxeguy> sorry I'm just making sure
<tjaalton> no
<pxeguy> and what is the process to uninstall?
<tjaalton> dpkg --purge linux-image linux-image-4.8.0-994-generic
<tjaalton> on the chroot
<pxeguy> I ran
<pxeguy> dpkg -i /tmp/linux-image....deb
<pxeguy> obviously with the correct file
<pxeguy> and it's not popping up in lib/modules
<tjaalton> you're in the chroot, and there's no 4.8.0-994 subdif?
<tjaalton> *subdir
<pxeguy> (Reading database ... 189752 files and directories currently installed.) Preparing to unpack .../linux-image-4.8.0-994-generic_4.8.0-994.201609262201_amd64.deb ... grep: /proc/cpuinfo: No such file or directory This kernel does not support a non-PAE CPU. dpkg: error processing archive /tmp/linux-image-4.8.0-994-generic_4.8.0-994.201609262201_amd64.deb (--install):  subprocess new pre-installation script returned error exit status 1 
<tjaalton> so how do you normally get new kernels there? follow the same procedure..
<pxeguy> okay I think I know what to do
<tjaalton> you'd probably need to bind mount /proc etc
<pxeguy> I missed the mount 
<pxeguy> ye
<pxeguy> exactly
<pxeguy> I missed that
<pxeguy> sudo chroot /opt/ltsp/i386 mount -t proc proc /proc
<pxeguy> think that's what I missed
<pxeguy> mount -t proc proc /proc
<tjaalton> and?
#ubuntu-x 2016-09-29
<TemperoR> yo tjaal
<TemperoR> I think I have what I was looking for
<TemperoR> W: Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1_01.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_guc_ver9_14.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_guc_ver8_7.bin for module i915 W: Possible missing firmware /lib/firmware/i915/skl_guc_ver6_1.bin for module i915
<tjaalton> no
<TemperoR> that was when I upgraded
<TemperoR> the kernel
<tjaalton> you don't need that
<tjaalton> for booting up
<TemperoR> oh
<TemperoR> okay well then the update to the kernel didn't work
<tjaalton> ok, then upstream needs to know about it. bugs.freedesktop.org
<tjaalton> DRI/intel
<TemperoR> cool
<TemperoR> thanks man will report it
<TemperoR> what is the command to purge the kernel?
<tjaalton> dpkg --purge ...
<TemperoR> okay ty
<TemperoR> vmlinuz-4.8.0-994-generic
<TemperoR> purge that
<tjaalton> no
<tjaalton> linux-image...
<TemperoR> or this 
<TemperoR> okay sec
<TemperoR> linux-image-4.8.0-994-generic_4.8.0-994.201609262201_amd64.deb
<tjaalton> no
<tjaalton> not full filename
<tjaalton> just linux-image-4.8.0-994-generic
<TemperoR> just linux-image-4.8.0-994-generic
<TemperoR> okay ty
<TemperoR> okay purged
<TemperoR> You don't think there is something I might be doing something wrong?
<TemperoR> like a possible missing driver
<tjaalton> no
<tjaalton> that pciid is supported, I have it on my desktop
<tjaalton> running xenial
<tjaalton> try a live image witih uefi
<tjaalton> -i
<TemperoR> as a point of interest
<TemperoR> my colleague downstairs
<TemperoR> tested on virtual box booting into my server and it worked completely fine.
<TemperoR> with the correct res and everything
<TemperoR> -i
<tjaalton> what does virtualbox have to do with real hw?
<TemperoR> just as a point of interest
<TemperoR> it doesn't
<TemperoR> btw you said that the pciid is also supported by the 4.4 kernel correct?
<tjaalton> yes
<TemperoR> you just wanted me to test the 4.8
<tjaalton> because 4.4 didn't work for you
<TemperoR> yes
<TemperoR> you want me to do a live boot on this PC with ubuntu
<tjaalton> yep
<tjaalton> and uefi
<TemperoR> well with uefi enabled
<TemperoR> makes sense
<TemperoR> that way we can rule out whether the ltsp is causing issues
<TemperoR> because atm, I'm using legacy
<TemperoR> on the bios on this PC
<TemperoR> so I will try uefi
<furkan> tjaalton: any plans to put out Xorg 1.18.4 for Xenial? would be nice to resolve the glamor glyph corruption issue in LibreOffice... it makes some dialog boxes basically unusable
<furkan> maybe in X staging PPA if you would prefer further testing?
<furkan> oh i see it's in xenial-proposed already
#ubuntu-x 2016-09-30
<tjaalton> yep
<furkan> tjaalton: ended up installing it, so far so good (no more glyph corruption in LibreOffice)
<furkan> i'll let you know if i encounter any regressions
#ubuntu-x 2017-09-26
<tjaalton> where does nvidia dkms determine if a kernel is supported or not (to build)?
<ricotz> tjaalton, maybe https://www.kernel.org/
<tjaalton> huh? I mean the dkms build
<ricotz> I assumed you mean how nvidia decides which kernel is still important
<tjaalton> it checks the linux-headers package
<ricotz> it simply tries to build it
<ricotz> and conditionally applies patches based on the kernel version
<tjaalton> ERROR (dkms apport): kernel package linux-headers-4.13.0-NNNN is not supported
<ricotz> I haven't encountered this yet
<tjaalton> tseliot is off this week, he'd have the answer
<tjaalton> okay
<ricotz> never ran into this using the ppa or mainline packages
<tjaalton> it comes from dkms itself
<tjaalton> so it refuses to build if the kernel is from a ppa. wonderful
<ricotz> tjaalton, is this acually the nvidia module failing? "apport" confuses me here
<tjaalton> yes
<tjaalton> it's a ppa kernel based on 4.13+drm-next
<tjaalton> so I'll fix nvidia to build against it and show what I got :P
<ricotz> hmm, I am using the canonical-kernel-team ppa packages here
<tjaalton> the apport error just confused me
<ricotz> might be that they handled special
<tjaalton> all it means is that it won't file a bug because it's an unofficial kernel, which is correct
<tjaalton> what I didn't see was the build error
<ricotz> which nvidia version?
<tjaalton> the latest
<ricotz> so 384.90?
<tjaalton> yep
<ricotz> if you are changing the drm stack it could be a legit failure though
<tjaalton> yep
<tjaalton> I know it is
<ricotz> nvidia doesnt build on 4.14
<ricotz> ok
<tjaalton> right, I'll fix that
<tjaalton> actually it's drm-intel-next-queued, which has drom from 4.14 and then some
<tjaalton> *Drm
<tjaalton> uh
<tjaalton> *drm
<ricotz> I guess you have to figure this out yourself then
<tjaalton> sure
<ricotz> there are some hacky 4.14 patches around
<ricotz> mamarley, hi, btw not a fan that you already copied 384.90
<ricotz> I was running it and didn't had issues though
<tjaalton> at which point are the dkms patches applied?
<tjaalton> the PATCH lines in dkms.conf are all commented out
<ricotz> tjaalton, there are no patches required up to 4.13.x
<tjaalton> ah
<ricotz> and 4.14 is not supported
<ricotz> you will have to add one
<tjaalton> why keep the old crap there to confuse random people? :)
<ricotz> for reference/ as how to ;)
<tjaalton> ok then
<mamarley> ricotz: Sorry, I thought you had already looked at it when I uploaded it without the ARM binary on Friday.
<ricotz> mamarley, I see, I just confirmed that I read your message
<tjaalton> wasn't too hard to make nvidia build against 4.13+dinq
<tjaalton> but now I need to provide something with the kernel to check against, since it's not really 4.13 nor 4.14
<tjaalton> or, fix conftest.sh
<ricotz> tjaalton, what is the goal here?
<ricotz> why aren't you just using 4.14+
<tjaalton> because I canm't
<tjaalton> -m
<tjaalton> you'll hear about it in a few weeks
<ricotz> backporting the drm stack like in the good old days...
<tjaalton> alright, I have a diff to the source that adds a couple of new tests to conftest.sh, works with funny kernels and doesn't rely on version.h
<tjaalton> mamarley: this seems to build at least, I have no hw to test https://pastebin.com/YFcVb8ZF
<mamarley> tjaalton: I think you highlighted the wrong person there; I'm not sure what this is about.
<tjaalton> mamarley: you don't upload new versions to the ppa?
<mamarley> tjaalton: I do, but I hadn't previously been attempting to install the driver on 4.14.
<tjaalton> ah
<mamarley> I usually hold off until -rc5 or -rc6 or so before installing the RC kernel, since in the past damage has been done to people's filesystems by installing early RCs.
<tjaalton> i'll have test feedback tomorrow
<mamarley> Thanks for the patch though!
<mamarley> It definitely looks more complicated than anything I would have been able to come up with myself.
<tjaalton> had to do it this way so that it builds with drm-intel-next
<tjaalton> and also mainlines
<mamarley> I imagine if it needs that to build against drm-intel-next, it will probably also need it for 4.15 later on down the road.
<tjaalton> no i mean can't do simple version comparison
<tjaalton> drm-intel-next is (currently) 4.13
<mamarley> Ah, OK, sorry, I misunderstood.
<ricotz> tjaalton, I don't think this will work with the real 4.14, I expected there to be GPL issues
<ricotz> tjaalton, what is happening with the legacy drivers in "a few weeks"?
#ubuntu-x 2017-09-27
<tjaalton> ricotz: right, need to test with 4.14 too
<tjaalton> ricotz: and legacies probably need something similar
<tjaalton> then again, the legacy drivers probably become useless soon unless nvidia adds glvnd support to them..
<ricotz> tjaalton, yeah, I was implicitly referring to glvnd, I guess only 340 will be relevant here while 304 is going EOL this year
<tjaalton> I let them know that we'll switch over in 18.04
<tjaalton> so far I heard crickets
<tjaalton> FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'sme_me_mask'
<tjaalton> with 4.14rc2
#ubuntu-x 2017-10-01
<billygoat> Is this the channel for x org?
#ubuntu-x 2018-09-27
<mamarley> soee_: If you're still interested in NVIDIA 410, there is a package in my staging PPA for all supported Ubuntu releases now.  It has been tested and found to be working by one other user so far.
<tjaalton> so it does tricks?
<mamarley> Apparently.
<soee_> mamarley: will try it
<soee> mamarley: works fine
<soee> on Bionic
#ubuntu-x 2018-09-28
<mamarley> ricotz_: I was eventually able to make 410.57 packages for Bionic, Xenial, and Trusty in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.  At least two users have tested the Bionic ones.
#ubuntu-x 2018-09-29
<ricotz> mamarley, great, I haven't got to run it myself here yet
