#ubuntu-x 2006-11-13
<Ubugtu> New bug: #71577 in xorg "Edgy upgrade: lost ability to change screen resolution" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71577
<Ubugtu> New bug: #71615 in control-center "Keyboard applet's Layout window does not display layouts" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71615
<Ubugtu> New bug: #71635 in linux-restricted-modules-2.6.17 "madwifi unloads immediately inserting module" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71635
<Ubugtu> New bug: #71636 in linux-restricted-modules-2.6.17 "madwifi-ng is include but not the wlanconfig utility" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71636
#ubuntu-x 2006-11-14
<Ubugtu> New bug: #71745 in xkeyboard-config "No UK pound sign" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71745
<Ubugtu> New bug: #70082 in linux-restricted-modules-2.6.17 (restricted) "xorg crashes while opening text file in gedit" [Undecided,Fix released]  http://launchpad.net/bugs/70082
#ubuntu-x 2006-11-15
<Ubugtu> New bug: #71846 in linux-restricted-modules-2.6.17 "ATI Installation" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71846
<Ubugtu> New bug: #71869 in xorg "Coming from locked screen shows password prompt in the middle of the two..." [Undecided,Unconfirmed]  http://launchpad.net/bugs/71869
<Ubugtu> New bug: #69935 in flashplugin-nonfree "mozilla and firefox browsers crash if flash installed" [Undecided,Unconfirmed]  http://launchpad.net/bugs/69935
<Ubugtu> New bug: #70287 in flashplugin-nonfree "Crash in http://www.banesto.com" [Undecided,Unconfirmed]  http://launchpad.net/bugs/70287
<Ubugtu> New bug: #71913 in xorg "X appears to crash randomly" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71913
<Ubugtu> New bug: #71920 in linux-restricted-modules-2.6.17 "installing nvidia-glx disables glx support for other drivers" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71920
* #ubuntu-x  [freenode-info]  channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
#ubuntu-x 2006-11-16
<Ubugtu> New bug: #71862 in xorg (main) "NVIDIA card incorrectly configured in xorg.conf " [Undecided,Unconfirmed]  http://launchpad.net/bugs/71862
#ubuntu-x 2006-11-17
<Ubugtu> New bug: #72114 in xserver-xorg-input-synaptics "Touchpad should be disabled when typing" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72114
<Ubugtu> New bug: #72119 in mesa-utils "glxinfo crashes - seg fault core dumped" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72119
<Ubugtu> New bug: #72122 in linux-restricted-modules-2.6.17 "FGLRX Version Mismatch" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72122
<Ubugtu> New bug: #72139 in xserver-xorg-video-ati "R250 in HP Pavilion laptop no longer works with external monitor" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72139
<Ubugtu> New bug: #72151 in xserver-xorg-video-ati "Error message when running Adept" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72151
<Ubugtu> New bug: #72153 in xserver-xorg-video-ati "[Regression]  Bad resolution choices on Edgy live CD" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72153
<Ubugtu> New bug: #72174 in xserver-xorg-video-trident "using up/down/right/left arrow in insert (i) mode wont works" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72174
<Ubugtu> New bug: #72199 in xserver-xorg-input-synaptics "Laptop Ac 100%cpu" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72199
<Ubugtu> New bug: #72231 in xorg "DPMS Backlight will not stay off in xorg, if any ACPI event comes" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72231
#ubuntu-x 2006-11-18
<Ubugtu> New bug: #72263 in xorg "Blank video playback in multimedia players" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72263
<Ubugtu> New bug: #62988 in firefox "[Edgy]  BadMatch (invalid parameter attributes)" [Unknown,Confirmed]  http://launchpad.net/bugs/62988
<Ubugtu> New bug: #72308 in gnome-power-manager "Dim panel on idle not working correctly with Asus V6J" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72308
<Ubugtu> New bug: #72353 in xserver-xorg-video-i810 "X cannot start with Intel 855GM intergrated graphics" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72353
<Ubugtu> New bug: #72361 in xserver-xorg-driver-i810 "libGL warning: 3D driver claims to not support visual 0x4b" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72361
<Ubugtu> New bug: #72375 in xorg-server "Xorg segfault in DRIDoBlockHandler" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72375
#ubuntu-x 2006-11-19
<Ubugtu> New bug: #72380 in xconsole (main) "Console font/locales error." [Undecided,Unconfirmed]  http://launchpad.net/bugs/72380
<Ubugtu> New bug: #72431 in xorg "offset after changing resolution 1280x800 -> 1024x768)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72431
<Ubugtu> New bug: #72483 in Ubuntu "Graphics arn't as good as they are when I boot windows instead of ubuntu..." [Undecided,Needs info]  http://launchpad.net/bugs/72483
#ubuntu-x 2007-11-14
<bryce> morning
<tepsipakki> morning bryce 
<tepsipakki> bryce: I checked the fedora9 xserver package, and it has a newer version of the dreaded patch
<bryce> hrm
<bryce> the XAA patch?
<tepsipakki> http://users.tkk.fi/~tjaalton/dpkg/xserver-1.4.99-xaa-evict-pixmaps.patch
<tepsipakki> yep
<bryce> what do you think about it?
<tepsipakki> I'm not sure, yet
<tepsipakki> should I upload the new -intel?
<tepsipakki> bbl, home ->
<bryce> yes definitely
<ubotu> New bug: #162726 in xorg (main) "Xorg Crash when closing screen on clone desktop setup" [Undecided,New] https://launchpad.net/bugs/162726
<tepsipakki> bryce: three of the peter's intel patches have been merged upstream, three don't apply fully and two apply
 * bryce nods
<tepsipakki> so I'll leave those that don't as commented out from the series so he can take a look
<bryce> I had a meeting with Rolla from Intel today to discuss bugs and the intel driver development process
<tepsipakki> how did it go?
<bryce> I gave her a lot of questions she'll be digging up answers to for us, and picked 5 bugs to highlight to her
<tepsipakki> good
<bryce> it went well, I think this gives us a better mechanism for escalating bugs than posting them to fdo
<bryce> (or in addition)
<tepsipakki> -intel uploaded
<tepsipakki> I didn't have time to edit the git-documentation, but maybe tomorrow..
<tepsipakki> now bed, good night! ->
<tepsipakki> +to
#ubuntu-x 2007-11-15
<ubotu> New bug: #158202 in xresprobe (main) "Ubuntu installer crashes to a blank screen" [Undecided,New] https://launchpad.net/bugs/158202
<ubotu> New bug: #155372 in openoffice.org (restricted) "Open Office does not start when using fglrx ATI driver." [Unknown,Confirmed] https://launchpad.net/bugs/155372
<ubotu> New bug: #162807 in xserver-xorg-video-nsc (main) "GX2 video doesn't work in Gutsy" [Undecided,New] https://launchpad.net/bugs/162807
<ubotu> New bug: #162818 in xorg (main) "german keyboard layout reverts to american one on reboot" [Undecided,New] https://launchpad.net/bugs/162818
<ubotu> New bug: #56649 in xserver-xorg-video-sis (main) "include path to strtod()" [Undecided,Fix released] https://launchpad.net/bugs/56649
<ubotu> New bug: #162888 in mesa (main) "ATI radeon - complete system lock-up with 7.10" [Undecided,New] https://launchpad.net/bugs/162888
<ubotu> New bug: #112279 in xkbutils (main) "Openoffice in Ubuntu doesn't work with devnagari fonts" [Undecided,New] https://launchpad.net/bugs/112279
<ubotu> New bug: #44393 in acpi-support (main) "After closing the lid, video does not come bak by pressing any key." [Medium,Incomplete] https://launchpad.net/bugs/44393
<bryce> morning
<ubotu> New bug: #159309 in linux-source-2.6.22 (main) "Gutsy (k)ubuntu 7.10 on notebook HP nx6110: lid state incorrect after close-reopen (dup-of: 44393)" [Undecided,New] https://launchpad.net/bugs/159309
<tepsipakki> evening..
<tepsipakki> oh, past midnight
<tepsipakki> guess it's morning then :P
<ubotu> New bug: #132241 in linux-restricted-modules-2.6.22 (restricted) "[nvidia-glx] Many GL apps show black windows with onboard GeForce 4 MX 440" [Undecided,Invalid] https://launchpad.net/bugs/132241
<ubotu> New bug: #115705 in linux-restricted-modules-2.6.22 (restricted) "[fglrx] openoffice crashes on startup" [Undecided,New] https://launchpad.net/bugs/115705
<Q-FUNK> :)
<bryce> hi guys
<Q-FUNK> hi bryce!
<tormod> hi, I noticed build failures on hppa (libgl1-mesa-dev could not be installed). Is this normal/known/fixed ?
<bryce> I think it's known; I  think tepsipakki had mentioned it to someone (pitti?) earlier
<tormod> good
#ubuntu-x 2007-11-16
<ubotu> New bug: #163003 in xserver-xorg-video-intel (main) "In xorg.conf, "DisplaySize x y" make no 3D acceleration" [Undecided,New] https://launchpad.net/bugs/163003
<ubotu> New bug: #107506 in linux-restricted-modules-2.6.22 (restricted) "openoffice 2.2 start up error on Feisty" [Undecided,New] https://launchpad.net/bugs/107506
<tepsipakki> morning guys
<tepsipakki> I'll merge mesa so it'll get built on hppa
<ubotu> New bug: #22915 in xserver-xorg-video-sis (main) "sis dri refuses to work since latest update to 1:0.8.1 (dapper) unclean update" [Low,Invalid] https://launchpad.net/bugs/22915
<ubotu> New bug: #163089 in xserver-xorg-video-sis (main) "[hardy] upgrade driver to 0.9.4" [Undecided,New] https://launchpad.net/bugs/163089
<ubotu> New bug: #163094 in xorg (main) "[Package Removal Request] Please remove these from hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/163094
<ubotu> New bug: #162950 in totem (main) "Totem crashes on close in gutsy with X error (dup-of: 111257)" [Undecided,Invalid] https://launchpad.net/bugs/162950
<ubotu> New bug: #163158 in linux-restricted-modules-2.6.22 (restricted) "[hardy] nvidia-glx-new driver and xserver-xorg-core version mismatch" [Undecided,New] https://launchpad.net/bugs/163158
<bryce> sheesh there's a lot of suspend/resume bugs with -intel
<Q-FUNK> bryce: you mean there's any driver without suspend/resume issue? ;)
<bryce> hah
<ubotu> New bug: #162149 in xorg (main) "Nautilus won't open or start in Ubuntu Gutsy with multiple monitors" [Undecided,New] https://launchpad.net/bugs/162149
<ubotu> New bug: #128297 in linux-restricted-modules-2.6.22 (restricted) "avm fritz wlan driver missing (dup-of: 104191)" [Undecided,New] https://launchpad.net/bugs/128297
<tormod> hi bryce, are you sure bug 71913 is a dup?
<ubotu> Launchpad bug 71913 in linux-restricted-modules-2.6.22 "[nvidia] X crash in compPaintWindowBackground" [High,Confirmed] https://launchpad.net/bugs/71913
<tormod> sorry I meant 86881 a dup of that one
<bryce> tormod: no I'm not sure; in fact since the backtraces don't match, I would guess they're unrelated
<ubotu> New bug: #163192 in xorg (main) "vesa driver freezes on VIA P4M900 " [Undecided,New] https://launchpad.net/bugs/163192
<tormod> I dug through mesa (Undecided, New) tonight. Down to one bug, my own...
<tormod> can someone low,wishlist 122994 please if they find it appropriate?
<bryce> I've written up the start of a troubleshooting section for suspend/resume, hibernate, and other mode change issues:  https://wiki.ubuntu.com/X/Debugging#head-0b6e9c6b60fa07cda4013a1c51239f1c14c4f89d
<bryce> sure
<bryce> timo should probably take a look at that one
<ubotu> New bug: #163077 in xorg "Resolution not supported" [Undecided,New] https://launchpad.net/bugs/163077
<tormod> bryce, just to be sure, you don't ask people to file bugs and assign them to you?
<bryce> I hardly ever do, but I did ask TeTeT to do that about 15 min ago
<tormod> was that bug #163192?
<ubotu> Launchpad bug 163192 in xorg "vesa driver freezes on VIA P4M900 " [Undecided,New] https://launchpad.net/bugs/163192
<bryce> yes
<tormod> d'oh, I will apologize then :)
<tormod> bryce, interesting you gave #122994 "high", since the DD just seemed to think it was irrelevant.
<tormod> do you think I should file a new Debian bug, or make a patch for Ubuntu?
<bryce> make a patch for ubuntu
<tormod> actually the orig.tar.gz doesn't look so clean either...
<tormod> oh it's such a mess I give up. upstream should clean up, then Debian, then we'll see.
<bryce> ok
<bryce> yeah mesa is a pita
<tormod> it's just cruft - unused files.
<tormod> does anyone know if Hardy mesa installs and runs fine on Gutsy?
<jcristau> what's the problem with the extra files in the mesa source package?
 * tormod leaves that one to bryce :)
<jcristau> we're building from git, so removing the files that aren't in the tarball manually would be time-consuming and error-prone afaics
<tormod> shouldn't you make the orig.tar.gz from upstream git then?
<jcristau> i suppose we could. i'm not sure why it matters though.
<tormod> IMO it's just ugly, but not a huge problem. personally I don't like inline patches, even if they're just adding files to src/
<tormod> inline - I mean diff.gz contents outside debian/
<jcristau> don't look at the diff.gz then :) the real source is the git repo anyway
<tormod> :) but ideally we want a smallest possible diff.gz right, close as possible to the upstream release. Now it's a little bit opaque what has been changed or not.
<tormod> well I should probably get friends with git.
<tormod> jcristau: I try to follow http://wiki.debian.org/XTips for the ati driver. The merge fails at: git pull . debian-unstable;  Any clue?
<tormod> I thought I could use debian-experimental instead, but then git checkout fails with "error: pathspec 'debian-experimental' did not match any file(s) known to git."
<jcristau> tormod: git-branch -a will list the branches
<jcristau> it'll be <something>/debian-experimental
<tormod> thanks, origin/ I suppose
<tormod> now I get "fatal: Fetch failure: ." at git pull . origin/debian-experimental
<tormod> if jcristau or anyone can spot the problem in https://wiki.ubuntu.com/XorgOnTheEdge?action=AttachFile&do=view&target=auto-xorg-git.v3.sh
#ubuntu-x 2007-11-17
<ubotu> New bug: #163237 in linux-restricted-modules-2.6.20 (restricted) "X Problems with nVidia on Qudra FX 1600M in Dell Precision M6300" [Undecided,New] https://launchpad.net/bugs/163237
<ubotu> New bug: #153917 in xserver-xorg-video-ati (main) "gnome-system-monitor when run as user has display problems on process tab.screen flashes on/off whenever the mouse cursor is on screen.flashing stops when mouse cursor is off screen.when run as sudo NO problem,always repeatable as user." [Low,Fix released] https://launchpad.net/bugs/153917
<ubotu> New bug: #57878 in xkeyboard-config (main) ""Serbia and Montenegro" no longer exists" [Undecided,Confirmed] https://launchpad.net/bugs/57878
<tormod> timo or bryce, can you ack bug #163356 please?
<ubotu> Launchpad bug 163356 in xserver-xorg-video-savage "please sync xserver-xorg-video-savage 1:2.1.3-5 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/163356
<tormod> bryce, http://people.ubuntu.com/~bryce/Xorg/versions_current.html seems broken: there are no Debian versions.
<ubotu> New bug: #163356 in xserver-xorg-video-savage (main) "please sync xserver-xorg-video-savage 1:2.1.3-5 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/163356
<tormod> can someone wishlist,low bug #157706 please?
<ubotu> Launchpad bug 157706 in xserver-xorg-video-ati "ATI crash with several graphics boards or other non-randr 1.2 drivers" [Undecided,New] https://launchpad.net/bugs/157706
<ubotu> New bug: #163250 in xorg (main) "Mouse cursor disappears in firefox during page loading" [Undecided,New] https://launchpad.net/bugs/163250
<bryce> tormod: ok wishlisted and acked.  
<bryce> tormod: regenned page with debian
<bryce> (I have to manually generate it to include debian packages for now, which is why it doesn't always show them)
<tormod> down to zero New bugs in -ati and mesa!
<bryce> yay!
<Q-FUNK> mesa been jah-jah binks
<bryce> what's up q?
<Q-FUNK> playing with the newest version of the ThinCan.
<Q-FUNK> benchmarking it against the previous one.
<Q-FUNK> waiting to see what sort of miracles dilinger will manage to accomplish with -amd
#ubuntu-x 2007-11-18
<tormod> bryce thanks for the acks and updates
<tormod> good night
<ubotu> New bug: #162795 in nautilus (main) "Cannot rename files with Traditional Chinese in Nautilus (dup-of: 66104)" [Low,Invalid] https://launchpad.net/bugs/162795
<ubotu> New bug: #129910 in xserver-xorg-video-intel (main) "tty[1-6] are active but display nothing in Gutsy" [Undecided,New] https://launchpad.net/bugs/129910
<ubotu> New bug: #163105 in xkeyboard-config (main) "Writer uses straight ticks instead of apostrophes" [Undecided,New] https://launchpad.net/bugs/163105
<ubotu> New bug: #163582 in xserver-xorg-video-intel "X.org crash when watching video on Intel graphics card" [Undecided,New] https://launchpad.net/bugs/163582
<tormod> bryce, for sync requests such as bug #163356, you are allowed as a dev to subscribe ubuntu-archive directly.
<ubotu> Launchpad bug 163356 in xserver-xorg-video-savage "please sync xserver-xorg-video-savage 1:2.1.3-5 from Debian unstable main" [Medium,Confirmed] https://launchpad.net/bugs/163356
<tjaalton> hmm
<tjaalton> maybe I'll just be lazy and not change the nick :)
<tjaalton> something happened to my irc-connections and it didn't reconnect
<ubotu> New bug: #159576 in ubuntu "blank screen when booting from live cd ubuntu 7.10 (dup-of: 132716)" [Undecided,Incomplete] https://launchpad.net/bugs/159576
<ubotu> New bug: #163673 in xorg (main) "[gutsy] unable to add screen resolution" [Undecided,New] https://launchpad.net/bugs/163673
#ubuntu-x 2008-11-10
<tjaalton> superm1: ping? is the latest fglrx known to be buggy with compiz & video?
<tjaalton> superm1: apparently bug 179042
<ubottu> Launchpad bug 179042 in fglrx-installer "Videos tear and "blink" when enabling compiz [AMD Feature #7647] [EPR#257833]" [Medium,Triaged] https://launchpad.net/bugs/179042
<wgrant> tjaalton: Doesn't the EPR # mean it has been forwarded to AMD already?
<tjaalton> wgrant: probably so
<tjaalton> there should be a wikipage with the forwarded bugs
<tjaalton> on it
<tjaalton> sigh, looks like wacom upstream is just ignorant
<wgrant> I noticed...
<tjaalton> http://sourceforge.net/mailarchive/forum.php?thread_name=20081009171824.GV5387%40cathedrallabs.org&forum_name=linuxwacom-devel
<wgrant> I thought either I was completely misunderstanding it, or they were ignorant.
<wgrant> And I suspected the latter.
<wgrant> Oh.
<wgrant> More traffic.
<tjaalton> seems like Ping doesn't follow the -devel list
<wgrant> How related to linuxwacom is Ping?
<tjaalton> the main author
<tjaalton> or developer
<wgrant> Oh.
<wgrant> Who is this Vincenzo character?
<tjaalton> wgrant: where?
<wgrant> -devel-discuss.
<wgrant> See #-devel
<tjaalton> ah, reading
<wgrant> He's just insane.
<tjaalton> ok, I won't bother then :)
<wgrant> Heh.
<tjaalton> loads of stuff to do
<tjaalton> starting from getting nvidia 173 in hardy-proposed
<tjaalton> with cuda
<wgrant> Aha.
<wgrant> Shiny.
<tjaalton> well, the library at least
<Ng> wgrant: a frustrated user, by the looks of it
<Ng> it's a tad harsh to call him insane, I would say
<Ng> it's not that he's especially wrong either (assuming you mean the thread about hardware support regressions), he's just not addressing the issue in a way that will have any positive outcome
<tjaalton> maybe his vga-problems are related to the latest upload to hardy-proposed, where every chip inluding 855 and earlier have to be quirked
<tjaalton> oh, it's only about vga-out
<wgrant> Bug #295990. Fsck. FOrgot about that.
<ubottu> Launchpad bug 295990 in xorg-server "Keyboard layout reset after attaching USB keyboard" [Undecided,New] https://launchpad.net/bugs/295990
<wgrant> I didn't bother with the keyboard stuff in g-s-d, because most of the settings are either really global or don't work with evdev...
<wgrant> But of course layout needs setting per-device.
<tseliot> tjaalton: nvidia-173 in hardy proposed???
<tseliot> tjaalton: that will break things for a few users, please don't do it
<tseliot> the reason why I didn't touch the lrm in hardy (instead of using the lrm-envy) is also that the current nvidia-glx-new works when 173, etc. doesn't with certain hardware configurations
<tseliot> s/when/while/
<tseliot> I think that backporting driver 173 and 178 to hardy through lrm-envy would be less risky
<tjaalton> tseliot: it's not my idea
<tjaalton> tseliot: what would break?
<tjaalton> 173 didn't drop any hw support AIUI
<tseliot> tjaalton: there are some cards (I don't remember which ones) for which the driver won't work
<tseliot> and I'm not talking about cards being dropped by a driver
<tseliot> the driver won't work at all
<tseliot> tjaalton: who asked you to do this? (not to blame it on him but only to talk to him about this)
<tjaalton> stefan bader
<tseliot> username?
<tjaalton> not on irc atm
<tjaalton> dunno
<tseliot> anyway rtg asked me to backport 178 to hardy and I will do it in the lrm-envy packages
<tseliot> but we have to be careful not to break the packages in main
<tseliot> tjaalton: BTW did you tell him about the linux-restricted-modules-envy?
<tjaalton> tseliot: no, I bet he knows already
<tseliot> ok, if you see him (metaphorically speaking), please ask him to talk to me
<tjaalton> I'll reply to his email
<tseliot> ok
<tseliot> tjaalton: oh and I know that you maintain the lrm in hardy but in the future please notify me when you decide to modify them (as regards fglrx and nvidia) so that we can discuss the changes, etc.
<tjaalton> tseliot: I don't really maintain it anymore, not since it was frozen :)
<tseliot> hehe right ;)
<pwnguin> Vicenzo is insane?
<pwnguin> interesting
<superm1> tjaalton, the fact that is has an EPR means AMD has an internal bug filed about it
<superm1> we'll be closing out bugs per their announce/release notes based on those EPR's
<tjaalton> superm1: yeah, a friend of mine suffers from it, that's why I was asking
<bryce> heya
<bryce> tjaalton: no need for wiki page, I got this set up for us to keep track:  https://bugs.edge.launchpad.net/fglrx/+bugs
<bryce> tjaalton: also, when you run across bugs that need upstreaming to AMD, we now have a way to mark them - click the "Affects project..." and then tick the third bullet "just mark as needs upstream for now"
<bryce> (full process documented at https://wiki.ubuntu.com/X/Upstreaming)
<tjaalton> bryce: ok, thanks
<bryce> how's thing tjaalton?
<tjaalton> got my plane tickets today
<bryce> :-)
<tjaalton> trying to decide what souvenirs to buy ;)
<bryce> have you been to san francisco before?
<tjaalton> nope, there are too many places to see when I have only the sunday off
<bryce> I used to live in san francisco, I can give tips if you need suggestions
<tjaalton> sure thanks
<bryce> I would suggest catching the BART from San Jose and get off downtown, then do one of the walking tours down through china town to fisherman's warf.  That should give maximum SF-ishness in the least amount of time.
<superm1> bryce, i'm  gonna be in SF for a few days before UDS starts too.  i'll have to get some ideas from you  then too :)
<bryce> sure
<bryce> if you like musicals/plays/concerts, it is a great place to catch one of those
<bryce> here's a link showing the neighborhoods:  http://www.sfcityguides.org/descriptions.html
<superm1> would you recommend a car for those few days?
<tjaalton> ok that should be a start :)
<bryce> the top NE corner is where the biggest concentration of "things to see" is, and if you have limited time, is where I'd suggest focusing
<bryce> superm1: well, downtown SF is *impossible* to get around in by car
<superm1> okay then for sure no car
<bryce> but the good news is it's totally walkable/public-transitable.  In fact the whole time I lived there I kept my car in storage
<bryce> so you just need to sort out getting around in San Jose
<bryce> San Jose is standard U.S. can't-get-around-without-a-car
<superm1> right, about what i'm used to :)
<bryce> although if the hotel is within walking distance of the lightrail, it might be ok
<superm1> havent picked one out yet (but that reminds me i need to! :)
<bryce> the weather in downtown SF is likely to be pretty cold and rainy, so plan accordingly
<bryce> in San Jose it will be a bit better.
<superm1> anything that's north of texas is cold to me now :)
<superm1> but you'd recommend a hotel in San Jose over finding one in SF though provided i can find one close to a light rail?  assuming due to cost?
<bryce> oh definitely
<bryce> right, hotels in downtown SF are damn expensive
<superm1> okay that's good to know
<bryce> superm1: is the one that UDS is held in booked up yet?  
<superm1> bryce, not sure.  i'd imagine so?
<superm1> but also given it's in mountain view - i'd expect pricey...
<bryce> oh duh, UDS is at google
<superm1> that'll be the other challenge to figure out; getting from SF to MTV cost effectively
<bryce> well, when I went to the X conference at google earlier this year, I got a hotel in San Jose and a car, and drove in each day.  Traffic wasn't too bad (the conference started fairly late though).  Walking would have been impossible.
<bryce> UDS is at a different google location than that, but might be the same situation.  not sure
<bryce> a lot of the X guys shared cars
<superm1> well i heard there is a free shuttle if you talk to the right people 
<bryce> cool, that could work
<superm1> i just dont know who those people are, and if i dont find them, it will probably just end up being a taxi or one day car rental
<bryce> anyway, even if you do rent a car, my recommendation for exploring SF would be the same - park it at a BART terminal and take BART in
<superm1> okay, will definitely keep that in mind.  would probably leave the car rental for sunday then to use in exploring San Jose and for driving down
<superm1> (if anything)
<tjaalton> so are sunnyvale, mtv etc part of san jose?
<superm1> tjaalton, http://maps.google.com/maps?f=q&hl=en&geocode=&q=san+jose+ca&sll=37.0625,-95.677068&sspn=42.224734,93.164063&ie=UTF8&ll=37.51844,-121.92215&spn=0.663338,1.455688&z=10
<superm1> you can see the breakdown there a bit
<bryce> superm1: yeah all three sort of run together in a big sprawl
<tjaalton> yeah i've used gmaps quite a bit :)
<tjaalton> my brother-in-law has been there many times
<tjaalton> and asked me to bring some parts for his '65 grand prix ;)
<bryce> hehe
<bryce> tjaalton: hey, given that Intel is no longer supporting i815/i825 chips (maybe more pre-855?) on -intel, I'm wondering about if we could/should put -i810 back in the archive
<superm1> bryce, hdmi audio on intel, any ideas what intel driver release it ends up falling into?  (i thought there was a video driver piece to it too)
<bryce> superm1: hmm no idea; I've never needed to touch video stuff before and would assume the kernel would split that out, but I've not done very much with hdmi so far
<superm1> bryce, well the video driver needs to let the audio driver know how much bandwidth it can have i believe. i thought there was an interaction there
<superm1> bryce, ah http://www.phoronix.com/scan.php?page=news_item&px=NjgzNg  there's some patches to both.  i'm assuming there will be more chatter on it in the coming months then
<bryce> superm1: ah cool
<tjaalton> bryce: but they don't support it either :)
<tjaalton> hm, still no internet.. at least my phone works
<tjaalton> s/internet/adsl/
<bryce> tjaalton: sure but at least (assuming it works at all), it'd give users the option.
<bryce> erf, already back up to 2000 bugs in ubuntu-x.  
<tjaalton> bryce: well, I don't know.. vincenzo's problem seems more like a hotkey-issue than a bug in -intel
<tjaalton> besides, -i810does not support xserver 1.5
<tjaalton> aiui it's not pcitoolized
<bryce> ahh
<bryce> good point.  So if community folks want -i810 back, they'll need to first get it up to date for 1.5.
<tjaalton> or better, help intel testing the new releases for regressions
<tjaalton> of -intel
<bryce> no, I'm thinking of the cases where the testing has already done, I've upstreamed the issue to Intel, and they've said they won't be supporting it in -intel.
<bryce> +been
<tjaalton> meaning that they refuse to include fixes or that they wont be doing the work themselves?
<bryce> the latter
<tjaalton> right, so the community might be able to fix them. i don't know which is more work, porting the driver (with other bugs) or fixing the bugs
<tjaalton> night
<bryce> night tjaalton
<tormod> hi there, I get some bad, spurious Xorg hangs on Intrepid. In order to investigate, I built xserver 1.5.3 to get the automatic backtracing. now it locks up at startup... I suspect the "RAW mode" commit. Any experiences among you?
<tormod> or do I miss some crucial ubuntu patches? (I built it from fdo+debian git)
<tormod> or do I need to recompile the DDX?
<tormod_> for once, my ssh session stayed alive/recovered. Actually Xorg is not hung, but died and I don't get my console back. just the gray X screen and the cursor (from running startx).
<tormod_> gdb is my friend: evdev_drv.so: undefined symbol: XIRegisterPropertyHandler
<tormod_> gotta love these xserver point releases....
<wgrant> tormod_: We carry property patches separately.
<tormod_> wgrant, thanks! I will take a look
<tormod_> I guess all those patches are in the ubuntu branch on git.debian.org and I just have to pull from there, d'oh.
<tormod_> hmm why is patch 138 not in git, but listed in "series" ?
#ubuntu-x 2008-11-11
<tjaalton> bryce: san jose has caltrain, not BART :)
<tjaalton> public transport seems pretty cheap there, but caltrain is surprisingly slow
<tjaalton> ~2h from the hotel to the airport, but only $7.25
<mvo> tjaalton: so you are comming?
<mvo> hm, so I read reports that compiz does hang on a i945 for intrepid
<mvo> anyone here with more information?
<tjaalton> mvo: yes
<tjaalton> no idea about the i945 issue
<mvo> tjaalton: is there someone familiar with intel I could talk to? do we have a contact at intel? I mean, blacklisting i830,845,945 does not leave that many cards that we don't blacklist
<mvo> bryce: ^--- ?
<tjaalton> mvo: bryce knows better, but I think he's been talking to jbarnes at least
<pcjc2> hi guys
<pcjc2> Anyone about who knows about the evdev vs. joysticks problem?
<tjaalton> o/
<pcjc2> https://help.ubuntu.com/community/Joystick_lshal_outputs suggests it is fixed with xserver-xorg-input-evdev 1:2.0.99+git20080912-0ubuntu6
<pcjc2> Not fixed for me, and 3Dconnextion space-navigator device
<pcjc2> according to changelog for the evdev driver, it was only an Amd64 big which was fixed
<tjaalton> yes
<tjaalton> evdev should refuse to use them
<tjaalton> so it's still picked for you?
<tjaalton> pcjc2: ^^
<bryce> heya
<bryce> (on holiday today)
<tjaalton> howdy
<bryce> tjaalton: ah, that's too bad, I thought bart went down that far
<tjaalton> not yet anyway, depends on how the ballot went :)
<bryce> too bad mvo's not online
<tjaalton> they are planning to extend it 16mi to san jose (the eastern route)
<bryce> tjaalton: if you can link up with enough other attendees, you can probably get a shuttle or taxi at a decent rate (and that will get you there faster)
<pcjc2> hi, sorry, got distracted in the lab
<pcjc2> tjaalton: Yes, lshal shows evdev being picked for the space navigator
<pcjc2> want the output posting somewhere... pastebin?
<jcristau> lshal picking evdev is ok, i think
<tjaalton> pcjc2: logfile should show if it's actually being used
<pcjc2> logfile does indeed show it being used
<pcjc2> (II) 3Dconnexion SpaceNavigator: Configuring as mouse
<pcjc2> (II) XINPUT: Adding extended input device "3Dconnexion SpaceNavigator" (type: MO
<pcjc2> USE)
<tjaalton> bryce: well I think that I'll just go straight to downtown for a couple of hours before getting to the airport, that should minimize waiting times on stations :)
<bryce> ah, good idea
<pcjc2> Seems that evdev's "is it a mouse" heuristic is being broken by the SpaceNavigator reporting as having mouse buttons
<pcjc2> (as well as axis)
<tjaalton> well, maybe the buttons are within the permitted zone
<tjaalton> duh, I've forgotten the command to show the keyid's of an input device?
<pcjc2> I have a driver I wrote / copy-pasted for it
<pcjc2> and it is finding those buttons as BTN_0 from the kernel's /dev/input/
<tjaalton> s/ten//
<pcjc2> ten?
<tjaalton> ok, s/forgotten/forgot/ :)
<tjaalton> I'm tired or somthing..
<pcjc2> ah... was looking for a number - brain didn't register the word forgotten
<tjaalton> heh
<pcjc2> ok, so its coming under the BTN_MISC rangeC
<pcjc2> s/C//
<pcjc2> But are there any devices which _are_ mice, which have no buttons under the BTN_MOUSE range?
<pcjc2> If not, that suggests a patch to the evdev driver to only register something as a mouse if it has axes, and (some) buttons which are > BTN_MOUSE
<tjaalton> hm, dunno
<pcjc2> s/>/>=/
<tjaalton> you should probably ask whot on #xorg-devel, although it's rather early down under
<pcjc2> My Hardy workaround, was to ensure I never installed the evdev driver, but going forward it would be nice to fix this properly
<pcjc2> xorg developers are in Oz?
<jcristau> x input developers are
<pcjc2> ok
<tjaalton> yes, whot and daniels both are :)
<pcjc2> I'll knock up a patch which seems "right" here, and post that and an explanation on xorg-devel
<pcjc2> (email)
<jcristau> but, you'll probably break something else if you change that check..
<pcjc2> No doubt... but as a local workaround, and a discussion point, it makes a good start
<jcristau> yup
<pcjc2> It would be nice to have this device handled properly by XINPUT generally
<pcjc2> I ended up writing a driver for the /dev/input/... device directly, rather than using XINPUT, due to various confusion about the way it represents its axis maxing it a bit screwey to use with xinput-joystic
<pcjc2> k
<pcjc2> its reporting relative axis, which IIRC, the joystic driver integrates
<pcjc2> where you really just want the raw-numbers (perhaps scaled) back for a 6DOF controller navigating a 3D application
<pcjc2> it makes no sense that the XINPUT system tries to return coordinates in X device space
<jcristau> doesn't XI give you the raw coordinates?
<pcjc2> it has been a while since i played with the device..
<pcjc2> there are about "n" different ways you can interface withit
<pcjc2> the proprioraty drivers open the USB device directly. You can use linux's input device support, X11...
<pcjc2> its not picking up the right number of axis at the moment - I'd guess because evdev has grabbed it, and thinks it is a mouse
<tjaalton> pcjc2: have you filed a bug on launchpad about this?
<pcjc2>  not yet, just figured I'd come and ask if this was supposed to be fixed along with the joystick issues which came up relating to evdev
<pcjc2> ah crap...
<pcjc2> Xinput is now a microsoft directX "name" as well
<pcjc2> Any idea what the easiest way to black-list the device is... so that evdev doesn't even try to use it?
<pcjc2> My application (and the "official" propriotary drivers) expect to own the device
<jcristau> an fdi file to unset the input.x11_driver key for that device
<pcjc2> Like in the comment here: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-October/005956.html ?
<jcristau> yeah
<tjaalton> pcjc2: people are reporting similar issues on bug 274203, so I'd like to redirect them to the new bug
<ubottu> Launchpad bug 274203 in xserver-xorg-input-evdev "Joystick detected as mouse, crashes X" [Undecided,Fix released] https://launchpad.net/bugs/274203
<jcristau> i didn't know people made proprietary drivers for joysticks..
<pcjc2> this is a Ndof controller. The proprieraty driver communicates with the application with X messags
<pcjc2> and their UI allows you to tune the 3D navigation preferences on a per-application basis. It is also their way of locking down using restrictive licensing... so I can buy a piece of hardware with no license to use the drivers for commercially related work
<pcjc2> On the plus side, the "Personal edition" is much cheaper, and with an OSS driver, no different to the expensive version ;)
<jcristau> heh
<pcjc2> didn't take too long for someone to clone the driver interface either... http://spacenav.sourceforge.net/
<bryce> http://www.collegehumor.com/video:1886349
<pcjc2> that would be funny if my XP desktop were _slower_ than my Intrepid install on this laptop...
<pcjc2> actually, it lots better since apt-get remove tracker* jockey* and landscape*
<pcjc2> I was upset to see how much disk IO was spent checking for propriatory drivers I don't have on the system
<tjaalton> yeah, they are such resource hogs ;)
<pcjc2> landscape is some kind of remote admin?
<jcristau> it's canonical's attempt to make money on support contracts aiui
<pcjc2> thought as much, hence apt-get remove 
<pcjc2> also, the gdm prefetch list was pointing to some bad links
<pcjc2> those readahead / prefetch files bitrot damned fast!
<tjaalton> the landscape client has no daemon, so it's harmless to have, unless you hate the stats when logging in from the console/ssh :)
<pcjc2> landscape-sysin took about 11 seconds blocking on disk-io if I'm interperting this bootchart correctly
<tjaalton> ah
<pcjc2> My laptop has a slow-spinning HDD, so I suffer from IO intensive boot processes
<pcjc2> For that matter... can't we have a "cron" type replacement start with the desktop, so the computer doesn't immediately check for apt updates every time I login?
<pcjc2> (It can wait a few seconds!)
<superm1> bryce, has there been any thought put forth in deciding whether to do SRU's or backports for newer nvidia drivers in the same release series?
<superm1> eg if NV were to do an updated 177 driver that fixed bugs
<tjaalton> duh, pcjc2 left.. http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?id=64554e4799a697d37dfd8be480f8eee636b9bea1
<bryce> superm1: it's something that there's been discussion about from time to time
<bryce> esp. around when we were thinking of doing an sru for -fglrx
<bryce> in general the release team is very uncomfortable doing sru's for binaries and would prefer avoiding it
<bryce> however, in the case where we would be going from a 100% non-functional binary driver, to a functional one, the case would be pretty evident
<bryce> in cases where the driver works for some people already, then the case to do an sru is harder to make
<bryce> with backports, the release team would be fine with that
<bryce> the trouble is aiui, the backport team is fairly manpower limited
<bryce> however that may be less of an issue in the case of binary drivers since they come precompiled ;-)
<bryce> and of course there's also envyng for solving the need
<superm1> bryce, okay well i expect a bug fix nvidia release very soon that is supposed to fix suspend regressions, so you'll see when it shows up i suppose
#ubuntu-x 2008-11-12
<njh> trying to get a marblemouse working on intrepid (upgraded from hardy)
<njh> two problems
<njh> first is the button reassignmentL:
<njh> njh@thestral:~/svn/lib2geom$ xinput set-button-map 6 1 8 3 4 5 6 7 2 9
<njh> X Error of failed request:  BadValue (integer parameter out of range for operation)
<njh>   Major opcode of failed request:  148 (XInputExtension)
<njh>   Minor opcode of failed request:  29 (X_SetDeviceButtonMapping)
<njh>   Value in failed request:  0xa
<njh>   Serial number of failed request:  13
<njh>   Current serial number in output stream:  13
<njh> the second is that although the scroll button correctly disconnects the cursor movement, it doesn't generate any scroll events
<njh> here's my props:
<njh> Device 'Logitech USB Trackball':
<njh> 	Device Enabled:		1
<njh> 	Middle Button Emulation:		1
<njh> 	Middle Button Timeout:		50
<njh> 	Wheel Emulation Inertia:		10
<njh> 	Wheel Emulation:		1
<njh> 	Wheel Emulation X Axis:		6, 7
<njh> 	Wheel Emulation Y Axis:		4, 5
<njh> 	Wheel Emulation Timeout:		200
<njh> 	Wheel Emulation Button:		9
<njh> 	Drag Lock Buttons:		0
<njh> these settings work on intrepid from scratch
<wgrant> njh: Please don't flood. The xinput problem is probably caused by your failing to understand that it wants a permutation of the buttons.
<njh> I gave it permutation of the buttons
<wgrant> There are precisely 9 buttons that X knows about?
<njh> how would I find out?
<njh> as I said, the same settings worked on a different machine
<njh> it's hard to debug this when debuging information is scant and the documentation lacking
<wgrant> It depends on the mouse, not the machine.
<njh> it is the same mouse
<njh> I simply unplugged it from one and moved it to the other
<wgrant> Are you sure you're giving it the right device ID?
<njh> but I'll just try again
<njh> yes
<njh> yep, it still works
<njh> so same mouse, both intrepid, same options
<njh> works fine on machine A (installed from CD)
<njh> doesn't on machine B (upgrade from vanilla hardy)
<wgrant> Same architecture?
<wgrant> No input devices in xorg.conf?
<njh> both 32 bit x86
<njh> all input devices commented out ("commented out by update-manager, HAL is now used")
<wgrant> 'xinput list' from both machines.
<wgrant> !pastebin
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<njh> *sniff*  how primitive
<wgrant> Hm?
<njh> can't copy and paste over remote desktop it seems :(
<njh> and now it works
<njh> oh well, bug solved
<wgrant> Heh.
<njh> though I wish I could make the hal thing work
<wgrant> What do you mean?
<njh> rather than using xinput
<wgrant> What isn't working about it?
<njh> I followed the instrutions at:
<njh> https://help.ubuntu.com/community/Logitech_Marblemouse_USB
<njh> but the fdi match file doesn't
<wgrant> Which bit doesn't work? Just the buttonmapping?
<njh> so I just created a new file.fdi with that xml
<wgrant> Oh.
<wgrant> That would do it.
<wgrant> That's not complete.
 * wgrant fixes.
<wgrant> Add:
<wgrant> <?xml version="1.0" encoding="ISO-8859-1"?>
<wgrant> <deviceinfo version="0.2"> <device>
<wgrant> To the start.
<wgrant> And:
<wgrant>   </device>
<wgrant> </deviceinfo>
<njh> incidently, any reason why that file isn't included in intrepid itself?
<wgrant> to the end.
<wgrant> Nobody I know has that hardware, and I wasnt sure if that was appropriate for the ubiquitous configuration.
<njh> ah, well everyone I mentioned I'd bought it too said they also had one
<wgrant> I hadn't heard of it until I tried to fix that page.
<njh> does it hurt to have such stuff?
<wgrant> Does everybody use the trackball like that?
<njh> given that it's 545 bytes
<njh> pretty much
<njh> it's the way that windows does it
<njh> ok, I've updated the fdi file
<wgrant> OK.
<njh> do I just unplug and replut?
<wgrant> That should do it, yes.
<njh> nup
<njh> where does the errors go?
<wgrant> Hmmm.
<wgrant> You could check /var/log/Xorg.0.log
<wgrant> It's possible that you'll need to restart hal (ie. reboot), but I've never had to.
<njh> it's finding the mouse, but setting the wrong options
<wgrant> Is it setting any of them?
<njh> yes, but to the hard defaults
<wgrant> You might want to try giving it the full button mapping - that might be why people have said the given fdi file doesn't do that.
<njh> it's not setting anything atm
<wgrant> Hmmmmm.
<njh> should  <merge key="input.x11_options.ButtonMapping" type="string">1 8 3 2 9</merge> be a permutation?
<wgrant> I suspect evdev will want it to be, yes.
<njh> (and if so, how do I find out the correct number of buttons)
<wgrant> mouse worked without it, but I'm not sure about evdev.
<njh> hmm
<njh> it hasn't set any of the other props though
<njh> which suggests that it isn't matching
<wgrant> Does lshal see that same product name?
<njh> yes
<wgrant> OK, you might have to restart hal. But don't do that while X is running.
<njh> no
<njh> that's bad
<njh> I wonder if adding that to the existing preferences file would work
<wgrant> It's possible that hal saw the file, noticed that it wasn't a real fdi file, so is now going to ignore it until you restart it.
<bryce> wgrant: why not restart hal while X is running?
<njh> it buggers everything up
<njh> btdt
<wgrant> bryce: X has got very very angry with me because of that twice now.
<wgrant> X wanders away and dies eventually.
<njh> yeah, that
<bryce> wgrant: interesting.  I've been doing that without issue, although not recently
<bryce> wgrant: is there a bug about that issue?  
<njh> ok, so deviceinfo tag is once per file?
<wgrant> bryce: I didn't think it would count as a bug.
<njh> it's a bit bad I think
<bryce> wgrant: no?  One of the advertised features of all this hal stuff was that hal changes could be made without having to restart X.
<wgrant> njh: deviceinfo is the top-level element, so yes, only one.
<wgrant> bryce: I normally don't have to restart hal to make changes to the hal config.
<njh> nup
<njh> still no go
<njh> so it's probably not matching something exactly
<njh> I wish it would tell me why not
<wgrant> bryce: Let's see what X does if I restart hal now... maybe brb.
<njh> a hal reload option might be useful
<wgrant> Hm.
<wgrant> X survived that time.
<wgrant> It doesn't always.
<njh> no
<njh> it could be a heisenbug
<bryce> huh.  well, if either of you run into this issue again, please file a bug on it with the logs / error messages.  That seems like something well worth getting fixed.
<njh> restarting hal didn't fix the problem in any case
<bryce> troubleshooting input-hotplug issues are hard enough without also having X fall to pieces ;-)
<wgrant> bryce: Sure, will do.
<njh> yes
<wgrant> Yep...
<njh> the doco says match key="@blah"
<wgrant> njh: Try contains= rather than string=
<njh> nup
<njh> I wish I knew exactly what steps are required
<njh> do I need restart hal after every edit?
<wgrant> njh: I don't think so. I can just drop a new file in /etc/hal/fdi/policy, replug the device, and have the new setting in place.
<njh> I don't even know if it is reading the file :(
<njh> ok
<njh> is there something I could put in the file which would prove it is being read?
<njh> perhaps a syntax error...
<njh> nup, a syntax error does not break it :)
<wgrant> I don't know how hal works, sorryu.
<wgrant> -u
<bryce> I was debugging by diffing lshal output before and after plugging in the device
<wgrant> That would work.
 * wgrant just read the email on ubuntu-x about the tablet config UI.
<wgrant> All of those things look like they should be exposed through XI device props...
<tjaalton> morning
<njh> >   input.x11_options.ButtonMapping = '1 8 3 2 9'  (string)
<njh> it's setting the buttons!
<njh> just nothing else
<wgrant> Morning tjaalton.
<bryce> heya tjaalton
<bryce> wgrant: yeah I'm writing a reply to that thread, it would be great to get your input on it as well
<njh> I'm wondering whether the x names differ from the xinput names
<wgrant> bryce: I think we're going to need one awfully big unified gnome-input-properties...
<bryce> wgrant: well my hope is to try to keep the scope of what we do within reason
<wgrant> Of course.
<njh> ok, I've got it correctly matching the mouse
<tjaalton> bryce: I was wondering, should we make it a policy that every change is in git, even the small ones. Then there would be no need to remove the Vcs-* stuff from control files like loÃ¯c did, and it would be more clear to the casual committer
<wgrant> njh: What needed changing?
<njh> <match key="info.product" string="Marble Mouse (4-button)">
<wgrant> Ah, so it's a different name.
<njh> doesn't actually set the xinput props though
<tjaalton> bryce: also, the mail address could probably be changed to ubuntu-x
<njh> but lshal sets props being defined
<wgrant> If hal sees them and the device has been replugged, X should see them too.
<wgrant> But the xinput/hal names won't match.
<bryce> tjaalton: to be honest, I find doing things in git to be a real hassle, and makes things take 2-3 times as long as they should
<wgrant> I think the old xorg.conf names should die soon and hal should be able to tell the server to set XI props.
<njh> hal does not need a restart
<njh> ok
<tjaalton> bryce: we should probably have a git BOF at UDS then :)
<njh> I've been removing the spaces from the prop names
<wgrant> bzr!
<tjaalton> bzr can't do git
<njh> is that bad?
<wgrant> njh: xinput properties don't have the same names. You should use fdi files as if they were xorg.conf.
<njh> oh
<njh> I have no idea what the xorg names are
<bryce> I'd be willing to give it a go with bzr
<wgrant> njh: The names in the example look good.
<wgrant> bzr makes sense, but the problem is that it's not trivial to keep pulling from git.
<wgrant> Importing from git is easy, but not continously.
<bryce> hm, I've tried doing merges through git a few times, but I found the procedure to be fairly intricate
<tjaalton> having stuff in git.d.o allows the debian people to see what we do, and point out potential problems like jcristau does
<bryce> for complex things like xserver, xorg, etc. that have a lot of patches and changes to merge, I can accept that it's worth the trouble, but with packages that have fewer changes it seems quicker just to do merges by hand
<njh> wgrant, but they don't work :)
<njh> so I can now effectively set hal attributes
<njh> but I can't work out how to convince myself that X is listening to them
<njh> bryce's diff trick is very helpful
<njh> add that to your toolbox!
<tjaalton> git fetch; git merge debian-unstable, that's not difficult
<njh> I find git frustrating
<njh> despite mental's badgering, I still find myself using svn
<tjaalton> when your own tree is old, you need to git rebase origin/ubuntu first
<tjaalton> there's at least one mesa change that is not in git yet
<njh> I suspect it's just curmudgeonness
<njh> it took me years to switch from cvs :)
<njh> at least with git I can use both on the same project
<wgrant> git doesn't seem to make sense.
<wgrant> bzr is fine.
<tjaalton> svn doesn't make sense :)
<njh> it must
<njh> it was written by god himself
<tjaalton> well I find bzr confusing so here we go :)
<njh> mental dislikes bzr
<njh> nup
<njh> those parameters are not being fed through to X
<njh> they get as far as hal
<bryce> njh, now that he works for canonical and will probably have to use it, it'll be interesting to see if his opinion evolves
<njh> actually, he hates it _since_ he started using it at canonical
<njh> on the other hand, he has seen the light wrt python :)
<wgrant> Who are we talking about?
 * njh smugly points out that bryce now uses apt and mental now uses python
<njh> wgrant, nobody knows...
<bryce> wgrant: njh and mental are two of the guys that founded Inkscape with me
<njh> he is known as....
<njh> ...mental
<wgrant> Ahh.
<njh> yes, the triumvirate: the maiden, the mother and the crone
<njh> (we're still fighting over who is what)
<bryce> njh: fwiw, I'm finally doing python too
<njh> bryce, good to hear
<njh> glad you've finally seen the light
<wgrant> How can one not do Python?
<njh> bryce and I used to argue about python vs perl
<njh> so, does anyone else have evidence that setting parameters via fdi actually has any effect on xorg?
<bryce> wouldn't go so far as seeing light...
<njh> because I can make them anything, and nothing changes
<wgrant> njh: Yes. I do it all the time.
<njh> the data is coming from somewhere else
<wgrant> njh: It depends on whether the driver is looking at them or not.
<njh> so what is ZAxis?
<njh> is it the same as YAxis?
<njh> is there an XAxis?
<njh> meh, I'm tired
<njh> thanks for all your hel[
<njh> help
<njh> at least I can trust hal works
<njh> I just need to connect it to xorg
<njh> however, unless you have evidence to the contrary, this page is wrong:
<njh> https://help.ubuntu.com/community/Logitech_Marblemouse_USB
<njh> perhaps you can ask if anyone has actually got it working
<njh> looks like people are still having trouble anyway
<wgrant> I've seen a few people on ubuntuforums use that fine,.
 * njh reads more bugs
<njh> really? (does spoke eyebrow thing)
<njh> or merely run away
<njh> ok, bed time
<njh> ttyl
<tjaalton> mvo: hey, I've seen a lot of "failed to install/upgrade" errors due to "package foo is already installed and configured". what's causing that?
<seb128> I was going to ask that too ;-)
<tjaalton> they are all over the place, so it's pretty common I guess..
<mvo> tjaalton: do you have a example  bug number for me?
<seb128> mvo: bug #296576
<ubottu> Launchpad bug 296576 in eog "package eog 2.24.1-0ubuntu1 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/296576
<tjaalton> mvo: bug 296571 (just happened to look at ghostscript bugs)
<ubottu> Launchpad bug 296571 in ghostscript "package ghostscript 8.63.dfsg.1-0ubuntu6 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/296571
<tjaalton> plenty of them against the x packages too
<mvo> thanks, looking
<tjaalton> seb128: heh, appears to be the same reporter
<seb128> he likely opened several duplicates
<tjaalton> yep
<bryce> heya mvo
<bryce> <mvo> hm, so I read reports that compiz does hang on a i945 for intrepid   --- lp#?
<bryce> <mvo> tjaalton: is there someone familiar with intel I could talk to? do we have a contact at intel? I mean, blacklisting i830,845,945 does not leave that many cards that we don't blacklist
<bryce> <mvo> bryce: ^--- ?
<mvo> bryce: good monring
<mvo> bryce: https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/296819
<ubottu> Launchpad bug 296819 in compiz "Intrepid Compiz hangs on login for i945GM video cards" [Undecided,Incomplete]
<bryce> mvo:  i830/i845 should be considered separate from i945
<mvo> bryce: it seems like it is ot affecting all i945 system so it is less servere
<mvo> bryce: 830/845 are blacklisted now
<mvo> but blacklisting i945 would blakclist half of the laptops out there (and all netbooks ;)
<bryce> pre-855 is hardly supported by upstream any longer, so compiz issues on those chips are not terribly high priority (unfortunately IMHO, but seems reality)
<bryce> i945 are more recent and more important
<mvo> yes, I'm sad about the lack of <855
<bryce> from bug reports, I've seen huge variability in i945
<bryce> many issues are specific down to the subsystem vendor pci id
<bryce> ...so if you blacklist, I'd just ask that you blacklist at the subsystem vendor pci id.  (i.e., the second line from lspci -vvnn)
<tjaalton> pitti had the same pci id and works fine
<bryce> if two people with the same subsystem vendor pci id have the same problem, then one would have to conclude it's due to some difference other than video card chips.
<bryce> anyway, night.
<tjaalton> night
<mvo> night
<seb128> mvo: did you look at this install bug?
<mvo> seb128: no, was doing other stuff
<mvo> not yet
<seb128> ok
<superm1> tseliot, not sure if you were aware yet: http://www.nvidia.com/object/linux_display_ia32_177.82.html
<superm1> it's a bug fix release
<tseliot> superm1: no, I wasn't aware of that. Thanks
<superm1> tseliot, when they are saying mobile GPUs with suspend problem, it's most 9xxx mobile GPUs, and rather annoying :(
<tseliot> superm1: ok, I'll request another SRU soon
<superm1> tseliot, if you need sponsorship to jaunty, let me know and i can upload it when you've got packaging ready
<tseliot> ok ;)
<superm1> tseliot, or if you normally use PPA pocket copying, nvm
<tseliot> I usually upload the source to my webspace
<solarion> will there be any trouble if I buy a HDCP-aware monitor for use with Linux?
<tjaalton> solarion: no
<solarion> tjaalton: thanks.  I waited and then asked xorg-devel. :)
<tjaalton> yeah noticed that afterwards
<solarion> :)
<solarion> what'd you say are the most important things to consider in an lcd monitor?
<solarion> screen size and res are obvious
<tjaalton> dont buy the cheapest, and preferably with !TN panel
<solarion> why not the cheapest?
<tjaalton> there's a reason they are cheap
<bryce> brightness is another consideration
<bryce> although most lcd's these days are sufficiently bright
<solarion> what's a good brightness?
<bryce> just make sure it's got a broad range
<solarion> tjaalton: I mean, is there usually a specific thing cheap lcd monitors are cheap because of, that's not immediately obvious to the novice?
<tjaalton> missing digital input(s), TN panels, bad ergonomics etc
<solarion> what digital inputs would be missing?
<tjaalton> dvi for instance
<solarion> aside from DVI and VGA, what other connectors do you think are important (HDMI is irrelevant to me, I think)
<tjaalton> mine has a usb-hub in it which is handy
 * solarion ponders
<solarion> what is better than a TN panel?
<tjaalton> IPS/*VA
<tjaalton> eizos are MVA's I think..
<solarion> why is tn bad?
<tjaalton> the viewing angle and gamut coverage is narrower
<solarion> ah
<solarion> what's the going price for a good lcd?
<tjaalton> but just buy what pleases your eyes and budget :)
<solarion> I can buy a second card and 3 monitors for under $600.  :)
<solarion> good resolution too
<tjaalton> my 24" benq cost around 800EUR, and it's pretty good
<solarion> ouch
<solarion> that's probably more than the bosses would let me have. :)
<tjaalton> yes, you can do a lot of stuff for $600 ;)
<tjaalton> hm s/do/get/
<solarion> both work.  :)
<solarion> thanks for the info
<solarion> maybe when I'm a professor I can get a real LCD.
<tjaalton> heh, and some time I'll get an eizo for photo management :)
<tjaalton> wow, 24" review champ eizo for 500EUR
<festr_> hi
<festr_> i'm trying to test GEM with 2.6.28-rc4 and xorg/mesa/intel master branches. I'm getting in xorg log (II) AIGLX: Screen 0 is not DRI2 capable
<festr_> but 3d works. so i'm wondering this DRI2 issue. any idea?
<tjaalton> don't think anyone here has gone that far
<tjaalton> besides it's not the master branches you want
<festr_> i'm not able to find any info how to check if GEM is actually used if you understand :)
<jcristau> there's no dri2 support in intel ddx master
<jcristau> so that's expected
<festr_> so thats explain it. exist some dri2 branch is it worth of try?
<jcristau> i don't think it's worth it at this point
<festr_> i though that new 2.5.0 with gem and uxa has dri2
<jcristau> nope
<bryce> tjaalton: regarding bug 278318, I've updated the patch to flip it such that texturedvideo is true by default.  I'll post a debdiff.
<ubottu> Launchpad bug 278318 in xserver-xorg-video-intel "video tearing with textured video on intel card" [High,Triaged] https://launchpad.net/bugs/278318
<bryce> tjaalton: posted.  If people wish for something more elaborate than just that, then I think we should leave it to jaunty and skip doing an sru.
<bryce> restoring an xorg.conf option seems pretty low risk, but mucking about in the video driver logic is probably better to leave for the development branch.
#ubuntu-x 2008-11-13
<bryce> heya sbeattie
<sbeattie> bryce: hey
<tjaalton> bryce: nice, I think it would be fine for an SRU
<tjaalton> for jaunty all the shiny stuff should make the patch obsolete for good
 * bryce ndos
<bryce> I'm working on writing an X smoke test next
<bryce> something I'd committed to doing a long time ago, and the due date of the EOY is coming up...
<bryce> got my pbuilders and chroots updated for jaunty...  ready to start in on merges now :-)
<bryce> btw, talked with jesse.  they're putting out a 2.4.3 driver
<bryce> however it looks like we already have all the patches that are going to be in it
<tjaalton> were you considering it for intrepid?
<tjaalton> btw, the versions_current -page doesn't load
<tjaalton> your site is not responding :)
<bryce> tjaalton: yeah try :8080
<bryce> http://bryceharrington.org:8080/X/PkgList/versions_current.html
<bryce> my ISP blocks port 80
<tjaalton> whee, that works
<wgrant> bryce: Oh, they do that over there too?
<bryce> yeah I was considering 2.4.3 for intrepid.  But we already have everything so
<bryce> wgrant: yep.  know of a good kludgearound that doesn't require some $10/mo or something?
<wgrant> bryce: Not really. I do some stuff over IPv6 tunnels, but that's not a workaround for everything yet.
<wgrant> But uni has IPv6, so it works for that.
<tjaalton> sigh, why doesn't requestsync work.. hangs when trying to open the smtp connection
<wgrant> tjaalton: Use the launchpadlib backend.
<tjaalton> wgrant: the what? I'll just file a bug if there's no quicker way to do it :)
<wgrant> tjaalton: Make sure you have python-launchpad-bugs installed, and run requestsync with --lp.
<wgrant> That will use the LP API to do things, rather than email.
<tjaalton> wgrant: oh, nice
<tjaalton> I need to login first?
<wgrant> Hmmm, probably.
<wgrant> Not sure how, but there will be docs somewhere...
<tjaalton> hmm, DEBSMTP.. I'll just set that
<bryce> tjaalton: hey got something for ya
<bryce> http://bryceharrington.org:8080/X/PkgList/versions_current.html
<bryce> now with jaunty jackalopes
<bryce> wgrant: not too many docs ;-)
<tjaalton> bryce: great thanks
<bryce> I'm using launchpadlib for the backend for my spamming scripts
<tjaalton> I'll file sync requests and merge some
<tjaalton> hmm libx11 1.1.99.2
<tjaalton> with handoff stuff
<bryce> I think you have to install launchpadlib out of git.  We really need to get the ubuntu package updated
<tjaalton> DEBSMTP worked fine
<tjaalton> with that I can use our own smtp-server. connections outside the network are not allowed
<bryce> cool
<tjaalton> smtp connections that is. otherwise the world would be a bleak place to be
<wgrant> tjaalton: Bleak and more productive?
<tjaalton> wgrant: if your profession is to twiddle thumbs, then yes ;)
<wgrant> I think the Book Meme must be the most complete one I've seen on Planet Ubuntu...
<tjaalton> my home ADSL has been down for nearly five days now, and it's hard to live without it. glad that 3G works on my phone&laptop
<tjaalton> wgrant: yeah, even I participated..
<wgrant> I noticed :(
<tjaalton> I should write something sensible quickly
<bryce> tjaalton: and risk getting kicked off planet???
<tjaalton> bryce: <g>
<tjaalton> uh, bryce, xorg-server git doesn't have patch 138
<tjaalton> git add ftw
<Kano> hi, what about an automatic mac keyboard detection? grep -q Apple /proc/bus/input/devices && echo apple keyboard
<Kano> to set model
<Kano> grep -q "Apple.*Keyboard" /proc/bus/input/devices && setxkbmap -model macbook79
<Kano> is maybe best
<jcristau> no, it's not 'best', it's ugly. plus, pretty pointless.
<Kano> but it is not detected at all currently
<jcristau> that's ok, it doesn't need to be
<Kano> no mac keyboard has a pc 105 layout
<Kano> is /etc/default/console-setup used for X?
<jcristau> yes. but again, setting the xkb model doesn't change anything, if it's not jp106 or abnt2
<jcristau> (other than the geometry, but that's usually unimportant)
<Kano> nope, @ is for example at a different place and other extra keys
<Kano> especially with german layout
<jcristau> that doesn't matter...
<Kano> is the console-setup evaluted for x too or not? i read that in a german mag
<jcristau> *sigh*
<Kano> jcristau: btw. i do not own a mac, but i got error reports from em, those do not want/know how to change keyboard layout with live mode every time
<tjaalton> bryce: I've added the patch to git, no worries
<tjaalton> hmm, I can make my laptop fail to resume.. attach to the doc, remove from it and then put to sleep. seems to happen every time
<tjaalton> but it's a kernel bug for sure
<Ng> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/273899 - anything that jumps out on that one?
<ubottu> Launchpad bug 273899 in xserver-xorg-video-intel "IBM thinkpad X200 use G45 and gma 4500 abnormal display 1280 x 800." [Undecided,Confirmed]
<Ng> I have an X200 in front of me for the next couple of hours
<Ng> it's just installing at the moment and then I need to get it working and have sane VGA out, so if anyone wants any info collecting, or tests trying, shout soon :)
<tjaalton> a logfile with modedebugging turned on
<tjaalton> home ->
<Ng> k
<Ng> how for to modedebugging?
<tjaalton> Option "ModeDebug" "true"
<tjaalton> to the driver section
<Ng> ta
<Ng> tjaalton: in the Device section?
<tjaalton> Ng: uh, yes
<Ng> http://mairukipa.tenshu.net/x200-xlog.txt
<Ng> (also attached to the bug)
<tjaalton> it thinks hdmi-1 is connected when it's not
<tjaalton> and since the only shared resolution is 10x7 it's used
<Ng> huh, yeah, xrandr confirms that
<Ng> err what
<Ng> just popped it out of the dock and now it thinks HDMI-1 and -2 are connected
 * Ng reboots with it out of the dock
<tjaalton> shiny
<Ng> it shipped with a dock :o
<Ng> right, so this brings me in line with what people were saying on the bug. booted out of the dock and the screen res tool shows three monitors now :/
<Ng> the same trick of disabling the other displays still works though
<Ng> hmm, I guess I could probably use xrandr to force those devices off
<Ng> I have two issues really, getting it fixed properly in Ubuntu, and making this laptop Just Work Right Now ;)
<tjaalton> it's a driver bug which should be upstreamed :)
<bryce> heya
<bryce> wow, AMD totally blew off this week's call.  :-/
<bryce> well I emailed them the 5 bugs, I guess I can mark them committed.
<bryce> er, confirmed
<bryce> tjaalton: hey do you know anything about a ubuntu fork of wacom-tools?
<superm1> bryce, any word on them about what's fixed in this release (8-11)?
<superm1> no bug numbers in their release announce unfortunately this time
<bryce> superm1: none
<superm1> bryce, .... hopefully this submitting bugs to them turns out a little more productive for upcoming releases then...
<bryce> yeah :-/
<bryce> actually
<bryce> they *did* say that a bug that we report to them _today_, would only show up in a release uh.. 3? months later
<superm1> oh that's right, they develop 3 months out
<bryce> anyway, so I wouldn't have expected that this release had any fixes for bugs we've reported
<superm1> except in extreme circumstances
<superm1> eg what happened with xorg 1.5
 * bryce nods
<tjaalton> bryce: it's not forked, we just wanted a newer version than what debian had
<bryce> not sure how much I can say on a public channel, but they described their typical process and it is *quite* different from what we do
<superm1> as i understand they won't blindly fix a bug even if it's blatantly obvious unless they reproduce the problem
<bryce> tjaalton: ah
<bryce> it's very interesting to me how different (and faster) FLOSS development process cycles are than ones around microsoft stuff
<bryce> tjaalton: ok, I'm getting complaints from debian about this.  I guess that explains what they're talking about.
<tjaalton> bryce: if you mean what ron said on the wacom ml I don't see it as a complaint
<bryce> tjaalton: private email
<tjaalton> i should probably subscribe to it
<tjaalton> oh...
<tjaalton> well he should bump the epoch so we could collaborate better :)
<bryce> I'll suggest that
<tjaalton> i've already done that, but got no reply
<tjaalton> let me do that again
<tjaalton> maybe he'll remember :)
<newz2000> hi, my goal is to get an external monitor connected to my laptop. I don't kneed to use both at the same time, but when I enable the external monitor it sets the virtual resolution and disables compiz.
<newz2000> is it possible to have the second monitor and compiz? I have a intel 945 gma video card
<jcristau> when you say "it sets the virtual resolution", what do you mean by "it"?
<tjaalton> clone mode should probably work
<tjaalton> but I think the default is to extend the desktop, and that might break it because of the current limitations
<newz2000> "it" is the screen resolution applet
<newz2000> the problem with the clone is that it doesn't show the right resolution
<newz2000> the laptop is 1280x800 the external is 1280x1024 and the highest clone allows is 1024x768
<jcristau> put one monitor above the other
<jcristau> then you can have 1280x1824
<jcristau> and compiz
<jcristau> anything > 2048 and you lose
<newz2000> ah, so 2048x2048 is ok but 2048x2049 and compiz is off?
<jcristau> yes
<newz2000> if I upgrade the ram and allow more for use by video will that help?
<jcristau> no
<newz2000> gotcha
<newz2000> is it possible to disable the internal screen and use the external at it's native res when its present?
<jcristau> 'xrandr --output LVDS --off; xrandr --output VGA --auto' should do that
<jcristau> assuming the external is vga
<newz2000> ok, I'll try it out.
<newz2000> Last question, how do I undo the virtual desktop so that I can have compiz again?
<jcristau> change the Virtual directive in xorg.conf
<jcristau> or remove it
<bryce> for anyone not on distro-team@, looks like focus on Jaunty will be on bug fixing.  :-)
<tjaalton> bryce: awww.. :)
<tjaalton> wonder what that'll mean in the real world
<bryce> hopefully should mean fewer blueprint specs this time through, and letting folks work on the bug queue instead
<pwnguin> is distro-team publicly archived?
<tjaalton> as long as it doesn't prevent us from uploading the latest cra^H^H^Hstable versions to the archive
<tjaalton> pwnguin: it isn't
<pwnguin> fun
<tjaalton> I've got xorg-server 1.5.3-1ubuntu1 nearly ready. let's declare that as the final upstream version for jaunty :P
<tjaalton> ok ok, I'll stop now.. bedtime it seems :)
<bryce> heh
<wgrant> Are you sure distro-team isn't publicly archived? Lots of private Canonical stuff is accidentally archived publicly on LP.
<pwnguin> heh
<bryce> wgrant: really?
<wgrant> bryce: Yep...
<Ng> distro-team isn't hosted on LP ;)
 * Ng goes to read the thread, but doesn't expect it will really work out like it sounds
 * wgrant grumbles at this stuff being private.
<wgrant> The community exists too, guys.
<jcristau> 'community' is just a nicer word for 'free testers' :)
<Ng> most of distro-team@ really isn't very exciting
<Ng> administrivia and cross-posted meeting minutes mostly
<Ng> If it was juicy I'd subscribe myself, but it's just not ;)
#ubuntu-x 2008-11-14
<bryce> most internal lists aren't that interesting.  If you post anything interesting, mdz or someone jumps on you and makes you post it to a public list.
<superm1> bryce, based on https://bugs.edge.launchpad.net/ubuntu/+source/fglrx-installer/+bug/284408/comments/40 i almost think this should be SRU'ed...
<ubottu> Launchpad bug 284408 in update-manager "r3xx Hardware does not work with fglrx [EPR#257839]" [Medium,In progress]
<bryce> superm1: would you like to put an sru through on it?
<bryce> superm1: or talk to pitti/slangasek to see if they'd consider it?
<superm1> bryce, slangasek said he'd consider.  i've uploaded to intrepid-proposed awaiting archive admin pokage then
<crevette> hello
<bryce> hi crevette
<bryce> superm1: okay, thanks
<crevette> hello bryce 
 * bryce spams launchpad (again)
<bryce> (done)
<wgrant> How many bugs this time?
<wgrant> (I prefer to spam Launchpad *devs* with *new* bugs)
<bryce> hrm, I need to print out a total
<bryce> couple hundred I guess
<wgrant> Ah, not too bad.
<bryce> wgrant: this run included the change that sets bugs to confirmed
<bryce> so some portion were set to incomplete with appropriate info requests, and a larger proportion -> confirmed
<wgrant> Nice.
<bryce> we should see a nice drop in total number New
<bryce> heh, notice how this graph has a big drop every 7 days:  http://people.ubuntu.com/~brian/complete-graphs/xorg/plots/xorg-month-new.png
<bryce> (I suspect that's cause I run my new bug triage script every thursday)
<bryce> (more graphs at http://people.ubuntu.com/~bryce/Plots/)
<wgrant> Yowch. Over 2000 bugs on ~ubuntu-x-swat's packages again...
 * bryce nods
<bryce> I closed 10 today
<bryce> == barely a dent
<bryce> heya tseliot
<bryce> wgrant: well, the good news is we had around ~2000 when hardy released, so at least we're staying even
<bryce> heya philwyett
<wgrant> bryce: Ah, not too bad then.
<philwyett> Hi bryce
<bryce> wgrant: of course my goal for intrepid had been not to stay at 2000 but to decrease to 1500
<tseliot> hi bryce
<bryce> guess I was a bit optimistic ;-)
<tjaalton> hmm, hyundai accent 90EUR for two days
<tjaalton> morning
<bryce> morning tjaalton
<bryce> tseliot: I'm having a lot of various discussions about a config tool for wacom tablets
<tseliot> bryce: good, did you decide anything?
<bryce> tseliot: I'm trying to tamp expectations down to something simple that even I could deliver on...  if you have thoughts on what *you* would like to do, it would be helpful to hear them
<tjaalton> wacom should just support properties
<wgrant> tjaalton: But that would make sense...
<tjaalton> wgrant: hehe
<wgrant> Properties make a GUI so much easier.
<bryce> tseliot: really it needs to be a group decision what we do...  I'd like to see us make good progress with wacom but don't want to commit people beyond myself to work
<tseliot> bryce: I haven't tried a tablet yet but it shouldn't be difficult to create a nice UI for tablets. Editing XML (fdi) and/or the xorg.conf should be easy.
<tseliot> however
<tseliot> I'm also working on outputs
<bryce> so I'm sort of dependent on people speaking up in relation to what they're interested / willing to do
<bryce> tseliot: btw did you get the one I mailed to you?
<wgrant> Why create a GUI for putting settings in fdi files when properties are surely the future?
<tseliot> bryce: ?
<tseliot> the tablet or the email?
<bryce> tseliot: tablet
<tseliot> no, nothing as of yet
<bryce> tseliot: ah.  well I posted it about 1.5 weeks ago, so hopefully should arrive soon
<tseliot> bryce: ok, thanks a lot
<bryce> tseliot: this is one that doctormo lent to me, with the provision that it should "go to whomever makes tablets work"
<tseliot> let me know how much is the shipping via email
<bryce> wasn't me, so I hope it's you :-)
<bryce> tseliot: no worries
<tseliot> I think I can make it easy to configure tablets in Ubuntu and as soon as the tablet arrives I'll start playing with it
<bryce> wgrant: actually what we've been discussing is even more ol' school - setting into xorg.conf
<wgrant> bryce: So I saw :(
<tseliot> bryce: I would also like to show my new Python API for RandR at the UDS
<bryce> tseliot: cool :-)
<tseliot> and we'll have to decide what I should focus on first
<tseliot> outputs or tablet? We'll see
<bryce> tseliot: btw I assume you're aware of mvo's python randr bindings?
<bryce> I put in a comment to cjwatson's jaunty focus thread that us ubuntu-x guys would like to put a focus on wacom's
<tseliot> bryce: yes, and if my xcb module is not enough I will rework mvo's bindings since the rest of my library should work
<tseliot> good
<tjaalton> surely we'll get xserver 1.6 and all the GEM/KMS-goodness too?
<tjaalton> even if it means pulling stuff from git
<tseliot> doesn't that depend on the kernel too?
<tjaalton> since I've no idea when mesa 8.3 is going to be released
<tjaalton> yes
<tjaalton> but .28 has GEM
<tjaalton> KMS on top of it isn't that much
<tjaalton> if we don't get .29
<bryce> tseliot: dunno if you saw my earlier comment but cjwatson suggested bugfixing on long-standing bugs be the focus for jaunty.  I basically consider our wacom situation to be one big longstanding regression bug, so figure whatever we want to do there will fit in well.
<bryce> tjaalton:  surely
<tjaalton> ok, sub'd to linuxwacom*
<tjaalton> bryce: ncie
<bryce> tjaalton: I do wonder if this gives us some flexibility as to what level of GEM support we want to push
<tjaalton> *nice
<tseliot> bryce: yes, right, that can be considered a big bug
<tjaalton> bryce: GEM is a must, but KMS is extra
<tjaalton> unless we want to have plymouth
<tseliot> can't we postpone Plymouth to Jaunty+1?
<bryce> tjaalton: I figure if we're a touch conservative this release, it wouldn't hurt
<bryce> mesa 8.3??  shouldn't that be either 8.0 or 7.3?  or am I drunk?
<tjaalton> oh right, 7.3
<tjaalton> tseliot: of course, but usplash is crap
<tjaalton> and unmaintained
<tjaalton> for years now
<bryce> well who cares with usplash ;-)
<bryce> suspend/hibernate ftw
<bryce> ftw?
<wgrant> Won't we still need usplash, given that KMS won't work everywhere for ages/ever?
<bryce> wgrant: true
<tjaalton> plymouth should get another fallback method between KMS and text
<bryce> wgrant: yeah aiui plymouth only works with -ati so far
<tjaalton> soon with intel
<tjaalton> too
<bryce> mm
<tjaalton> and nouveau doing slow progress
<bryce> we'll see.  -intel is bouncy
<bryce> oh hey while you're all here
<bryce> I've been adopting a practice of trying to upstream 1 bug a day
<tseliot> tjaalton: usplash may be crap but it works (or pretend to work) with a number of graphics drivers. Plymouth doesn't (because of drivers, of course)
<bryce> and I'm surprised how effective this is
<bryce> I'm seeing about a 50% response rate pretty much across the board on all X packages, which seems pretty good
<tjaalton> tseliot: plymouth as of now, but surely we could change that?
<tseliot> tjaalton: yes, of course. And I'm very excited about plymouth too ;)
<bryce> I don't know how actively y'all upstream bugs, but if you're not, I'd definitely encourage you to set aside a chunk of time to do so
 * wgrant should be able to get into X bugs in about a week.
<tseliot> bryce: 50% rate is more than good
<bryce> I particularly focus on -intel, -ati, xserver, and xkeyboard-config
<bryce> tseliot: indeed, I expected about a 10% rate, so I'm quite happy
<bryce> tjaalton: could I ask a favor?  I find it difficult to upstream bugs to debian.  I would appreciate it if you would write a short description to ubuntu-x@ of how you forward packaging bugs to debian.
<tjaalton> bryce: I don't, git is more efficient :)
<bryce> (this may tie into your interest in setting up git for ubuntu)
<bryce> heh
<tjaalton> I usually just ask on #debian-x, and if a change is ok I'll do it
<bryce> tjaalton: so push git from that angle, but I'd like to read your thoughts on that
<tjaalton> bryce: ok, I'll see what goes on in my head and post
<bryce> thanks
<bryce> my particular problem has been knowing how to forward bugs to debian (via email?)
<tjaalton> yes, email is the interface
<tjaalton> I could write a short summary, but for real bugs b.fd.o is our upstream
<tjaalton> I don't see that many packaging bugs in lp
<tjaalton> and some that have been fixed were problems only in our packages
<tjaalton> due to different history etc
 * bryce nods
<tjaalton> bryce: you agree that we could change the Maintainer address to ubuntu-x@?
<bryce> tjaalton: yep
<tjaalton> cool
<tjaalton> I'll upload xorg-server and probably libdrm 2.4.1 today
<bryce> awesome
<bryce> with libdrm uploaded, -intel 2.5.x can be merged
<wgrant> Ooh shiny.
<wgrant> I might upgrade to Jaunty soon.
<tjaalton> btw, intel has a lot of patches and is not in git ;)
<bryce> yeah yeah
<tjaalton> :P
<bryce> :-P
<bryce> and I'm out next week so who knows if I'll get to it
<tjaalton> the ubuntu branch could be handled like debian-experimental is; when debian-unstable is good enough we just sync that and use the ubuntu branch again when needed
<tjaalton> oh I can do that, it's not a huge amount of work
<bryce> pretty much all the ubuntu changes to -intel have also gone upstream
<bryce> same with -ati
<tjaalton> yeah, probably
<bryce> most if not all were also accepted upstream
<bryce> so I *think* everything we have different from debian will be able to just be dropped when we up to latest
<tjaalton> hmm, I'll check if intel could be updated on -experimental, at least the git branch. it would be trivial to merge then
<tjaalton> experimental has drm-snapshot which means that the new libdrm can't go there
<tjaalton> so i'm not sure if drm-snapshot is good for -intel
<tjaalton> but will ask jcristau 
<tjaalton> oh, I just did
<bryce> nite
<tjaalton> night
<tseliot> night
<Ng> can I somehow make the intel driver pretend that certain outputs don't exist?
<tjaalton> see the thinkwikipage
<tjaalton> mentioned on the bug
<tjaalton> or did you paste it here
<Ng> well I used xrandr --output HDMI-1 --off to turn it off, but I would be happiest if it simply didn't show up in the available outputs at all
<tjaalton> right, so turn it off on xorg.conf
<tjaalton> in
<Ng> I flicked through the intel manpage and didn't see options for that
<tjaalton> the example xorg.conf on the wikipage has
<jcristau> Section "Monitor"\n\tIdentifier "HDMI-1"\n\tOption "ignore"\nEndSection
<Ng> oh :)
 * Ng hangs head in shame ;)
<Ng> ugh, this just isn't working, I'm going to force the whole thing to stay at 1024x768 the whole time
<Ng> plugging a projector in after the fact and configuring the displays to mirror just makes X crash afaics
<Ng> and once the intel driver has loaded once it never works properly the second time
<wgrant>  /win 4
<wgrant> Grh.
 * Ng wonders if it would make sense for the "Detect Displays" button in gnome-display-properties to go away
<Ng> out of interest, what does that button actually do? just look through xrandr outputs for ones that are connected?
<Ng> well whatever it does it seems to produce a callback when things have changed, so doing it periodically while the tool is running (and less frequently when the tool isn't running, unless there are power usage implications) would be nice
<Ng> "ohai! you has a new output device, want configures?"
<wgrant> Ng: Does it not make your screens flicker as the EDID is transferred in-band?
<Ng> wgrant: no, but it seems like it does for a lot of people, so scratch that idea ;)
<tjaalton> anyone here uses virtualbox?
<tjaalton> can't get usb devices to work with it
<tjaalton> although usbfs is mounted and vboxusers has access to it
<tseliot> tjaalton: can you upload your fstab somewhere?
<tjaalton> it should be fine, vboxusers has rw
<tjaalton> and I'm on the group
<tjaalton> ah
<tseliot> did you put something like this in the fstab? none /proc/bus/usb usbfs devgid=85,devmode=664 0 0
<tjaalton> yes
<tjaalton> found the culprit
<tseliot> ?
<tjaalton> it has to be enabledd
<tjaalton> -d
<tjaalton> from the host
<tjaalton> um, I mean the image properties
<tseliot> hehe right
<tseliot> the easiest part
<tjaalton> first I tried to use the -ose edition
<tjaalton> no go
<tseliot> I guess USB support is only for the non oss edition
<tjaalton> yep
<tjaalton> vbox faq didn't mention that
<tjaalton> oh well, nokia pc suite doesn't work with it so..
<tjaalton> apparently fixed in vbox 2.1
<Ng> tjaalton: for syncing or firmware upgrades?
<tjaalton> Ng: both
<tjaalton> I'd like to get rid of xp
<tjaalton> er, the partition that is
<Ng> tjaalton: fwiw I'd be very wary of doing the latter via virtualised windows
<tjaalton> well, I'll just wait until someone tests that :)
<Ng> I nearly bricked my N95 upgrading the firmware via vmware
<tjaalton> with 2.1
<tjaalton> oh?
<Ng> it seems like the devices get put into a simple bootloader state which can receive the firmware image, and then it restarts with a different USB id, gets confirmation of something from the host, and then boots normally
<Ng> something about the USB interaction with linux meant the phone thought it had failed and went into a loop
<Ng> the upgrade tool would just see that and upload the firmware again
<Ng> and it didn't seem to be able to continue the process from another computer, the nokia software doesn't seem capable of noticing the bootloader and continuing from that point in the process
<Ng> I only got out of the loop by very carefully yanking the USB cable at a particular point in the cycle ;)
<Ng> similarly I can't upgrade my iphone's firmware via vmware, it also seems to do some sneaky USB ID magic on reboot, which gets lost in the handover from linux to windows, and so the firmware just gets written again
<Ng> thankfully itunes is able to recover a device in that state, so I could do it properly from a real windows machine ;)
<tjaalton> pc suite will get scrapped in the not-too-distant future, so hopefully the next one is better
<Ng> I hear nokia are mostly moving to over-the-air upgrades anyway?
<tjaalton> yeah, probably
<tjaalton> heh, looks like logitech harmony remotes have the same problem
<tjaalton> oh, there's native support for it now (concordance/congruity)
<tjaalton> I'll just have to package those :)
<tjaalton> already done and available on revu, great
<Ng> win :)
<Ng> maybe I should get one of those, but unless they can do PS3 style bluetooth remote too, it's a bit pointless ;)
<tjaalton> that's why I'm getting a PS3IR-PRO
<tjaalton> it translates ir-commands to bluetooth
<tjaalton> I'd just need someone from the US to get one for me before UDS ;)
<tjaalton> shipping & customs would make it a bit pricey
<tjaalton> the harmony database has the device, so setting it up should be a breeze
<tjaalton> (bought my own PS3 yesterday :)
<Ng> tjaalton: get one shipped to the UDS hotel? :)
<Ng> (I'm going to be at this UDS \o/ )
<tjaalton> Ng: that might work
<Ng> I didn't know such a thing existed, how much are they?
<tjaalton> cool :)
<tjaalton> $100
<Ng> ouch
<tjaalton> yep
<Ng> on top of a Harmony, that's an expensive setup to avoid a few remote controls ;)
<tjaalton> not much competition there, ir2bt revised their model and now it's $150
<Ng> I'm getting so annoyed by the problems with my new TV PC that I'm going to get upnp transcoding going and just use the PS3 to watch media
<tjaalton> I'm thinking about doing the same
<Ng> I'd recommend mediatomb for the upnp server. ushare and gmediaserver are both a bit too basic. mediatomb won't melt your heart with awesomeness, but at least it works ;)
<tjaalton> I've got a QNAP TS-409 which has twonkymedia, works great
<tjaalton> once vdr can write mpeg-ts, PS3 can play those directly
<tjaalton> 1.7 should be able to
<Ng> interesting
<Ng> hmm, isn't DVB already -ts?
<tjaalton> yes, but the format vdr has used is kinda special
<Ng> ah
<tjaalton> file format I mean
<Ng> well fwiw with appropriate magic in the mediatomb config, you can do transcoding, so any appropriate source that ffmpeg/mplayer/vlc/whatever can process, is fine
<Ng> I'm going to play with some online sources :)
<Ng> I happen to know of some secret URLs to bbc x.264 streams ;)
<tjaalton> hehe
<tjaalton> hmm, VDPAU..
<superm1> lots of chatter about VDPAU in #mythtv at least atm 
<tjaalton> I can imagine :)
 * bryce waves
<superm1> even patches for ffmpeg mplayer.. wow     ftp://download.nvidia.com/XFree86/vdpau/mplayer-vdpau-3076399.tar.bz2
<pwnguin> when is uds?
<jcristau> something like 8-12 dec, iirc
<bryce> dec 8-12
<pwnguin> nuts
<pwnguin> just got a new job (promotion really); so it seems while i can afford a trip to mountain view, i cant get the time off =)
<tjaalton> what was the command again to print out the key definitions of the current keymap?
<jcristau> 'xkbcomp -xkb :0 -' ?
<tjaalton> yeah that's the one, thanks
<tjaalton> looks like I got the fix for bug 272606 completely backwards :)
<ubottu> Launchpad bug 272606 in xkeyboard-config "ABNT2 Numpad Keyboard keys misbehaving" [High,Fix committed] https://launchpad.net/bugs/272606
<bryce> jcristau: have you looked at bringing in libdrm 2.5.1 so far?
<jcristau> there's already a drm snapshot in experimental, and i can't update libdrm in sid before lenny.
<bryce> jcristau: ok 
#ubuntu-x 2008-11-15
<bryce> http://people.ubuntu.com/~bryce/Testing/libdrm-2.4.1/
<tjaalton> bryce: yeah I didn't get to it yesterday
<bryce> tjaalton: oh sorry, I thought you'd upped it to 2.3.1
<bryce> anyway, maybe my work will have helped out a bit
<tjaalton> intrepid has 2.3.1
<tjaalton> I was supposed to update the debian-experimental branch to 2.4.1, and then use that as a base
<bryce> ah ok
<tjaalton> even if it can't be uploaded (to debian) the branch can be kept up to date
<bryce> well basically I just snagged tormod's control file, which I gather came from debian's git tree.  was pretty straightforward
<tjaalton> but now that my home-adsl works again, I can get to it :P
<bryce> cool, yeah I didn't want to upload anything and get us out of sync 
<tjaalton> well I can take your changes if they fit debian too
<tjaalton> hmm, part of it seems to be from git
<bryce> ah neither of my changes are really worth propagating
<bryce> I just commented out the installation of ChangeLog, and the distclean rule, since they were generating errors for my build
<tjaalton> ok, I can check those out
<tjaalton> why that happens
<tjaalton> the Changelog probably should be generated from git logs
<tjaalton> but breakfast ->
<bryce> yeah, if I make a git snapshot I just grab it from there, but this one was a tarball release, so not clear where to get the correct list
<bryce> since I was just making this for testing -intel 2.5 on hardy, I didn't care whether the changelog was installed so could be lazy
<bryce> anyway, I'm pooped... going to bed.  cya
<bryce> btw I'm going to be off at an OEM team retreat thingee all next week
<bryce> night
<bryce> oh forgot to mention, the motivation here is to provide backports of -intel to hardy and intrepid for testing purposes, since upstream has been invariably asking to test the newer code when I've forwarded bugs to them
<bryce> ok, really going to bed now.
<tjaalton> heh, ok
<bryce> tjaalton: http://bryceharrington.org/X/PkgList/versions_current.html now redirects properly
<bryce> https://code.edge.launchpad.net/~ubuntu-x-swat/xorg-server/xsmoke
#ubuntu-x 2009-11-09
<philsf> In Jaunty I used to set my keyboard settings in /etc/default/console-setup, but it's being ignored now in Karmic, both for console and X. I need to use setxkbmap everytime I login and also everytime I switch to the console. How can I set my keyboard variant permanently now?
<jcristau> /etc/default/console-setup is still supposed to work afaik
<jcristau> maybe gdm overrides it though?
<philsf> it doesn't work even for the console
<jcristau> no clue then, sorry
<philsf> I reported Bug #359719 in jaunty about the particular variant not being available anymore (it used to exist in the UIs in Hardy), but now in karmic the situation has degraded since the workaround doesn't work anymore
<ubottu> Launchpad bug 359719 in xserver-xorg-input-keyboard "abnt2 keyboard layout missing thinkpad variant" [Undecided,Invalid] https://launchpad.net/bugs/359719
<philsf> should I report a new bug agains this issue?
<jcristau> oh hum, the weird brazilian layout..
<philsf> yes :)
<philsf> so you remember
<jcristau> not this particular bug.  just the fact that abnt2 has some weirdness with keycodes
<philsf> so, what should I do now?
#ubuntu-x 2009-11-10
<bryce> superm1, there is a script which automatically moves bugs from 'xorg' to other packages.  It just makes guesses and sometimes is wrong.  If you set the importance, or assign the bug, or set status to triaged, the script will ignore the bug.
<bryce> superm1, perhaps I should make the script check for 'failsafe' in the title too.  /me todo's
<superm1> bryce, ah i figured it was something like that.  i dont like to triage or assign other teams bugs even if i have permissions too as then i dont know that the right eyes get to see them
<superm1> and i dont trust that my opinion of what the priority should be is what the team would agree on
<bryce> understood, just be aware that bugs filed against xorg are volatile since that's our incoming queue for all X issues
<bryce> superm1, I've updated the script to leave bugs with titles including (failsafe|please|depend|apport) alone
<superm1> cool okay
<bryce> tjaalton, I notice we have 104_nvidia_autodetect.patch and 105_fglrx_autodetect.patch present in xorg-server but disabled in series, and no mention of them in changelog.  Do you recall what the status of these is?
<superm1> bryce, if i am to recall correctly, there is a problem with them when an xorg.conf is present
<bryce> ah
<bryce> ok, sounds like something we could look at as part of that blueprint
<superm1> but sorting out those issues should definitely be something to mention in that blueprint
<superm1> could you by chance assemble a karmic PPA that we can have with them enabled for a quick test so we can evaluate definitively what's missing?
<superm1>  /broke
<bryce> sure
<bryce> btw, presently I'm trying to draft up a test plan for the proprietary drivers...  https://wiki.ubuntu.com/X/Testing/ProprietaryDrivers
<bryce> just started about 30 min ago; please toss out ideas for stuff/configurations/corner-cases worth testing
<superm1> well i should probably throw out the idea that i had at you too then
<superm1> what would you think about offering proprietary drivers via a ubiquity plugin that ran jockey?
<superm1> just the ones that are on the media
<superm1> so if you install from a DVD, you'll be able to install them all, but otherwise it would just be wireless
<bryce> on the media?  do you mean on the dvd?
<superm1> the idea comes more out of the horrible experience you have with the 10v where you dont have wireless after a fresh karmic install
<superm1> but if you are installing from live media that contains fglrx or nvidia, those can be offered too
<bryce> hmm
<superm1> i haven't talked it over with evan and colin yet
<bryce> I think that'd be a great idea
<bryce> although I don't know all the ramifications and impact it'd have on ubiquity
<bryce> yeah
<bryce> well I'd have no concerns against it, I think it or something equivalent would be a good idea
<superm1> hopefully it doesnt need to actually be part of ubiquity if mterry did all his ubiquity code for plugins right, it would be part of jockey
<bryce> right
<superm1> at some point during the week i'll bring it up with them, i'll see what session fits best
<bryce> ok
<superm1> i think that upgrade and fallback testing are both great things that are definitely undertested
 * bryce nods
<bryce> yeah that is the main motivation here; I figure the main root cause of the nvidia problem was that it was not tested fully enough
<superm1> well i have a differing view.
<bryce> I'd tested both drivers heavily at the point that I uploaded them, but they were fine at that point; they really needed re-testing after the upstart stuff
<superm1> upstart was introduced very late in the cycle, and brought with it unforseen consequences that weren't fully hammered out for a long long time
<bryce> sounds like our views are not so different actually ;-)
<superm1> yeah :)
<bryce> anyway, I want something that I can point testers to for any time we change something like that drastically
<bryce> next time it could be a late kernel change, or some build system thing
<superm1> Yeah
<bryce> what I hope to do is hand this to our QA team and get them to own it
<bryce> I figure they'll be able to do the testing much more reliably and rigorously than I could alone
<bryce> https://wiki.ubuntu.com/X/Testing/ProprietaryDrivers updated
 * bryce --> dinner
<tobi_> bryce_: I'm not able to find out, which patch would fix my problem. But it looks like there aren't that much fixes from intel 2.9.0 to 2.9.1. why don't you do a complete packport?
<bryce_> tobi_, because the Ubuntu release managers do not allow complete version backports, just specific patch backports
<bryce_> IOW, it would be rejected if I tried to put it through.
<bryce_> (trust me, I've tried many times before)
<tormod> tobi_, there are really few commits: one i830 fix, one uxa fix, one dvi revert fix.
<tobi_> tormod: but I have no clue how to find out which patch is the on to fix my problem
<tormod> tobi_, what is your problem?
<bryce_> <tobi_> the version in 9.10 broke tho only winform mono app I use :(
<tobi_> I have an mono winform application, and in that the text is white on white
<tormod> and you know or suspect 2.9.1 to fit it?
<tormod> *fix
<tobi_> that was what I was told on #mono
<tobi_> <directhex>	supertobi, , intel?
<tobi_> <supertobi>	yes
<tobi_> <directhex>	driver bug.
<tobi_> <directhex>	use intel 2.9.1
<tobi_> the answer was so fast, that it sound like a well nown problem there
<tobi_> apropos, you can test it with this app:
<tobi_> http://code.google.com/p/rasterbator-ng/
<bryce_> tormod, could only be the uxa fix,  yeah?
<bryce_> it is a fix to http://bugs.freedesktop.org/show_bug.cgi?id=24459
<ubottu> Freedesktop bug 24459 in Driver/intel "Intel Driver > 2.8: Cairo rendering bug, triggered in QtCurve GTK engine" [Major,Resolved: fixed]
<bryce_> tobi_, ^ is that your bug?
<tobi_> not sure
<tobi_> I think that's could be the bug
<albert23> https://bugzilla.novell.com/show_bug.cgi?id=549882
<ubottu> bugzilla.novell.com bug 549882 in Windows.Forms "No font / text displayed in winforms on Ubuntu 9.10 (Karmic)" [Major,New]
<albert23> they confirm 2.9.1 works
<tobi_> yes, that is at least my problem
<bibinou> hi
<bibinou> i'm no X wizard and I have a problem triaging a bug 
<bibinou> https://bugs.launchpad.net/ubuntu/+bug/409640
<ubottu> Launchpad bug 409640 in gstreamer0.10 "Video is tinted blue after update to karmic" [Low,Invalid]
<bibinou> it seems to affect the "Xv Driver"
<tormod> bryce_, sorry got busy. did tobi try xorg-edgers?
<bryce_> tormod, sorry I got distracted as well
<tormod> np :) I found his initial discussion on #intel-gfx
<tormod> would have talked him into patching it himself but he ran away
<bryce_> I'm heading out on vacation for the week soon (and will be heading to UDS after that) so probably won't be of much help
<tormod> well have a nice time!
<tormod> so no xorg updates in lucid then?
<bryce_> as nice as a new baby will allow!
<bryce_> yeah... was hoping to have done some work on it this week, but still dealing with -nvidia fallout
<tormod> did you look at my mesa git history rewrite?
<tormod> yeah proprietary drivers suck
<bryce_> not yet, it's in the queue
<bryce_> I'm unfortunately backed up with a bunch of requests to look at things...
<bryce_> wife is not letting me work late to stay caught up any more ;-)
<bryce_> looking at it now
<tormod> well just hope we can get back to use git for next mesa version
<tormod> I am just wondering if I should sync the non-debian/ stuff to the tarball
<tormod> *from the tarball
<bryce_> what's the non-debian stuff?
<tormod> things outside the debian/ directory
<bryce_> heh, I know that, I mean, what were the changes outside debian/?  Not spotting them
<tormod> well that's the thing, I ignored them in the git history because they make so much noise
<tormod> the alternative would be to have them in separate commits
<bryce_> oh were those configure change stuff?
<bryce_> any autoconf type stuff can be dropped.  As long as the package still builds that should be sufficient
<tormod> no, these are non-used changes for instance in the windows dirs
<bryce_> hmm, not sure I understand why those changes would be there though... did our source tarball differ from debians?
<tormod> It certainly did sometimes, when we shipped 0ubuntu1 for instance
<bryce_> right
<tormod> and debians tarball != debian git
<bryce_> ah so there are non-debian/ changes present in debian's git tree?
<tormod> yes lots. additionally, the Debian tarball is not made from git it looks like
<bryce_> urf
<tormod> the ubuntu 7.6.0 tarball is the same as debian 7.6 tarball. however there are diffs between the bzr tree (autoextracted from package) and the git tree (outside debian tree)
<tormod> bryce_, http://ubuntu.pastebin.com/d6ad766c2
<bryce_> ok yeah I'm not sure what to do about those either
<bryce_> glew.c?
<tormod> yes these are things that doesn't really matter, it's just to get it MrClean
<bryce_> the depend files are probably innocuous
<bryce_> dunno what the glew stuff is, maybe jcristau can elaborate
 * bryce_ --> lunch
 * tormod --> bed
#ubuntu-x 2009-11-11
<tormod> bryce, I updated the pastebin report: http://ubuntu.pastebin.com/d2e3f7b0a
<corp186> I debugged an X crash, patched it up, and got the fix pushed upstream into the xserver git repo
<corp186> It fixes bug 361489
<ubottu> Launchpad bug 361489 in xorg-server "Xorg crash when usb mouse is connected before gdm login" [Medium,Confirmed] https://launchpad.net/bugs/361489
<corp186> I left a comment about this in the bug
<corp186> is there anything else I can do to help get this fix released for ubuntu?
<hyperair> corp186: create a debdiff?
<corp186> hyperair: done
<corp186> anything else I can do?
<Sarvatt> hey guys, is there any plan regarding xorg 7.5 component syncs from debian for lucid? I noticed a few protos like render and xf86dri were synced, just curious if more will automatically or if it'll be done manually later because of all the breakage that will come and I'm not sure if I should start throwing things on edgers
<hyperair> corp186: well you can subscribe the relevant parties i suppose
<hyperair> Sarvatt: lp #361489
<ubottu> Launchpad bug 361489 in xorg-server "Xorg crash when usb mouse is connected before gdm login" [Medium,Confirmed] https://launchpad.net/bugs/361489
<hyperair> corp186 was working on that
<Sarvatt> phew 2 libs left then i can work on xserver master, think i'll leave that and all the video and input drivers until tomorrow unless anyone wants to help out in lucid on edgers
<Sarvatt> i'm just guessing we're going to have xorg 7.5/xserver 1.8 in lucid, figure i'd follow xserver master then switch to 1.8 branch later. anyone know if thats about right? i've been out of the loop for a few months and havent seen any schedules, dunno if it'd be better to do 1.7 for now
<mvo> bryce: thanks for your update on the nvidia issues - when I tested without nvidia.ko the system would come up normally, just without glx and with a big warning in the log. is this different for some nvidia driver versions/models? i.e. does it sometimes fails complettely?
<Duke`> latest xserver-xorg-video-intel is broken for me (x86_64): pix and fonts are defect. Is is already known?
<Sarvatt> woohoo, xorg 7.5 and xserver master are up and running on edgers now, intel ddx has a nasty bug where alpha channels arent rendering right now though
<Sarvatt> no need to add the replaces tormod i dont think, it was just a bad partial upgrade on my end cus i still had libxxf86vm1 1.0.2
<Sarvatt> just finishedcompiling an older intel snapshot, lets see how this works
<Sarvatt> that header isnt in the version it depends on i mean
<Sarvatt> yep works great, i just reverted to 2.9.1 because i dont have the battery power to revert a bunch of commits and recompile a few times
<bryce> heya Sarvatt
<Sarvatt> heyo!
<bryce> Sarvatt, you coming to UDS?
<Sarvatt> congrats on the baby man! I saw your halloween pictures while I was trying to find your x package status page :)
<Sarvatt> i wish :(
<bryce> ahh thanks :-)
<Sarvatt> cant afford the $600 for rooms right now
<bryce> yeah we're taking veterans day and thurs/fri to head to the beach for a little vacation
<bryce> well, maybe we can work out sponsorship for you next time
<bryce> actually for X this UDS may be rather dull... we've got few X people coming
<Sarvatt> life forced me out of the loop for a few months there, just getting back into the swing of things now that lucid is all set up and I got excited again :D
<Sarvatt> yeah i saw that there wasnt much in the way of X stuff on the blueprints
<bryce> yeah we missed you.  Baby took me out of the loop as well
<bryce> I feel bad, there's a couple severe bugs due to the new gdm and upstart that I could have caught sooner if I'd not been on leave
<Sarvatt> i still have to wrap my head around all this new upstart stuff, imagine it is throwing dkms for a loop?
<JanC> bryce: sometimes there are more important things in life  ;)
<bryce> Sarvatt, pretty much
<bryce> JanC, yeah tell that to all the users sending in bug reports ;-)
<Sarvatt> karmic was an amazing release, i gave 6 people who dont know much about computers install cds and they have no problems with it unlike jaunty :D the only friend that had problems with it was from doing an upgrade when he had some PPA nvidia blob drivers (like most people do..)
<bryce> yeah
<bryce> https://wiki.ubuntu.com/X/Bugs/Nvidia
<Sarvatt> i had alot of problems with karmic during the dev cycle though that werent really that big a deal but all of them are gone in the release, first time i actually left things alone and used stock stuff there :D
<bryce> the whole nvidia thing has been really irritating me.  It seems rather than focus on the huge improvements that have been made on the open source side, esp. intel, it seems everyone is fixated on -nvidia problems, which hardly has ever been without upgrade hassles
<bryce> anyway, my guess is just that there have been the usual assortment of -nvidia problems, just that the experience has been poor due to the new gdm lacking failsafe x
<Sarvatt> would it be possible to ship precompiled nvidia.ko's with the package? im guessing dkms is gonna need to be running via upstart and putting things on hold instead of building the updates in parallel to booting somehow?
<bryce> precompiled only works if we know absolutely what kernel will be running (which we won't)
<bryce> we used to do things that way with lrm, and it was quite a hassle
<bryce> yeah the real solution is to not do stuff quite so parallel
<bryce> also, it may be possible to make it build multiple kernels during install time rather than post-boot time
<Sarvatt> yeah i know it can do that from using the drivers straight from nvidia
<Sarvatt> kernel packages dont run a postinst trigger to build any dkms modules for the new kernel in it? dunno why i thought they did
<Sarvatt> guess that would make dkms a mandatory install though
<Sarvatt> since its optional is it a big deal if it delays booting a few seconds always if its installed?
<Sarvatt> oh yeah the ko is huge, precompiled for the release kernels would suck :D
<Sarvatt> anyone know what arguments this i915 module powersave parameter takes in 2.6.32? is it just 1 for on 0 for off?
<tormod> hi guys!
<Sarvatt> heyo :D
<Sarvatt> 0.16.2-1 (in Ubuntu) to 0.16.2-1~xorgedgers (243 bytes)
<Sarvatt> @tormod
<bryce> Sarvatt, what was discussed was adding a way to queue up dkms requests during install, so after all base packages are done installing, it does a cycle of dkms builds prior to the reboot
<Sarvatt> like add a test for dkms to see if it exists and run it in the gdm shutdown script if so maybe?
<bryce> well I got the impression it'd be part of the upgrader, rather than gdm
<bryce> but yeah something like that
<bryce> ok I'm getting evil eyed by my wife for not being more helpful packing for the beach... gotta go
<Sarvatt> have fun man!
<RAOF> Yay! Beach!
<Sarvatt> hopefully the weather isnt as crappy there as it is here, we've got another 2 days of rain coming :D
<tormod> beach? it's skiing season
<Sarvatt> maybe they're going somewhere on the way to UDS, its like 80 degrees in texas right now :D
<tormod> booting the lucid kernel now, want to check KMS also
<Sarvatt> hey you pulled a sarvatt!
<Sarvatt> i wish i had my hd2400 pro in the HTPC still, too much of a pain in the butt putting it in to try it out when at best it'll just work like normal but slow.. lol
<maco> what's that command to generate a skeleton xorg.conf?
#ubuntu-x 2009-11-12
<maco> nevermind. dexconf
<maco> which apparently doesnt work anymore (dtchen is yelling "that's deprecated!" at me)
<superm1> skeleton?  you dont need an xorg.conf anymore
<superm1> so i say the command is 'rm -rf /etc/X11/xorg.conf' ;)
<virtuald> X -configure?
<maco> superm1: installfest. trying to make poulsbo Not Suck ;-)
<superm1> maco, you should be able to boot in safe graphics mode from live media at least
<superm1> that asks casper to put out a basic xorg.conf with vesa in it
<superm1> although i'm surprised the fallback stuff isn't working and vesa isn't picked in the first place
<JanC> heh, dexconf should still work AFAIK  :P
<superm1> JanC, wouldn't count on it. http://pastebin.com/f77e73ac5
<corp186> I have a new package I would like included in ubuntu, so I need at least two advocates
<corp186> it's very closely tied to the x system: http://launchpad.net/rinput
<corp186> thanks for your consideration
<kees> bryce: can you give me some background on xorg-server (2:1.6.0-0ubuntu12) jaunty  and  xorg-server (2:1.6.4-2ubuntu3) karmic ?
<kees> it seems like 2:1.6.0-0ubuntu12 reverted 2:1.6.0-0ubuntu9, but 2:1.6.4-2ubuntu3 was not reverted?
<kees> bryce: I ask because I think 2:1.6.4-2ubuntu3 broke xvfb which openjdk-6 uses during its build-time testsuite (which is totally failing)
#ubuntu-x 2009-11-13
<tseliot> jbarnes: a colleague of mine is using my X packages patched with your non-root X stuff and, after starting X with -nohwaccess, he's getting this: https://pastebin.canonical.com/24757/
<tseliot> any ideas?
<tseliot> jbarnes: sorry, this one: http://pastebin.ubuntu.com/317932/
#ubuntu-x 2009-11-15
<hagabaka> does the x-edgers ppa contain "drm-next"?
<bryce> hagabaka, no. xorg-edgers only contains X updates not kernel updates
<hagabaka> oh
<hyperair> there's always the kernel-ppa
<hagabaka> yeah, I'm already using 2.6.32-020632rc6-generic from kernel ppa to have compositing with ATI Radeon
 * Ng wonders if X should maybe do something more useful than give up if there are no connected outputs on an intel card
<Ng> defaulting to something safe like 1024x768 would seem better than gdm sitting in a tight loop of death
 * Ng tries to remember how to write an xorg.conf file
#ubuntu-x 2010-11-15
<ScottK> RAOF: Found a victim/volunteer.  Should be here in a few.
<ScottK> afiestas: Welcome.
<ScottK> afiestas: meet RAOF (one of the Ubuntu X maintainers).
<RAOF> afiestas: Howdie.
<ScottK> RAOF: Meet afiestas.  He's interesting in improving the multimonitor experience in KDE.
<ScottK> I don't know how much he knows about the video layer, but he's one of the developers that got us a new (working) bluetooth stack in the last cycle for KDE.
<RAOF> Sweet!
<afiestas> hi
<ScottK> The idea is (loosely) the perhaps you two can work on something that we can experiment with in Kubuntu this cycle that would then be ready for upsteam KDE in KDE 4.7 (natty +1 for us).
 * ScottK goes to find out if his youngest child drowned in the shower yet or not.
 * RAOF wonders if they do that often?
<RAOF> afiestas: So, what is your current level of understanding of the multimonitor stack?
<afiestas> RAOF: well, my knowlege about video or X is limited to libxrandr, I played with it a kind of xrandr (cli) replacement 
<afiestas> also I read a big part of randr specification until the point where the actual specification starts
<afiestas> (so I know the basics terms and so on)
<RAOF> Superb; you've therefore mastered almost the entirity of the tools available.
<afiestas> RAOF: so, what you guys have in mind :o?
<RAOF> Basically, to standardise the decisions that currently get made.
<RAOF> The blueprint is here: 
<RAOF> https://blueprints.launchpad.net/ubuntu/+spec/multimedia-desktop-n-xorg-multihead-defaults
<RAOF> Basically, what a DE needs to do is:
<RAOF> Have some process which selects for hotplug events.  In GNOME this is gnome-settings-daemon; I presume KDE has an equivalent.
<RAOF> When a hotplug event is detected, do something.  This something is dependent upon past configuration:
<RAOF> 1) If the user has previously plugged in this device, use the same settings for this device as before.
<ScottK> One of the unfortunate things at the moment is that KDE has two: krandrtray and kcm_randr (or something close).
<RAOF> ScottK: And, I notice, nothing running in KDM to detect hotplug - this makes plugging in a monitor after boot fail.
<afiestas> well, I don't  have clear what would be my first steps in kde+xrandr
<RAOF> 2) If the user has previously not plugged in this device, choose the largest possible shared mode, clone the screens, and pop up a quick selection dialog.
<ScottK> One of the fun bits is if you do it, as soon as you open kcm_randr, kranrtray suddenly notices the monitor and you go from no tools helping you to two.
<afiestas> from what I've seen so far, I will rewrite everything from scratch, and it should not be difficult
<afiestas> RAOF: would not be better to show the selection dialog first?
<RAOF> It sounds like the first thing to do would be to get rid of one of the two tools :)
<ScottK> No one will object I don't think.  The current KDE code could be described optimistically as "under maintained".
<afiestas> change the resolution sounds annoying :/
<RAOF> afiestas: What monitor do you show the selection dialog on?
<afiestas> primary
<RAOF> Which one is the primary display?
<afiestas> it is decided by the driver iirc from xrandr 1.3 and up
<RAOF> Also, how do you know the user can actually *see* the primary display - laptops in a docking station suffer from this problem.
<RAOF> You can also explicitly set a display as primary; that's one of the things the DE tools should expose.
<afiestas> well, then we should detect if a dock station is plugged
<afiestas> anywya I'm not a usability expert... so I can't say 
<afiestas> but from my user point of view, I don't want unexpected resolution changes
<afiestas> (osx extends the desktop iirc)
<RAOF> There are all sorts of similar corner cases.  Basically, the idea with cloning is that you can *guarantee* that the user can see how to select what they want.
<RAOF> As long as they can see one of their outputs, at least.  But if that constraint isn't satisfied, they've got other problems :)
<afiestas> so, when you connect your laptop to a docking station, the lvds is turned off?
<afiestas> (just curious)
<RAOF> Not for *me*.  But many people shut the lid (which *doesn't* disable the display, just blank it) when they put their laptop in a docking station.
<RAOF> It would be perfectly reasonable for you to decide that KDE should have a default of âextended desktopâ.  The participants in the UDS session decided that cloning was the best compromise, but if you work around the corner-cases, extending can make sense, too.
<RAOF> Also, this behaviour should only be for monitors which you haven't already configured; if you plug in a monitor and then set extended desktop, next time you plug it in the desktop should be extended, not cloned.
<afiestas> RAOF: maybe atm since we don't hnave anything to work on, we may agree on where and how save that informatio
<afiestas> *information
<afiestas> I know that gnome is using some kind of not docummented xml, right?
<afiestas> wouldbe nice if we can unify that
<RAOF> Right.  ~/.config/monitors.xml
<RAOF> Hm.
<RAOF> I wasn't thinking of a fd.o standard, but it does make sense.
<afiestas> yes, would be awesome
<RAOF> Well, ~/.config/monitors.xml has a version field, and an appropriate name :)
<RAOF> Where does KDE store such information?
<RAOF> (Or does it?  I've never had anything but trouble with multi-head in KDE)
<afiestas> and about the different behaviors, I'm ok with implementing yours always that they're the GNOME's too
<afiestas> it doesn't afaik
<afiestas> Lubos implemented "Set this as default settings" but nothing to care of
<RAOF> Ok.  Well, reading from/writing to ~/.config/monitors.xml seems like a reasonable first step.
<afiestas> yes
<afiestas> well, before we've to catch up :p
<RAOF> There should probably be a shared library extracted to do that, at the same time as I work out how to identify TVs, projectors, etc.
<afiestas> we can identify them with the EDID in theory
<RAOF> Hah!
<RAOF> Yeah, that's a nice theory :)
<RAOF> You don't get âI'm a TVâ out of the EDID, though, at least as far as I'm aware; you get model & manufacuter names and modelists and such.
<RAOF> That's enough to identify âI'm a TVâ, but with a bit of work / lookup tables.
<RAOF> So there should be a library which handles the lookup/herustics in a nice way for apps.
<RAOF> KDE would in theory be happy to add a dependency on a pure-C library which implemented such an idea, plus handled read/write to monitors.xml, right?
<afiestas> yes 
<afiestas> even if it is a glib based, a lot of kde features is depending on glib stuff 
<RAOF> Oh, really?  I presume gobject is out of the question, though :)
<RAOF> I don't think it'd be particularly useful, either.
<RAOF> There'd be quite a simple interface; something like pass in an xrandr handle and get âI'm sure this is a TV, and last time it was connected the configuration was $fooâ out.
<RAOF> *Note: API almost entirely pulled from the top of my head.
<afiestas> that would be fine 
<RAOF> Send your email address to raof at ubuntu dot com and I'll try to keep you in the loop.  Also, subscribing to the blueprint wouldn't hurt.
<afiestas> RAOF: oks
<afiestas> emailt sent
<RAOF> And received.
<jman123> hey guys. having problems under a fresh install of 10.10 detecting correct resolutions (best it does is 640x480 on my 1680x1050 lcd) with an nvidia 9500. i tried installing the nvidia drivers, that doesnt do any better. tried editing xorg.conf: http://paste.ubuntu.com/532148/ to no avail. the new modelines dont get recognised by nvidia-settings. 
<RAOF>  /var/log/Xorg.0.log is the price of entry to the debugging train :)
<RAOF> Could you pastebin it, please?
<jman123> sure
<jman123> http://paste.ubuntu.com/532166
<jman123> i used nvidia-xconfig a couple of times to make a default xorg.conf
<jman123> and mucked around with xrandr trying to get a modeline working
<RAOF> So, yeah; as expected, the problem is that your display isn't sending a valid EDID, so the driver has no idea what the valid modes for it are.
<RAOF> It _looks_ like your xorg.conf contains a valid modeline, but I'm not sure what arcane supplications the nvidia binary driver requires before it'll accept modelines.
<jman123> btw here where my attempts at using xrandr paste.ubuntu.com/532168
<JanC> the nvidia driver doesn't support xrandr, I think?
<RAOF> Correct.
<RAOF> Well, it supports xrandr 1.1, which doesn't do anything very interesting.
<jman123> should i ditch the nvidia driver?
<RAOF> (In particular you can't add modelines via xrandr 1.1)
<jman123> lol
<RAOF> You could ditch the nvidia driver.  You'd end up with the nouveau driver, which does support xrandr 1.2, so you'd be able to xrandr-up some appropriate modes.
<jman123> the monitor is a VX2235wm connected via DVI
<jman123> i also have a VA1912wb connected via VGA
<jman123> both viewsonic
<RAOF> And the nvidia driver is unable to read an EDID from either; it doesn't get an EDID at all from the VGA monitor, and it gets a corrupted EDID from the DVI.
<jman123> why would that be?
<RAOF> So, either there's something wrong in the cabling or Viewsonic has failed to correctly write 128 bytes of EDID data.
<RAOF> Or, I guess, someone wired up your GPU badly :)
<jman123> lol. asus
<jman123> so.. what to do?
<JanC> you could try with another graphics card if that gets a correct EDID...
<RAOF> My bet would be on a corrupted EDID.
<jman123> not an ubuntu bug then?
<RAOF> Probably not an Ubuntu bug, except in so much as we could possibly handle it better.
<jman123> works fine under windows btw, so i sorta doubt its the hardware
<RAOF> Windows is special :)
<jman123> probably should have mentioned that before
<JanC> some monitors come with "windows drivers"
<RAOF> Or, rather, Windows contains more / better work-arounds (up to and including special GPU drivers which embed corrected EDIDs for some displays)
<jman123> and it did work under ubuntu. i was using 10.04. then after a couple of reboots it refused to see the dvi monitor at all and only had the wrong resolutions on the vga one
<JanC> hm
<jman123> fubar
<RAOF> That's without changing anything in the Ubuntu install?
<jman123> it was with stock drivers yes
<RAOF> So - it was working fine, and then it stopped working?
<jman123> indeed
<JanC> you did check the cables/connectors too?  âº
<jman123> yes
<jman123> actually.. i did put in a KVM but that was only for the vga monitor
<RAOF> What changed between it working and it not-working?
<jman123> a reboot
<RAOF> Well, the KVM is probably why the driver can't get an EDID from the VGA monitor.
<jman123> yeah i forgot about the kvm
<RAOF> Far too many KVMs don't wire up the DDC pins.
<jman123> ok kvm disconnected
<jman123> will a reboot re probe the EDID?
<RAOF> Just restarting X should work.
<jman123> logging out does that right?
<RAOF> Logging out & logging back in again will restart X if you're using a default Ubuntu install, yes.
<jman123> ok
<RAOF> (Kubuntu does it differently, and exposes fun new sources of bugs because of it!)
<jman123> so those modelines i put in the xorg.conf.. why doesnt that work?
<jman123> shouldnt it force the screen into it?
<RAOF> I'm not sure.  Those options are driver-dependent, and the nvidia driver clearly isn't reading the modelines.
<jman123> the log does mention removing each of the modes
<RAOF> Yeah.  It's either not finding those modelines you've specified or it's found them and decided they're invalid.
<jman123> ok new log after removing the kvm is 532172
<JanC> RAOF: is the GDM vs. KDM differences why Robert Ansell made a DM that could work for multiple DE with the functionality separated from the greeter?
<RAOF> Partially.
<RAOF> Partially it was becase he discovered he could replace GDM with 1/10th the code, while implementing a couple of missing features :)
<JanC> well, from what I read, large parts of the gdm source were dead code anyway  ;)
<jman123> well is there anything i can do to analyze whats happening here? dont mind reinstalling or whatever as this is a fresh install anyway
<RAOF> Does it work any better without the KVM?
<RAOF> Oh, I see you've posted the ID for a pastebin.  Right.\
<jman123> yes, nvidia-settings now has the correct res for that monitor, still not the dvi one
<jman123> oh yeah, sorry about that
<jman123> its http://paste.ubuntu.com/532172
<JanC> hm, IIRC you can tell the driver to ignore the EDID
<jman123> im not chatting from the pc im having trouble with
<jman123> heh the question is how i suppose
<jman123> i wonder why nvidia didnt chose to make their driver open source
<RAOF> I think âOption "IgnoreEDID"â is what you're afther to ignore the... oh.
<JanC> well, nvidia released the obfuscated nv driver IIRC  ;)
<jman123> empathy is giving me the shits
<RAOF> I think âOption "IgnoreEDID"â is what you're afther to ignore the EDID errors on the DVI monitor; I'm not entirely sure what modes nvidia will pick in that case.
<jman123> nothing seems to work today :P
<jman123> will using that option interfere with the vga monitor though?
<jman1234> alright. pidgin.. empathy kept crashing
<jman1234> and to answer my own question, yes it will interfere. x now finds no screens
<RAOF> Hm, ok.
<jman1234> i guess if i use that option i will need to set up modelines for both screens
<RAOF> Have you determined whether Windows has been working since Ubuntu startied doing this?
<RAOF> Yeah, you will.
<jman1234> lemme check
<RAOF> It's curious that the driver is now reading a corrupted EDID from the DVI monitor, given it clearly worked in the past.
<jman1234> windows works as well as it always did
<jman1234> i dont suppose there is any way of viewing a log similar to the xorg log containing EDID's in windows?
<RAOF> I'm pretty sure there's _some_ way to extract an EDID from Windows.
<jman1234> it'l be a hack
<RAOF> Google suggests many options, including http://www.nirsoft.net/utils/dump_edid.html
<jman1234> well the nvidia control panel in windows detects the right resolutions first time
<JanC> you said that the driver in Ubuntu did that too at first?
<jman1234> here is a dump using that program in windows paste.ubuntu.com/532181
<RAOF> Yeah, that seems all fine.
<jman1234> so both displays are outputting correct EDID's
<RAOF> I'm not sure why the linux driver isn't reading the EDID right; it's possible that the Windows driver does it in a more cautious way.
<jman1234> 1680x1050 is native for the VX2235wm (DVI) and 1440x900 is native for the other
<RAOF> (Sometimes if you try to read each bit of the EDID 5 times and pick best-of-three it'll be more reliable.  True story!)
<jman1234> shall i see how the open source lin driver does it?
<RAOF> Not a bad plan.
<jman1234> im not fussed about 3d and will go with whatever driver works!
<RAOF> Then nouveau may well be a better bet for you; it's got better integrated dual-head support.
<jman1234> alright i removed nvidia the same way i installed it (using the driver gui thing)
<RAOF> You'll need to reboot before the nouveau drivers will kick in.
<jman1234> what is default in ubuntu desktop?
<RAOF> *Not technically true, but it's generally easier to reboot than to faff around trying to do it without rebooting.
<RAOF> Nouveau.
<jman1234> ok just finished rebooting
<RAOF> Ah, the merry boot speed of someone who isn't testing btrfs :)
<RAOF> Any joy?
<jman1234> vga monitor is fine
<jman1234> system>preferences>monitors doesnt have any mention of the 2nd monitor
<jman1234> this is the same behaviour i was getting back in 10.04 and in 10.10 before i installed nvidia drivers
<RAOF> I bet dmesg will have something about a missing EDID.
<jman1234> paste.ubuntu.com/532186 <-xorg.0.log
<RAOF> dmesg is going to be more interesting; Running âdmesg | pastebinit -â should send that to a pastebin.
<jman1234> lol pastebininit
<jman1234> if i grep EDID i get a lot of *ERROR*'s
<jman1234> for DVI-I-1
<RAOF> Yeah.  It's going to be looking at the EDID, finding it's corrupt, and going âOMG! A WALRUS!â
<jman1234> EDID checksum invalid etc
<RAOF> I'm not quite sure why it decides that means it should mark DVI-I-1 as *disconnected*, though; that seems a bug.
<jman1234> there should be an option to force modes onto displays
<jman1234> like via GUI
<RAOF> Yeah; that's something I'll be working on.
<RAOF> It's possible with xrandr at the moment, but it should be exposed in a GUI.  With suitable admonishments about blowing up ancient monitors.\
<jman1234> it seems nouveau just decides the monitor isnt even worth an attempt to display something on
<jman1234> ah yes xrandr
<RAOF> Yeah.  That should be regarded as a bug.
<jman1234> i should try that again
<jman1234> xrandr fails
<JanC> RAOF: maybe some newer screens can blow up too (maybe not consumer stuff, but I'm not sure all embeded stuff has proper protection against misconfiguration?)
<jman1234> they definately do now
<RAOF> JanC: Oh, it's possible to physically damage LCD displays, but the drivers don't expose those knobs.
<jman1234> i know some old CRT's could do crazy stuff if set at too high refresh rates
<jman1234> now lcds will usually show out of range or something
<jman1234> here is my attempt at xrandr http://paste.ubuntu.com/532190
<JanC> jman1234: you could actually make the electronics in many ancient CRT monitors to *explode* too ;)
 * RAOF would love to see that.  From a safe distance :)\
<jman1234> lol. probably a pop would be heard as the components release their magic smoke
<JanC> hehe, until now I only had a power supply say *pop* and give a burning smell and a bit of smoke  ;)
<RAOF> Dinner time here; sorry this hasn't been more helpful.
<jman1234> I've had IC's split in half, capacitors ping off boards ricocheting off walls :P
<jman1234> alright thanks RAOF
<jman1234> yeah xrandr gave some error when i tried to set the dvi screen to a modeline
<jman1234> "Configure crtc 1 failed"
<jman1234> RAOF are you in australia by any chance?
<jman1234> internode. indeed he is
<jman1234> is nouveau configurable with xorg.conf? any examples to force modelines?
<RAOF> http://wiki.debian.org/XStrikeForce/HowToRandR12
<jman1234> my current xorg.conf is empty
<jman1234> what should go in driver under the device section?
<jman1234> also any idea why xrandr was unable to get the dvi display going? http://paste.ubuntu.com/532190
<JanC> jman1234: I guess the driver thinks no monitor is connected...
<JanC> maybe because it didn't manage to get a proper EDID
<JanC> I would check the DVI cable (maybe try another one?)
<JanC> also, with the open source drivers, xorg.conf should ideally be empty or not exist even, in your case maybe it should contain a monitor section...
<jman1234> JanC: windows drivers are able to collect correct EDID's so i dont think the cable or monitor is the problem. is there some command to generate a xorg.conf? what should i put as the driver in the device section when using the nouveau drivers.
<JanC> you should not need anything in the Device Section...
<jman1234> ok well i have tried writing an xorg.conf and so far it hasnt made any difference
<stephank> I'm writing some WebGL stuff, but I'm seeing incorrect output for some very basic shaders. Now I'm looking at launchpad and (in my case) intel's bugtracker on freedesktop, and lots of bugs seem really broad in subject. I'm not even sure how to figure out if my bug is already known?
<stephank> Hope I'm not being awfully vague. Maybe I should just report the issue, and attach my test case, seeing as I can't seem to find anything related.
<JanC> stephank: I think the developers prefer clear bugs with testcases over those broad fuzzy ones, so yours would be more likely to get fixed  ;)
<Sarvatt> stephank: http://intellinuxgraphics.org/how_to_report_bug.html would be the most appropriate, you want to file it on freedesktop.org against the mesa product with the appropriate dri driver component that you are seeing the failure on. fwiw your webgl test case shows light pink here on the nvidia blob
<Sarvatt> for firefox you can install libosmesa6 and change the webgl.osmesalib option in about:config to the right path to libosmesa to test software rendering
<stephank> Sarvatt: Totally weird thing is, I get the same result using software rendering. (Pretty sure it's doing sw rendering. I enabled verbose and it tells me in the console.)
<Sarvatt> stephank: just curious, what mesa version?
<stephank> Sarvatt: I'm on maverick, the package version of libgl1-mesa-dri is 7.9~git20100924-0ubuntu2
<doctormo> In the new xorg input system, how does the system know an input is available?
<doctormo> I'm trying to think of the quickest way to enable serial wacom tablets which usually have a /dev/ttyS0 node.
<doctormo> The file xorg.conf.d/50-wacom.conf mentions something about serial wacom, but then doesn't specify the device to use.
<doctormo> As if it's disconnected somehow from detection.
<jcristau> X gets told by udev when a device appears
<doctormo> jcristau: So is there a way to tell udev there is a certain kind of device connected to a serial port?
<jcristau> well you can tell that to X
<jcristau> like Section "InputClass" Identifier "my serial device" MatchDevicePath "/dev/ttyS0" Driver "wacom" EndSection
<jcristau> in your xorg.conf
<jcristau> with whatever options are needed
<doctormo> jcristau: I'm unhappy about that kind of method. It's hackish.
<doctormo> I'd be happier with a udev solution, if possible.
<jcristau> dunno.  it's serial stuff.  it's always going to be hackish.
<tjaalton> serial wacoms should already work
<tjaalton> since lucid
<tjaalton> though only builtin models I guess
<doctormo> tjaalton: Do you know how they work?
<tjaalton> doctormo: I have a lenovo X61 which has one
<tjaalton> and it works
<doctormo> tjaalton: Did you have to do anything? and is it really serial or is it usb?
<tjaalton> doctormo: works OOTB
<tjaalton> and it's serial alright
<doctormo> Damn magic... hmm.
<tjaalton> the serial device is probed somehow when the system starts
<tjaalton> so udev knows about it
<doctormo> Ah I think I see where that is happening.
<doctormo> tjaalton: Could I get your help please? I'm after pnp information for your tablet.
<tjaalton> doctormo: it's not really mine and not at hand atm (a testbed at work)
<doctormo> Curses! :-)
<doctormo> I'm trying to find a good guide to getting pnp info too.
<ion> I have a tablet if thatâs relevant.
<doctormo> ion: Is it serial or usb?
<ion> USB
<RAOF> Boo.  No-one told stephank about piglit?
<bryceh> who's stephank?
<RAOF> He was asking about one of his WebGL shaders that's rendering incorrectly.
<RAOF> If he's got a nice test-case, piglit is where it should go!
<bryceh> just had one of my systems overheat due to a failed fan on a radeon card
<bryceh> I'd just rebooted it but for whatever reason the gpu fan wasn't spinning
<bryceh> I'd noticed a smell like someone ironing clothes
<bryceh> new graphics card time!
<RAOF> Mmmm.
<RAOF> The smell of ironing clothes is surprisingly pleasant.
<bryceh> indeed
<RAOF> Maybe you should keep that card in there, as an air freshener!
<bryceh> I'm ok with wrinkles
<bryceh> sad... was a nice RV630 dual head card that now supports 3d and kms and everything just right
<RAOF> You can probably get about the same performance out of a nice, cheap evergreen card now.
<RAOF> As long as you don't mind xorg-edgers, and don't want to alt-tab in compiz :)
<bryceh> I had a spare rv505 single-head card which is enough
<bryceh> fanless ;-)
<bryceh> the machine in question is only used for doing charts and web page generation now so don't need 3d or dual head
<RAOF> Yeah.  I got a nice $30 fanless r700 a while back.
<bryceh> for whatever reason the case on this one tends to collect a lot of dust
<bryceh> and the cat likes to sit on it
<RAOF> I suspect these two phenomena might be related :)
<bryceh> you may be right
<bryceh> you know it makes me wonder how many "X bugs" really are over-heating / under-power issues
<RAOF> As a proportion of the user-base, I think few people will hit those sorts of problems.
<RAOF> As a proportion of the *bug* setâ¦ wouldn't it be nice if we could figure out how the user-base is represented in the bug set? :)
#ubuntu-x 2010-11-16
<RAOF> You are in a maze of twisty Makefiles, all alike.  Don't forget to include $(TOP)/configs/current.  Remember, there can be no logic in configure.ac that's not duplicated five or six times in diffrent handwritten configs.  Because.
<bryceh> what's this in?
<Sarvatt> mesa
<ion> Your sanity is likely to be bitten by a grue.
<RAOF> Fun mesa buildsystem fact: passing -noprefix to mklib silently overrides -static.
<jcristau> RAOF: i did not want to know that...
<Sarvatt> tseliot: nvidia-settings needs a minor change to build on natty whenever it gets uploaded next - http://sarvatt.com/downloads/patches/nvidia-settings_04_natty_ftbs.patch (it's in x-updates too)
<tseliot> Sarvatt: ah, thanks for the patch, I'll include it when I upload a new driver for Natty
<Sarvatt> nvidia-96 desperately needs some love on maverick, they released a compatible version at the beginning of the month. would updating that be allowed in -updates?
<tseliot> Sarvatt: I know but I've been too busy to deal with it since UDS. We'd need an SRU and upload to proposed
<tseliot> it's not just a simple update I think I'll have to change the scripts for the video ABI as I did for -current too
* You're now known as ubuntulog
* You're now known as ubuntulog_
* You're now known as ubuntulog
<apparle> why is dexconf not generating the default conf file?
<jcristau> because the default conf file is /dev/null
<apparle> so how to generate a default one... I just want to change a few lines
<jcristau> as i said the default one is /dev/null
<jcristau> so take that, and change a few lines
<apparle> jcristau: stop joking... serious solution please
<apparle> jcristau: I want to add this in server layout  InputDevice    "LIRC-Mouse"
<jcristau> so add it
<apparle> jcristau: where? there is no server layout, no device etc etc. and I don't know xorg.conf enough to write a file from scratch
<Sarvatt> bryceh: http://sarvatt.com/downloads/patches/0001-egl_dri2-Add-missing-intel-chip-ids.patch -- kinda required for wayland on any of those devices :)
<bryceh> Sarvatt, that's against mesa?
<Sarvatt> yeah about to send it upstream, it wouldn't work on ironlake/arrandale/sandybridge/b43 as it is now
<Sarvatt> oh and pineview desktop chips
<bryceh> hey, is fglrx now officially broken in natty now with the latest kernel?
<bryceh> looking @ bug 671868
<ubot4> Launchpad bug 671868 in fglrx-installer (Ubuntu) "package fglrx 2:8.780-0ubuntu2 failed to install/upgrade: fglrx kernel module failed to build (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/671868
<Sarvatt> bryceh: yeah, there's a patch for it though, haven't gotten around to putting it in the x-updates one in the past few weeks
<Sarvatt> http://sarvatt.com/downloads/patches/fglrx-2.6.37.patch
<bryceh> cool, although there's still another error
<bryceh> firegl_public.c:410:5: error: unknown field âioctlâ specified in initializer
<Sarvatt> i miss having a separate fglrx kernel module package to test build this junk :)
<Sarvatt> ah yeah needs to be changed to compat_ioctl
<Sarvatt> oh wait the dkms patch is only applying to 2.6.36 is the problem
<Sarvatt> we're doing unlocked_ioctl there
<Sarvatt> got a fixed up fglrx going up to x-updates now
<bryceh> cool
<bryceh> Sarvatt, is that appropriate to stick in natty too?
<Sarvatt> not the one in x-updates, I have both X.Org 7.5 and 7.6 sources in the orig.tar.gz to make backporting to lucid easier in the PPA
<Sarvatt> I can send ya a debdiff for the fglrx in the archive though in a few minutes
<bryceh> that'd be great
<Sarvatt> just need to make add-compatibility-with-2.6.36-kernels.patch apply to 2.6.3[67] and add this patch (not the one I linked, had to refresh it a bit for the dkms build)
<Sarvatt> bryceh: http://sarvatt.com/downloads/merges/
<Sarvatt> debdiff diff.gz and .changes there, can't upload the orig.tar.gz without killing my net 20 times
<Sarvatt> http://sarvatt.com/downloads/make.log
<Sarvatt> cable modem is resetting every 10mb uploaded or so if its done too fast, updating nvidia-current yesterday was fun
<Sarvatt> bryceh: sorry, one sec
<bryceh> no prob
<Sarvatt> use-cflags_module-together-with-modflags.patch is the patch that needed to get applied to later kernels
<bryceh> wow that sucks, is that a temporary glitch or just service crappiness?
 * Sarvatt is on his second guinness since gettin off work :)
<Sarvatt> ok files all updated on sarvatt.com/downloads/merges/
<Sarvatt> http://sarvatt.com/downloads/merges/fglrx-installer_8.780-0ubuntu3.debdiff
<Sarvatt> service crappiness for the past few months actually, gotta love comcast
<Sarvatt> ARGH
<Sarvatt> I was right the first time!!
<bryceh> yeah I hated being on comcast
 * Sarvatt steps away from messing with packaging for the night..
<Sarvatt> did you download those first ones? :)
<bryceh> thanks, I'll take care of uploading it
<Sarvatt> the first changelog was right, I changed it and reuploaded like an idiot
<bryceh> of course it figures, the user says they went with open drivers and are happy with that
<bryceh> #insert rant-about-users-abusing-bugtracker-for-tech-support-issues
<Sarvatt> i'll refix it one last time, I'm *sure* this one is right :)
<bryceh> ok
<Sarvatt> http://sarvatt.com/downloads/merges/fglrx-installer_8.780-0ubuntu3.debdiff http://sarvatt.com/downloads/merges/fglrx-installer_8.780-0ubuntu3.diff.gz http://sarvatt.com/downloads/merges/fglrx-installer_8.780-0ubuntu3_source.changes
<Sarvatt> those are right now
#ubuntu-x 2010-11-17
<bryceh> Sarvatt, mind posting the .dsc too?
<bryceh> dget: curl fglrx-installer_8.780-0ubuntu3.dsc http://sarvatt.com/downloads/merges/fglrx-installer_8.780-0ubuntu3.dsc failed
<Sarvatt> bryceh: sorry about that, done!
<bryceh> Sarvatt, [ubuntu/natty] fglrx-installer 2:8.780-0ubuntu3 (Accepted)
<bryceh> thanks again
<ScottK> RAOF: BTW: I think it's ~time for my fortnightly ping on the KDE logout crash/kills my daughter's desktop bug ...
<RAOF> Yeah, it's probably that time again.
<RAOF> I've been sidetracked by wrangling 30-odd MB of disc space out of mesa.
<RAOF> I've confirmed it in the upstream xserver, though.
<ScottK> OK.  That's progress.
<ScottK> Any sign upstream cares?
<RAOF> Not yet.
<ScottK> Ah well.
<ScottK> Good night.
<RAOF> Good night; sorry for the lack of fix.
<ScottK> I understand it's not the only thing you have to work on ...
<Sarvatt> woohoo someone guified ppa-purge - http://www.webupd8.org/2010/11/y-ppa-manager-easily-search-add-remove.html
<Sarvatt> ricotz: someone sent me a message saying the wine ppa has a newer version of ia32-libs than edgers and screwed things up, I'm guessing most people wanting ia32-libs are using that PPA since the archive wine lags so much
<ricotz> Sarvatt, hi
<ricotz> you mean this ppa https://launchpad.net/~ubuntu-wine/+archive/ppa/+packages ?
<Sarvatt> yeah ubuntu10~ there
<Sarvatt> 795MB, sheesh!
<ricotz> * Add over 73 packages to the list for Wine's gstreamer support - mhh looks scary :(
<ricotz> Sarvatt, if you bump our version to ubuntu10+ it would break the gstreamer support for wine it seems
<ricotz> so i would need to add these 73 packages which would work for maverick, but there were some soname-bumps in natty for sure :(#
<ricotz> so i need to go through them all :(
<Sarvatt> I just installed 32 bit on this new pc because I really do care about wine working that much :)
<Sarvatt> shame the 64 bit kernel on 32 bit userspace idea for natty was dropped
<ricotz> have you talked to scott if this is going to be a natty release of ia32-libs?
<ScottK> Did you see his mail to ubuntu-devel on the topic?
<ricotz> ScottK, me? no
<ScottK> That would tell you more about where he is with it.
<ricotz> ScottK, this one https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/032044.html ?
<ScottK> ricotz: Yes
<ricotz> this is a hell of a diff :(
<Sarvatt> dropping gstreamer support doesn't seem so bad looking at this diff :)
<Sarvatt> people use ia32-libs in edgers for 3D, doesn't look like gstreamer support gives you anything you cant get without winetricks
<ricotz> Sarvatt, i will add them
<Sarvatt> thank you very much for doing that!
<ricotz> Sarvatt, hoping the best it didnt go boom ;-) - uploaded the maverick one
<Sarvatt> ricotz: thanks, asked that guy to let me know if it does go boom :)
<ricotz> Sarvatt, hmm seems this upload got lost
<ricotz> Sarvatt, please dont upload new packages to maverick in the ppa
<ricotz> until ia32-lib has built
<Sarvatt> alrighty, only have lucid stuff to update at the moment anyhow, there might be stuff waiting from earlier
<Sarvatt> uploaded mesa 3 hours ago
<ricotz> Sarvatt, thats ok, they are already built, i will try to finish the natty update soon, so please no update for natty ;)
<Sarvatt> already ran the update script this morning and it only does natty and maverick, no worries :)
<ricotz> ok, ta
<jewsucanuse> yo sarvatt, is it common for totem and mplayer to  start having gradient banding during playback after running the computer for a few hours?
<jewsucanuse> or fiddling around with compositing
<Sarvatt> go figure, right after fixing the last packages http://support.amd.com/us/gpudownload/linux/Pages/radeon_linux.aspx?type=2.4.1&product=2.4.1.3.42&lang=English
<dandel> Sarvatt, i was about to inform you about that driver release lol.
#ubuntu-x 2010-11-18
<jcristau> anybody here familiar with xf86-input-multitouch?
<jcristau> (trying to understand if i should really push back on bugs.debian.org/603534)
<tseliot> cnd: ^^
<tseliot> Sarvatt: do you know how to disable nouveau in mesa (so that it doesn't build)?
<tseliot> shall I just disable gallium (I'm working on the source from -edgers)?
<jcristau> --disable-gallium-nouveau
<tseliot> ah, nice, thanks
<Sarvatt> starting from edgers might be a headache because I build the kitchen sink including stuff that wont be in the distro anytime soon like vmware, might want to put debian/ from the ubuntu package in the git checkout and add --enable-vg to the confflags
<Sarvatt> that should be the only change needed in 7.10 so far
<Sarvatt> http://sarvatt.com/git/cgit.cgi/mesa-packaging/commit/?id=9553f72c1200b42ad6387c5d9170e58806e3ff93
<Sarvatt> oh need that too
<tseliot> Sarvatt: ah, ok. The only driver that I need is r600c BTW
<tseliot> Sarvatt: actually evergreen
<Sarvatt> \o/
<cnd> jcristau, rydberg maintains xf86-input-multitouch
<cnd> you can find him in #ubuntu-touch
<Sarvatt> wow, how did I miss THIS http://www.opengl.org/sdk/tools/BuGLe/
<tseliot> sweet (if it works as advertised)
<virtuald> is there an intel version of x.org/wiki/RadeonFeature?
<Sarvatt> argh, went to start packaging it then I see the ChangeLog * Replace automake with scons
<Sarvatt> virtuald: I wish!
<virtuald> 8]
<virtuald> i found this http://www.x.org/wiki/IntelGraphicsDriver last changed in march
<Sarvatt> dang, BuGLe works for egl, gles1 and gles2 too
<ScottK> RAOF: I thougth you might find http://aseigo.blogspot.com/2010/11/multihead-plasma-desktop-needs-you.html interesting.
<ScottK> afiestas: ^^^
<tseliot> Sarvatt: does the radeon DDX driver work with Lucid's xserver?
<Sarvatt> yep
<tseliot> Sarvatt: the DDX from -edgers, that is
<Sarvatt> it needs a minor change to build against lucid's xserver
<Sarvatt> thats in x-updates I believe
 * tseliot has a look at x-updates
<Sarvatt> oh bryce updated it without the changes
<Sarvatt> reverting the xsfbs stuff from this diff http://launchpadlibrarian.net/58593127/xserver-xorg-video-ati_1:6.13.1-1ubuntu1~xup3~lucid_1:6.13.1-1ubuntu5~xup1~lucid.diff.gz
<tseliot> Sarvatt: thanks
<Sarvatt> http://sarvatt.com/downloads/patches/ati-lucid.patch something like that
<Sarvatt> err im sure that doesnt apply directly but those are the changes
<tseliot> right
<Sarvatt> hmm, interesting stuff here https://wiki.linaro.org/Releases/1105/PublicPlanReview?action=AttachFile&do=view&target=graphics-wg-plans-11.05.odp
<Sarvatt> curious about "Provide upstream path for Mali Xorg driver stack as an example for other vendors."
<Sarvatt> and an OpenGL proxy library?
<Sarvatt> bryceh: what was your bug upstreaming page again?
<Sarvatt> finally found one that needs to go - https://bugs.launchpad.net/bugs/676183
<ubot4> Launchpad bug 676183 in mesa (Ubuntu) "Basic shaders produce incorrect output (affects: 1) (heat: 6)" [Undecided,New]
<bryceh> Sarvatt, oh sorry it's down for maintenance at the moment
<Sarvatt> no worries, easy enough to do it by hand just wanted to try it out
<bryceh> yeah I think once I'm done with wayland and launchpad I'll focus on that project again
<Sarvatt> it took what, 6 months for me to find a bug i'm positive needs to be upstreamed? :)
<bryceh> heh
<bryceh> Sarvatt, hey btw did you get to doing natty versions of the wayland packages?
#ubuntu-x 2010-11-19
<Sarvatt> doh, can't even pass LDFLAGS to configure in debian/rules to make xterm build anymore now that gcc changed to default --as-needed apparently
<jcristau> fun.  i didn't try --as-needed, thought --no-add-needed would be where most problems would come from
<RAOF> Can't you just pass --no-as-needed in LDFLAGS?
<RAOF> (Before fixing the buildsystem, of course?)
<jcristau> meh, --as-needed is just wrong..
<Sarvatt> I dont know how to properly fix this and am just trying to get things building locally at least, https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/677129
<ubot4> Launchpad bug 677129 in xterm (Ubuntu) "Please merge xterm 266-1 (main) from debian unstable (main) (affects: 1) (heat: 10)" [Wishlist,New]
<Sarvatt> how I "fixed" it to build locally was probably totally wrong :)
<jcristau> Sarvatt: run make with EXTRA_LOADFLAGS="-lX11 -lfontconfig"
<jcristau> seems to work
<jcristau> (ugly workaround, but meh)
<jcristau> built for me with http://paste.debian.net/100177/ anyway
<Sarvatt> fails needing -lXmu still
<jcristau> bleh
<jcristau> -lXmu is getting passed here
<jcristau> i get -lXft -lXaw7 -lXt -lXmu -lXt -lSM -lICE -lutempter -ltermcap -lX11 -lfontconfig
<jcristau> Sarvatt: does gcc 4.4 in natty also do that?  if not you could set CC=gcc-4.4 :p
<Sarvatt> yeah I'm so tempted to just CC=gcc-4.4 everything :D
<jcristau> sounds like thomas has a patch
<Sarvatt> darn, fixes everything but -lX11
<Sarvatt> ah crap, missing a new big bang theory :)
<RAOF> The internet will have archived it for you :)
<Sarvatt> indeed
<ScottK> There was a change where the order of LDFLAGS matters now and it didn't before.
 * ScottK doesn't recall details.
<jcristau> i'm still hoping to avoid the as-needed madness in wheezy
<ScottK> At least a Debian release cycle is a little longer to deal with it.
<lesshaste> does anyone else have problems with X hanging after a recent update? It just hangs for a few minutes especially when I am running kile. I can go to a VT and strace kile where I see "kile: cannot connect to X server"
<Sarvatt> RAOF, bryceh: seen this nugget of awesomeness? http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg00803.html
<bryceh> Sarvatt, wow, exactly what we need
<ScottK> Wow.  No sarcasm.  Very unusual.
<ScottK> (unless my sarcasm meter is way off)
<bryceh> ScottK, haven't had my coffee yet
<Sarvatt> thats something we were talking about at UDS and turns out someone already did it, very awesome :)
<bryceh> Sarvatt_, I'm going to update my mesa snapshot in wayland, and am going to use the latest snapshot in xorg-edgers
<bryceh> Sarvatt_, anything I should be aware of?
<bryceh> Sarvatt_, also, should I use the debian/ for xorg-edgers or the one from maverick (or natty?)
<Sarvatt_> nope, it doesnt really matter if you're not disabling stuff
<Sarvatt_> only differences are that it builds the xorg state tracker, has the changes needed to build 7.10, builds vmwgfx, r300g is default, and doesn't have ARB_fragment_shader disabled on gen3 intel
<Sarvatt_> also it installs nouveau_vieux for older nvidia
<Sarvatt_> well, now that I remember it also installs a bunch more into /usr/lib/dri/gallium for manual use like r600g and swrastg
<bryceh> openvg1?  Looks like I had disabled that in my build
<Sarvatt_> dunno why
<Sarvatt_> thats in ubuntu too
<Sarvatt_> the configure flags to enable it in 7.10 are different though
<bryceh> think I had a build error vs. egl
<bryceh> but I'll try it again enabled
<Sarvatt_> oh you passed --disable-gallium and broke the world :)
<bryceh> Sarvatt_, what's the commented out i965 gallium 'kill it with fire' stuff?
<bryceh> yeah could be
<Sarvatt_> i965 gallium driver is severely broken
<bryceh> vmware?
<bryceh> that'd given be build issues before
<Sarvatt_> when you passed --disable-gallium?
<bryceh> no after I'd re-enabled gallium
<bryceh> you'd also mentioned at the time something about it being sketchy
<Sarvatt_> it builds fine on stock natty, i did it last week
<Sarvatt_> yeah it's sketchy but is fixing up every copy worth it? :D
<Sarvatt_> it's in dri-experimental
<bryceh> well I'll give it a try
<Sarvatt_> want to start merging 7.10 snapshots in git in preparation and just use that instead of edgers?
<bryceh> maybe yeah
<bryceh> I'll just go with this for now though
<soren> How can I check if a given card is supported? Didn
<soren> t there used to be a list of pci id's and how they corresponded to drivers?
<bryceh> soren, that's changed.  there's now a file in sysfs for the driver which lists the pci id's the driver supports
<bryceh> nouveau_context.c: In function ânouveau_context_initâ:
<bryceh> nouveau_context.c:132: warning: passing argument 4 of ânouveau_channel_allocâ makes pointer from integer without a cast
<bryceh> /usr/include/nouveau/nouveau_channel.h:51: note: expected âstruct nouveau_channel **â but argument is of type âintâ
<bryceh> nouveau_context.c:132: error: too many arguments to function ânouveau_channel_allocâ
<bryceh> make[7]: *** [nouveau_context.o] Error 1
<bryceh> Sarvatt_, ^ maverick build of mesa failed there
<soren> bryceh: Oh, it moved into the kernel?
 * soren hasn't kept up, clearly.
<bryceh> soren, yeah you may have seen mention of 'KMS'
<Sarvatt_> bryceh: bah, libdrm :(
<soren> bryceh: Right.
<soren> bryceh: Just thought there was still a bit of that stuff left in "userspace".
<bryceh> Sarvatt_, well maybe it'll build in the ppa where I have a newer libdrm snapshot
<Sarvatt_> guess I had a newer libdrm in the chroot it built in, sorry about that :(
<bryceh> this system builds fast but I don't want to install random libdrms and stuff
<soren> bryceh: Do you have a maverick or natty system handy to check if 1002:3151 is supported there?
<soren> bryceh: I
<bjsnider> Sarvatt_, did you see that amusing email from linus today?
<bjsnider> http://lists.freedesktop.org/archives/dri-devel/2010-November/005615.html
<jcristau> i found dave's reply better
<Sarvatt_> same
<bjsnider> i'm surprised that the intel driver is smaller than nouveau, i mean fewer lines of code
<Sarvatt_> soren: "0x3151","RV380_3151","RV380",,,,,,"ATI FireMV 2400 (PCI)"?
<soren> Sarvatt_: Yup.
<soren> Sarvatt_: On Lucid,I don't see it in modules.pcimap, at least.
<Sarvatt_> yeah dont see it here either
<Sarvatt_> I see it in the ddx though
<jcristau> bjsnider: less variations in hw
<Sarvatt_> alias:          pci:v00001002d00003152sv*sd*bc*sc*i*
<Sarvatt_> alias:          pci:v00001002d00003150sv*sd*bc*sc*i*
<Sarvatt_> waaaay less
<soren> Sarvatt_: http://www.spinics.net/lists/xorg/msg50868.html
<soren> Sarvatt_: That one lists it in an Xorg.log. that seems somewhat promising.
<soren> ..but now that the kernel's involved, I'm not sure my logic is sound.
<Sarvatt_> make it a duplicate of whatever 1002:3155 uses and see if it goes splat :)
<soren> Sarvatt_: Trouble is I'm trying to work out if I should buy it.
<Sarvatt_> "0x3151","RV380_3151","RV380",,,,,,"ATI FireMV 2400 (PCI)"
<Sarvatt_> "0x3155","RV380_3155","RV380",1,,,,,"ATI FireMV 2400 3155 (PCI)"
<bjsnider> Like I know the goal here is to create the perfect kernel for hardware Linus owns...
<Sarvatt_> tried asking in #radeon? probably just an oversight 3151 didn't get added to the list, newer revision or something not many people have
<soren> Sarvatt_: I didn't, but I will now. thanks!
<Sarvatt_> hmm
<Sarvatt_> soren: this might be interesting https://bugzilla.redhat.com/show_bug.cgi?id=581927
<ubot4> bugzilla.redhat.com bug 581927 in xorg-x11-drv-ati "MULI-GPU FireMV 2400 missing pciid + dual screen issue" [Medium,New]
<soren> Sarvatt_: thanks!
<Sarvatt_> soren: why not go for a hd 5xxx single gpu? they come with up to 6 dp connectors
<bryceh> soren, maverick - http://pastebin.com/EeQfiUzr
<bryceh> soren, natty - http://pastebin.com/Kh7ea0WF
<Sarvatt_> multi-gpu solutions aren't going to be fun
<soren> Sarvatt_: No particular reason (other than complete ignorance).
<Sarvatt_> a firepro 2460 might be a better option (and cheaper)
<soren> Sarvatt_: Excellent. That's the other one I'm considering.
<soren> Sarvatt_: I just couldn't even find a PCI id for it, so didn't know where to start.
<soren> Sarvatt_: Rocking. I'll just grab one of those.
<soren> Sarvatt_: Thanks!
<Sarvatt_> 1002:68F1
<Sarvatt_> supported by fglrx too if you care about that :D
<soren> Sarvatt_: How did you find it?
<soren> I looked in an up-to-date pci.ids
<soren> No dice.
<Sarvatt_> googled FirePro 2460 pci id, its in the description of the second result
<Sarvatt_> "ATI FirePro 2460 (FireMV)" = ati2mtag_EvergreenGL, PCI\VEN_1002&DEV_68F1
<soren> And here I was, using grep like a sucker.
<soren> Sarvatt_: Wicked. Thanks!
<Sarvatt_> soren: do you care about 3D performance at all?
<bryceh> Sarvatt_, ok the mesa built locally (finally) on my test laptop.  Got a whole mess of W's and E's tho
<Sarvatt_> if you're going firepro there are consumer variants that are much faster with 6 displayport outputs even
<bryceh> just lintian stuff I guess
<jcristau> bryceh: it's mesa, anything other than a mess would be wrong ;)
<bryceh> http://pastebin.ubuntu.com/534397/
<soren> Sarvatt_: I suppose the price tag is accordingly higher?
<Sarvatt_> soren: http://www.newegg.com/Product/Product.aspx?Item=N82E16814102888&nm_mc=OTC-Froogle&cm_mmc=OTC-Froogle-_-Video+Cards-_-Sapphire+Tech-_-14102888
<Sarvatt_> not really
<Sarvatt_> its at least 8-10x faster of a card
<bryceh> I gather all the latest-debian-changelog-entry-without-new-version is just because of pitti's dropping of the changelogs?  Any way we could easily suppress that warning?
<soren> Sarvatt_: 3d doesn't really matter.
<soren> Sarvatt_: And I like the passive cooling bit.
<Sarvatt_> I haven't read up on things lately, there may even be 6870's with 6 dp outputs now too at a cheaper price
<Sarvatt_> ah yeah, that firepro is nice in that area, 13 watts max power usage too
<Sarvatt_> but its a lot of extra money for the firepro name :)
<Sarvatt_> lemme dig around, might be able to find something else
<bryceh> re: linus' email... they could cut down on drm churn if they had a better non-code mechanism to deal with monitor and card quirks
<soren> Sarvatt_: Thanks, man. I really appreciate it. I gave up on keeping track of graphics cards years, and years and years ago.
<Sarvatt_> only 5870's with 6 mini-dp and that firepro 2460 with 4 it looks like, darn
<soren> Sarvatt_: They don't have to mini-dp's if that makes a difference.
<Sarvatt_> that 2460 is amazingly slow though so I really hope you don't plan on doing anything 3D related
<soren> In fact, I prefer DVI.
<Sarvatt_> soren: do you have dispayport monitors?
<soren> Sarvatt_: Nope.
<bjsnider> bryceh, what kind of mechanism?
<Sarvatt_> oh thats a problem
<soren> Sarvatt_: Yeah, I'd need dongles.
<Sarvatt_> active dongles if you use more than 2
<Sarvatt_> quite expensive
<bryceh> bjsnider, e.g. DeviceTree
<Sarvatt_> soren: oh nice! http://www.amazon.com/Accell-B087B-005B-DisplayPort-Single-Link-Certified/dp/B004071ZX0/ref=pd_cp_e_1
<Sarvatt_> they got quite a bit cheaper, they used to be over $100 each
<Sarvatt_> the active part is really important, you are limited to 2 monitors otherwise if you aren't using native displayport
<soren> Sarvatt_: They're (unsurprisingly, I guess) quite silent about that in the product description.
<soren> Sarvatt_: Or vague, at least.
<soren> Sarvatt_: I would have thought an active component would have some sort of power source.
<Sarvatt_> http://www.botchco.com/agd5f/?p=51
<Sarvatt_> the evergreen hardware: part of it explains how complicated it is :D
<Sarvatt_> hmm, looks like I was mistaken
<Sarvatt_> oh nope, "However, you are limited to two active non-DP monitors (due to there only being two PLLs) at a time."
<soren> Right.
<soren> It's not entirely clear to me if I could get by with two active and two passive converters.
<soren> The card seems to come with just one passive converter.
<Sarvatt_> passive ones work for up to 2 non displayport monitors, you could have 2 single link DVI with passive converters and 4 native dp at once
 * Sarvatt_ is just assuming your monitors dont require dual link dvi
<soren> I think I've reached the threshold for how much information I can take in on a Friday evening.
<soren> Sarvatt_: Thanks! this has been great. I'll ponder it over the weekend.
<Sarvatt_> no worries, good luck with it
<Sarvatt_> bryceh: hmm, I haven't noticed any no changelog lintian warnings..
<bryceh> Sarvatt_, I figured it out
<Sarvatt_> no dh_installchangelogs?
<Sarvatt_> yeah no lintian warning, just built xterm
<Sarvatt_>         #XXX: FIXME - causes error with copyright file(?!)
<Sarvatt_>         #dh_installdocs
<Sarvatt_>         #dh_installchangelogs ChangeLog
<Sarvatt_> sorry yeah you figured it out :)
<Sarvatt_> bryceh: already fix up cairo locally or want me to upload it?
<Sarvatt_> (optional)__gnu_lto_v1@Base 1.10.0
<bryceh> Sarvatt_, go for it
#ubuntu-x 2010-11-20
<Sarvatt> new record! gtk-window-decorator segfaulted 37 times in 5 minutes :)
<Sarvatt> I am *so* glad we didn't pull in compiz 0.9 for maverick now
<ion> Hah
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=31499 -- good bug to pass along to the kwin guys
<ubot4> Freedesktop bug 31499 in Drivers/Gallium/r300 "[r300g] KWin Lanczos filter problems - Black Windows using effects" [Normal,New]
<JanC> hm, how does X decide what keys are the result of combining dead keys with other keys?
<jcristau> JanC: the compose map
<JanC> jcristau: it uses that for regular dead keys?
<jcristau> JanC: grep '^<dead_' /usr/share/X11/locale/en_US.UTF-8/Compose
<JanC> *aargh*
<JanC> so this is a bug caused by GNOME...
<JanC> or maybe not, let me check  ;)
<JanC> right, so GNOME prevents this from working correctly...  :-(
#ubuntu-x 2010-11-21
<Sarvatt> soren: http://support.amd.com/us/eyefinity/Pages/eyefinity-dongles.aspx
<xelister> Sarvatt: hi
<xelister> Sarvatt: ubuntu's naming of fglrx package is stupid
<xelister> Sarvatt: it should include number of corresponding upstream (Ati/AMD) Catalyst version like 10.10 or 10.9 - like debian does it
<xelister> Sarvatt: can you fix it?
<Sarvatt_> tseliot is the person to ask, I don't agree though because we frequently release fglrx that doesn't correspond to a monthly release (like 8.780)
<jcristau> dunno what "like debian does it" refers to, the package is named fglrx-driver and fglrx-glx in debian afaict
<ion> One could do 8.780+catalyst10.10-0ubuntux or whatever.
<Sarvatt_> he means how we varsion it by the actual fglrx version instead of the monthly release codenames. 8.793 instead of 10.11. yeah what ion suggested would be nice
<Sarvatt_> version rather, ugh
<ion> Btw, xvba-va-driver is uninstallable because it depends on fglrx-driver (>= 1:10-9). Would fglrx having Provides: fglrx-driver fix that?
<Sarvatt_> will ask tseliot what he thinks, lucid and maverick shipped fglrx that wasnt a monthly release and looks like natty will too
<ricotz> Sarvatt, hi
<Sarvatt_> hiya, need to go afk a bit because the stupid cat got out sorry, brb
<ricotz> Sarvatt, i have a problem with my intel g31 - it uses i915 but it isnt working with kms
<ricotz> ok
<jcristau> ion: no, you can't do versioned provides
<ion> fglrxâs version is higher than the version of fglrx-driver it depends on. It still wonât work?
<jcristau> Depends: fglrx-driver (>= 1:10-9) will never be satisfied by a Provides.
<ion> ok
#ubuntu-x 2011-11-14
<Sarvatt> RAOF: forgot to get the huey off ya at UDS, mind bringing it to budapest?
<RAOF> Of course!
<RAOF> Yeah, I noticed it in my backpack once I got back.  Sorry!
<RAOF> I'll probably pick up one of the (misspelt!) colorhug thingies :)
<Sarvatt> that huey was cheaper than getting a colorhug, gogo USD! :)
<Sarvatt> i paid $58 for it
<Sarvatt> $67 after conversion for a colorhug not including shipping which will be massive :(
<ricotz> Sarvatt, hi :), by any chance did you report the "-Woverflow" problem in /src/mesa/swrast/s_spantemp.h
<ricotz> ah, nvm this isnt the error
<Sarvatt> ah didnt notice it failed, you watch it like a hawk eh? :)
<Sarvatt> lemme check mesa-dev to see if its a known issue before reporting it
<ricotz> no it is the missing wayland 
<ricotz> not like a hawk :\, the last upload failed too ;)
<Sarvatt> ha
<Sarvatt> i usually notice failures by upgrades not coming through but i'm not using it atm
<ricotz> ;)
<ricotz> should be fixed soon
<Sarvatt> by what?
<ricotz> actually uploading the new wayland to the precise pocket
<ricotz> only the precise build failed
<Sarvatt> OH
<Sarvatt> haha
 * Sarvatt slaps forehead
<ricotz> yeah, i was waiting for mesa first ;P
<ricotz> i am on it
<Sarvatt> \o/ thanks man
<Sarvatt> wow, all this time i didnt realize how easy it was to rip out geis/gesture support from unity :)
<broder> ooh, it is? how do i do that? :)
<Sarvatt> http://sarvatt.com/downloads/patches/byegeis.patch ? :)
 * Sarvatt still needs to test it
<Sarvatt> will be nice being able to use edgers again, been a long 2 months
<broder> ah, i was hoping for a ccsm option or something
<Sarvatt> uses it unconditionally, no option :(
<Sarvatt> yay, unity under xserver 1.11 works finally :)
<bryceh> :-)
<slangasek> bryceh: hiya
<Daviey> bryceh: Is there a plan to upload a new X to precise, that will not be compatiable with nvidia binary driver? 
<bryceh> slangasek, when the mouse is directly plugged in, is Xorg.*.log still showing it mis-mapped to the wrong event?
<bryceh> Daviey, yes probably this week
<bryceh> Daviey, RAOF has the task to do the upload
<Daviey> bryceh: Do you have a roadmap on when it will be expected to work again?
<Daviey> oh, or RAOF ^^ ? :)
<bryceh> Daviey, I understand a 1.11-compatible -nvidia is already available so assume it will only be a few days max.
<RAOF> Daviey: The new xserver will not be incompatible with the nvidia binary driver.
<RAOF> We'll stage everything in a PPA and copy to the release so there shouldn't be any interruption of regular service.
<Daviey> RAOF: You sir, are my hero. :)
 * RAOF needs to work out precisely how to do that, but that's the plan 
<Daviey> Pass GO and collect $200^D beer from me at next event.
<slangasek> bryceh: the bottom of /var/log/Xorg.0.log shows no mention at all of the mouse being plugged in
<bryceh> slangasek, nothing shows up there when plugging in the mouse?  Anything written to dmesg?
<slangasek> bryceh: sure; as before it's detected fine, event device created, and I can get events from it.
<slangasek> [542179.573910] input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/input/input67
<slangasek> [542179.574154] generic-usb 0003:046D:C03E.002A: input,hidraw2: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1d.0-1.2/input0
#ubuntu-x 2011-11-15
<Sarvatt> RAOF: that soon? will ping tseliot about the binary drivers tomorrow then, the november fglrx release isnt out yet and thats the one with 1.11 support
<RAOF> Sarvatt: Hah.  I wasn't aware of that :)
<RAOF> I would have noticed while preparing stuff (hopfully âº)
<bryceh> slangasek, ls -l /dev/input ?
<slangasek> bryceh: http://paste.ubuntu.com/738776/
<Sarvatt> so was udev updated recently? keyboard/mouse not working bugs have almost always been following a udev update (4-5 times in oneiric..)
<bryceh> slangasek, interesting!  and ls -l /dev/input/by-id/ ?
<slangasek> http://paste.ubuntu.com/738777/
<bryceh> aha
<bryceh> slangasek, yeah so that's showing events 12 and 13 mapped to your input devices
<slangasek> hmm
<bryceh> udev sounds a likely culprit
<slangasek> aha
<slangasek> udev ISN'T RUNNING
<slangasek> score
<bryceh> slangasek, ahhhh
<bryceh> :-)
<slangasek> bryceh: thanks for looking at this :)
<slangasek> now let me see if I can figure out why it's died, since apport said nothing
<bryceh> slangasek, sure thing, glad it got sorted
<slangasek> Setting up udev (175-0ubuntu1) ...
<slangasek> Installing new version of config file /etc/init/udev.conf ...
<slangasek> restart: Job failed to restart
<slangasek> bryceh: X is still not happy loading it, but maybe udev dying has just left it too confused; do you care about debugging that side further, or should I just restart?
<bryceh> slangasek, go ahead and restart.  This is sort of getting into error handling logic which probably is only worth looking into if we get more people encountering this type of problem.
<slangasek> yep
<slangasek> thanks again :)
<bryceh> slangasek, also the X stack is going to get refreshed in the next week or so anyway
 * slangasek nods
<Sarvatt> eww, unity updates are "fun", unity-common is built on i386 so it's all uninstallable when amd64 builds and i386 has a huge queue which is a really common scenario
 * slangasek glares at launchpad's redirects, which have handily lost his bug comment due to midair collision with bryceh's bug reassignment
<bryceh> slangasek, sorry, I bumped it over to udev
<slangasek> yep
<slangasek> which is what I was doing :)
<bryceh> aha :-)
<Sarvatt> RAOF: so are you saying you fixed up grabs somehow magically?
<Sarvatt> clicking an address bar in a web browser is probably one of the more common things done in ubuntu...
<Sarvatt> i'd love to test out anything you've done if you have before 1.11 is pushed to precise is what i'm saying :)
<RAOF> Sarvatt: No, I haven't fixed grabs yet.
<RAOF> The "few days max" was the time between everything breaking and everything getting fixed, not the time before I upload 1.11 :)
<Sarvatt> planning on uploading 1.11 with broken grabs?
<Sarvatt> was talking to chase at UDS, multitouch seriously is almost ready to go in the december timeframe this time around, it might make more sense to wait for that
<Sarvatt> 1.11 with backported 1.12 multitouch that is
<Sarvatt> s/multitouch/input/
<RAOF> No, without broken grabs.
<RAOF> I was also talking to Chase at UDS, and while I'm optimistic, he certainly wasn't committing to it being done :)
<Sarvatt> oh?
<Sarvatt> whot is pushing for it soon this time around
<RAOF> Yeah - they'll be tag-teaming on the implementation.
<Sarvatt> cnd was saying he was going to work on the one remaining problem with grabs this time around while whot was on vacation and it should really be ready in december
<RAOF> But Chase was also âyeah, and we've found out that some things we thought won't actually work properly, and will take a bit more workââ¦
<RAOF> Not that it wouldn't be done by December, but more a âsometimes, things happenâ.
<Sarvatt> note to self: dont refuse to look at code because you dont want to get involved with things like unity if things are broken :)
<Sarvatt> cant belive i let xorg-edgers be broken for 2 months for 2 lines of code
<LLStarks> 1.5.99 synaptics is unusable either way
<LLStarks> :3
<Sarvatt> on your machine with the upstream code base meaning its just as "broken" on other distros?
<Sarvatt> synaptics is heavily patched with the multitouch stuff :(
<Sarvatt> what kind of "broken" do you mean? input drivers are the worst, everyone has their own opinions on what they should be
<Sarvatt> like acceleration too fast for your tastes?
<LLStarks> many important patches were dropped
<LLStarks> acceleration, sensitivity, and tapping are off-scale
<Sarvatt> i could be wrong but those werent changed by any of the patches i dropped
<LLStarks> and that was on top of 1.3.99's hovering and jumpiness
<Sarvatt> synaptics had a huge change in sensitivity and crap in the upstream driver
<LLStarks> is there any way to get edgers without an abi-updated synaptics?
<Sarvatt> hmm
<LLStarks> because no amount of fiddling has worked
<Sarvatt> fiddling with synclient right?
<LLStarks> yeah
<LLStarks> and the guis
<Sarvatt> GUI's were only updated in fedora and crap, etfc
<Sarvatt> etc
<Sarvatt> ok, lemme check
<LLStarks> what is the target synaptic driver for precise? i'd like it to land sooner than later so that  this can receive wider testing.
<Sarvatt> there is no target, i think i can say that confidently
<Sarvatt> we might sync whats in debian
<Sarvatt> which is 1.5.0 currently
<LLStarks> as for unity, don't leave things up to ayatana. they don't know drivers or user-oriented ui design.
<Sarvatt> theres a few of us that try to keep crap in date with debian wrt syncs and update things in debian but we dont have upload access to debian just git access, 1.5.0 was updated recently so that stcks out as what we might ship with
<Sarvatt> the problems you are hitting are well past 1.5.0 though :)
<LLStarks> can i get 1.5 with 1.11 abi?
<Sarvatt> you can actually just dget -u -x the debian 1.5.0 .dsc file and debuild -uc -us -b in your current environment
<Sarvatt> no multitouch support in edgers so no need to care about the ubuntu delta
<Sarvatt> i think a corner tap functionality change might be the only thing you'd hit :)
<LLStarks> the multitouch is unfortunate as only a hover by a second finger will cause a jump
<LLStarks> *the lack
<LLStarks> imho, an epoch update might be in order since functionality is lacking upstream. hopefully 1.5.0 is better.
<LLStarks> brb
<LLStarks> much better, indeed
<Sarvatt> 1.5.0?
<LLStarks> yeah, lemme reset the synclient settings though
<Sarvatt> i dont really want to put known-working versions in the ppa if possible, rather people complain its broken to upstream if its really broken upstream so they dont release the crap broken :(
<LLStarks> i've been complaining upstream
<LLStarks> people just tune it out and ignore the bug reports with the standard lalalallalal can't hear you
<Sarvatt> i think the post 1.5.0 updates might be reliant on gnome-control-center updates going into 3.4 though
<Sarvatt> (mouse control panel in gnome-control-center)
<Sarvatt> heh, guess i should have quantified "working", cant get the dash up an hour into using unity on 1.11
<Sarvatt> no clue where it's going wrong, only thing in ~/.xsession-errors is a few thousand nautilus errors
<bjsnider> Sarvatt, what do the nautilus errors look like?
<Sarvatt> (nautilus:13888): GLib-GObject-CRITICAL **: g_value_get_object: assertion `G_VALUE_HOLDS_OBJECT (value)' failed
<Sarvatt> Nautilus-Share-Message: Called "net usershare info" but it failed: 'net usershare' returned error 255: net usershare: cannot open usershare directory /var/lib/samba/usershares. Error No such file or directory
<Sarvatt> Please ask your system administrator to enable user sharing.
<Sarvatt> minus the last two lines, that only comes up every few hundred iterations
<RAOF> bryceh: Looks like we've got a couple of blueprints that need bedding down - https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-hybrid-graphics and https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-xorg-lts-updates
<RAOF> And by âbedded downâ mostly I mean âneeds a victim for the work itemsâ.
<tjaalton> i should probably clean up the hg one
<tjaalton> oh, updated already
<tjaalton> renamed packages? ugh..
<tjaalton> hmm, so i guess upgrading from .3 to Q would be a no-go
<tjaalton> which would be a downgrade for x
<tjaalton> and the kernel
<tjaalton> so the only upgrade path for >.2 would be to the next lts
<Sarvatt> awesome http://cgit.freedesktop.org/~eugeni/xf86-video-intel/
<Sarvatt> sna via an xorg.conf option
<bryceh> RAOF, I've added myself to a couple items; I'll see where I'm at after I draft the MM blueprints; feel free to add me to tasks that you think need my attention
<Sarvatt> mdeslaur: any chance you could try http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ to see if the blurry screen problem still exists upstream? jbarnes pinged me saying it should be fixed
<mdeslaur> Sarvatt: the ati blurry problem I have or the -intel blurry problem I have?
<Sarvatt> intel on your t510
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=40172
<ubot4> Freedesktop bug 40172 in DRM/Intel "[arrandale] Fuzzy screen after dpms cycles on lenovo t510 [bisected, 3.0+]" [Normal,New: ]
<mdeslaur> Sarvatt: ah! cool, yeah, I'll give it a try later on. thanks!
<Sarvatt> can look into getting it into oneiric if it is
<Sarvatt> mdeslaur: appreciate it, we never could find any other machine it reproduced on
<mdeslaur> Sarvatt: hopefully it'll be fixed, as it's a PITA :P
<mdeslaur> Sarvatt: unfortunately, the problem persists with 3.2.0-999
<Sarvatt> mdeslaur: thanks a ton for checking that, sorry to hear it :(
<mdeslaur> Sarvatt: I'm getting used to doing a dpms cycle every few reboots :P
<Sarvatt> bryceh: so some of those previous work items you pasted that were postponed i did a long time ago, should I just delete them from the list?
<Sarvatt> nvidia/fglrx autoloading stuff
<bryceh> Sarvatt, just tell me which they were and I'll mark them
<bryceh> I'm doing a bunch of edits at the moment
<Sarvatt> [sarvatt] Fix logic in patches 104 and 105 to correctly select -nvidia when appropriate: DONE
<Sarvatt> [sarvatt] Ensure fallbacks work if nvidia/fglrx is failing to load: DONE
 * Sarvatt is knee deep in poulsbo 2.0 aka cedarview "fun", ugh
<bryceh> got it thanks
<cnd> hooray, I can build and install upstream X and it all just works :)
<Sarvatt> cnd: what changed?
<Sarvatt> ripping geis out of unity? :P
<Sarvatt> master is working good here too after doing that
<Sarvatt> (xserver)
<Milos_SD> Hi
<Milos_SD> I need help installing ATI fglrx driver for HP ProBook 4530s laptop with switchable graphics
<cnd> Sarvatt, last year about this time I tried to do the same
<cnd> I think we were patching in the no-background option
<cnd> something like that
<cnd> that and maybe gdm wasn't playing nice
<RAOF> That'd be right, yes.
<cnd> I was actually quite amazed I got it all working given how complex it is to configure and install everything
<cnd> getting the right --libdir values and all the drivers I needed
<RAOF> So, how's XI 2.2 going? :)
<cnd> RAOF, well, I just got whot's branches of multitouch up and running :)
<cnd> for the next two weeks I'll be working on implementing the pointer emulation
<cnd> but the basic touch stuff looks to be working well
<RAOF> That sounds like early December it'd be reasonable to have it in Precise?
<cnd> might be
<cnd> but that's if everything goes really well
<cnd> we have to get it implemented for touchscreens
<cnd> and then get it working for trackpads
<cnd> so I think it might be more mid-december
<cnd> and only if we want to push crack into precise, which the desktop team may not like
<cnd> we'll have to figure out the details
<RAOF> Ok.
<RAOF> Thanks.
<RAOF> Bah!  Why is the t420s' touchpad so rubbish?
#ubuntu-x 2011-11-16
<bryceh> hey, there was someone who was really keen on working with us on the multihead xrandr stuff; anyone remember who that was?
<bryceh> aha, ayan it was
<RAOF> Also Evan.
 * broder waves
<broder> Yeah, I never seem to quite get up the throughput I want, but I am very interested in multihead stuff
<RAOF> Yo yo!
<RAOF> Story of our lives :)
<broder> (And I'm happy to rant passionately about how I think things should work :-P)
<RAOF> Should the design team start making unreasonable demands I'll be sure to roll you out :)
<bryceh> broder, awesome!
<bryceh> broder, so, we've roughed out the blueprints enough to be worth perusing I think
<broder> Yeah, I have them sitting in my inbox and was planning to look through them this evening when I got home from work
<bryceh> broder, tentatively we've assigned many of the work items, but I think both raof and I are over limit on tasks so if you happen to be interested in one or two we'd be happy to share :-)
<broder> Most of my interest is around what happens at the g-s-d/gnome-desktop level or so
 * bryceh nods
<bryceh> broder, in the near term I'll be focusing mainly on the X side of stuff, but expect in 1-2 months the gnome-rr bits will start becoming worth giving attention to
<bryceh> later on there's probably going to be a fair bit of testing and polishing needed
<bryceh> I'm still a little sketchy on where Design's work fits in, but figure that'll get sorted out
 * broder nods
<bryceh> meantime, if you know of any bug#'s relevant to any of this, shoot them my way; I'm going to build a collection of 'em
<bryceh> RAOF, I've worsened your Work Item overload today, sorry about that.  Figure we will need to do some prioritization and filtering the next day or two
<RAOF> bryceh: That's ok.  Roughly 30 of my work-items aren't actually mine.
<RAOF> When pitti's awake I'll work out how they should be marked.
 * bryceh nods
<bryceh> yeah I'm waiting for status to update so I can see what my score is currently
<broder> RAOF: i know we were talking about wayland and grabs (or lack thereof) at uds. does wayland have an answer for, e.g., polkit prompts where you want to own the keyboard/mouse to be sure you get the credentials?
<RAOF> Not as far as I'm aware, no.
<RAOF> Although I suspect that the correct answer is "build it into the shell"
<RAOF> Which is, after all, what we plan to do anyway.
<broder> good point
<RAOF> And that's obviously easier with wayland, because your shell is your compositor and can simply gobble up the input.
<tjaalton> RAOF: disable it (the touchpad) ;)
<RAOF> I rather like *having* a touchpad, especially an almost-multitouch one.  This clearly reports 3 fingers; it just does it badly!
<RAOF> Also, two-finger scrolling is love.
<tjaalton> middle-button + nipple does the same
<RAOF> This is true.  It doesn't do it as well, though.
<tjaalton> well, the touchpad gets on my way all the time, so I just disabled it from bios
<Sarvatt> RAOF: hmm, when I used that last it was tolerable under oneiric
<Sarvatt> RAOF: if you want to see bad, try lucid
<Sarvatt> the cursor moves constantly just resting your finger in one spot
<ricotz> Sarvatt, hey :)
<ricotz> looks like there is a fglrx driver with 1.11 support ;)
<jcristau> only two months late?
<tjaalton> they didn't need to rush it this time :)
<jcristau> tjaalton: because of 11.10 not shipping with 1.11?
<ricotz> yeah, unfortunatelly, they need some pressure to catch up ;)
<tjaalton> jcristau: right
<tjaalton> jcristau: well, that's the theory anyway
<ricotz> having fglrx support now could change this
<tjaalton> change what?
<ricotz> not going with 1.11
<jcristau> for 11.10?
<jcristau> a bit too late for that.
<tjaalton> yep
<ricotz> 12.04
<tjaalton> precise will get it soon
<ricotz> ah, nvm thinking about 1.12
<tseliot> ricotz: I'm on it
<tseliot> (fglrx)
<ricotz> tseliot, thanks :), still hoping for nvidia 285.x for oneiric
<ricotz> tseliot, could you upload fglrx to edgers too (natty, oneiric, precise)
<tseliot> ricotz: I haven't made an announcement yet but have a look at bug #887630
<ubot4> Launchpad bug 887630 in nvidia-settings-updates (Ubuntu Precise) (and 5 other projects) "SRU: update nvidia-graphics-drivers-updates to 285.05.09 (affects: 4) (dups: 1) (heat: 20)" [Medium,In progress] https://launchpad.net/bugs/887630
<ricotz> tseliot, or point me to the fglrx upload and i push it to the ppa
<ricotz> tseliot, thanks!
<tseliot> ricotz: yes, I'm going to upload it to precise first. I can ping you when it's done
<ricotz> tseliot, ok
<bryceh> Intel says mesa 7.11 coming next week; 8.0 will be in january with open gl 3.0.  Bugfix versions in feb.
<jcristau> they don't do RCs for mesa anymore?
<Sarvatt> 7.11.1
<jcristau> ah right 7.11 is already out.  silly me.
<Sarvatt> they did rc's for point releases of mesa at one point?
<Sarvatt> oh
<jcristau> i was just confused :)
<ricotz> bryceh, i got lucky looking for a newer wacom driver and they have done a new release, you might want to grab this https://launchpad.net/~xorg-edgers/+archive/ppa/+sourcepub/2079193/+listing-archive-extra
<Sarvatt> ricotz: tjaalton is the one to poke about that :) 
<ricotz> oh, alright, i just looked at the last changelog entry
<ricotz> tjaalton, perhaps you want to grab this update for precise ^
<ricotz> Sarvatt, it even suppose to work with ABI 14 (1.12) ;)
<Sarvatt> our stuff is different than the debian ones and not maintained in pkg-xorg, he does it in his own branch on git.debian.org
<jcristau> ricotz: ABI 14 is not 1.12.
<ricotz> Sarvatt, i see, this is an uupdate from the precise package
<ricotz> jcristau, currently it is
<jcristau> 1.12 doesn't exist, and i expect its ABI will see a few more bumps.
<jcristau> no it's not
<ricotz> input abi
<Sarvatt> its not pushed yet and could be 15 or more by the time it releases is what he means
<Sarvatt> jcristau: we're most likely going to have a horrible abomination xserver this time, input stack from 1.12 on 1.11 (yay..)
<jcristau> Sarvatt: ewww
<jcristau> because 1.12 comes too late?
<Sarvatt> yeah feature freeze is feb 16th and there hasn't even been any talk of release dates or following of schedule so far so its a bit up in the air
<Sarvatt> oh it is abi 14 right now, doubt its going to be 14 in 1.12 then
<ricotz> jcristau, yeah, i meant "currently", i know it is still in transition, just saying it is nice having a driver following it
<ricotz> Sarvatt, i guess the multitouch stuff might bump it further
<ricotz> if it finally lands...
<tjaalton> ricotz: sure
<tjaalton> and while the branch is on my own repo, pkg-xorg has write access
<tjaalton> hmm, haven't seen wacom release announcements on any list
<tjaalton> oh there's a separate list for it..
<ricotz> tjaalton, ok, i just got from the sourceforge page
<Sarvatt> oh wow, cairo 1.12 this week
<Sarvatt> release candidates? who needs em
<bryceh> mesa 7.11.2 in december specifically
<bryceh> and a .3 in january in addition to 8.0
<Milos_SD> Hello... Why is there no fglrx 11.11 drivers packaged in xorg-edgers or x-swap ppa? :)
#ubuntu-x 2011-11-17
<bjsnider> Sarvatt, do you happen to understand the rationale behind the choices of alternatives in fglrx?
<Sarvatt> bjsnider: no i dont, thats why i dont touch it lately
<bjsnider> i guess i shouldn't try, but i'd like to get it into x-updates
<bjsnider> i just don't understand why some of the libs were chosen for alternatives while others weren't
<RAOF> What libs are these?
<Sarvatt> bjsnider: you know you can build source debs from the installer right?
<bjsnider> well
<Sarvatt> its really easy to install your own fglrx from their website, thats the other reason i dont
<RAOF> Huh.  This laptop has a single combined headphone/mic port.  How annoyingly useless!
<Sarvatt> third reason is its a pain in the butt to verify the kernel module builds, thats where things always go wrong
<bjsnider> RAOF, usr/lib/libaticalxx is strange
<bjsnider> where xx is rt and cl, alternatives are in play, but dd and libatiuki are not covered
<bjsnider> and this is where two new opencl libs have appeared
<Sarvatt> oh thats opencl stuff, i bet they put that in there themselves without alberto's help
<bjsnider> so i don't know if they should be included, but it seems like they should because amd has a now-obsolete opencl package that would have those files and also nvidia provides a libopencl.so.1
<bjsnider> but nvidia's libopencl is not covered by alternatives...
<Sarvatt> bjsnider: tseliot is going to upload 11.11 probably tomorrow, hopefully they dont have much package churn after that so it should be easy for a few months :)
<bjsnider> Sarvatt, phoronix says the december release is a big change too
<bjsnider> the source package is now too big to fit on a cd
<bjsnider> j/k
<Sarvatt> bjsnider: yep you're right, ugh
<bjsnider> Sarvatt, for oneiric?
<Sarvatt> just looked at the betas
<Sarvatt> bjsnider: nah precise but nothings changed really
<Sarvatt> easy to nab it :)
<Sarvatt> 4 new libs in the december ones
<bjsnider> i thought alternatives existed to stop to packages from installing the same file, thus overwriting each other
<bjsnider> but all of these laternatives are ati-specific stuff, so why do they need alternatives?
<RAOF> They don't.
<bjsnider> that's not too confusing or anything
<bjsnider> why are laternavites used in fglrx then?
<bjsnider> nvidia ships libgl, so it makes a lot of sense there
<bjsnider> all of this stuff is libati* or amd*
<RAOF> It probably shouldn't be alternatived.
<bjsnider> so these packaging scripts are overcomplicated for no apparent reason?
<RAOF> That would seem to be the case?
<bjsnider> Sarvatt, are the 4 new libs going to add 200mb more size this time?
<bjsnider> the graphics driver is bigger than the friggin' kernel
<bjsnider> and it's not even shipping its own gl
<bjsnider> thier code must be shared cross-platform like nvidia
<tjaalton> wacom 0.12.0 uploaded
<tjaalton> bryceh: might be the time to change versions-current to show precise?
<ricotz> tseliot, hello
<tseliot> ricotz: hi
<ricotz> tseliot, how is it going with fglrx?
<tseliot> I haven't updated the driver yet. I need to upload a fixed nvidia-common and jockey first then I'll think of fglrx (my scripts should be mostly ready)
<ricotz> ok, i will be patient then :)
<tjaalton> ricotz: wacom is uploaded though
<ricotz> tjaalton, good
<tjaalton> support for intuos4 oleds should now be in precise.. will test once it's built
<ricotz> tseliot, do you thought about getting cuda in repos yet?
<tseliot> ricotz: cuda for what?
<ricotz> tjaalton, unfortunatelly i dont have a wacom device for testing
<ricotz> tseliot, libraries like nvidia-texture-tools can use it for example which isnt packaged yet
<tseliot> ricotz: is it in debian already?
<ricotz> tseliot, since it is already available in debain syncing it would be nice, but it isnt compatible with the nvidia-driver packaging of ubuntu
<tseliot> ricotz: oh, I'll have a look at the debian package then, and see what needs to be done
<ricotz> tseliot, do you think it is possible to adapt the nvidia packaging
<ricotz> they splitted up all libraries in their own debs though
<tseliot> ricotz: it depends. I'll know only when I see it
<ricotz> tseliot, ok, thanks
<tjaalton> ricotz: no worries, i have one, and an Aiptek (waltop)
<tjaalton> i packaged cuda locally for the university where i used to work
<tjaalton> there were people doing some research with it
<tseliot> ah
<tjaalton> there's this sdk that you had to initialize so that it'd be linked to from your home directory
<tjaalton> can't remember, strange stuff :)
<Milos_SD> can someone help me to get FGLRX drivers installed and working on HP ProBook 4530s with Intel Sandy Bridge + AMD HD6490 graphics?
<Milos_SD> When starting Xserver with FGLRX installed, XServer get segmentation fault
<Milos_SD> here is the log: http://pastebin.com/hsnCw47g
<bjsnider> tseliot, i was looking at the fglrx scripts last night and i don't understand the choices of which files to use with alternatives
<bjsnider> they all look like amd-centric stuff, so why are they in danger of overwriting anything?
<tseliot> bjsnider: I'm not sure I understand what you mean
<bjsnider> well i thought the reason for using alternatives was to make sure file a doesn't overwrite file b of the same name also provided by another package?
<bjsnider> but all of this stuff is called libati* or amd*
<tseliot> bjsnider: right, and we have 2 flavours of the same driver
<tseliot> it's just a case that they cannot be installed at the same time
<tseliot> (because of hybrid graphics)
<bjsnider> you have 2 versions of fglrx?
<tseliot> fglrx and fglrx-updates
<bjsnider> why not just make the packages conflict with each other?
<Milos_SD> does anyone know how can I fix a problem that I described ? 
<jcristau> don't use fglrx
<tjaalton> hybrid graphics fail
<tseliot> bjsnider: I did that, when I realised that they couldn't be installed at the same time
<tseliot> jcristau: that's definitely a solution ;)
<bjsnider> but if they conflict then why are alternatives needed?
 * tseliot uses only open driver on his main pc
<jcristau> that and don't buy silly hybrid graphics.
<tseliot> *drivers
<tseliot> bjsnider: libGL, and other stugg
<tseliot> *stuff
<bjsnider> nvidia provides its own libgl
<tseliot> and so do mesa and fglrx
<tseliot> this way you can install both nvidia and fglrx at the same time
<tseliot> (using only one though)
<Milos_SD> well, it worked on SLED 11 :S
<tseliot> Milos_SD: I don't know what problem you're facing but did you file a bug report about it?
<bjsnider> tseliot, http://pastebin.com/hsnCw47g
<bjsnider> that's Milos_SD's pastebin
<tjaalton> right, it's trying to load both intel and fglrx -> fail
<bjsnider> Milos_SD, have you got a switch to turn off one chip or the other?
<tseliot> in theory that should work
<Milos_SD> bjsnider, there is only switch to turn ATI off
<bjsnider> good
<tjaalton> and that intel kms is probably being used
<Milos_SD> can fglrx that charge if I disable modseting for intel?
<Milos_SD> that is the only think I didn't try
<bjsnider> a lot of people don't even have a switch
<Milos_SD> thing*
<tseliot> Milos_SD: there's a script you can try to switch
<Milos_SD> it is not actualy a switch... it is option to disable switchable graphics (it disables ATI totaly)
<Milos_SD> switchable graphics : ON or OFF... nothing else
<Milos_SD> :)
<tseliot> Milos_SD: so, if you want to use both cards
<tseliot> (in the BIOS)
<tseliot> and experiment with the fglrx driver
<tseliot> you can do this to use the AMD card:
<tseliot> sudo /usr/lib/fglrx/switchlibGL amd
<tseliot> sudo /usr/lib/fglrx/switchlibglx amd
<tseliot> and restart
<tseliot> or
<tseliot> sudo /usr/lib/fglrx/switchlibGL intel
<tseliot>  sudo /usr/lib/fglrx/switchlibGL intel
<tseliot> to use only the intel card (without having to remove fglrx)
<tseliot> Milos_SD: if this ^ doesn't help, feel free to file a bug report
<Milos_SD> problem is that, I think there are few bug reports about this :)
<tseliot> Milos_SD: I don't think this is officially supported by AMD but I do what I can to help
<Milos_SD> tseliot, it doesn't work... it is the same as doing: sudo aticonfig --px ddx or --px idx
<Milos_SD> and switchlib doesn't even switch libs :)
<tseliot> Milos_SD: how so?
<tseliot> I mean, how are you so sure that it doesn't switch libraries?
<Milos_SD> in xorg log it says something about not right libs are loaded
<tseliot> are you using oneiric?
<tseliot> 11.10
<tseliot> ?
<Milos_SD> yes
<tseliot> ok, so, do an update-alternatives --display x86_64-linux-gnu_gl_conf (if you're using Ubuntu 64 bit) before and after those two commands
<tseliot> things should change. The fact that the driver segfaults is a different issue
<tseliot> oh and sudo aticonfig --px ddx or --px idx call those two scripts
<tseliot> (which I wrote)
<Milos_SD> yes I know that... and after I use aticonfig --px idx I can't use aticonfig at all anymore
<Milos_SD> libGL is missing
<tseliot> Milos_SD: oh, I think I know what's going on...
<tseliot> no wonder it's missing
<tseliot> I should've updated the powerXpress alternative with multiarch paths for mesa... my bad
<tseliot> I'm going to upload a new upstream release with a fix anyway
<tseliot> :~$ cat /usr/lib/pxpress/ld.so.conf
<tseliot> /usr/lib/mesa
<tseliot> /usr/lib/pxpress/lib
<tseliot> /usr/lib32/mesa
<tseliot> /usr/lib32/pxpress/lib
<tseliot> wrong ^
<tseliot> ;)
<Milos_SD> btw, I need to create /usr/lib64 directory and then copy fglrx folder from /usr/lib/ in it to make aticonfig --initial -f work at all
<tseliot> Milos_SD: it's best if you don't copy things manually, otherwise things will break on next update
<Milos_SD> well I do that when I install 11.10 version of fglrx from amd site... but it has to be done for fglrx-updates from repos too
<Milos_SD> and I think for fglrx package too
<tseliot> Milos_SD: that's because I maintain the scripts for all of them ;)
<tseliot> therefore if something is not fixed in my packages in ubuntu it's likely that it's not fixed in the amd installer
<Milos_SD> for fglrx package (not the -updates one) have that bug fixed in changelog, but it isn't realy fixed :)
<tseliot> I'll check that and make sure that it's really fixed
<tseliot> thanks for reporting the issue
<Milos_SD> so, that is the main problem that Xserver is segfaulting here?
<Milos_SD> main reason*
<tseliot> Milos_SD: it could be
 * tseliot -> phone call
<bryceh> tjaalton, right; will try to get that updated today
<tjaalton> bryceh: cool, thanks
<Sarvatt> multiarch with PPAs is really proving to be unfun because i386 is always backed up more than amd64 and you get http://paste.ubuntu.com/741401/ for a few hours every day
<Sarvatt> accept that and wine silently stops working
<ricotz> Sarvatt, thanks for updating right drivers ;)
<Sarvatt> the right drivers?
<ricotz> the ones which failed so far with xserver git master
<ricotz> didnt follow their changes but maybe they got fixed
<Sarvatt> oh my script updates every driver whenever there are new updates in upstream git, they must be fixing it :)
<Sarvatt> yeah ajax fixed a bunch up it looks like
<Sarvatt> its screwed up on mga though, i have to do that one manually
<Sarvatt> is that broken?
<Sarvatt> ricotz: does geode build on master?
<Sarvatt> or openchrome
<ricotz> mga built
<ricotz> geode i havent in the ppa though
<ricotz> https://launchpad.net/~ricotz/+archive/unstable/+packages
<Sarvatt> so just vmmouse still
<Sarvatt> might be able to fix that up, lets see
<ricotz> i am copying the missing one, i just grabbed the driver from the precise pocket
<Sarvatt> oh hell
<Sarvatt> spent the past half hour fixing up vmmouse then it hit me
<Sarvatt> ajax was fixing the upstream drivers up, check fedora
<Sarvatt> http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-drv-vmmouse.git;a=blob;f=0001-Deal-with-opaque-InputOption-types-in-ABI-14.patch;h=ef4a765a4839bb5cd3e8ac8e7fc927c1c8fd952d;hb=9b1097ff9fc1a828eb8e899c5ed4c8f006b88574
<Sarvatt> ricotz: new vmmouse incoming :)
<ricotz> Sarvatt, nice ;)
<ricotz> unfortunatelly wacom failed against all odds
<Sarvatt> ricotz: did you check fedora?
<ricotz> yeah, it might work with git master
<ricotz> wacom said so too ;)
<Sarvatt> ricotz: you could always override_dh_auto_test:
<Sarvatt> 	dh_auto_test || echo "Test suite failure, but keeping on anyway"
<Sarvatt>  :P
<ricotz> i see, havent looked at it closely while i dont really need it
#ubuntu-x 2011-11-18
<bryceh> "Enlightenment E17 Running On Wayland" ooh
<Sarvatt> bryceh, RAOF: hrm so theres not much use spending significant effort getting this lts backports stuff into the archive before got 12.04?
<Sarvatt> since its going to be the crazy backporting 100 packages with suffixes deal
<Sarvatt> we cant have xserver-xorg-video-quezacotl if we dont know what its actually called :P
<Sarvatt> xserver-xorg-video-intel-quezacotl that is
<RAOF> Sarvatt: Right.  We just need to ensure that we *can* get quezacotl into the archive.
<Sarvatt> well the kernel does it and we were told this was how it has to be done so i guess thats how it's going to be? :P
<Sarvatt> imagine we'll have some metapackage stuff to work out, would be good to get it working and tested before release at least
<Sarvatt> i can probably integrate that into edgers, make a whole new stack an optional install
<Sarvatt> xserver 1.12 for instance
<Sarvatt> except yeah, libs..
<bryceh> Sarvatt, yeah anything that can be practiced in edgers would likely help
<tjaalton> well i guess at least libxi, libxrandr will have to be updated too, whatever the server needs
<tjaalton> i thought about the upgrade issues the other day..
<tjaalton> but now is not the time to remember what it was :)
<tjaalton> +try to
<Sarvatt> tjaalton: very much agreed about the time issue :)
<Sarvatt> libs will have to be upgraded, thats a given
<Sarvatt> its only the subtle releases like 1.9->1.10 where you dont, that wont happen for long
<Sarvatt> 1.6->1.7, ugh
<Sarvatt> i'm slightly worried about pixman because it has a history of affecting things like notify-osd without fixing it and is required quite often
<tjaalton> ok so the issue is that you can't "upgrade" to Q from 12.04.3 without cleaning up the backports first
<tjaalton> since it would be a downgrade X and kernel-wise
<Sarvatt> is that an issue?
<tjaalton> not to me
<Sarvatt> packages could be versioned lower than Q i mean
<tjaalton> just something that should be made clear
<Sarvatt> ~Q
<tjaalton> ah
<tjaalton> well you lose functionality
<broder> that's not a problem, because the package names will be different
<tjaalton> so if you need the hw support you'll regress
<tjaalton> and there's no way to detect that
<Sarvatt> tjaalton: what are you doing up at 5am? :)
<tjaalton> so, installations made with .3 should not offer the upgrade to other than the next lts imho
<tjaalton> Sarvatt: youngest giving trouble for the past 2+h
<Sarvatt> oh once P is out yeah that'll be an issue since it'd offer to upgrade to Q but versions would be higher, think i get what you mean
<tjaalton> then it was my turn and it took 15min to get her back to sleep :)
<tjaalton> yeah the upstream version part, doesn't matter what the package revision is
<Sarvatt> err i meant R instead of P there, sheesh
<tjaalton> anyway, if we can make our lives easier by adding policy, then lets do that :)
<bryceh> hey yeah the 12.04.3 -> Q issue might be worth mentioning, can one of you add it to the blueprint?
<tjaalton> on the subscription?
<bryceh> also makes me wonder about problems relating to 12.04.3 -> P (skipping Q)
<tjaalton> uh
<tjaalton> description
<tjaalton> s/P/R/
<tjaalton> :)
<bryceh> in the linked wiki page
<tjaalton> oh
<tjaalton> hadn't noticed that
<broder> 12.04.3 -> P should be fine, right?
<broder> because precise's kernel will be newer than any of the 12.04 backports
<tjaalton> well it is P :)
<broder> it's just, e.g., 12.04.3 -> M that have potential to be problematic
<tjaalton> hmm
<tjaalton> versions messed up there?
<bryceh> yeah I meant 12.04.3 -> R :-)
<broder> err...right :)
<tjaalton> bryceh: should I add a "questions" headline for drive-by comments like this? :)
<broder> 12.04.3 -> R isn't a valid upgrade path, though
<Sarvatt> 12.04->Q is fine, thats the only one thats fine, 12.04.5->R will be the problem because it'll offer Q
<broder> you can only upgrade 6 months at a time or 2 years at a time
 * Sarvatt is totally slow at responding
 * RAOF is confused.
<Sarvatt> holy crap, me too
<tjaalton> .4 is the latest there'll be
<Sarvatt> 12.04.5 is R X stack
<Sarvatt> newer than Q
<bryceh> tjaalton, yeah
<tjaalton> .2 (Q stack), .3 (R stack), .4 (S stack)
<RAOF> And then we drop everyone on the T stack.
<tjaalton> then the next one is another lts
<Sarvatt> tjaalton: .3 should be Q still, .4 R?
<tjaalton> Sarvatt: .2 is released after Q
<tjaalton> .1 just before
<tjaalton> https://wiki.ubuntu.com/X/Blueprints/LtsPointUpdatesForXorg
<broder> Sarvatt: the point releases are offset from 6-month releases by 3 months
<tjaalton> it's all there :)
<bryceh> broder, right, so from 12.04.3 you could go to Q (downgrading your X stack), or to R (correct X stack, but not a valid upgrade path)
<RAOF> Ahem.  Then after .4 we transition everyone to the T stack, because P is still supported for a long while after .4
<tjaalton> RAOF: yep
<RAOF> As the various stacks drop out of security support.
<bryceh> I put a table with all these into the wiki blueprint page (and dates!)
<tjaalton> so basically only vanilla P and maybe P.1 is upgradable to Q, the others -> T
<bryceh> yeah it's just something we'll have to document
<bryceh> I can't imagine someone who's already opted into 3 point releases is suddenly going to wake up one day and decide to go non-LTS ;-)  But users are crazy, anything could happen.
<broder> bryceh: if it was possible to retain the backport-R stack when you upgraded from 12.04.3 -> Q, the user could reboot and upgrade to R immediately
<broder> but i don't know if that's going to be possible. it depends on how the packaging magic plays out
<tjaalton> bryceh: users can still do that, just that update-manager shouldn't offer it. no way to protect them from sed & apt-get :)
<RAOF> That'd be different.
<bryceh> broder, right, the only problem would be if they installed 12.04.3 because the Q stack was faulty on their hardware or something.  But we get into weird corner cases at this point.
<RAOF> broder: Hm, but you raise a good point; there needs to be some update-manager trickery to ensure that things work correctly.
<broder> bryceh: but if they kept using backport-R stack after they upgraded to Q, in the same way that you can have old kernel versions lying around...
<tjaalton> yeah they just should reinstall at that point, it'll keep /home intact anyway
<RAOF> There's a policy question here - on a 12.04.x â 12.10 upgrade, what stack should the user end up with?  I'd like to say they should just end up with the 12.10 stack, regardless of which 12.04.x they upgraded from.
 * Sarvatt was seriously hoping we could just upgrade via -backports and include that on the livecd and not do package name mangling
 * broder 's backporter head hurts from that idea
<Sarvatt> RAOF: sounds like something update-manager could handle, removing the old stack before upgrading
<RAOF> Sarvatt: Right, that's one way of doing it; we could also have the 12.10 stack declare breaks/replaces on the appropriate bits.  Either way, it needs deciding before the 12.10 release.
<tjaalton> but then they risk losing hw support
<broder> in fairness, that's always a risk on upgrade, regardless of whether you're going forwards or backwards
<tjaalton> just declare it as a non-supported upgrade path.. you're on your own if you do that
<RAOF> I think this is a huge corner case.  The use-case we're talking about is for people who installed 12.04.3 *in preference to* 13.04, and then want to upgrade to 12.10.
<Sarvatt> very true, was about to say that too
<RAOF> They probably don't want to do that at all :).  At worst, they *actually* want to upgrade to 13.04 or 13.10.  And we'll support upgrading to 14.04.
<tjaalton> right
<Sarvatt> so say, ubuntu-desktop depends on xorg
<Sarvatt> how does that get fixed
<Sarvatt> i'm not seeing it
<tjaalton> :)
<RAOF> xorg-q Provides: xorg
<tjaalton> install ubuntu-desktop-q :)
<RAOF> Which is one of the things we need to check pre-12.04: we need to ensure that nothing outside the stack has versioned dependencies on pieces of the stack.
<tjaalton> if there are going to be other backports due to pixman changes or such
<Sarvatt> we're going to end up having deltas to debian on all of X doing this aren't we?
<tjaalton> only on the next lts when it's cleaning up the mess :)
<tjaalton> but don't see why the interim release packages should
<RAOF> The stack is reasonably self-contained; I don't think we'll need to touch *everything*.
<Sarvatt> do you really think meta packages will handle this correctly?
<Sarvatt> like right now, try to upgrade to a new X video abi version with a nvidia driver or virtualbox installed providing the old one, the dist-upgrade will remove a metapackage and a bunch of other crap, then things are screwed
<RAOF> Those drivers shouldn't provide the old one.
<RAOF> But, indeed, that's the sort of thing to check :)
<tjaalton> updated the wiki
<bryceh> wonder if stuff depending on xvfb will get confused
<Sarvatt> yeah this is my xorg-edgers experience since xserver 1.5 bugging me, i've never seen an abi update handled correctly
<Sarvatt> always some weird quirk in apt ordering screwing things up
<Sarvatt> probably my own fault with crappy packaging or not packaging absolutely everything though
<Sarvatt> by probably I mean guaranteed I guess, still worried about it :)
<Sarvatt> the 1.8 transition in ubuntu didnt go well
<Sarvatt> but was ok by 1.9
<Sarvatt> 1.9 was in 10.10 and 1.8 was only stopgap during the dev cycle though
<bryceh> tjaalton, versions-current now updated
<bryceh> http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/versions-current.html
<Sarvatt> sucks about 6.14.3 ati :(
<Sarvatt> new git snapshot?
<tjaalton> bryceh: thanks!
<bryceh> Sarvatt, yeah
<tjaalton> oh, heh. as if they'll ever bump the minor release :)
<Sarvatt> they will, 6.14.4, bet ya a beer at budapest :)
<bryceh> we could ask them to do 6.15 for the lts
<Sarvatt> oh thats micro
<tjaalton> Sarvatt: that's patch release, or micro yeah
<tjaalton> :)
<Sarvatt> any point to going through that list yet?
<Sarvatt> i was waiting for xserver 1.11
<Sarvatt> only did libdrm
<tjaalton> nah, stuff will get synced from testing, and the rest can wait for the server push
<tjaalton> though I did upload wacom already
<tjaalton> merges can be staged in git though
<Sarvatt> rebuilds are a lot faster than syncs though thinking about it
<bjsnider> why is it necessary to have nvidia provide xorg video abi?
<Sarvatt> bjsnider: i wish i knew, i debated that one with tseliot since the start
<bjsnider> nvidia doesn't even care what else is installed
<Sarvatt> it works on multiple abi's, it's only useful during the development release when it might be updated to a new abi it doesnt support
<Sarvatt> artifical limitations dont make sense to me
<tjaalton> well, if we are always going to update the stack via a ppa in the future, maybe it is unnecessary to have the blobs provide it
<Sarvatt> nvidia especially, they have new abi support publically at most a week or so after its out, the real lag is the distro upgrading the driver
<tjaalton> though fglrx is always behind
<Sarvatt> fglrx on the other hand is guaranteed 3 months
<bjsnider> even if nvidia doesn't officially support an abi, it almost always works fine with ignoreabi
<Sarvatt> bjsnider: yea
<bjsnider> 3 months behind?
<bjsnider> does it work anyway?
<broder> re: apt mangling upgrades, that's probably because the thing that's not getting upgraded is marked as manually installed
<broder> while everything else is auto installed
<broder> so apt (unfortunately) concludes that you *clearly* meant to keep the manually installed thing, even if it means you lose the auto installed thing
<Milos_SD> Is there a bug in ppa-purge ?
<Milos_SD> it says that there are a lot of packages with unmet dependencies...
<Milos_SD> and it wants to delete a lot of packages not from xorg-edgers ppa
<ricotz> Milos_SD, i think ppa-purge has some problems handling multiarch and get confused by it
<ricotz> tseliot, please upload fglrx :)
<tseliot> ricotz: I'm working right now on some changes for the upstream fglrx but I'm afraid I won't make it today for the one in Ubuntu
<tseliot> I'm sorry
<ricotz> tseliot, hmm, if there are only problem regarding jockey could upload it somewhere where I can grab it?
<tseliot> ricotz: I've fixed jockey but something else's come up today and I had to delay my work on fglrx
<ricotz> tseliot, i see, so you dont have a "kind of working" source package at all?
<tseliot> ricotz: no, sorry
<tseliot> I only have an untested local branch
<ricotz> tseliot, i cant test it myself, but i really like to push something to the edgers ppa
<tseliot> ricotz: I know but can't we wait until Monday?
<ricotz> tseliot, sure, if you think it will break the world it might better
<tseliot> ricotz: it should. Also, I have yet to fix an issue with hybrid graphics...
<ricotz> tseliot, alright, it is ok then
<tseliot> ;)
<ricotz> it would fit the cracky edgers ppa though :P
<tseliot> heh
#ubuntu-x 2011-11-20
<Sarvatt> urg
<Sarvatt> sarvatt@kyoko{/opt/google/earth/free}:ldd googleearth-bin | grep drm
<Sarvatt> 	libdrm.so.2 => /usr/lib32/libdrm.so.2 (0xf45c3000)
<Sarvatt> ia32-libs..
<Sarvatt> libGL error: dlopen /usr/lib/i386-linux-gnu/dri/i965_dri.so failed (/usr/lib/i386-linux-gnu/dri/i965_dri.so: undefined symbol: drm_intel_gem_bo_clear_relocs)
<Sarvatt> things were just silently broken but it didn't matter because we had the same versions in oneiric and ia32-libs at release
<Sarvatt> yep wine's busted too, err:winediag:X11DRV_WineGL_InitOpenglInfo The Mesa OpenGL driver is using software rendering, most likely your OpenGL drivers haven't been installed correctly (using GL renderer "Software Rasterizer", version "2.1 Mesa 7.12-devel").
<Sarvatt> sudo mv /etc/ld.so.conf.d/biarch-compat.conf{,.bak} && sudo ldconfig also works
<Sarvatt> guess I can just remove libdrm and mesa from ia32-libs to work around it
<Sarvatt> (in edgers)
<Sarvatt> only 12 hours to apt-get source ia32-libs, woohoo
 * Sarvatt prepares the whiskey for when ia32-libs fails to build properly in the PPA after the 580MB upload
 * jcristau prepares the champagne for when ia32-libs ceases to exist
<Sarvatt> it's already gone in precise :)
<jcristau> yay
<Sarvatt> still no news on dpkg? most everything is already multiarched in debian because slangasek is awesome
<jcristau> grrr dpkg.
<Sarvatt> not everything is converted and ia32-libs is uninstallable on precise at the moment but we freeze in like february, hopefully thats plenty of time to get to wheezy before its frozen in june
<jcristau> (and, yeah, vorlon is awesome)
<Sarvatt> multiarch dpkg is in dpkg git
<Sarvatt> master
<Sarvatt> \o/
<Sarvatt> author	RaphaÃ«l Hertzog <hertzog@debian.org>	
<Sarvatt> Fri, 14 Jan 2011 11:44:21 +0000 (12:44 +0100)
<Sarvatt> committer	Guillem Jover <guillem@debian.org>	
<Sarvatt> Mon, 24 Oct 2011 17:50:59 +0000 (19:50 +0200)
<Sarvatt> http://paste.ubuntu.com/744765/ ppa-purge with multiarch is so screwed
<Sarvatt> oh wow, easier than I thought possibly, no :i386 action going on there
<Sarvatt> nothing like writing something, finding out its broken a year or two later, then going back to fix it and finding it been majorly refactored and you have to figure out how its working now :)
<Sarvatt> oh and yay at https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/831768, fixing it probably wont even help
<ubot4> Launchpad bug 831768 in baltix (and 3 other projects) "aptitude cannot handle conflicts with multiarch enabled (affects: 139) (dups: 1) (heat: 700)" [Undecided,New]
<jcristau> Sarvatt: i think like half of the commits are in dpkg.git
<jcristau> guillem is still stalling the rest
#ubuntu-x 2012-11-12
<mlankhorst> RAOF: can we sru x11proto and wayland then to precise? after that we should be ready to upload lts-quantal stuff..
<mlankhorst> oh and llvm-3.1
<mlankhorst> I think libxrandr sru would make sense too, difference is only adding the support for provider objects and adding nameLen in XRROutputInfo (which I don't care about and can be reverted for all I care). The additions are noops on precise, and no existing code will behave differently with it in place, see libxrandr commit 5d2edde0bf8460a.
<ximion> hi!
<ximion> I am currently working on bug #1069031 to make Ubuntu at least show *something* on the screen on the hardware mentioned in this report.
<ubottu> Launchpad bug 1069031 in xorg-server (Ubuntu) "intel gma3600: X unable to start" [Medium,In progress] https://launchpad.net/bugs/1069031
<ximion> what is the right procedure to get this included in Ubuntu updates?
<ximion> I'll soon simply attach a debdiff to this report
<ximion> (as soon as my chroot build has completed and I have been able to test the package)
<task> Hi, since I updated to 12.10 my Gnome is very slow... I heard this might be realted to NVidia or my bumblebee setup. Any Idea how to solve this?
<mlankhorst> task: glxinfo might give you some clue
<mlankhorst> but we can't officially support bumblebee, so I'd try without first if I were you
<task> http://paste.ubuntu.com/1353259/
<mlankhorst> not official quantal versions at least for mesa..
<mlankhorst> other than that nothing looks suspicious
<task> ok, but you still would say my power consumption is related to X in some way
<mlankhorst> power consumption probably, unless you turned off the nvidia gpu
<task> that's what I get if I play musik, too http://paste.ubuntu.com/1353215/
<mlankhorst> but that'd be more a case of leaving the nvidia gpu on rather than anything else..
<task> nono the nvidia is off right now.. It's just that I wonder what my be the cause for my slow Gnome. Therefore, I investigating in any directin ,)
<task> When I click an non-focused window it takes almost 1-2 seconds to bring it to the front and focused.
<task> even when CPU usage is below 5% ... as I understadn you I'm on the right track by examin Bumblebee environemt
<task> Ok, I'll move on. Thanks for your help.
#ubuntu-x 2012-11-13
<mlankhorst> RAOF: poke :p
<RAOF> mlankhorst: Ow!
<mlankhorst> RAOF: i posted a update on ubuntu-x on the lts stack, can you read through it a bit?
<RAOF> Will do
<mlankhorst> still not 100% sure what to do with -dev packages though, right now 1 of the possible resolutions is uninstalling the entire stack. For example if you try to install libclutter-1.0-dev
<mlankhorst> although I think that could be fixed by dropping version there
<mlankhorst> libclutter and libcogl would need a SRU to remove version from libgl1-mesa-dev, or I need to make msea -dev packages coinstallable
<mlankhorst> RAOF: I knew you meant libdrm.so.2ltsq, but I think this was less likely to break
<RAOF> Ok. It seems like it's caused you a bit of extra work, but I guess you're the one doing that work :)
<mlankhorst> hey if i write a hack i dont want to spend more time on it than needed, so this was less likely to run into weird ld bugs
<jcristau> itym features
 * mlankhorst is lazy, do some extra work to prevent having to do other work later ;-)
<mlankhorst> RAOF: going to see if i can get the mesa patch upstream in a cleaner way, I already have the intel version upstreamed
<ricotz> tjaalton, hi
<ricotz> tjaalton, i know you touched (at least sponsored) virtualbox :)
<ricotz> tjaalton, unping ;)
<bjsnider> ricotz, 310.19 blob released
<ricotz> bjsnider, thanks
<ricotz> bjsnider, unfortunately, nv-mmap.c looks broken in regards to the obvious support for 3.7
<bjsnider> ricotz, how so?
<ricotz>         vma->vm_flags |= (VM_IO | VM_LOCKED | VM_RESERVED);
<ricotz>         vma->vm_flags |= (VM_DONTEXPAND | VM_DONTDUMP);
<bjsnider> won't build against it?
<ricotz> it include both line like that, so it wont compile
<bjsnider> patch possible?
<ricotz> the precompiler conditions are missing
<ricotz> yes
<ricotz> bjsnider, ah nevermind they redefining them themselves
#ubuntu-x 2012-11-14
<seb128> mlankhorst, hey, did you see https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1056511/comments/10 ?
<ubottu> Launchpad bug 1056511 in xserver-xorg-video-nouveau (Ubuntu Quantal) "Xorg crashed with SIGABRT in memcpy() from NVRefreshArea()" [Undecided,New]
<xclaesse> Hello there :)
<xclaesse> any idea why I don't have GLX inside Xephyr on ubuntu?
<xclaesse> I just do "Xephyr :2" and then "DISPLAY=:2 glxinfo" and it says: Error: couldn't find RGB GLX visual or fbconfig
<xclaesse> on debian/fedora it works
<mlankhorst> seb128: hm now I do 
<seb128> mlankhorst, cool
<seb128> mlankhorst, tjaalton: do you have any idea about the Xephyr question from xclaesse?
<mlankhorst> the kwin bug seemed to have a followup since it broke some other situation
<bryceh> RAOF, when you get in, can you bump the two experimental drivers in precise NEW?  I'd at least like to get those into proposed before I send out the steam keys
<RAOF> bryceh: Huh. Why are they in NEW?
 * RAOF checks
<bryceh> well fglrx is legitimately in there.  nvidia dunno
<RAOF> Yeah, accepted fglrx
<mlankhorst> btw I finally got around spending some time on my vdpau side project again http://testbot.winehq.org/~mlankhorst/visuals.png
<mlankhorst> gnight :)
<Sarvatt> mlankhorst: I was about to ask why you didn't link the pic of it working, then G+.. :)
<mlankhorst> :P
<mlankhorst> kernel bits should be easy to upload, extracting firmware correctly is the big pain
<mlankhorst> s/upload/upstream/
#ubuntu-x 2012-11-15
<bryceh> sweet:  $ DIST=precise chet version fglrx-experimental-9
<bryceh> fglrx-experimental-9  precise  2:9.010-0ubuntu0.1
<mlankhorst> nice
<mlankhorst> hm when using a version of unreleased debian experimental git, should I have something like 1.0.4-0ubuntu1 for version?
<xclaesse> FYI, I reported my Xephyr issue since I did not have answers: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1079096
<ubottu> Launchpad bug 1079096 in xorg-server (Ubuntu) "Xephyr does not have GLX" [Undecided,New]
<mlankhorst> xclaesse: there's a upstream bug report for it afaict
<xclaesse> it works on f17
<xclaesse> not sure which version they have
<mlankhorst> great fd.org is having issues all of a sudden
<mlankhorst> https://bugs.freedesktop.org/show_bug.cgi?id=54798 probably
<ubottu> Freedesktop bug 54798 in Server/DDX/Xephyr "Add glXCreateNewContext support to Xephyr" [Normal,Resolved: fixed]
<mlankhorst> xclaesse: if you want can you test if that patch works so we can include it in the xserver sru?
<maxb> mlankhorst: I believe that -0ubuntu1 is correct in that circumstance, yes
<xclaesse> mlankhorst, thanks, I'll try the patch and let you know :)
<xclaesse> mlankhorst, hm, I've fetched the code with apt-get source xserver-xephyr, then ./autogen.sh --enable-xephyr && make
<xclaesse> but I don't see any Xephyr binary
<xclaesse> mlankhorst, I applied the patch with patch -p1 < foo.patch, if I do "debuild" will it include the patch in the build?
<mlankhorst> yeah
<xclaesse> ok, let's see if that works :)
<mlankhorst> So uploading to ubuntu is just dput ubuntu.. how anticlimactic
<xclaesse> mlankhorst, ok I've installed the new xephyr with sudo dpkg -i ../xserver-xephyr_1.13.0-0ubuntu6_amd64.deb
<xclaesse> but still same problem :(
<mlankhorst> what if you also add [PATCH] Xephyr: GLX: Support MakeContextCurrent and MakeCurrentReadSGI (on ml) ?
<xclaesse> mlankhorst, which ML? I'm no X dev :/
<jcristau> xorg-devel
<mlankhorst> also an upstream commit it seems
<xclaesse> link?
<mlankhorst> 11afebc92ce1a7462ff2886286504425b1c8f0ba
<xclaesse> ok, compiling
<xclaesse> mlankhorst, doesn't change anything :(
<xclaesse> mlankhorst, from commit msg they seems to fix virtualbox, but here I'm not using a VM
<mlankhorst> it's probably something similar though :/
<mlankhorst> what drivers do you use?
<xclaesse> intel
<mlankhorst> needs some more digging then :/
<xclaesse> mlankhorst, btw seb128 has the same issue, so it's not just me. can't you reproduce?
<xclaesse> mlankhorst, I'm here if you need info/tests, but tbh I'm not X dev so I cannot tell much :/
 * xclaesse just wants to run gnome-shell in xephyr
<mlankhorst> want to  become a x dev? :P
<xclaesse> not really, thanks :)
<xclaesse> can't wait for wayland to replace that aging x server :)
<mlankhorst> saying as if age is a bad thing
<xclaesse> hehe, fair enough :)
<jcristau> you're a wayland dev?
<xclaesse> no at all :)
<xclaesse> I'm telepathy dev
<xclaesse> IM stuff, and gtk/clutter :)
<mlankhorst> ugh no idea what xephyr is doing there
<jcristau> no glxinfo from the host x on that bug?
<mlankhorst> jcristau: argh seems I didn't get log info because server was compiled with disable-debug >:(
<mlankhorst> xclaesse: (!!) in ../../../../hw/kdrive/ephyr/ephyr.c:662:ephyrInitScreen: (!!) host x does not support DRI. Disabling DRI forwarding
<mlankhorst> :/
<mlankhorst> xclaesse: does fedora have a patch to enable dri2 on xephyr, by any chance?
<mlankhorst> hm doesn't look like it
<xclaesse> mlankhorst, I've no idea... it works on debian as well
 * xclaesse should maybe try to install the debian package and see what happens
<mlankhorst> yeah fails on x1.13 though
<mlankhorst> does the one from precise work on quantal?
<xclaesse> mlankhorst, it works !
<xclaesse> awesome, that's a good enough solution for my needs
<xclaesse> mlankhorst, thanks :)
<mlankhorst> blegh it regressed then, don't suppose you want to run a regression test?
<mlankhorst> could try if the one from 1.12 works first, debian should have a version there
<xclaesse> mlankhorst, FYI, on debian SID  they have xephyr 2:1.12.4-3 and it has glx as well (with llvmpipe it seems)
<mlankhorst> yeah probably broken something on 1.13 then :/
<mlankhorst> you probably want to file an upstream bug for it on bugs.freedesktop.org, maybe someone looks at it
<bryceh> RAOF, when you get in, there's a bunch of nvidia and fglrx packages waiting on SRU review.
<bryceh> RAOF, there's still an nvidia -310 driver in NEW for precise-proposed, I don't think we ever figured out why that is still in new
<bryceh> RAOF, fglrx-installer-experimental-9 is also in NEW still, although I thought you'd given it a bump the other day?
<bryceh> RAOF, in unapproved there is an -updates 304.64, and a couple fglrx -updates as well as jockey
<tjaalton> why do the experimental packages have the version number appended?
<bjsnider> well, obviously there are going to be more than one type of experimental package
<bryceh> tjaalton, right, for nvidia there are going to be multiple lineages in parallel.  If a user installs 310.04 that's going to be unstable, but as it progresses 310.14 up to 310.42 it will become more stable with time.  If we were to automatically bump him to some new experimental driver -342, we'd regress them in stability without their permission
<bryceh> for fglrx their numbering system doesn't lend itself to this same scheme, so we're just having one -9 package that's just going to be a grab bag of periodic instability.
<bryceh> but who still uses fglrx anyway?  ;-)
<tjaalton> bryceh: ok, thanks
 * bryceh sends out steam keys
<bjsnider> lots of people use fglrx
<bryceh> bjsnider, guess we'll find out how many, soon.
<tjaalton> i should probably create an account there...
<bcurtiswx> ooh steam keys :)
<ajmitch> bryceh: you'll have a lot of thankful people for sending keys 
<bryceh> btw I set up #ubuntu-steam for folks that might need advice
<bjsnider> lots of users were asking about it/complaining about it in +1 before quantal was released
<bryceh> bjsnider, of course you know I joke.  But I do think the userbase is trending downward with that driver.
<bjsnider> not fast enough. faster, please
<bryceh> bjsnider, amd's working on it
<jcristau> bryceh: because people use radeon, or because they don't buy amd? :)
<bjsnider> ideally the latter
<bryceh> jcristau, bit of both I suspect.
<bjsnider> it's a decent graphics card for windows though
<bryceh> for my (non-gaming) purposes I find the foss driver works fine and seems less buggy compared with fglrx
<jcristau> bryceh: ack
<ajmitch> for gaming, my last experience of radeon was that it wasn't in the same ballpark
<bryceh> I expect for laptops fglrx would be preferred due to better power management
<bcurtiswx> laptops for gaming in general is a bad idea
 * ajmitch was trying to game on a laptop
<ajmitch> it was cooking
<bjsnider> are they still infiltrating their way into laptops as a discrete chip?
<bcurtiswx> yeah, great heat source.. helps with those winter heating bills ;)
 * ajmitch now has a decent desktop & using the nvidia 310.14 driver from quantal-proposed
<bcurtiswx> bryceh, confirmed receipt of key :)
<mlankhorst> so many double frees inside steam client, it's scary
<mlankhorst> then valgrind gave up altogether, ah well
<RAOF> bryceh: Pushed nvidia, fglrx out of binary NEW.
<bryceh> RAOF, \o/
<RAOF> (Had previously pushed them through source NEW)
<bryceh> ahh
<fagan> Hey all, I have a weird issue on 12.10 installing any of the nvidia drivers, after the reboot the screen is completely off. Like I can only see 1/3 of the desktop. I was using the 310 driver but reinstalled so I know it should work fine. 
<bryceh> fagan, weird
<fagan> bryceh: yeah thats exactly what I was thinking 
<fagan> :)
<bryceh> fagan, :-)
<bryceh> fagan, no idea offhand; I've not seen that when running 310 myself, but imperfections in the video driver are certainly not unknown
<fagan_> firefox crashed :D Is there anything I can do to try get it working?
<fagan_> I tried each of the drivers and they all had the same problem. I upgraded the other time so I didn't install from scratch so that might explain why it was working before
<bryceh> fagan, dunno, but if you figure out what the problem is let me know so we can investigate getting a fix in for it.  I'd probably first go through the usual troubleshooting techniques for nvidia bugs.
<fagan_> Ill have a poke around 
<fagan> Here is what the install looks like http://paste.ubuntu.com/1361508/ nothing seems a miss there 
<fagan> brb
<Sarvatt> fagan: sudo apt-get install linux-headers-3.5.0-18-generic linux-headers-3.5.0-18
<bjsnider> linux-headers-generic should be good enough
<fagan> Ok so that didn't work still, hmmmmmmm ill try install 304.64 bryceh does the steam beta work with 304.64 or will it complain about not having 310?
<fagan> (I want to check if its just a problem with installing through the package manager over the driver themselves not doing something correctly)
#ubuntu-x 2012-11-16
<bjsnider> if you mean use the nvidia-installer, forget it
<bjsnider> unless you want to damage your system
<fagan> bjsnider: well manually installing the .run from nvidia
<bjsnider> yeah, do not do that thing
<fagan> bjsnider: any ideas on how to get the nvidia-installer working then?
<bjsnider> maybe it is working
<bjsnider> it used to be less tolerant of broken edid info than other drivers
<bjsnider> maybe still is
<fagan> Well I said above that I installed the driver in 11.10 and upgraded up till now. So it must be something funny going on recently
<bjsnider> it's pictureboxed or windowboxed or letterboxed or something?
<Sarvatt> <Sarvatt> fagan: sudo apt-get install linux-headers-3.5.0-18-generic linux-headers-3.5.0-18
<Sarvatt> its not building because you dont have all the headers, theres a bug open about that
<fagan> nice thanks Sarvatt 
<Sarvatt> or just linux-headers-generic like bjsnider said would work
<Sarvatt> (and upgrade automatically)
<bjsnider> i think he was offline when i said that
<fagan> I was :)
<Sarvatt> yeah was off when i said it too, oops
<bjsnider> that log says:
<bjsnider> Module build for the currently running kernel was skipped since the
<bjsnider> kernel source for this kernel does not seem to be installed.
<bjsnider> i thought this problem was solved already
<bjsnider> nvidia-current should depend on linux-headers-generic shouldn't it?
<fagan> Ah I completely looked over that line everything else seemed usual oh except demod didn't run I should have remembered that :)
<Sarvatt> bjsnider: some people use -lowlatency or -server, no way to guarantee the right headers are installed :(
<fagan> Anyway it looks like it worked going to reboot again thanks :D
<bjsnider> this has been a bug for awhile
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-updates/+bug/1068341
<ubottu> Launchpad bug 1068341 in software-properties (Ubuntu) "No way to specify correct dependencies for dkms packages (nvidia driver install fails to get matching header)" [High,Triaged]
<bjsnider> lots of people complained baout this in the +1 channel the past few months
<bjsnider> must be because of the switch away from jockey
<fagan> Worked! :)
<bryceh> Sarvatt, hrm, is that bug something we should put on our TODO list?
<bjsnider> of course it worked
<fagan> bjsnider: well im excited because I was scratching my head for an hour wondering what was gone wrong :)
<bjsnider> lots of people had th is problem
<Sarvatt> Prf_Jakob: is the decimal seperator in your locale a . or a ,?
<Sarvatt> because if its , possibly http://steamcommunity.com/app/221410/discussions/1/882965239689221201/
<Prf_Jakob> Sarvatt: Haha yeah it is.
<Prf_Jakob> utf8-se
<bryceh> hmm, apt-cache policy shows me fglrx-experimental-9, however jockey-text -l does not
<bryceh> hmm, lets' try rebooting.
<Prf_Jakob> Sarvatt: thanks! that helped!
<Sarvatt> tjaalton: ^ you'll hit the same issue in finland :P
<darkxst> bryceh, there  no nvidia 310 drivers for R :( 
<bjsnider> they're in xorg-edgers aren't they?
<darkxst> bjsnider, oh yes, didnt think to check there
<Sarvatt> darkxst: thanks so much for looking into the ppa-purge multiarch thing, i'll run through this tomorrow and see how it works. i didn't even know about dpkg-query!
<darkxst> Sarvatt, np, I really needed to purge a ppa on my system and turned out it wasnt too hard to fix ;)
<mlankhorst> bryceh_: pingÂ¿
<bryceh_> yep
<bryceh_> tjaalton, looks like 2:1.13.0-0ubuntu7 is unreleased?  Is it waiting on anything before going in?
<tjaalton> bryce: I think the barrier patch needed a proper review
<tjaalton> mlankhorst: ^?
<bryce> ok; I'll just add the poulsbo pci id patch with it then
<bryce> or given that it's been a few weeks, maybe we should drop the patch for the time being until it gets reviewed?
<mlankhorst> bryce: well the sru queue is moving pretty slow in general too, so don't think it matters that much.
<mlankhorst> I was hoping for raof to review it but he lost out on his chance to do so, just keep it in. :P
<bryce> well, xserver git targets raring, so no sru queue blockage to worry about there...
<mlankhorst> oh sure go for it then
 * bryce shrugs
<tjaalton> first point-release rc coming next week
<tjaalton> 1.13.1rc
<tjaalton> but uploads are cheap
<tjaalton> i'll be back to work starting monday
<mlankhorst> sru's are expensive :/
<mlankhorst> enough fixes I do want to push, but not necessarily have a test for
<tjaalton> they need to go to the devel series first
<tjaalton> and let's get that exception for xserver point-releases..
<bryce> mlankhorst, in the changelog you mention 234-composite-borderclip.patch "is wrong".  Did you get a better solution for that, or should we drop that for now?
<mlankhorst> bryce: drop for now, upstream didn't respond
<bryce> ok
<bryce> and then the pointer barrier change is the update to 500_pointer_barrier_thresholds.diff.  You want to drop that one as well, or is it ok?
<mlankhorst> keep
<bryce> okie doke
<mlankhorst> I'm more amused that games were playable with nouveau, didn't expect that :D
<bjsnider> pretty soon the "all we need is the documentation" crowd will be proven wrong, because they didn't even need that
<mlankhorst> bjsnider: well it is a lot faster with documentation..
<mlankhorst> we have no clue how to do memory reclocking right for example
<mlankhorst> I'm reclocking my memory with a glue of shell script, c, and assembly for the card to run :-)
<mlankhorst> but it's all hardcoded, so it might even damage other cards when you try
<bjsnider> well, i do think it's interesting that a community can build a good graphics driver with no help at all from the manufacturer
<bjsnider> although the manufacturer has to protect other organizations' ip
<mlankhorst> wee, crashed mplayer again
<bryce> bjsnider, I get the sense that nouveau is about where radeon was around the time that AMD opened the docs
<bjsnider> oh, i thought it was further along than that
<bryce> I recall alex and them mentioning that when they started looking through the docs they discovered all these registers that they'd mis-guessed
<bjsnider> radeon couldn't do any opengl could it?
<bryce> I'd have to check but I seem to remember it at least had some experimental support for it
<mlankhorst> now we just need a nvidiahd driver then..
<bryce> 17 Apr 2009: AMD releases initial code branches for 3D support on R6xx/R7xx (see more below) 
<bryce> however I think there was 3D for older devices before that.
<tjaalton> r200 worked just fine
<tjaalton> way before the docs were public. but that was for r5xx anyway
<mlankhorst> well this looks even uglier
<mlankhorst> :D
<tjaalton> bryce: did you test the xserver patch for the input matrix funkyness?
<bryce> tjaalton, on my todo list for today
<tjaalton> bryce: ah :)
<bryce> mlankhorst, rtg asked for an r ppa, so I've set up https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport
<tjaalton> if it works, add a tested-by on xorg-devel@ :)
<mlankhorst> bryce: sure, just need a new mapping file
<mlankhorst> I need to add a hack to make it get the prefix from the mapping file, but it ought to work
<mlankhorst> I'm also working on getting the changes to mesa upstream, the ones from intel already are
<mlankhorst> ones in mesa too, but needs to be backported to the 9.0 branch after release
<bryce> mlankhorst, no I mean he was asking for a ppa so he could start uploading his kernels there.  :-)
<mlankhorst> ah
<bryce> mlankhorst, but that's great you're ready to go with our bits.  But no worries, take care of higher priority stuff first.
<mlankhorst> well it's not a big problem, I tried to keep most of the changes easy enough for forward compatability
<mlankhorst> plus i want to upload libdrm 2.4.40 to raring so I can keep playing with mesa master on my weird backport stack :-)
<ricotz> hi :)
<ricotz> hmm, who broke linking against mesa? ;)
<mlankhorst> sigh mplayer hates -vc , atm (disabling vdpau acceleration). some out of bounds write
<bjsnider> mlankhorst, are you using mplayer or mplayer2?
<bjsnider> uau's mplayer is better than the regular one
<mlankhorst> uau?
<bjsnider> he's the lead mplayer2 developer
<mlankhorst> ah
<mlankhorst> no I probably know why it happened
<mlankhorst> ah I was right, silly mistake :D
<mlankhorst> bjsnider: actually it works worse with mesa afaict..
<bjsnider> -vo vdpau -vc ffh264
<mlankhorst> channels = 6
<mlankhorst> vc = ffmpeg12vdpau,ffh264vdpau,ffwmv3vdpau,ffvc1vdpau,ffodivxvdpau,
<mlankhorst> vo = vdpau:colorspace=0,
<mlankhorst> is what i use atm
<mlankhorst> still some glitches though, probably messing up image parameters :-)
<bjsnider> that wouldn't work without the blob
<bjsnider> you'd better have a 6-channel sound system
<bjsnider> that doesn't have a dac
<mlankhorst> works fine without the blob ;-)
<bjsnider> ok, so gallium does vdpau?
<mlankhorst> well strictly speaking still blobby
<bjsnider> there's a working vdpau state tracker in gallium?
<mlankhorst> not upstream, but it does have some vdpau output support, and if you're insane and know nouveau some you can load the decoder blobs into the hardware
<bjsnider> i know they'd talked about it
<mlankhorst> yeah
<mlankhorst> it's just the drivers that are lacking
<bjsnider> well, i'd use the cpu assuming it's sandybridge or ivybridge
<mlankhorst> Where's the fun in that!!!
<mlankhorst> 1000     22700  1.0  0.2 542568 39148 pts/1    Sl+  23:09   0:05 mplayer -framedrop -aid 1 01 The Crystal Empire, Pt. 1 (HD).m4v
<mlankhorst> :D
<bjsnider> i'm assuming you want it to work as an htpc or whatever. if you're trying to burn down the house that's a different motive
<mlankhorst> i want it working because I can :p
<bjsnider> m4v my butt
<mlankhorst>  ISO Media, MPEG v4 system, iTunes AVC-LC
<bjsnider> itunes my butt
<bjsnider> anyway, ffmpeg has multithreaded decoding which beats gpu decoding in speed
<bjsnider> although it uses more power
<bjsnider> libav i mean
<mlankhorst> Again, where's the fun in that, more fun to hack on nouveau :P
<bryce> xserver 1.13.0-0ubuntu7 uploaded
<bjsnider> it would probably be more fun if they'd release the docs
<mlankhorst> No, but it would be more productive
<mlankhorst> :P
<mlankhorst> vdpau's been my puzzle
<bjsnider> wikileaks is going to have to release those docs
<bjsnider> which means they'll need a whistleblower
<mlankhorst> I would rather have permission to redistribute the firmware blobs
<mlankhorst> bjsnider: does mplayer2 support mvc?
<bjsnider> what does that acronym mean?
<mlankhorst> erm h264 multiview codec
<bjsnider> i would suggest going to #mplayer2 and asking uau about it. he will answer
<mlankhorst> or whatever it was called
<mlankhorst> I know the firmware has support for it, but nvidia doesn't support it
<bjsnider> he's got betetr vdpau support i can tell you that
<bryce> aha there's 9.0.1
<jwi> mlankhorst: afair there's a (obsolete?) nouveau-firmware package in multiverse. maybe put the video blobs there?
<mlankhorst> jwi: I was thinking of writing an extraction program instead, I don't want to redistribute anything myself..
#ubuntu-x 2013-11-14
<Fish-Face> what's the current best way to get multitouch gestures from a touchpad to work (without Unity)
<RAOF> That's not really our purview. We only care about delivering multitouch events, not really what the client wants to do with them :)
<Fish-Face> erk
<Fish-Face> well
<RAOF> It's kinda difficult for anything but the window manager to do gestures properly.
<Fish-Face> what's the current best way to do that part
<Fish-Face> I know of the synaptics and mtrack drivers
<RAOF> If you've got a touchpad then you want synaptics.
<RAOF> If you've got a touchscreen then you want evdev.
<Fish-Face> mtrack worked but had horrible mouse movement
<RAOF> Yeah.
<Fish-Face> OK
<RAOF> There are only 3 input drivers - evdev, synaptics, wacom.
<RAOF> Everything else is a pack of lies ;)
<Fish-Face> :D
<Fish-Face> OK
<RAOF> Basically, you don't have to do anything to get multitouch events reported.
<Fish-Face> OK
<RAOF> But, as far as I know, Unity is the only thing that actually listens to them.
<Fish-Face> yeah
<Fish-Face> that is sad
<Fish-Face> I mean, I have no plans to install Unity, and even if I did the gestures wouldn't be configurable...
<RAOF> You could always write your own :)
<RAOF> (Not helpful, I know)
<Fish-Face> mmmmm
<Fish-Face> there are already two awful solutions (ginn, touchegg)
<Fish-Face> I don't want to contribute another!
<RAOF> Even better! Fix one of them!
<Fish-Face> D:
<Fish-Face> a good start would be if I could get 3+ finger taps to generate the appropriate button events
<Fish-Face> because apparently the easystroke tool is then reasonable for detecting arbitrary gestures (it's completely separate from multitouch considerations, so I guess it won't do pinches, but who needs that...)
<RAOF> Ah, well. Three finger taps are in the synaptics driver.
<Fish-Face> oh, yes... I think I knew that o_0
<RAOF> (Or you could handle them at a higher level, but the synaptics driver should handle 3 finger taps. If your hardware does, of course)
<Fish-Face> yeah
<Fish-Face> it does, but apparently it doesn't support 4 or more :S
<Fish-Face> I know the hardware supports this because touchpad with geis will grab those events
<Fish-Face> err
<Fish-Face> touchegg*
<RAOF> Yeah, that's right.
<Fish-Face> hmm
<Fish-Face> as a matter of fact, easystroke does no cope will with touchpad events it seems
<Fish-Face> three-finger drags don't trigger it at all (when trying to set up the gestures)
<Fish-Face> so, hmm.
<Fish-Face> I guess it will be back to geis and touchegg
<Fish-Face> before that, work
<Fish-Face> o/
<Fish-Face> cheers
#ubuntu-x 2013-11-16
<hyperair> has anyone seen this? [341026.114] (EE) intel(0): [drm] failed to set drm interface version: Permission denied [13].
<mlankhorst> hyperair: sadly too many time :P
<mlankhorst> please tell me it happens from running xmir
#ubuntu-x 2013-11-17
<hyperair> mlankhorst: nope, it's from running X
<hyperair> mlankhorst: i think it was some odd lightdm screwup
<hyperair> restarting lightdm fixed the issue.
#ubuntu-x 2015-11-11
<ricotz> tseliot, hi, is the archive nvidia blob working with the latest xserver upload for you?
<ricotz> (xserver 2:1.17.3-2ubuntu1)
<tjaalton> just told him to add xserver-xorg-legacy to depends..
<tjaalton> try installing that
<tjaalton> my bad, forgot about the blobs :)
<ricotz> tjaalton, ah, I forgot about that
<jcristau> tjaalton: i thought nvidia worked without that?
<tjaalton> jcristau: dunno, guess not
<tjaalton> my old card is buried too deep somewhere to test
<ricotz> tjaalton, I assume there were others asking before me?
<tjaalton> no
<tjaalton> well, Sarvatt pointed it out last night
<ricotz_> tjaalton, alright
<ricotz_> tjaalton, seems to work
<tjaalton> good
<tseliot> ricotz_: I haven't tested that yet. A new upload is in the plans though ;)
<ricotz_> tseliot, make sure to update to 352.55 on the way ;)
<tseliot> ricotz_: oh, you'll be surprised ;)
<ricotz_> tseliot, better just tell :)
<tseliot> I can't yet. You'll see it soon
<tjaalton> ricotz_: looks like they're still in proposed, so that's why noone noticed
<ricotz_> I know, "the early bird catches the bug"
<tjaalton> autopkgtest for ofono-phonesim 1.20-1ubuntu3: amd64: Regression
<tjaalton> and no useful output
<tjaalton> nice
#ubuntu-x 2016-11-16
<mamarley> ricotz: Kernel 4.9 has been uploaded to Zesty staging, so I am working on some patches to make the NVIDIA drivers compile against it.  I already have 375.10 working and uploaded to my staging PPA and I hope to get 340 done before I leave for work, but I won't be able to do anything else until the afternoon.
<mamarley> s/staging/proposed
<ricotz> mamarley, hey, that is great, 367 is still important too
<mamarley> OK.
<mamarley> ricotz: My attempt to patch 340.98 has failed.  I can get it to compile, but it crashes badly with a storm of kernel oopses when it is loaded.  I think someone with more kernel knowledge than me is going to have to do that one.
<ricotz> mamarley, if you have 375 working then 367 might be easier
<mamarley> Yeah, I expect it will.
<mamarley> But I am about to run out of time.
<ricotz> I don't think I will have time for it, I wanted to look at thunderbird 51 later
<mamarley> OK.  I will do it after I get home from work.
<mamarley> tseliot: Hey, I noticed that kernel 4.9-rc5 had been uploaded to zesty-proposed, so I started trying to patch the NVIDIA drivers for it.  I did 375.10 successfully and I expect 370 and 367 will be similar, but I couldn't get 340 to work.  I applied https://raw.githubusercontent.com/manjaro/packages-extra/master/linux49-extramodules/nvidia-340xx/linux-4.9-rc2.patch to it which got it to build, but then it just crashes on startup complaining that 
<mamarley> the procfs entry is already registered and that the probe failed because the driver is already registered.
<mamarley> It looks like it might be trying to initialize the driver multiple times, but I can't tell exactly what was going on.
<tseliot> mamarley: thanks for letting me know. I'll have a look at it as soon as I'm done with another nvidia related bug in 14.04 (OEM work)
<mamarley> tseliot: OK.  And if you want to look at or use the patches I have for 375, they are in ppa:mamarley/staging.
<mamarley> Thanks!
<tseliot> mamarley: great, thanks!
#ubuntu-x 2016-11-17
<mamarley> ricotz: I got 4.9-patched packages for 370 and 367 built.  They are compile- and run-tested.  In the case of 367 after I had uploaded to the staging PPA, I realized that I had screwed up the version numbers (I forgot to undo dch's automatic bump).  I have fixed this locally and will reupload those directly to the main PPA instead of copying: https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages
<mamarley> tseliot: ^The exact same patch applied to all of 375, 370, and 367.  I still haven't had any luck with 340 though.
<tseliot> mamarley: sorry, I haven't looked into it yet
#ubuntu-x 2016-11-18
<ricotz> mamarley, hi, if your testing was fine then go ahead and copy/upload
<mamarley> ricotz: Will do, thanks!
<jcastro> ricotz: do you think regular copies of mesa from xorg-edgers to graphics-drivers would make sense? 
<ricotz> jcastro, hard to say, obviously it is not only mesa, but also llvm, libdrm and likely libva for proper support
<jcastro> right
<ricotz> and the most common 2d-drivers
<ricotz> this works fine for non-lts release, but lts with hwe stack is problematic
<jcastro> does the HWE stack pull in all that stuff itself?
<ricotz> hwe stack as a different "namespace"
<jcastro> Like, I wonder if the answer is just "the HWE stack will be pulling in all that stuff anyway"
<ricotz> so those packages are not compatible and won't be installed
<mamarley> Ooh, Mesa 13.0.1, nice!
 * mamarley installs.
<ricotz> jcastro, and the snapshot in xedgers is 13.0.1 , currently
<mamarley> And sorry, I forgot to copy those drivers before I left for work.  I will do it when I get home.
<ricotz> mamarley, no hurry, better be careful ;)
<ricotz> (this hits quite some users)
<mamarley> Indeed.  I did test both driver versions before uploading.  I can't test every supported distro though because I don't have that many boxes/that much storage space.
<mamarley> jcastro: Do you by any chance have any numbers about how many people use the PPA?
<jcastro> mamarley: yeah let me fire off the script
<ricotz> mamarley, I installed 4.9 here on zesty and the nvidia patch but havent rebooted into yet
<ricotz> nvidia-370	370.28-0ubuntu0~gpu16.04.2	xenial	amd64	11016
<ricotz> nvidia-367	367.57-0ubuntu0~gpu16.04.1	xenial	amd64	5845
<ricotz> this might be the most interesting numbers
<mamarley> I checked to make sure both 367 and 370 would boot and 3D acceleration worked on my laptop.  I also checked to make sure they would still compile against <4.9 (i.e., the patch for 4.9 did not apply in those cases).
<mamarley> Are those download counts?
<ricotz> yes, for those specific builds
<mamarley> Eleven thousand installs, whoa.  That's actually kind of scary.
<ricotz> plus like 5000+ scattered around
<mamarley> I guess it is also surprising that so many people are still on Xenial.  I would think the driver crack addicts like me would also want the latest stuff otherwise as well.
<ricotz> not really, many want to have a stable base, with some cherry-picked crack ;)
<mamarley> I know I have gotten a bunch of emails about when 375.10 is going to be in the PPA.  I was hoping NVIDIA was going to release the next 375 driver sometime this week.  That driver should support the xserver 1.19 ABI, so I can try out the PPA build I did of that on my non-Intel-GPU systems.
<mamarley> And indeed they did!  375.20 is apparently out!
<mamarley> soee: You're sleeping on the job again!
<ricotz> hehe, this was basically there since 1 hour?
<mamarley> I will package and test it once I get home.
<ricotz> sounds good! :)
<mamarley> This should also fix the segfault-on-exit problem.
<ricotz> yes, that is the blocker 
<jcastro> mamarley: http://paste.ubuntu.com/23496674/
<jcastro> the ppa-stats script I use is here btw: https://github.com/marcoceppi/gypsy-danger
<mamarley> Ah, cool.  Thanks!
<jcastro> sometimes it misses certain versions in the PPA, I haven't investigated why yet
<soee> mamarley: i was out :D
<soee> mamarley: ping me when you have it in your staging ppa
<mamarley> Sure thing :)
<tjaalton>  so.. someone wants stable mesa backports
<tjaalton> the headline of the graphics-drivers ppa says "proprietary gpu drivers", which today means nvidia
<tjaalton> right now the reason why zesty doesn't have 13.0 is that the mir patch hasn't been tested yet
<tjaalton> and I don't have a working unity8 setup
<mamarley> ricotz: soee: 375.20 is uploaded to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages and the 367 and 370 updates have been copied/reuploaded as applicable to https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+packages. :)
<mamarley> 375.20 was all that I was expecting it to be (crash-on-exit fixed, xorg 1.19 supported) and more (compiles cleanly against kernel 4.9 without patching)
<mamarley> ricotz: So it looks like 375.20 isn't entirely bug-free either.  On my desktop, it seems to have issues with several OpenGL applications running at once.  If I launch several Chromium windows, for example, a game would crash if I launched it.
<mamarley> That doesn't happen on my laptop though.
<mamarley> Or, more annoyingly, if I have Chromium running, the KDE lock screen gets stuck and unusable.
#ubuntu-x 2016-11-19
<Guy1524> hey guys, how do I install vulkan for a haswell graphics card (HD 4600) on ubuntu 16.04?
<Jordan_U> Guy1524: I'll note that https://launchpad.net/~canonical-x/+archive/ubuntu/vulkan exists, but I've never tried it. Be sure to read all of the PPA description.
<Guy1524> ok, thanks
<Guy1524> well although it worked, its just vulkan version 1.0.8, but thanks anyway
<Guy1524> even triangle applications do not work on vulkan 1.0.8 here, well thanks for helping, atleast its installed
<tjaalton> that ppa was for testing only..
<tjaalton> vulkan needs to be backported to xenial anyway like libdrm for the hwe stack to build
<tjaalton> there, vulkan ppa cleared..
<mamarley> ricotz: I have users bugging me about 375.20.  Should I go ahead and copy it over to the main PPA?
<ricotz> mamarley, ok, do it
<mamarley> Done.  Oddly, I got an error email from Launchpad saying that one of the copies had failed, but the package still ended up in the PPA anyway.
<jcastro> I think I've been getting mails since 375 went into beta
<jcastro> tjaalton: hey so how feasible would it be to get a copy of 13.0 in the graphics-drivers PPA after thos patches land? 
<jcastro> tjaalton: I am wondering how far the dep chain goes with LLVM, etc.
<mamarley> soee_: Tried out 375.20 yet?  Specifically, I am curious if you can reproduce https://devtalk.nvidia.com/default/topic/977518/linux/problems-with-multiple-opengl-applications-running-simultaneously-with-375-20-on-a-gtx970 and on what kind of GPU.
<soee_> mamarley: can i test it with glxgears ?
<soee_> mamarley: http://i.imgur.com/9Fxl54e.jpg on gforce 650M
<soee_> but the screen teraing with those instances if horrible :D and there is slowness in effects like minimize all windows
<mamarley> soee: Thanks!  It must start sometime between 7xx and 9xx then.
<mamarley> ricotz: Have you tested 375.20 on your 750?
<ricotz> mamarley, no, I don't have a 750, but a 970 -- I am 4.9 + 367
<mamarley> Ah, OK, for some reason I thought you had both.
#ubuntu-x 2016-11-20
<soee> mamarley: i have noticed that i can't play to good movies now on nvidia card, if i scroll it the video freezes
<soee> i think this is after installing latest drivers, on intel profile all seems to be just fine
<mamarley> soee: Yeah, that could be the same problem I am seeing.  You didn't really open enough of the glxgears instances before to necessarily reproduce the issue.  Computers with less screen resolution tend to take more instances to reproduce it.
<mamarley> soee: If you could, making a reply to https://devtalk.nvidia.com/default/topic/977518/linux/problems-with-multiple-opengl-applications-running-simultaneously-with-375-20-on-a-gtx970 might be helpful.  So far there have been 3 responses, but I think all of them are for other 9xx cards.
<soee> if only i get password reset email :)
<mamarley> I still think the issue is limited to certain generations of cards though because no matter how hard I try, I can't reproduce the issue on my NVS5400m.
<soee> mine is 650M so pretty old
<soee> bb
<soee> brb
#ubuntu-x 2018-11-12
<michael-vb> tjaalton: everything still running fine with the new X server.  I won't tell you again unless something goes wrong, as I assume you have enough things to do.
<tjaalton> michael-vb: ok, thanks. yeah it'll get otherwise tested anyway
#ubuntu-x 2018-11-13
<mamarley> ricotz: Hey, is there any reason why 415.13 hasn't been copied to the main PPA yet?
<ricotz> mamarley, sorry, I wanted to run it first, but didn't got to it yet :(
<mamarley> OK
<ricotz> if you feel comfortable then copy it
<mamarley> It works fine on my system and soee also tried it.  It also isn't like anyone will get automatically upgraded since it is a new major release, so I will go ahead and copy it.
<mamarley> Oops, dang, wrong PPA.  Just a secâ¦
<mamarley> Fixed.  Sorry, please ignore the build failures.
#ubuntu-x 2018-11-15
<michael-vb> Hello again.  I am here with a different issue: when I start a virtual machine in VirtualBox with vmgfx emulation and 3D enabled, my whole (Ubuntu 18.10) system hangs.  With tjaalton's updated X server packages, but I doubt they are related.
<michael-vb> I see some OOM killer entries in the system log, sometimes for the VM process, sometimes for Xwayland, but neither of those processes looks like it is OOM-ing the system based on the memory usage reported in the log entries.
<michael-vb> So wondering if anyone has an idea how I can debug this, or who else I could poke.  The system is a Thinkpad T470 with HD Graphics 620.
<tjaalton> michael-vb: is it the host which hangs, or client?
<michael-vb> The host.
<michael-vb> Oh yes, and it happens with X or Wayland session, no matter.
<tjaalton> could be a bug in i915, hard to tell
<michael-vb> That was also my first guess.
<michael-vb> When the OOM killer hits the VM process the system recovers.  When it hits Xwayland I can at least switch VTs.
<tjaalton> ok so it is oom related
<tjaalton> limit the display ram in vbox?
<michael-vb> The whole VM process is comfortably under host system RAM.
<michael-vb> Though it might be interesting to try increasing the VM VRAM.
<michael-vb> As I said, the OOM logs suggested that VBox was not using a lot of RAM.
<michael-vb> Or Xwayland for that matter.
<tjaalton> but sounds like they'd balloon and oom kills them
<tjaalton> or something
<michael-vb> Right, but it prints the amount of RAM they were using at kill time into the log.
<michael-vb> I am guessing that i915 starts swallowing system RAM and that the OOM killer then starts going for small-ish processes.  It has also hit as and cpp.  But that is just a guess so far.
<tjaalton> try #intel-gfx
<michael-vb> Thanks.
