#ubuntu-x 2007-01-29
<Ubugtu> New bug: #32716 in xserver-xorg-video-i810 (main) "Vertical green lines bands in 24-bit on Compaq Deskpro (i815)" [Medium,Confirmed]  https://launchpad.net/bugs/32716
<Ubugtu> New bug: #82095 in xorg-server (main) "nvidia resolution and 3d not initialised properly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82095
<Ubugtu> New bug: #82109 in xorg (main) "tablet stylus buttons default values are not the expected ones" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82109
<Ubugtu> New bug: #82110 in xorg (main) "xinput clients receive input even when the window manager is getting mouse input" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82110
<Ubugtu> New bug: #34700 in xkeyboard-config (main) "keyboard indicator does not have Nepali" [Medium,Unconfirmed]  https://launchpad.net/bugs/34700
<Ubugtu> New bug: #82132 in xserver-xorg-video-nv (main) "Auto-detect from live-cd ubuntu 6.10 isn't working correctly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82132
<Ubugtu> New bug: #80512 in xorg (main) "HP Nvidia GeForce Go 7400 laptop increase LCD brightness cause X to crash in Edgy" [Undecided,Needs info]  https://launchpad.net/bugs/80512
<Ubugtu> New bug: #79210 in xorg (main) "Wrong driver used after installing herd2 on M2NPV-VM" [Undecided,Needs info]  https://launchpad.net/bugs/79210
<Ubugtu> New bug: #45942 in linux-restricted-modules-2.6.15 (restricted) "AGP does't work with an SIS760 motherboard and a geforce 6200" [Medium,Unconfirmed]  https://launchpad.net/bugs/45942
<Ubugtu> New bug: #78860 in xorg (main) "Open source nvidia driver crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78860
<Ubugtu> New bug: #33504 in xserver-xorg-video-s3 (main) "Server failure with S3 86c764/765 [Trio32/64/64V+] " [Unknown,Unknown]  https://launchpad.net/bugs/33504
#ubuntu-x 2007-01-30
<Ubugtu> New bug: #34568 in xserver-xorg-video-s3 (main) "old s3 videocards never properly configured (dup-of: 33504)" [Medium,Confirmed]  https://launchpad.net/bugs/34568
<Ubugtu> New bug: #17613 in xserver-xorg-video-s3 (main) "[s3]  mode validation more strict than xfree86 version" [Medium,Rejected]  https://launchpad.net/bugs/17613
<Ubugtu> New bug: #40560 in xserver-xorg-video-s3 (main) "GDM session does not start (dup-of: 33504)" [Medium,Unconfirmed]  https://launchpad.net/bugs/40560
<Ubugtu> New bug: #35068 in xserver-xorg-video-s3virge (main) "Ubuntu hangs at logon screen" [Medium,Rejected]  https://launchpad.net/bugs/35068
<Ubugtu> New bug: #38846 in xserver-xorg-video-savage (main) "[ProSavage8]  slow and jerky, high CPU usage (dup-of: 39647)" [Medium,Needs info]  https://launchpad.net/bugs/38846
<Ubugtu> New bug: #82164 in Ubuntu "xorg.conf wrong default FontPaths (dup-of: 63408)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82164
<Ubugtu> New bug: #32415 in bluez-utils "Bluetooth Mouse and Keyboard Broken in Dapper/Edgy/Feisty" [Medium,Needs info]  https://launchpad.net/bugs/32415
<Ubugtu> New bug: #80611 in xorg (main) "Intel i965 doesn't have an appropriate driver " [Medium,Unconfirmed]  https://launchpad.net/bugs/80611
<Ubugtu> New bug: #80262 in xorg (main) "X does not start with SAM2 Abit NF-M2S NVidia 6100" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80262
<Ubugtu> New bug: #82320 in xorg (main) "Dell Latitude X200 display dpi detected incorrectly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82320
<Ubugtu> New bug: #56892 in linux-restricted-modules-2.6.15 (restricted) "Wireless on MacBook not activated easily..." [Medium,Unconfirmed]  https://launchpad.net/bugs/56892
<Ubugtu> New bug: #82372 in xserver-xorg-video-sis (main) "Problem with XVideo on sis 620 (530)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82372
<Ubugtu> New bug: #38555 in Ubuntu "usb mouse not properly initialized" [Medium,Fix released]  https://launchpad.net/bugs/38555
#ubuntu-x 2007-01-31
<Ubugtu> New bug: #45522 in notification-daemon (main) "XChat-gnome shows popups on wrong monitor" [Low,Needs info]  https://launchpad.net/bugs/45522
<Ubugtu> New bug: #82478 in xorg (main) "iBook monitor not selected automatically in X/KDE" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82478
<Ubugtu> New bug: #38198 in xorg "Garbled using open source Radeon driver" [Low,Confirmed]  https://launchpad.net/bugs/38198
<Ubugtu> New bug: #81994 in xkeyboard-config (main) "Japanese pc 106 keyboard closing curley brace is showing |" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81994
<Ubugtu> New bug: #81826 in Ubuntu "[feisty herd2]  [27.01.2007 i386-desktop]  screen cuts off after the steps battery state and local.rc ! (dup-of: 22985)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81826
<Ubugtu> New bug: #82434 in xserver-xorg-video-ati (main) "[rage]  Striped corner and mode switch failure" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82434
<Ubugtu> New bug: #72555 in linux-restricted-modules-2.6.17 (restricted) "ATI x700 fglrx-powered 3D accel works on Edgy using kernel *-386 but not *-generic" [Undecided,Unconfirmed]  https://launchpad.net/bugs/72555
#ubuntu-x 2007-02-01
<Ubugtu> New bug: #58171 in xorg (main) "Connection to ICE-unix/.. socket times out so programs take minutes to start" [Medium,Unconfirmed]  https://launchpad.net/bugs/58171
<Ubugtu> New bug: #73931 in xorg-server (main) "login in nested window dies changing workspace" [Medium,Unconfirmed]  https://launchpad.net/bugs/73931
<Ubugtu> New bug: #82659 in xserver-xorg-video-i810 (main) "Xorg crashes when using xinerama" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82659
<Ubugtu> New bug: #19133 in xserver-xorg-video-ati (main) "No video or Ubuntu fails to boot on G4 Towers after successful installation" [Medium,Rejected]  https://launchpad.net/bugs/19133
<Ubugtu> New bug: #21211 in xserver-xorg-video-nv (main) "When screensaver switch display off it never switch on again" [Medium,Rejected]  https://launchpad.net/bugs/21211
<Ubugtu> New bug: #24862 in xorg (main) "Manual tweaking needed to support a resolution of 1920x1200" [Medium,Fix released]  https://launchpad.net/bugs/24862
<Ubugtu> New bug: #33373 in xserver-xorg-video-ati (main) "Server failure with ATI Radeon RS100 (IGP320M)" [Medium,Rejected]  https://launchpad.net/bugs/33373
<Ubugtu> New bug: #44873 in xserver-xorg-driver-ati "Resolution in X will not go above 640x480 on Radeon X800" [Unknown,Confirmed]  https://launchpad.net/bugs/44873
#ubuntu-x 2007-02-02
<Ubugtu> New bug: #3406 in ksynaptics (universe) "ksynaptics not working in dapper/breezy" [Medium,Confirmed]  https://launchpad.net/bugs/3406
<Ubugtu> New bug: #78100 in xorg (main) "X fails after installing updates, black screen, locked" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78100
<Ubugtu> New bug: #14644 in xorg (main) "Runlevel 2 starting GUI" [Critical,Rejected]  https://launchpad.net/bugs/14644
<Ubugtu> New bug: #82783 in xvidtune (main) "NoDesktopFile:  xvidtune" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82783
<Ubugtu> New bug: #64672 in xfonts-100dpi (main) "these fonts do not work anymore (dup-of: 39560)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/64672
<Ubugtu> New bug: #21302 in xserver-xorg-video-via (main) "VIA UniChrome PRO IGP (K8N800) dosent work correctly." [Medium,Needs info]  https://launchpad.net/bugs/21302
<Ubugtu> New bug: #49782 in xserver-xorg-video-via (main) "Google Earth Beta 4 does not display properly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/49782
<Ubugtu> New bug: #82875 in xorg (main) "xorg hangs on boot (feisty)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82875
<Ubugtu> New bug: #82902 in xinit (main) "20xorg-common_process-args doesn't work with zsh" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82902
<Ubugtu> New bug: #82903 in xinit (main) "20xorg-common_process-args doesn't work with zsh" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82903
#ubuntu-x 2007-02-03
<Ubugtu> New bug: #38243 in control-center (main) "Dapper: Window properties no longer has an option for <Super>" [Medium,Unconfirmed]  https://launchpad.net/bugs/38243
<Ubugtu> New bug: #37444 in xserver-xorg-driver-ati "RandR stops working with MergedFB when the external display is disconnected" [Unknown,Confirmed]  https://launchpad.net/bugs/37444
<Ubugtu> New bug: #32963 in xserver-xorg-driver-i810 "Xv movies on 810/i945 gives horrible color, Gamma" [Unknown,Needs info]  https://launchpad.net/bugs/32963
<Ubugtu> New bug: #34727 in linux-restricted-modules-2.6.20 (restricted) "glxgears -fullscreen renders incorrectly." [Medium,Needs info]  https://launchpad.net/bugs/34727
<Ubugtu> New bug: #30447 in xserver-xorg-video-ati "Lockup problems with both the free xorg ATI driver and the proprietary fglrx driver, using various ATI cards" [High,Confirmed]  https://launchpad.net/bugs/30447
<Ubugtu> New bug: #82995 in xorg (main) "Screen Resolution shows wrong refresh rates" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82995
<Ubugtu> New bug: #83002 in xserver-xorg-input-mouse (main) "ubuntu-desktop doesnt depend on xserver-xorg-input-all anymore" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83002
<Ubugtu> New bug: #83036 in luit (universe) "[apport]  luit crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83036
<Ubugtu> New bug: #83056 in xorg (main) "xorg regression: Keyboard not working after reboot, color-dirt on login screen" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83056
<Ubugtu> New bug: #83072 in xorg (main) "Skewed screen - Mobility Radeon X1450 with vesa (only feisty, edgy; dapper is ok)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83072
<Ubugtu> New bug: #36492 in xkeyboard-config (main) "french symbols map for macintosh is incomplete" [High,Confirmed]  https://launchpad.net/bugs/36492
#ubuntu-x 2007-02-04
<Ubugtu> New bug: #83147 in mesa-utils (main) "[apport]  glxinfo crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83147
<Ubugtu> New bug: #83207 in xserver-xorg-input-synaptics (main) "Synaptics Touchpad occasionally blocked" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83207
<Ubugtu> New bug: #83226 in linux-restricted-modules-2.6.15 (restricted) "ati driver proces 'atieventsd' takes 100% CPU" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83226
<Ubugtu> New bug: #36306 in xserver-xorg-video-i810 (main) "dapper: intel 945 runs 640x480" [Medium,Confirmed]  https://launchpad.net/bugs/36306
<Ubugtu> New bug: #3731 in xorg (main) "Xorg can't load another resolution" [Medium,Needs info]  https://launchpad.net/bugs/3731
<Ubugtu> New bug: #83126 in abiword (main) "Incorrect keyboard mapping used for shortcuts when xorg.conf's "XkbLayout" has multiple mappings. (dup-of: 23244)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83126
<Ubugtu> New bug: #27541 in xserver-xorg-input-synaptics (main) "Touchpad should block while typing" [Wishlist,Confirmed]  https://launchpad.net/bugs/27541
<Ubugtu> New bug: #37980 in compiz (universe) "Errors __GLcontextMode in x86_64 version of fglrx drivers" [Medium,Needs info]  https://launchpad.net/bugs/37980
<Ubugtu> New bug: #74395 in ndiswrapper (restricted) "Fail to build fglrx module" [Undecided,Unconfirmed]  https://launchpad.net/bugs/74395
#ubuntu-x 2008-01-28
<ubotu> New bug: #182599 in xserver-xorg-driver-via (universe) "x crashes when using kde4.0 not with kde 3.5.8 " [Undecided,New] https://launchpad.net/bugs/182599
<ubotu> New bug: #186523 in xserver-xorg-video-amd (main) "Please sync xserver-xorg-video-amd (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/186523
<ubotu> New bug: #186540 in linux-restricted-modules-2.6.22 "NVidia and Intel wireless driver should have separate restricted-* packages" [Undecided,New] https://launchpad.net/bugs/186540
<ubotu> New bug: #186589 in xserver-xorg-video-ati (main) "X freezes frequently with ati on Radeon 9800 PRO" [Undecided,New] https://launchpad.net/bugs/186589
<ubotu> New bug: #186698 in ubuntu "X applications lose keyboard input sporadically (dup-of: 66104)" [Undecided,New] https://launchpad.net/bugs/186698
<ubotu> New bug: #123388 in ubuntu "Mouse Pointer goes invisible after Re-login (dup-of: 63905)" [Undecided,New] https://launchpad.net/bugs/123388
<ubotu> New bug: #186764 in xorg (main) "GoogleEarth leads into "drmWaitVBlank returned -1" error" [Undecided,New] https://launchpad.net/bugs/186764
<ubotu> New bug: #180755 in ubuntu "touchpad scrolling gone in hardy (dup-of: 173411)" [Undecided,Confirmed] https://launchpad.net/bugs/180755
<ubotu> New bug: #183911 in xorg-driver-synaptics "[Hardy] synaptics touchpad not recognized / detected (dup-of: 173411)" [Undecided,New] https://launchpad.net/bugs/183911
<ubotu> New bug: #185437 in xorg-driver-synaptics "No touchpad scrolling in Hardy Alpha 3 (dup-of: 173411)" [Undecided,New] https://launchpad.net/bugs/185437
<ubotu> New bug: #186783 in xserver-xorg-video-nv (main) "Please sync a new version from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/186783
<ubotu> New bug: #186659 in xorg (main) "Conflict with Graphic Card In Kubuntu&Edubuntu" [Undecided,New] https://launchpad.net/bugs/186659
#ubuntu-x 2008-01-29
<tjaalton> bryce: so, should be switch -intel to XAA for alpha4?
<ubotu> New bug: #186928 in xdm (universe) "Please sync a new version from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/186928
<ubotu> New bug: #186930 in xinit (main) "Please sync a new version from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/186930
<tjaalton> hmm, mesa not listed on the versions_current
<tjaalton> ..page
<pwnguin> fyi, it looks like wacom-tools might break X as currently packaged =(
<ubotu> New bug: #186932 in xserver-xorg-video-mga (main) "Please sync a new version from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/186932
<tjaalton> pwnguin: tell the debian maintainer (ron lee) to package the latest version
<pwnguin> indeed
<pwnguin> how do you tell a debian developer what to do?
<tjaalton> file a bug :)
<pwnguin> theres already a bug filed saying it causes crashes and the new version fixes that
<tjaalton> so he's just lazy
<pwnguin> I guess
<pwnguin> im not sure how much debian patches linux wacom
<pwnguin> or i'd probably give it a shot myself
<tjaalton> I'll update it today
<pwnguin> you're a hero
<tjaalton> bah, doesn't build
<tjaalton> for some reason it doesn't -I../../../src/xdrv so it fails
<tjaalton> strange, the Makefile has -I$(srcdir)
<tjaalton> $(CC) -MM $(CFLAGS) $(DEPFLAGS) $(DRIVER_INCLUDES) $(XF86OBJS:%.o=%.c) > .depend
<tjaalton> that fails, because XF86OBJS expands as "file1.c file2.c.." without paths
<tjaalton> so.. I'll leave it to Ron then :)
<Ng> out of interest, how are things looking on the -intel, EXA and TTM fronts? :)
<tjaalton> no news :/
<Ng> shucks
<tjaalton> I've noticed that there have been commits on mesa/drm/intel git about it, and I should try it out again
<tjaalton> maybe later this week
<tjaalton> uploaded a new -intel which contains all the fixes from 2.2-branch
<Ng> cool
<ubotu> New bug: #187007 in xserver-xorg-video-suntcx (main) "sync request" [Undecided,New] https://launchpad.net/bugs/187007
<bryce> morning tjaalton
<bryce> tjaalton: I've talked with most everyone about EXA vs. XAA and that we're likely to need to go with XAA.  I think most people will accept it
<bryce> after discussing it, most people thought it was the correct tradeoff to be making
<bryce> tjaalton: I'm thinking though, that perhaps we should write up a Hardy driver status page, explaining the current state, what doesn't work, what's improved, etc.
<tjaalton> bryce: ok, I already uploaded a new package but didn't change that yet
<tjaalton> yep
<bryce> looking into why mesa isn't on the versions page...
<tjaalton> wow, drivers getting deprecated
<tjaalton> about time
<bryce> ah, mesa is the source package, but not what's installed.  hrm
<bryce> libgl1-mesa-dri?
<bryce> ah libgl1-mesa-dev would be better
<bryce> hrm
<bryce> tjaalton: looks like mesa uses sourceforge as its download site.  I've found SF notoriously difficult to maintain screen scrapers for.  
<tjaalton> oh right
<bryce> investigating if we can at least pull in the debian version info
<tjaalton> like libdrm
<bryce> hrm, this is proving thorny
<bryce> oohhhh
<bryce> tjaalton: fixed http://people.ubuntu.com/~bryce/Xorg/versions_current.html
<tjaalton> nice :)
<bryce> tjaalton: over the next few weeks I'm going to focus on fixing our gui x config setup
<bryce> tjaalton: colin and I talked about this friday, and he agreed it should be my high priority through to FF
<bryce> our current config tools are hopelessly broken at the moment, and not in a release-worthy state
<bryce> I've exchanged a couple emails with glatzor but unfortunately he appears to be extremely busy
<tjaalton> ok, I've wondered where he's been :)
<bryce> it seems he's moved to night shifts again
<ubotu> New bug: #144068 in xorg (main) "X graphical interface not loading." [Undecided,New] https://launchpad.net/bugs/144068
<ubotu> New bug: #184073 in xorg-server (main) "xserver-xorg-core 2:1.3.0.0.dfsg-ubuntu8.1 Gutsy AMD64 update is 403 forbidden" [Undecided,New] https://launchpad.net/bugs/184073
#ubuntu-x 2008-01-30
<pwnguin> anyone care to describe what this means?
<pwnguin> pushed as d954f9c80348de294602d931d387e5cd1ef4b9a5
<pwnguin> from x.org bugzilla
<pwnguin> http://bugs.freedesktop.org/show_bug.cgi?id=13961
<ubotu> Freedesktop bug 13961 in Server/general "xkbLEDs causes segfault on login" [Critical,Resolved: fixed] 
<ubotu> New bug: #187240 in linux-restricted-modules-2.6.24 (restricted) "NVidia driver and kernel module driver mismatch" [Undecided,New] https://launchpad.net/bugs/187240
<tjaalton> pwnguin: http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=d954f9c80348de294602d931d387e5cd1ef4b9a5
<tjaalton> it's not on the 1.4-branch though
<tjaalton> bryce: the reporter is not subscribed on bug 144068 :)
<ubotu> Launchpad bug 144068 in xorg "X graphical interface not loading." [Undecided,Invalid] https://launchpad.net/bugs/144068
<tjaalton> so maybe just close it as invalid (it's nvidia blob related anyway)
<seb128> hum
<seb128> is xorg eating modifiers every now and then a known issue?
<tjaalton> seb128: you mean that the special keys don't work?
<tjaalton> ctrl,alt,shift..
<seb128> yes, that's not called modifiers?
<tjaalton> I guess they are :)
<seb128> looks like it keeps generating this event when that happens
<seb128> KeyRelease event, serial 31, synthetic NO, window 0x2e00001,
<seb128>     root 0x69, subw 0x0, time 11773833, (167,-13), root:(174,41),
<seb128>     state 0x2000, keycode 101 (keysym 0x0, NoSymbol), same_screen YES,
<seb128>     XLookupString gives 0 bytes: 
<seb128>     XFilterEvent returns: False
<tjaalton> I haven't seen that but I've been using evdev.. gues there's a bug open for that
<ubotu> New bug: #44912 in xorg (main) "Default desktop is too cpu hungry when idle." [Medium,Confirmed] https://launchpad.net/bugs/44912
<ubotu> New bug: #187365 in xserver-xorg-video-intel (main) "Xorg 7.3 with Intel does not display maximum resolution anymore" [Undecided,New] https://launchpad.net/bugs/187365
<bryce> tjaalton: that sounds fine
<bryce> tjaalton: fwiw, now that triaged bugs are at 0 New, I've turned attention to Incomplete bugs with a response, and have begun working my way through them
<bryce> (starting with some old ones -- so if you notice reports that are invalid or whatever, please feel free to handle accordingly)
<tjaalton> bryce: ok, cool
<tjaalton> I noticed that there are at least two mesa patches upstream that affect some compiz related crashes, but they are not on the stable branch for some reason
<pwnguin> heh
<pwnguin> "And it turns out null-pointer dereferences are bad."
<tjaalton> yeah, that was one of them :)
<ubotu> New bug: #186017 in linux-restricted-modules-2.6.24 (restricted) "kaffeine-xine crashed with ATI Radeon official drivers" [Undecided,New] https://launchpad.net/bugs/186017
<pwnguin> tjaalton: so uh, do i need to back/forward port the patch?
<tjaalton> pwnguin: the xkbLED patch?
<pwnguin> yea
<tjaalton> ask if it could be included in the 1.4-branch
<tjaalton> that's the best approach imho
<bryce> tjaalton: hey btw, colin and I were wondering what further work is needed for input support / hal?
<bryce> tjaalton: if there's work still needed, I want to set aside some time to assist with that
<tjaalton> bryce: gravity has some patches that would make it use the configuration on xorg.conf
<tjaalton> so no need to edit some bizarre fdi file
<tjaalton> he hasn't published them yet afaik
<tjaalton> but please poke him about it :)
<bryce> ok
<bryce> aside from that, is the autoconfiguration of input devices all squared away, or is there more feature development work needed?
<bryce> or are we back to just bug squishing?
<pwnguin> does that mean i wouldnt need an xorg.conf for say, wacom?
<bryce> pwnguin: yes that's the intent
<tjaalton> actually, that depends on how the wacom driver is doing
<tjaalton> bryce: mjg59 said once that synaptics needs some love, and he promised to do something about it but I don't know if he's had the time yet
<bryce> ok, maybe we should follow up with him
<tjaalton> it was before christmas though :)
<bryce> in fact he was at the sprint in london for one day last week
<tjaalton> and now at LCA
<bryce> ted asked him some questions about reusing the synaptics approach for configuring wacom and other things
<bryce> he was talking about needing an X extension similar to xrandr, but for input devices, in order to do all this stuff right
<bryce> hrm, which I'd taken notes
<bryce> ok, I'll follow up with him at some point.  I suspect this is going to take more time than we have for hardy
<tjaalton> yeah
<bryce> btw, I've had some emails with glatzor, mpt, and others to get the plans sorted out for the xrandr gui tool
<seb128> hey bryce
<bryce> heya seb128
<tjaalton> bryce: cool, right now it's pretty useless :/
<seb128> bryce: didn't you read my comment before?
<bryce> seb128: oh I must have missed it
<bryce> seb128: btw, I got confirmation regarding your advice on gnome-control-center preferring C - http://mail.gnome.org/archives/gnomecc-list/2007-November/msg00043.html
<bryce> seb128: sorry, could you repeat the comment?
<seb128> bryce: no, I switched computer since, basically that's modifier not working every now and then, I think that's an xorg issue
<tjaalton> yes, I'll dig up the bug
<seb128> when that happens the cursor is directly hidden in widget that do that on key events
<seb128> and xev confirm that xorg seems to generate continuous events
<seb128> I copied the xev event on the chan, I've it on my laptop and can attach it to a bug or copy it again later if required
<bryce> seb128: ah ok; sorry technically I'm on holiday today so am trying not to work (it's hard!) but I'll look into it tomorrow after I finish more ubuntu-mobile stuff, if you can send me the bug
<seb128> ups, sorry
<seb128> technically I've finished my work day ;-)
<seb128> right
<seb128> let me know when you look at it, there is no hurry
<seb128> I'm just hanging around in case of one of the late GNOME 2.21.90 upload is an issue for the CD build
<bryce> cool
<tjaalton> 17:31 < seb128> looks like it keeps generating this event when that happens
<tjaalton> 17:31 < seb128> KeyRelease event, serial 31, synthetic NO, window 0x2e00001,
<tjaalton> 17:31 < seb128>     root 0x69, subw 0x0, time 11773833, (167,-13), root:(174,41),
<tjaalton> 17:31 < seb128>     state 0x2000, keycode 101 (keysym 0x0, NoSymbol), same_screen YES,
<tjaalton> 17:31 < seb128>     XLookupString gives 0 bytes: 
<tjaalton> 17:31 < seb128>     XFilterEvent returns: False
<bryce> yeah I plan to spend today on getting inkscape further along for the release :-)
<seb128> tjaalton: thanks
<bryce> ok, got it, I'll investigate more tomorrow
<seb128> thanks
<seb128> I'm using compiz there in case that's revelant, I'll try without it if that happens
<bryce> oh btw, is there a LP# for this?
<tjaalton> I bet there is
<seb128> not from me, but Hobbsee mentionned she has a such issue for some time and somebody else too
<seb128> I doubt that's due to the wm, I tried switching to no desktop effect and activating the option again and that didn't fix it
<bryce> ok, I'll search if someone already put in a report.  I may ask for your Xorg.0.log and xorg.conf later
<seb128> so that looks like an xorg issue
<seb128> sure
<seb128> I'll copy those next time I run into the bug
<bryce> maybe check ~/.xsession-errors too, just in case
<seb128> ok
<seb128> will do that tomorrow, I doubt I'll work enough to trigger it again today ;-)
<bryce> seb128: btw, I was looking at some dejavu font issues yesterday.  Is that package owned by Arne?  
<seb128> nobody owns package in ubuntu ;-)
<bryce> it appears some of his patches from Gutsy were not ported forward to Hardy, so there were regressions
<bryce> ahh, "Is he the person that normally would keep an eye on that package?"
<seb128> I don't think arne did lot of packaging changes yet but he's the fonts contact, so if you have any change to do there might be a good idea to talk to him first
<bryce> ok good, I described the solution for the user reporting the problem and asked that he contact arne about it
<tjaalton> seb128: so the modifier key is 'stuck' for a while?
<seb128> the events seem to be loop generated or something like that
<seb128> I've looked to the logs but there was nothing obvious there
<tjaalton> I can't find any bugs with that description on LP
<tjaalton> hehe, freedesktop bug 13538
<ubotu> Freedesktop bug 13538 in Server/general "staggering server memory leak" [Blocker,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=13538
<ubotu> New bug: #97107 in gnome-screensaver (main) "Braid screensaver cause desktop to freeze up (dup-of: 101943)" [Medium,Triaged] https://launchpad.net/bugs/97107
<ubotu> New bug: #187430 in xkeyboard-config (main) "New Variant/Layout for symbols/ca - shs" [Undecided,New] https://launchpad.net/bugs/187430
#ubuntu-x 2008-01-31
<pwnguin> tjaalton: thanks for the tip. bc72ef3a159efd67067322c043bba444869dc356 contains the patch
<tjaalton> pwnguin: cool, so it'll be in hardy before too long
<tjaalton> bryce: check the video blog entry by john palmieri on planet.fd.o
<tjaalton> fedora has some config tool for configuring X, with multiple heads even
 * Ng tsks, imho this stuff shouldn't be tool based, it should be event based. "hey, I detect a new monitor, select which display you want to clone/extend" :)
<jcristau> Ng: there's no such event
<jcristau> vga or tv load detection causes flicker, so you don't want to do that every second
<Ng> I didn't say it was possible ;)
<Ng> but if xrandr --auto can know that I have a VGA monitor on my laptop or not, it suggests that (perhaps with hardware modifications) it ought to be possible to have a non-polling solution
<Ng> no ordinary user wants to go digging around in a display configurmatron, is my basic point :)
<ubotu> New bug: #182189 in ubuntu "ACPI vs Radeon M6: Thinkpad X23 suspend issue (dup-of: 148408)" [Undecided,New] https://launchpad.net/bugs/182189
<tjaalton> of course the default is to just use the new display, that's what the video demonstrates, but the tool that they use to statically force some settings is what I was pointing out :)
<ubotu> New bug: #178061 in xorg (main) "*** Error: couldn't find any ServerLayout sections" [High,Confirmed] https://launchpad.net/bugs/178061
<ubotu> New bug: #187634 in linux-restricted-modules-2.6.24 (restricted) "package linux-restricted-modules-2.6.24-5-generic None failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1)" [Undecided,New] https://launchpad.net/bugs/187634
<ubotu> New bug: #187635 in nautilus (main) "package nautilus-data 1:2.21.90-0ubuntu1 failed to install/upgrade: subprocess post-installation script returned error exit status 1 (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/187635
<ubotu> New bug: #187638 in nautilus-sendto (main) "package nautilus-sendto 0.13.1-0ubuntu1 failed to install/upgrade: unable to fill /var/lib/dpkg/updates/tmp.i with padding (dup-of: 187634)" [Undecided,Incomplete] https://launchpad.net/bugs/187638
<ubotu> New bug: #187641 in wine (universe) "package wine 0.9.54-0ubuntu3 failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1) (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/187641
<ubotu> New bug: #187628 in evince (main) "package evince 2.21.90-0ubuntu1 failed to install/upgrade: subprocess new post-removal script returned error exit status 1 (dup-of: 187634)" [Undecided,Incomplete] https://launchpad.net/bugs/187628
<ubotu> New bug: #187630 in gimp (main) "package gimp-data 2.4.3-1ubuntu1 failed to install/upgrade: subprocess new post-removal script returned error exit status 1 (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/187630
<ubotu> New bug: #187631 in libcairo-ruby (universe) "package libcairo-ruby1.8 None [modified: /var/lib/dpkg/info/libcairo-ruby1.8.list] failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1) (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/187631
<ubotu> New bug: #187632 in linux (main) "package linux-headers-2.6.24-5 None [modified: /var/lib/dpkg/info/linux-headers-2.6.24-5.list] failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1) (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/187632
<ubotu> New bug: #187639 in openoffice.org (main) "package openoffice.org-core 1:2.3.1-3ubuntu3 failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1) (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/187639
<ubotu> New bug: #187640 in scribus-ng (universe) "package scribus-ng None failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1) (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/187640
<seb128> mvo: ^ see what the apt apport thing do ;-)
<mvo> seb128: meh, maybe it should be limited to a single report for all failures
<mvo> seb128: I think that is what I'm going to do
<seb128> that would be nice
<ubotu> New bug: #155785 in xboard (universe) "package xboard None [modified: /var/lib/dpkg/info/xboard.list] failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1) (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/155785
<ubotu> New bug: #177987 in pexpect (main) "package python-pexpect None [modified: /var/lib/dpkg/info/python-pexpect.list] failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1) (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/177987
<ubotu> New bug: #178009 in imagemagick (main) "package imagemagick 7:6.2.4.5.dfsg1-2ubuntu1 failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1) (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/178009
<ubotu> New bug: #155790 in xchat (universe) "package xchat-common None [modified: /var/lib/dpkg/info/xchat-common.list] failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1) (dup-of: 187634)" [Medium,New] https://launchpad.net/bugs/155790
<seb128> bryce: hi
<seb128> bryce: my laptop is in broken keyboard state again if you are interested in debugging it
<ubotu> New bug: #187680 in ubuntu "[Hardy] Minefield (Firefox) renders transparent or scaled images incorrectly or not at all (dup-of: 182038)" [Undecided,New] https://launchpad.net/bugs/187680
<mvo_> bryce: is it known that the failsafe mode for X is not working?
<tjaalton> mvo_: not working in what sense?
<ubotu> New bug: #187748 in openoffice.org (main) "package openoffice.org-core 1:2.3.1-3ubuntu3 failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1) (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/187748
<ubotu> New bug: #187749 in wine (universe) "package wine 0.9.54-0ubuntu3 failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1) (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/187749
<bryce> mvo, yes, I'm aware there's a number of things not working with it, most fundamentally displayconfig-gtk no longer can deal with xorg.conf as they're currently written
<bryce> bbiab
<mvo_> bryce, tjaalton: on the life-cd in a VM I get the X failed to start dialog box. when I click "continue" then X shuts down 
<mvo_> it maybe specific to the live-cd
<mvo_> or the VM
<tjaalton> ok, that's new
<tjaalton> I guess
<tjaalton> it didn't work before either, but still :)
<mvo_> heh :)
<mvo_> ok, sorry for not being more helpful
<tjaalton> I'll test that myself before too long
<seb128> re
<bdmurray> bryce: I've submitted bug 187846 is that a driver or compiz bug?
<ubotu> Launchpad bug 187846 in compiz "glxgears artifacts when dragging window around with compiz enabled" [Undecided,New] https://launchpad.net/bugs/187846
<bryce> bdmurray: -intel bug, not a compiz bug
<bryce> bdmurray: also, please check the -intel bugs, as there was another one like that filed.  However it was against 965 iirc, so may not be dupe-able
<bdmurray> okay, I've changed the package then
<ubotu> New bug: #187846 in xserver-xorg-video-intel (main) "glxgears artifacts when dragging window around with compiz enabled" [Undecided,New] https://launchpad.net/bugs/187846
<bryce> bdmurray: also, I'd appreciate it if when you put bugs into an xorg component, that you ask them to attach /var/log/Xorg.0.log, /etc/X11/xorg.conf, and lspci -vvnn output
<bryce> bdmurray: it'd save us an extra step in triaging
<bdmurray> okay
<seb128> got the keyboard bug again, anybody interested to debug it before i restart xorg,
<bdmurray> bryce: Do you want those same bits for the bug on the live cd I just filed?
<seb128> that is supposed to be a question but without modified there is some limitation ;-)
<bryce> seb128: sure, I've just finished the ubuntu-mobile work and am ready to re-task
<bryce> seb128: however I'm not certain what approach to take for debugging it yet
<seb128> k
<bryce> bdmurray: yes; in fact by default generally all xorg bugs need those three things.
<seb128> i confirm that xorg see this key event i mentionned yesterday in continuous
<seb128> that breaks modifiers use and make applications open in background
<bryce> bdmurray: in fact, my fingers now type out requests for those files in my sleep
<bdmurray> bryce: you mentioned a similar issue in bug 147359 what model video card did you notice it with?
<ubotu> Launchpad bug 147359 in xserver-xorg-video-intel "intel 3D artifacts" [Medium,In progress] https://launchpad.net/bugs/147359
<bryce> seb128: ok; did we identify any existing bug id#'s for this?  that's probably step #1
<bryce> bdmurray: 965
<tjaalton> bryce: I couldn't find one
<bryce> tjaalton: ok thanks
<seb128> bryce: no
<seb128> should i open one
<bdmurray> bryce: and I have 945 so is my bug a duplicate?
<seb128> sorry about the limited punctuation, azerty without modifier is funny
<bryce> bdmurray: I'd keep it separate.  There's actually a significant difference in the driver between 915-945, and 965
<bdmurray> okay
<jcristau> missing redirected direct rendering is not a driver issue, though
<bryce> seb128: can you open a bug in LP and attach your /var/log/Xorg.0.log, /etc/X11/xorg.conf, lspci, and ~/.xsession-errors?
<seb128> bryce: ok
<bdmurray> bryce: The reason I was testing this is because it is listed as test case.  Perhaps it shouldn't be?
<bryce> no, it's a good test case
<bryce> running glxgears and moving it around turns up a variety of bugs
<bryce> unfortunately probably not bugs we can easily do something about yet
<bdmurray> perhaps the test case should have a note about bug 147359 then?
<ubotu> Launchpad bug 147359 in xserver-xorg-video-intel "intel 3D artifacts" [Medium,In progress] https://launchpad.net/bugs/147359
<bryce> bdmurray: sure
<bdmurray> And this only happens when compiz is enabled right?
<jcristau> yes
<bdmurray> thanks jcristau
<bdmurray> bryce: I've updated the bug summary then
<bryce> bdmurray: thanks
<seb128> bryce: https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/187855
<ubotu> Launchpad bug 187855 in xorg "keyboards events generated wrongly create issues" [Undecided,New] 
<bryce> seb128: thanks... reviewing
<seb128> bryce: nothing interesting in xsession-errors
<seb128> is the lspci useful for keyboard issue,
<bryce> seb128: ok
<seb128> that's a dell latitude
<seb128> cant type numbers without shift ;-)
<bryce> seb128: feel free to reboot; I think this is enough info for now.  I'll need to do some research before I have more troubleshooting advice
<seb128> k
<seb128> i did restart the g-s-d and compiz that makes no difference
<seb128> and i'm pretty sure there is no key stucked on this keyboard
<ubotu> New bug: #187855 in xorg (main) "keyboards events generated wrongly create issues" [Undecided,New] https://launchpad.net/bugs/187855
<ubotu> New bug: #187850 in compiz (main) "intel x3100: screen artifacts (dup-of: 175774)" [Undecided,New] https://launchpad.net/bugs/187850
<ubotu> New bug: #185063 in xserver-xorg-video-ati (main) "[hardy] ATI Resctricted Drivers cause pc to block on reboot." [Undecided,Incomplete] https://launchpad.net/bugs/185063
<bryce> seb128: found your bug in debian bts:  http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/2dfb33a5ec826ea2/7a160deb430814b6?lnk=gst&q=keyboard+modifier#7a160deb430814b6
<seb128> bryce: might be the same issue indeed
<bryce> I'll summarize some of the findings from the parent bug report, for testing
<Q-FUNK> Praha, here we come! :)
#ubuntu-x 2008-02-01
<ubotu> New bug: #187906 in xserver-xorg-video-sis (main) "Screen corruption on low resolutions: xserver-xorg-video-sis" [Undecided,New] https://launchpad.net/bugs/187906
<ubotu> New bug: #187967 in xserver-xorg-video-ati (main) "[regression][M6 LY] blue box instead of video output" [Undecided,New] https://launchpad.net/bugs/187967
<ubotu> New bug: #187808 in xserver-xorg-video-ati (main) "driver ati CTRL+ALT+DEL doesn't work" [Undecided,New] https://launchpad.net/bugs/187808
<ubotu> New bug: #188014 in xserver-xorg-video-intel (main) "[hardy] intel driver wants to use resolution 1280x768 instead of 1024x768 (i830m)" [Undecided,New] https://launchpad.net/bugs/188014
<ubotu> New bug: #186643 in xserver-xorg-driver-ati (main) "Radeon treiber in Gutsy unterstÃ¼tzt nicht Grafikkarte Radeon 8500" [Undecided,New] https://launchpad.net/bugs/186643
<ubotu> New bug: #9379 in xorg-server (main) "Xnest default size messed up with Xinerama" [Medium,Confirmed] https://launchpad.net/bugs/9379
<Q-FUNK> oh lovely. 
<Q-FUNK> it turns out that the linuxbios guys also have a fork of vm86 and of x86emu. 
<Q-FUNK>  they have apparently asked the X.org team if they could be persuaded to maintian only one tree and to do it jointly. "yeah, maybe we should do it, one day..."
<Q-FUNK> *sigh*
<ubotu> New bug: #188115 in libx11 (main) "XkbGetKeyboard no longer reporting correct keyboard geometry" [Undecided,New] https://launchpad.net/bugs/188115
<ubotu> New bug: #174756 in xserver-xorg-video-intel "Inspiron 1420: Intel GM965 s-video TV-out shows wrong colors on Ubuntu 7.10" [Undecided,New] https://launchpad.net/bugs/174756
<ubotu> New bug: #188152 in linux-restricted-modules-2.6.24 (restricted) "aticonfig crashes" [Undecided,New] https://launchpad.net/bugs/188152
<ubotu> New bug: #188178 in xserver-xorg-video-intel (main) "xserver-xorg-video-intel: 945GM always crashes within 10 seconds of login" [Undecided,New] https://launchpad.net/bugs/188178
<bryce> wow, intel finally released their gfx driver manuals 8-)
<tjaalton> yep
#ubuntu-x 2008-02-02
<Q-FUNK> how do i add a link to the upstream bug, in launchpad?
<bryce> Q-FUNK: click on 'Also affects <Project>'
<bryce> for packages that have already been linked to an upstream bug tracker, you can just paste in the bug tracker URL at that point
<bryce> if it's not been configured, there's some extra one-time steps, that I think are fairly straightforward, but I'd be happy to take care of it for you if you'd prefer.
<Q-FUNK> also affects project seems to want a project hosted on launchpad
<Q-FUNK> see Bug #140051
<ubotu> Launchpad bug 140051 in xserver-xorg-video-amd "xf86-video-amd: fails to autoconfigure" [High,Triaged] https://launchpad.net/bugs/140051
<Q-FUNK> I ended up pasting it in in an ugly way, by marking debin as also affected
<bryce> ah, yes -amd needs configured... stand by
<bryce> there we go
<Q-FUNK> ah!
<Q-FUNK> ok, looks more clear now
<Q-FUNK> thanks!
<bryce> sure
<Q-FUNK> http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=history;h=e8334262e4beadda794317b1fddd5dfe39795f6f;hb=1692dcf197470d074f69d5af1608cb2ff1d08872;f=hw/xfree86/int10/helper_exec.c
<bryce> checking to see if I can make it automatically file against that
<Q-FUNK> I was looking at the history for the file we patch.
<Q-FUNK> this is what i found
<Q-FUNK> 2 main guys seem to be modifying this, every once in a while. we need them to either merge or reject the patches.
<Q-FUNK> bryce: although actually, upstream, bart's patches really need to go against xserver.
<Q-FUNK> in fact, it could be a good idea to reassign 140051 to xserver-xorg-core
<bryce> we can set it to also-affects... one sec
<bryce> okay there we go.  Now when you click on 'Also affects project' for -amd ubuntu bugs, it just gives the URL to paste the bug in
<Q-FUNK> ah, ok
<bryce> you should be set with that now
<bryce> ok, added an xserver component as well
<Q-FUNK> it seems that filing upstream got them to react and assign it as a blocker for 1.5
<Q-FUNK> at least, that's progress. we got their attention.
<Q-FUNK> bryce: has the patch been merged for Hardy, beyond your test packages?
<bryce> not as far as I know
<Q-FUNK> ok
<bryce> how much testing is it getting so far?  
<Q-FUNK> I have it on my laptop running -siliconmotion.  no averse effect, so far.
<Q-FUNK> 1.4 that is
<Q-FUNK> 1.3 is in my LTSP chroot on Gutsy, on my LTSP server.
<Q-FUNK> again, no averse effect, so far
<Q-FUNK> bryce: can you attach your 1.4 patches to the upstream bug?
<bryce> tjaalton: you about still?
<bryce> tjaalton: when you get back, would you mind pushing this change up for Hardy main?  http://people.ubuntu.com/~bryce/Uploads/xorg-server_1.4.1~git20080118-1ubuntu3_source.changes
<bryce> tjaalton: this is the change that includes Q-FUNK and bartman's -amd patches.  Sounds like they've gotten adequate testing, so should be ready for adding to hardy
<bryce> tjaalton: these are for bug 140051
<ubotu> Launchpad bug 140051 in xorg-server "xf86-video-amd: fails to autoconfigure" [High,In progress] https://launchpad.net/bugs/140051
<ubotu> New bug: #188249 in xserver-xorg-video-ati (main) "Radeon xserver shows corrupt display on X startup (IGP330/340/350 chipset)" [Undecided,New] https://launchpad.net/bugs/188249
<tjaalton> bryce: sure
<tjaalton> bryce: you can push them to git :)
<bryce_> hey, I made a ton of progress today on the xrandr 1.2 coding stuff
<tjaalton> displayconfig-gtk?
<bryce_> libxrandr actually.  migrating some common logic into it from xrandr.
<tjaalton> just for fun?-)
 * tjaalton crosses fingers, reboot time
<ubotu> New bug: #188279 in xorg (main) "[Guts] xserver crashs with vlc xv not use shared memory" [Undecided,New] https://launchpad.net/bugs/188279
<tjaalton> huh, how did I end up having a -386 kernel
<tjaalton> hangs on boot
<ubotu> New bug: #187825 in libcairo-ruby (universe) "package libcairo-ruby1.8 None [modified: /var/lib/dpkg/info/libcairo-ruby1.8.list] failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1) (dup-of: 187634)" [Undecided,New] https://launchpad.net/bugs/187825
<ubotu> New bug: #151141 in restricted-manager "When switching from nv to nvidia driver lose screen resolution; nvidia doesn't use EDID freq. data even though that data is correct" [Undecided,Confirmed] https://launchpad.net/bugs/151141
<ubotu> New bug: #188305 in linux-restricted-modules-2.6.24 (restricted) "[fglrx] xorg-driver-fglrx not properly installed" [Undecided,New] https://launchpad.net/bugs/188305
<ubotu> New bug: #183582 in xserver-xorg-video-nv (main) "Ubuntu 7.10 fails to install on ThinkPad T61p" [Undecided,Incomplete] https://launchpad.net/bugs/183582
<ubotu> New bug: #188342 in xserver-xorg-input-keyboard (main) "keymap fr: numpad '.' mapped to period instead of KP_Decimal" [Undecided,New] https://launchpad.net/bugs/188342
<ubotu> New bug: #188351 in xorg (main) "[Hardy] External mouse on laptop will only double-click" [Undecided,New] https://launchpad.net/bugs/188351
<ubotu> New bug: #188409 in linux-restricted-modules-2.6.24 (restricted) "xorg.conf generated by fglrx doesn't work" [Undecided,New] https://launchpad.net/bugs/188409
<ubotu> New bug: #188449 in xorg (main) "[hardy] broken keyboardlayout by using serverlayout in xorg.conf" [Undecided,New] https://launchpad.net/bugs/188449
#ubuntu-x 2008-02-03
<ubotu> New bug: #188387 in ubuntu "Can only do double clicks (dup-of: 188351)" [Undecided,New] https://launchpad.net/bugs/188387
<ubotu> New bug: #186042 in gnome-control-center (main) "mouse settings touchpad preferences not avaiable (dup-of: 173411)" [Undecided,New] https://launchpad.net/bugs/186042
<ubotu> New bug: #188720 in xorg (main) "[Hardy Alpha-4]  xserver-xorg can't start with ATI Radeon X1200" [Undecided,New] https://launchpad.net/bugs/188720
<ubotu> New bug: #188725 in xorg (main) "Rebooting After enabling fglrx and display goes white in Hardy" [Undecided,New] https://launchpad.net/bugs/188725
<ubotu> New bug: #188729 in xorg (main) "1680x1050 doesn't work, black bar on the left" [Undecided,New] https://launchpad.net/bugs/188729
<ubotu> New bug: #47765 in xserver-xorg-input-evdev (main) "Logitech Cordless Desktop don't work with evdev (dup-of: 44169)" [Medium,Confirmed] https://launchpad.net/bugs/47765
#ubuntu-x 2009-01-26
<bryce> tjaalton: michael larabel says he doesn't have the logs or output
<bryce> tjaalton: I told michael that it's sort of like going to a restaraunt where you can see into the kitchen, and then complain about all the undercooked food you see back there
<tjaalton> bryce: lol :)
<tjaalton> mmmm, Ubuntu Cola...
<tjaalton> a coworker brought me one can from Sweden
<bryce> tjaalton: awesome
<tjaalton> tastes good too, even unchilled
<bryce>  morning
<Alexia_Death> bryce: just out of curiosity, where are you located? because around here its about bed time.
<bryce> Alexia_Death: I'm in Tigard, Oregon, where it's right about noon
<Alexia_Death> O_o timezones are weird.
<bryce> can't live without them ;-)
<tseliot> federico1: the detect button works well here as it's likely that XRRGetScreenSizeRange() does hardware probing
<tarimari> hi
<tarimari> there is a ppa for xorg crack pushers. when these new version will be backported at intrepid?
<bryce> tarimari: you need to ask tormod
<tarimari> where's he?
<bryce> ah wait
<federico1> tseliot: but then you want to avoid that slow function as well, in the "I don't need to detect" case :)
<federico1> bbiab; lunch
<bryce> those items in the ppa are not planned to be put into -backports
<tarimari> so only at jaunty
<tarimari> i see
<tarimari> i installed them by i did not see any significant change. i hope i dont miss something :)
<tarimari> i also installed 2.6.28 kernel which is suppose to have gem
<tarimari> i have intel 965 card
<tarimari> but i did not see any improvement in speed of google earth for example
<tseliot> federico1: you're right but it still helps to call only 1 expensive function instead of 2 ;)
<bryce> tjaalton: 
<bryce> <maxb> Anyone else seeing update-manager disinclined to install a lot of libx11 / libxcb updates?
<bryce> <Turl> just found 2 broken packages,   libx11-6 and libxcb-xlib0-dev
<bryce>  can you look into them?
#ubuntu-x 2009-01-27
<alex-weej> bryce: any idea where the best place to put "xcalib /etc/display-profiles/someprofile" is for a crude configuration?
<alex-weej> i've put it in my gdmrc but it only runs after i've logged in for some reason
<alex-weej> (in terms of potentially being a standard thing in ubuntu)
<bryce> alex-weej: you want it to run prior to login?
<alex-weej> want it to run as soon as X even starts
<alex-weej> thankfully it persists across s3 suspend now
<alex-weej> and cheese/logout don't screw with the CLUT anymore
<alex-weej> so it's actually pretty sufficient to just run it when X starts
<bryce> would /etc/X11/Xsession.d be appropriate?
<bryce> else maybe fit it in with the session stuff in /etc/gdm
<alex-weej> bryce: all of this runs as soon as X comes up?
<bryce> you may want to play around with it, but yeah
<alex-weej> atm i've got it in /etc/gdm/PreSession/Default
<bryce> depends on the persistence of the xcalib changes I guess
<bryce> how's that working?
<alex-weej> it doesn't affect GDM
<alex-weej> as soon as i log in i see the colours change
<bryce> you mean, doesn't affect the login screen?
<alex-weej> yes
 * bryce nods
<bryce> ok, try in /etc/X11/Xsession.d next.  afaik that should apply for all X sessions including the gdm login screen
<alex-weej> ok i'll add a new file
<bryce> I'm not sure when /etc/gdm/Init/* stuff gets invoked but you could try that as well
<bryce> my guess is that it runs once only when gdm starts though
<alex-weej> i think that should be fine
<alex-weej> let me try it
<alex-weej> brb
<alex-weej> bryce: i added a 35display-profile to Xsession.d but it only did the same as my PreSession GDM thing
<alex-weej> changes colours when i log in
<bryce> what do you mean by 'changes colors'?
<alex-weej> so i added it to the end of /etc/gdm/Init/Default and it seems to work flawlessly
<bryce> ah ok
<alex-weej> applies the CLUT
<alex-weej> any idea if there's a way to get it to apply to X on an even lower level?
<alex-weej> (other than hacking X --- that's what i'm trying to avoid for now)
<bryce> maybe /etc/X11/xinit/xinitrc ?
<bryce> there is also /etc/X11/xinit/xserverrc although I'm not sure gdm uses that
<bryce> anyway, I think we're running out of rc solutions :-)  so yeah next step would probably involve X hackery
<alex-weej> ok will have a play tomorrow
<alex-weej> cheers!
<bryce> tjaalton: btw the above libx11 issue turned out to just be an out-of-sync mirror
<tarimari> hi guys
<bryce> hi tarimari
<tarimari> i have put this xorg pushers ppa
<tarimari> latest xorg etc. i have intel
<tarimari> and now my screen is very bright!
<tarimari> by default
<tarimari> how i can change that
<tjaalton> bryce: I don't think the patch to the xkeyboard-config README is right, since the files in /usr aren't configuration files, and will be overwritten on upgrade
<tjaalton> I thin it can be configured on the desktop well enough so that the section could be removed completely
<bryce> hmm
<tjaalton> and having configuration files in /usr would be against the policy AIUI
<bryce> yeah
<bryce> ok, feel free to fix up as you think it should be
<tjaalton> well, I don't know what it should look like :)
<tjaalton> maybe evdev.xml should be symlinked to it
<tjaalton> I'll reply to the list first
<tarimari> where are the devs of xorg pushers ppa?
<tjaalton> you are lookin for tormod
<tarimari> should i wait tormod at this channel?
<tjaalton> maybe, or email him
<tarimari> hmm. where i may find his email? :)
<tarimari> google "tormod xorg" ?
<tjaalton> launchpad?
<tarimari> ok thanks
<tjaalton> or the package changelogs
<tarimari> thanks
<tarimari> ok  i found
<tarimari> tormod volden
<tjaalton> jcristau: libxcb1 Conflicts libxcb-xlib0, but since there's no Replaces libx11-6 and libxcb1 are held back on upgrades
<tjaalton> jcristau: this was probably because of "libxcb-xlib is no more"?
<tjaalton> seb128: ok, I've got a workaround for you.. put http://users.tkk.fi/~tjaalton/foo/drirc in /etc and restart X
<tjaalton> might need to reboot too
<seb128> tjaalton: ok thanks!
<tjaalton> seb128: is it a i965?
<tjaalton> the gfx chip
<seb128> tjaalton: yes
<tjaalton> ok, so that'll work without modification
<seb128> on a dell d630 laptop configuration
<tjaalton> confirmed here.. I'll update mesa
<seb128> thanks
<tjaalton> bryce: btw, I can't see any kind of a performance regressions since patch 107 was disabled from xorg-server
<tjaalton> -a
<bryce> sweet :-)
<tjaalton> at least on my intel
<tjaalton> ok, jesse pointed out some mesa commits that might fix the vblank hangs
<tjaalton> I'll try them out later today
<tarimari> guys i saw somewhere a krandrtray tool with gamma. what version is that, and where ican find it?
<bryce> tjaalton: http://people.ubuntu.com/~bryce/Graphs/totals.svg
<tjaalton> bryce: wider scale?
<bryce> tjaalton: yeah I've gone to setting the time scale to quarters
<bryce> tjaalton: I cleaned up xkeyboard-config yesterday, and it's interesting to see it produced a little drop in the totals
<tjaalton> bryce: yes, looks like it
<tjaalton> bad tuxpaint.. no way to maximize the window
<tjaalton> heh, altgr-sysrq-k really works
<tjaalton> no need for ctrl-alt-backspace
<tarimari> guys how i can change the brightness of monitor at xorg?
<tarimari> or the contrast
<tarimari> are there somewhere these settings?
<tarimari> the console's black color is like grey
<tjaalton> what console?
<tarimari> black color anyway
<tarimari> it is like grey
<tarimari> konsole - terminal window - command line
<tarimari> this change happened after installing tormod xorg files, i uninstalled and still this exists
<tarimari> i can fix it by changing gamma
<tarimari> but i think there is problem with contrast
<tarimari> how can i reset these settings?
<tjaalton> don't know
<tarimari> ok
<tjaalton> is it a laptop? have you tried shutting it down?
<tarimari> -- kde 4.2 final ready at kubuntu-experiment repo
<jcristau> tjaalton: i don't understand the problem with libx11/libxcb
#ubuntu-x 2009-01-28
<tjaalton> jcristau: prevents upgrades, says slangasek
<tjaalton> jcristau: sorry for not mentioning that in the first place :)
<jcristau> so what should i do to get the package manager to remove the obsolete package?
<tjaalton> Replaces should do according to him
<jcristau> hrm. i thought replaces was about replacing files. /me goes read policy.
<RAOF> I've missed the first part of this, but Conflicts+Replaces sounds like what you want, I think.
<jcristau> oh. 7.6.2.
<jcristau> Replaces: libxcb-xlib0 is enough, or do i add the -dev?
<tjaalton> if libxcb1-dev replaces libxcb-xlib0-dev, then perhaps
<jcristau> installing the new libxcb1 breaks libxcb-xlib0, and thus also libxcb-xlib0-dev
<jcristau> so i'm not sure explicitly replacing is needed. and if it is where it should be.
<jcristau> (also fwiw 'apt-get -t experimental dist-upgrade' does remove libxcb-xlib0)
<jcristau> gah, s/explicitly replacing/& libxcb-xlib0-dev/ above.
<tjaalton> works here too, but I'm just the middle-man :)
<jcristau> bad vorlon.
<tjaalton> maybe prod him on #debian-x :)
<jcristau> that worked :)
<tjaalton> yeah :)
<tjaalton> turns out to be quite hard to debug a crashing xserver on acpi resume
<jcristau> last time that turned up, screen came to the rescue
<tjaalton> maybe I didn't use the correct options for gdb
<jcristau> you told it to not stop on sigusr1?
<tjaalton> I did now, let's see
<tjaalton> hey, I've got a backtrace
<tjaalton> let's try with -dbg
<tjaalton> http://bugs.freedesktop.org/attachment.cgi?id=22303
<ogra> tjaalton, seems ouchscreens with the new evdev infrastructure dont work at all ... (just got some user feedback, didnt look myself yet)
<tjaalton> ogra: that's unfortunate
<tjaalton> tseliot: new nvidia*.. but you probably knew that already :)
<ogra> yes, StevenK tested it today and he sees no motion at all tapping or touching the screen
<tjaalton> does evdev pick the device?
<ogra> it should at least show some miscalibrated movement 
<tjaalton> logs etc in a bug report would be nice :)
<jcristau> and evtest output probably
<tjaalton> yes
<tjaalton> tseliot: oh, they still don't support the current ABI
<tjaalton> seems that aaron didn't get his message through
<tjaalton> (or the got problems)
<tjaalton> *they
<tjaalton> hmm, legacy drivers apparently do support the new ABI
<tseliot> tjaalton: maybe he forgot to add a note about the new ABI in the changelog
<tseliot> I'll test them
<tjaalton> could be
<tjaalton> Maple v12 crashed my jaunty today.. after I resized the window. I blame nvidia :)
<tseliot> well, running drivers with IgnoreABI is not recommended ;)
<tjaalton> yeah..
<tseliot> but I do it
<tjaalton> I'd like to listen to my music though
<tjaalton> no sound on the desktop or the laptop..
<tseliot> don't resize the window then
<tseliot> or is it pulseaudio?
<tjaalton> of course it works now, can't reproduce it :)
<tseliot> hehe
<tjaalton> I've had issues with sound since pa 0.9.14 was uploaded
<tjaalton> well, no sound
<tseliot> audio is choppy here e.g. when I switch between windows
<tjaalton> for instance the playing doesn't even start, it just hangs there
<tjaalton> +in rhythmbox
<tjaalton> and if I kill pa, no sound
<tseliot> :-/
<tseliot> did you talk to theMuso about it?
<tjaalton> yes
<tseliot> no solution?
<tjaalton> he could reproduce some of the issues, but no solution
<tseliot> ok, then
<tjaalton> for instance alsamixer fails to start
<tseliot> pulse_haters++
<tseliot> but isn't that a bug in alsa?
<tjaalton> that too
<tjaalton> but I'm hopeful that the commits he requested for the kernel might help
<tseliot> keep your fingers crossed then
<tjaalton> I will..
<ogra> tjaalton, hrm
<ogra> so i'm trying out the samsung Q1 with the new ubuntu-netbook-remix image ... it still includes evtouch ... lshal shows me though that "synaptics" is forcefully used for the touchscreen
<ogra> while the evtouch initscript seems to have run and all calibration data is applied
<ogra> shouldnt it use evdev ? 
<ogra> instead of synaptics
<tjaalton> yes
<tjaalton> but that depends what the new image holds
<jcristau> sounds like it shouldn't be reported as a touchpad..
<tjaalton> +on
<tjaalton> right
<ogra> well, lshal shows capabilities input and input.touchpad ... where does touchpad get set  ?
<ogra> is there an fdi i can mangle ? 
<jcristau> probably hal source
<tjaalton> ogra: what version of hal?
<jcristau> and probably based on what the kernel reports about the device
<tjaalton> I bet it's too old
<ogra> its todays image build 
<ogra> so whatever is in the archive atm
<tjaalton> ok, maybe hal is still missing something.. bug pitti :)
<ogra> git20090120-0ubuntu1
<tseliot> seb128, mvo: can you merge from my branch, please? https://code.launchpad.net/~albertomilone/gnome-control-center/randr-virtual
<tseliot> seb128, mvo: this adds the DontZap checkbox to enable users to decide whether Ctrl+Alt+Backspace can restart X or not
<superm1> tseliot, while you are getting the upload ready for the new drivers, did you have a fix queued for https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/309116 ?
<ubottu> Launchpad bug 309116 in nvidia-graphics-drivers-96 "when removing nvidia-glx-177 /usr/lib/libGL.so is gone" [Medium,In progress]
<tseliot> superm1: I won't upload the new drivers without fixing that first
<tseliot> ;)
<superm1> tseliot, okay :)
<bryce> morning
<bryce> I spoke with amd this morning and asked them for a date on when they expect to provide a 1.6/.28 compatible fglrx
<bryce> they didn't have that info currently but will try to get it by the end of the week
<tjaalton> ok
<tjaalton> nvidia released new versions of the legacy drivers
<bryce> sweet
<bryce> yeah amd seemed a bit surprised that we were planning on 1.6 for 9.04.  I had to remind them I emailed them a month and a half ago that this was our plan
<tjaalton> heh
<superm1> bryce, any indications from them if a driver will be coming more than 1 month prior to release this time around?
<bryce> superm1: I pressed them on giving us a date.  they said they'll get back to us after they've "scrubbed their schedule"
<bryce> I would be feeling frustrated if the deja vu feelings weren't keeping me in such mirth
<federico1> mister bryce
<bryce> superm1: anyway, so I sense we're going to be in about the same situation as last time, despite our efforts.
<federico1> I resurrected the 10-second confirmation dialog for the RANDR tools and committed it to gnome svn
<bryce> federico1: oh interesting
<superm1> bryce, oh that's too bad :(
<federico1> bryce: http://bugzilla.gnome.org/show_bug.cgi?id=545115
<ubottu> Gnome bug 545115 in Screen resolution "should ask for confirmation before writting the changes" [Normal,Resolved: fixed]
<superm1> bryce, well at least this time, all the packaging is ready and it's at least easy to update new drops etc
<federico1> bryce: are you or anyone here in distributor-list?
<federico1> I'll post an evil patch to deal with wacom tablets and RANDR
<bryce> federico1: "distributor-list"?  first I've heard of that; what is it?
<bryce> federico1: thanks for committing that revert dialog patch; I'd been disappointed that it hadn't been taken previously
<tseliot> federico1: what's the plan on wacom tablets?
<bryce> superm1: yep.  
<federico1> bryce: distributor-list@gnome.org
<bryce> federico1: ah, I bet seb128 is on that list, he usually handles the gnome interfacing
<federico1> ah, ok
<federico1> tseliot: one sec, meeting
<kees> fun
<kees> [ 6009.433242] mtrr: no MTRR for f0000000,100000 found
<kees> [ 6009.604066] Xorg[12735] general protection ip:4961b6 sp:7ffff1fccde0 error:0 in Xorg[400000+1c2000]
<kees> 64bit jaunty under kvm
<superm1> kees, i've been seeing mtrr: no MTRR for e0000000,10000000 on real systems, is there any significance to what that's representing?
<kees> superm1: not sure.  :(
<superm1> kees, oh okay.  just wasn't sure what MTRR was an abbreviation for.
<bryce> I've seen reports about that
<bryce> btw speaking of acronyms I finally learned what fglrx stands for...  "FireGL and Radeon for X"
<bryce> MTRR == Memory Type Range Registers maybe?
<bryce> http://www.mjmwired.net/kernel/Documentation/mtrr.txt
<kees> bryce: ah! I've always wondered wtf fglrx stood for.  :)
<tormod> well we always knew it was an f-word
<tormod> bryce: landslide in radeon git today - what are your plans for updating jaunty? There's some agp quirks etc that otherwise could be cherrypicked
<tjaalton> bryce: got a patch from jesse for the interrupt loss when using vblank, will try it out tomorrow
<tjaalton> against the kernel(drm) though, so a bit harder to get through if it works
<bryce> tjaalton, ok
<bryce> tormod: I anticipate updating -ati at least once more before we're done with jaunty
<bryce> even if that might mean shipping a git snapshot.  A release would be nice of course, but we've shipped git snapshots before
<tormod> bryce: good
<bryce> tormod: at some point post-beta I also will be pulling any outstanding quirks for both -ati and -intel
#ubuntu-x 2009-01-29
<bryce> troubleshooting guide for blank/black screen issues --- https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
<tseliot> tjaalton: just FYI nvidia driver 180.27 supports the new X ABI :-)
<tjaalton> tseliot: wow, that was fast
<tseliot> tjaalton: now switching between windows is fast and doesn't make sound choppy
<tseliot> :-)
<tjaalton> great
<tjaalton> phoronix failed to notice the support for the new abi
<tseliot> well, it wasn't in the changelog
<tjaalton> ok
<jcristau> tjaalton: you expected him to do a tiny bit of research? :)
<tjaalton> jcristau: yeah, I have such high hopes
<tseliot> :-P
<johanbr> Hmm. The new synaptics driver broke vertical scrolling for me.
<tjaalton> nice to know
<tseliot> the synaptics driver is on my todo list. I'll start working on it after I'm done with nvidia
<johanbr> Okay, found the bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/320632
<ubottu> Launchpad bug 320632 in xserver-xorg-input-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Undecided,Confirmed]
<tseliot> johanbr: can you attach the output of this command in the report? xinput list-props name_of_your_synaptic_device
<tseliot> maybe you're using an AlpsPS device
<jcristau> i'm using an alps, and edge scrolling is a lot harder to use on 0.99.3 than previously, too..
<tseliot> jcristau: I forgot to fix it for ALPS. Can you attach the output of that command to the report, please?
<jcristau> well. i want to get it fixed upstream eventually, just haven't had time to look into it yet..
<johanbr> tseliot: It is an alps device. I think the edge is misdetected.
<tseliot> ok
<tseliot> jcristau: I would like to provide upstream with some of my patches
<johanbr> I managed to get edge scrolling back with xinput, but completely broke normal mouse pointer movement. :)
<johanbr> Is there an xinput command to reset the properties?
<jcristau> tseliot: paste.debian.net/27180/ (this is on debian, so unpatched 0.99.3)
<tseliot> jcristau: ok, thanks
<johanbr> input properties for my touchpad: http://paste.ubuntu.com/111247/
<johanbr> Doing 'xinput set-int-prop 6 "Synaptics Edges" 32 40 0 882 0' enables edge scrolling, but completely disables pointer movement. Is this expected?
<tseliot> johanbr: please add all the information to the bug report
<johanbr> alright
<tjaalton> tseliot: the gui mechanism for dontzap meant the xorg.conf editor AIUI..
<tjaalton> and the poll in ubuntuforums is not authoritative..
<tseliot> tjaalton: yes, I know but it's too late for me to rewrite its UI
<tseliot> and we need a solution
<tseliot> i.e. a compromise
<tjaalton> alt+sysrq+k
<tseliot> go tell users ;)
<tjaalton> normal users don't need that, they have the power button
<tseliot> or pull the plug
<tjaalton> sigh, kernel compile filled my /home
<tjaalton> maybe I should reinstall
<tjaalton> heh, I couldn't even empty my trash, since it tries to touch some files which obviously failed
<tjaalton> great, the patch from jesse helped.. no more temporary freezes with intel
<superm1> tjaalton, were those the same temporary freezes related to the xrandr event with monitors changed all the time, or *another* set of freezes that were happening?
<tjaalton> superm1: another.. related to vblank
<superm1> tjaalton, yippee then
<tjaalton> the randr-related problems are caused by gnome AIUI
<tjaalton> and are WIP
<tjaalton> probably also the reason why my session startup seems to idle for 5-10s before getting up
<tjaalton> no disk activity during that time
<maco> does the intel driver in jaunty have KMS yet?
<tjaalton> no
<tjaalton> well, the kernel doesn't
<tjaalton> and won't
<maco> ok
<maco> a friend is trying to figure out why i have solid black (with no prompt) tty's with i965
<tjaalton> also without usplash?
<maco> have to test that still
<maco> lack of working ttys isnt constant for me. its frequent, but occasionally (like right now) ttys do work, so i guess id have to turn off usplash for about 2 weeks to test it
<tjaalton> sometimes that happens here too
<bryce> maco, is it just the tty's that are blank, or your X session too?
<maco> usually just the tty's. sometimes i cant bring X back afte trying to VT switch
<bryce> ok
<bryce> I'm not sure how to debug the tty breakage issue, but that's something I've looked at before.  I need to understand why that particular kind of bug comes up
<bryce> I'm not entirely sure whether it is an X bug, or kernel, or what, but it's common enough we ought to have some troubleshooting guidelines for it
<maco> he said that in cases where it happens while X is locked, it's expected
<maco> in cases where it happens while X is working perfectly fine...well, he wants me to try git master for a little while and see if VT switching works properly and consistently
<bryce> maco: ok interesting.  who is 'he'?  jesse barnes?
<maco> bgamari
<maco> he's in #ubuntu
<bryce> ah ok, I don't know him, but sounds like decent advice
<maco> we go to school together, and it turns out he works on the i965 drivers
<bryce> ahh kewl
<ogra> hmm, i have a /sys/class/input/input0 and input1 device for mouse and kbd but no /dev/input/eventX for either of them ... doesnt hal use sysfs for determining the devices ? (i have no input in X )
<ogra> hmm, ok, ignore me, i just found CONFIG_INPUT_EVDEV is missing in our arm qemu kernel ... 
#ubuntu-x 2009-01-30
<bryce> http://bryceharrington.org/drupal/zap
<tjaalton> bryce: hope it does it's job to silence the minority
<bryce> thanks for mentioning the alt-sysrq-k on the merge thread; I'm not sure how to add replies to that other than replying to emails
<tjaalton> yep, me neither
<bryce> heya mvo
<mvo> hey bryce
 * mvo yawns
<mvo> is there a consensus now on the discussion about the dontzap option? 
 * mvo reads the mails about it
<bryce> mvo: see my blog as well
<pwnguin> i cant believe it went this long without noticing
<bryce> mvo: I don't know that we necessarily have consensus, but we do have definitive sabdfl direction on it
<bryce> I don't think we really need the checkbox anyway; we still have alt-sysrq-k which seems to work just as well for me
<mvo> ok, I will revert the merge again
<bryce> thanks mvo
<tjaalton> i was surprised to see the merge request, since there had not been any discussion about adding it to the capplet
<bryce> tseliot had emailed me and rick privately with the idea.
<bryce> in hindsight probably should have been discussed more widely first
<mvo> I had the impression this was part of the uds discussion already
<mvo> a bit unfortunate that alberto did the work on it and now its not being used :/
<bryce> yeah, for kubuntu we decided at the uds session to have a checkbox for it.  For ubuntu we actually decided to make it available in the xorg.conf options editor
<bryce> however tseliot is thinking he may not get that sufficiently done in time, so suggested doing a checkbox for gnome as well, for the time being
 * mvo nods
<mvo> about the transition for fglrx->ati, I think that is straightforward, I will answer in detail today
<bryce> thanks.  Yeah it will be good to have that in our back pocket
<bryce> after my last confcall with them I think we may need that in the future
<bryce> new troubleshooting guide --  https://wiki.ubuntu.com/X/Troubleshooting/HugeFonts
<marijus1> what are the prerequisites to get kms working on jaunty with intel?
<jcristau> marijus1: a new kernel, and possibly rebuilding the driver against that
<jcristau> not sure about the latter
<marijus1> i got .29-rc3
<RAOF> Depends on how much you want X to work, I think.
<marijus1> :D
<marijus1> well... i tried... and gdm was kind of not messed up
<jcristau> if you want things to work somewhat better, you probably want master of the driver and libdrm, instead of the releases
<RAOF> And probably building the kernel modules from master wouldn't hurt.
<jcristau> RAOF: .29-rc3 is fine
<jcristau> results will depends on the chipset, too. and you need to use uxa iirc
<marijus1> so jaunty libdrm is not suited for that?
<RAOF> Cool.  Ish.  More cool would be if nouveau did it :)
<marijus1> i got an 855GM :)
<jcristau> ah. that's probably not going to work
<marijus1> not yet... or never ever?
<jcristau> not yet
<marijus1> well i guess ill try anyway...
<marijus1> does it also have anything to do with mesa?
<bryce> marijus1: 855 is just such an old chip...
<marijus1> i know :)
<dholbach> hello my friends - how are you doing?
<dholbach> I was wondering if somebody knew the magic silver bullet to make my compose key and the "usual accents" and stuff work on my intrepid and jaunty again
<dholbach> ~n  'e  `e  ^e  ,c  "i  is the stuff that I get right now
<dholbach> with German Eliminate Dead keys
<dholbach> and a compose key set
<dholbach> the might seb128 says it might be xkeyboardconfig
<dholbach> Å Ã± Ã© Ã¨ Ãª Ã§ Ã¯ - seems like I have to use the right strg key
<dholbach> everything else either blocks other key combinations or does not work
<dholbach> the behaviour definitely changed
<dholbach> s/strg/ctrl
<Ng> mmm, compose. I probably can't help, I just told gnome to use Alt-Gr as compose and it kinda just worked with the UK layour ;)
<dholbach> thanks Ng - I fixed it now
<dholbach> using "Germany" instead of "Germany Eliminate Dead Keys"
<Ng> huh
<dholbach> and the right win key or is it a menu key(?) does not work for me
<dholbach> Germany with Ctrl as compose works
<dholbach> very weird
<dholbach> I hope I get it working on jaunty on the other machine now too
<dholbach> I felt stupid and illiterate for not writing names properly :)
<dholbach> works in jaunty now too
 * dholbach is happy
<dholbach> thanks again my X friends
<ogra> hmm, did Xorg drop support for ~/.xsession ? 
<jcristau> no
<ogra> creating a .xsession in my homedir that just contains xterm makes startx fail 
<ogra> removing that file gets me to a desktop proper
<jcristau> define fail
<ogra> its in qemu ... so it uses fb0 ... i see (==) using config file: "/etc/X11/xorg.conf" which is a completely empty file apparently 
<ogra> next line says "Primary device is not PCI" (how did it know that ! :) )
<ogra> then an xkbcomp warning 
<ogra> and then: waiting for X server to shut down ddxSigGiveUP: closing log
<ogra> thats all
<ogra> removing .xsession just works
<ogra> its an armel install done with d-i with yesterdays iso 
<ogra> gdm works as well btw ... but both, gnome and gdm are just to heavy since the arm qemu has a restriction to 256M
<ogra> so i wanted to use an xterm to be at least able to test single apps
<ogra> nothing in the log either, no errors or anything
<ogra> looks like X itself comes up fine but doesnt go to the .xsession file 
<ogra> same if i put gnome-terminal instead f xterm in there
<ogra> hmm, works with metacity (which indeed doesnt get me anywhere)
<ogra> argh and no zapping ... 
 * ogra reboots the VM and grumbles
<ogra> hmm
<ogra> metacity &
<ogra> xterm
<ogra> doesnt work either 
<ogra> the other way round metacity starts but i dont get an xterm ... 
 * ogra doesnt get it
<ogra> aha !
<ogra> .xsession-errors: xterm Xt error: Unresolved inheritance operation
<ogra> whatever that means ... it prevents treminals from starting apparently
<tjaalton> bryce: heh, not a single comment on your blog, or maybe they are on the moderation queue?
<bryce> tjaalton, oh yeah probably in the moderation queue
<Rocket2DMn> hey bryce , got a few minutes?
<bryce> Rocket2DMn: sure
<Rocket2DMn> cool, ive been working on bug 322610 triage for a friend
<ubottu> Launchpad bug 322610 in linux "[Regression] Screen brightness not 100% at boot or resume from monitor sleep" [Low,Confirmed] https://launchpad.net/bugs/322610
<Rocket2DMn> ive been having trouble deciding on the package to file under, im thinking it might be the intel driver though, which is why im asking you
<Rocket2DMn> since in Xorg.0.log intel is talking about the backlight
<bryce> mmm
<bryce> gnome-power-manager would be my first guess
<bryce> often problems with backlights are ACPI issues rather than X.
<Rocket2DMn> yeah the bug was originally filed under gpm
<bryce> that said, there have been some cases where it is the video driver that's at fault.
<Rocket2DMn> but the problem kicked in only after a kernel upgrade, so i filed it under linux as a hardware regression
<Rocket2DMn> the kernel upgrade came in the other day, the intel driver update a few days before
<bryce> yep that's also possible
<kees> Rocket2DMn: you can booting an earlier kernel, or downgrading the intel driver?
<Rocket2DMn> kees, i had him reboot into an older kernel and the problem goes away
<Rocket2DMn> there are attachments on the bug from both kernels, but the logs basically line up
<Rocket2DMn> there was a quirk in hal, the older kernel picked up 2 compter_backlight entries, whereas the new kernel only saw one
<Rocket2DMn> thinkpad_acpi has some stuff in kern.log but its the same in both, it looks like its surrendering control
<Rocket2DMn> which seems normal in this case
<bryce> yeah, sounding a lot like an acpi kernel issue
<bryce> Rocket2DMn: speak with ogasawara who is the kernel bug triage person, to help get attention on your bug
<Rocket2DMn> alright, its not my bug, its a friend's
<Rocket2DMn> ill ping her about that
<Rocket2DMn> do you think its ok under linux or should it be under acpi-support?
<pwnguin> its kind of unfortunate that one person determines what kernel devs do and don't see
<pwnguin> if you follow all the triage rules, it still won't make it onto her "suggested bugs of the week" list
<Rocket2DMn> i think sometimes she is a little slow to look at some bugs, but im sure the kernel team is very busy
<pwnguin> rocket2dmn: well, its also easy to fall off her radar
<Rocket2DMn> yeah, i dont doubt that
<bryce> at least there is a process; it was worse before
<Rocket2DMn> hehe, yeah, i guess they decided at the last UDS to not have triagers assign bugs to the kernel team either
<Rocket2DMn> i think that's unfortunate, but i hope it helps their process
<bryce> tjaalton, ok comments are up at http://www2.bryceharrington.org:8080/drupal/zap
<tjaalton> bryce: cool :)
<bryce> heh, most common message is that yet again macbook is missing keys
<bryce> it baffles me why people buy macbooks when they are missing so much functionality
<jcristau> tell them to get a real computer :)
<bryce> anyway, presumably they still have a power button at least
<tjaalton> hehe
<tjaalton> bryce: hmm, still can't see the comments there
<bryce> really? hm
<bryce> tjaalton, try reloading?  they should all be there
<tjaalton> still nothing.. bad firefox
<tjaalton> oh well, maybe I don't want to read them anyway
<tjaalton> s/want to/*shouldn't*/
<tjaalton> uh, s/don't//
<tseliot> tjaalton: firefox knows what's better for you :-P
<tjaalton> tseliot: seems to be the trend ;)
<tseliot> hehe
 * tseliot -> away
<bryce> I really need to upgrade drupal...
<bryce> tjaalton, could you try again?  I tried a different method for publishing the comments this time
<tjaalton> bryce: shiny.. works this time
<bryce> awesome
<tjaalton> nothing too alarming there. on my thinkpad I don't need to use Fn, but altgr instead of alt
<tjaalton> so maybe documenting "the new behaviour" isn't that straightforward as would be ideal
<bryce> yeah
<bryce> tjaalton oh btw, what do you think of that patch for kees' bug to change the max client limit?
<jcristau> hrm. the vmmouse_detect(1) manpage upstream says 'report bugs to launchpad'.
<jcristau> should that be changed to fd.o bugzilla?
<bryce> jcristau: interesting; yes that should be changed
<jcristau> the manpage has your copyright so it's not too surprising, just noticed it while looking at getting the latest version in experimental
<jcristau> http://people.debian.org/~jcristau/0001-Point-to-freedesktop.org-bugzilla-instead-of-launchp.patch
<bryce> jcristau: wow nice.  I didn't know about @PACKAGE_BUGREPORT@ before
<jcristau> yeah it's the third argument to AC_INIT
<tjaalton> bryce: yeah, I do agree
<bryce> working on the 'High CPU' bugs this afternoon
<tjaalton> the gnome-madness bug you say?
<bryce> it feels very nice to be able to drop bugs as "looks like a client-side application problem to me"
<bryce> oh all over the place.  one was an xfce-theme problem (just two themes triggered it)
<tjaalton> hehe
<bryce> "I notice these two themes do some really intense gradient animation... no idea if that's related..."
<bryce> also appears kde was doing monitor polling with xrandr calls every 10 sec at some point too
<bryce> http://jakob.petsovits.at/projector-fun
<bryce> it drives me crazy that even after people realize the problem was caused by something other than X, they still blame X for their problems ;-)
<bryce> silly people
<tjaalton> yeah, more work for the cluebat
<bryce> tjaalton, btw I pushed out the xorg changes that were sitting in git.  Figured we should get them out for alpha-4 next week
<bryce> making bug 294972 master for cpu load issues
<ubottu> Launchpad bug 294972 in xorg "MASTER: xorg high cpu usage, general system sluggishness" [Undecided,Confirmed] https://launchpad.net/bugs/294972
<tjaalton> bryce: ok, did you push the release commit?-)
<bryce> oh yeah
<tjaalton> k, our spamfilter must've eaten it
<bryce> no I mean, "Oh yeah, <mumble> git <mumble> needs to be committed still..."
<tjaalton> hehe
<bryce> pushed
<tjaalton> thanks
<bryce> oh btw, seb128 is thinking about dropping the forced 96 dpi in gnome next week at the sprint
<bryce> so we might get more of those "HUGE font" bugs
<tjaalton> figures
<tjaalton> did I already ask about 'gdm on vt1'?-)
<tjaalton> I guess we need a flamewar for jaunty+1 too
<bryce> hehe
<bryce> we need a section in the release notes titled, "How X will piss you off to no end in this release of Ubuntu"
<tjaalton> I've been running X on vt1 since UDS. very few changes needed, gdm and system-services (drop /etc/event.d/tty1)
<bryce> we can end it with a link to the Wayland home page
<tjaalton> bwaha
<tjaalton> "a teaser of what we'll see... in 2017!"
<bryce> ok, high cpu bugs done.  I was able to drop x from almost all of them, except a couple that actually were xserver lockups
<bryce> ok, lunchtime
<tjaalton> whoa, first real nouveau bug
<tjaalton> bug 323377
<ubottu> Launchpad bug 323377 in xserver-xorg-video-nouveau "X fails to start with nouveau driver on nforce2" [Undecided,New] https://launchpad.net/bugs/323377
<bryce> sweet
<bryce> I'll close it
<tjaalton> well, even though it's not really supported, it might be nice to see how the driver progresses
<bryce> hank you for testing the new -nouveau driver and reporting your finding of a problem.
<bryce> However, while we are providing -nouveau for testers to experiment with, we are not yet supporting -nouveau in Ubuntu and will not be following up on this bug at this time.
<bryce> It sounds like you have a good lead on finding a solution to this problem associated with lvds detection though, and I would strongly encourage you to contact the upstream developers directly and work with them on finding a solution.
<bryce> +T
<tjaalton> getting late.. night!
#ubuntu-x 2009-01-31
<bryce> night tjaalton
<pwnguin> bryce: who is "we"?
<bryce> pwnguin: ubuntu-x team
<bryce> if anyone is interested in taking charge of caring for -nouveau bugs, we can change that
<pwnguin> im already subscribed to them, but im not sure what it'd take to "care for" them
<bryce> 'care for' == triage and forward upstream as appropriate
<pwnguin> triage normally means designate an importance
<bryce> yep
<pwnguin> if the x team isn't touching the package for jaunty I'm not sure why an imporatnce should be set
<pwnguin> man. can you believe that was my second try at importance?
<bryce> heh
<pwnguin> anyways, if there's going to be a time where nouveau DOES garner X Team attention, it might be helpful to have a bug corpus
<bryce> well, in bug tracker context, triage generally is taken to mean "make sure the report has sufficient information included" as well
<pwnguin> but this really depends on nouveau upstream being ready to work on such stuff
<bryce> perhaps, but presumably many of these bugs will be fixed upstream between now and whenever we switch it to supported, so having a bunch of old, likely-fixed bugs will detract from issues reported against the version uploaded
<bryce> correct; last I checked they still were not accepting bug reports
<bryce> partly the reason to close bugs for now is to set expectations
<bryce> I don't want users feeling they can file -nouveau bugs against LP and trust us to take care of them, when we won't.  Better to close them and get the users to go upstream with them.
<bryce> we've got a somewhat similar problem with -radeonhd
<bryce> guess I should close those out as well
<bryce> (actually they may be xserver issues...)
<pwnguin> nouveau seems to have a bug tracker
<pwnguin> mainly for 2d
<superm1> tjaalton, i thought it was decided at uds to switch gdm to vt1 already?
<superm1> or am i just imagining things...
<bryce> [ANNOUNCE] xorg-server 1.5.99.902
<tjaalton> superm1: it wasn't that widely discussed, and it doesn't need changes in any X packages other than maybe xdm, so maybe the desktop team should make the decision, not us
<tjaalton> hmm, so the xserver did do something wrong when the xrandr sluggishness occurred
<tjaalton> randr: Avoid re-querying the configuration on everything but
<tjaalton> GetScreenResources.
<bryce> yeah saw that
<bryce> tjaalton, we should definitely pull that in for the xserver
<bryce> also, I forgot to pull the client limit patch today
<tjaalton> they need more work
<tjaalton> since the ones were for 1024 clients, but we should probably settle for 512
<tjaalton> and they were for the server and proto
<tjaalton> IIRC
<tjaalton> I'll push server rc2 and mesa 7.3 shortly
<bryce> ok
<tjaalton> hmm the maxclients is defined only in the server nowadays
<tjaalton> so no need to touch coreproto
<tjaalton> since XPoll.h is gone
<tjaalton> hmm not quite
<tjaalton> bryce: I was wrong, the patches are ok as-is, just s/1024/512/
<bryce> sweet
<bryce> ok I'm heading to bed, and then up early for a 6am flight to berlin, so I probably won't be online 'til monday
<bryce> cya tjaalton
<tjaalton> ok, bye
<superm1> tjaalton, perhaps it's worthwhile to put a call for feedback to ubuntu-devel for getting more people to test it then and look for side effects?  I mean it's going to happen eventually anyway (when KMS hits), so the sooner you know about the side effects of say the other drivers (NV and AMD), the more time you'll have to get those things reported and fixed at least
<superm1> maybe a few line description of how to change your server to run on VT1
<tjaalton> superm1: it shouldn't matter what driver is used, but maybe it should be discussed openly right from the start :)
<tjaalton> and KMS doesn't dictate which VT to use, but it'll reduce flicker to run X on VT1
<tseliot> tjaalton, superm1: I sent this file with the new drivers to pitti (so that he can upload them ASAP). In the meantime, if you want to play with the new drivers: http://albertomilone.com/ubuntu/newlrm/pitti/jaunty/driver_jaunty.txt
#ubuntu-x 2009-02-01
<tjaalton> yawn
<tseliot> tjaalton: did you see my new patch? https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/320632/comments/53
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/320632/+text)
<tjaalton> tseliot: nope, I'll add it later
<tseliot> tjaalton: ok, thanks
<desrt> hi guys
<desrt> i have a tablet PC and it's broken on jaunty alpha 2
<desrt> i know how to fix it by editing the xorg.conf, but that's obviously not going to be helpful in the longrun
<desrt> the tablet is a serial interface
<desrt> i'd like to know how to cook up proper .fdi magic to get the serial interface recognised as belonging to a tablet so that this can be included in ubuntu properly so it works out of the box when jaunty ships
<desrt> any help with that would be wonderful
<desrt> hal already seems to recognise it as a tablet: i get a device node in hal for "Wacom Serial Tablet PC Pen Tablet/Digitizer" with serial.device="/dev/ttyS0"
<desrt> but no love from X
<pwnguin> desrt: afaik, hal can't work properly
 * desrt raises eyebrow
<desrt> pwnguin: what's the issue?
<tjaalton> desrt: it's a serial device, so it can't be detected automatically
<pwnguin> well, most serial wacom are internal
<pwnguin> one could probably ID the laptop
<desrt> tjaalton: it is autodetected, though
<desrt> hal knows that this serial device is a wacom tablet
<pwnguin> what i was referring to is the apparent limitation that you get one device for a tablet instead of three
<desrt> well, it really is only one device....
<pwnguin> not if you want GIMP to tell between an erasor and stylus
<desrt> that's sort of X's issue, though
<desrt> unless you want hal to plug and play auto-detect the eraser tip as it comes in range
<pwnguin> were you intending to use the tablet without X?
#ubuntu-x 2010-02-01
<libv> ah michaellarabel, you're awake :)
<RAOF> Hm.  What have I broken in nouveau?
<RAOF> Oh.  I may have built it against broken headres.
<RAOF> Aha!  It was, of course, option 3.  "lbm-drm" != "drm_lbm"
<RAOF> Combined with VESA hating kms with a passion.
<Duke`> interresting: http://bugzilla.kernel.org/show_bug.cgi?id=15004
<ubottu> bugzilla.kernel.org bug 15004 in Video(DRI - Intel) "i915: *ERROR* Execbuf while wedged" [Normal,New]
<Sarvatt> RAOF: did you see someone already released 2.4.17-0ubuntu2 without updating git?
<Sarvatt> some ports people needed libdrm-intel1 to build on arm and powerpc so plymouth would build there
<jcristau> libdrm-intel on arm and powerpc?  srsly?
<Sarvatt> yeah tell me about it..
<Sarvatt> easier to make libdrm-intel generic than fix plymouth i guess
<jcristau> why don't they fix the actual bug instead?
<Sarvatt> fedora builds it on all arches as well
<jcristau> still doesn't make sense :)
<Sarvatt> i tried to explain that but the person i was talking to was convinced intel might make an arm chipset because of xscale... :D
<jcristau> *shrug* not my problem anyway.
<bjsnider> why are people getting OpenGL version string: 2.1.2 NVIDIA 190.53
<bjsnider> when they do glxinfo?
<bjsnider> that's the wrong opengl version
<bjsnider> should say 3.2
<Sarvatt> bjsnider i just said why in #ubuntu+1 :D not all cards support all of the extensions for 3.2, they dont just show 3.2 globally because the driver supports it
<Sarvatt> only G80 or newer does opengl 3+
<Sarvatt> The new features in OpenGL 3.0, OpenGL 3.1 and OpenGL 3.2 require G80, or newer hardware. Thus OpenGL 3.0/3.1/3.2 is not supported on NV3x, NV4x nor G7x hardware.  - from http://developer.nvidia.com/object/opengl_3_driver.html
<hyperair> what about nv1x? =p
<Sarvatt> not supported by that driver at all so they didnt reference it :D i'm sure its opengl 1.4 or 1.5 though
<Sarvatt> or not
<Sarvatt> eww :D
<Sarvatt> yeah 1.3
<vish> Sarvatt: could you have a look at Bug #515548  , it is logging the errors right now , any other info i can attach to the bug report?
<ubottu> Launchpad bug 515548 in xserver-xorg-video-ati "Radeon errors overflow in gdm logs. Makes root run out of space." [Undecided,New] https://launchpad.net/bugs/515548
 * vish watches disk space running out :(
<Ng> dear xinput, please sit still! love, Ng
<Sarvatt> i'd like to know why the xorg log is going to the gdm log in the first place
<Sarvatt> the useful gdm log info is getting overwritten by the xorg log stuff
<jcristau> Xorg stderr goes to gdm.log
<Sarvatt> does your Xorg.0.log have all those CS section size missmatch start errors Ng? the ones attached to the bugs dont
<Ng> Sarvatt: I'm not entirely sure what errors you're referring to, but "CS" doesn't occur in any of the Xorg logs I have on-disk right now
<Sarvatt> the ones filling your gdm log, ah
<Sarvatt> have you tried xorg-edgers to see if its any different with the newer mesa/ati?
<bjsnider> Sarvatt, i didn't know the nvidia blob was so intelligent that it enables certain extensions depending on the hardware it's driving...
<Sarvatt> it happens when watching videos with Xv right?
<jcristau> "intelligent"?
<jcristau> it's like 3d driver 101
<Sarvatt> ./radeon/radeon_cs_gem.c:        fprintf(stderr, "CS section size missmatch start at (%s,%s,%d) %d vs %d\n",
<Sarvatt> are there any upstream bugs about it that you know about Ng? it'd be easy to disable the error reporting from libdrm if you just want it fixed on your system and its working right but its obviously a bug with ati
<Sarvatt> what are you doing when it writes that? watching a video with Xv or just using the system?
<Sarvatt> can ya sudo tail -f /var/log/gdm/:0.log in a terminal while you use the system to see?
<Ng> Sarvatt: I think you may have me confused with someone else, I'm not using an ati system or havnig problems with video, I was just whining at xinput for changing device names, breaking my scripts ;)
<Sarvatt> ohh I'm really sorry Ng, indeed it was vish having the problem
<Ng> np :)
<Sarvatt> vish: see above please :D
 * vish catches up , to
<jcristau> Ng: blame udev for putting quotes in the device names :)
<vish> Sarvatt: I havent used Xorg-edgers since mesa in that crashes my X :( , But Xorg log doesnt seems to have any errors , the x log in the bug report didnt have the info?
<Sarvatt> odd that the radeon stderr stuff is only going to the gdm log, intel stuff goes to the Xorg.0.log when it prints this stuff
<jcristau> ErrorF vs fprintf(stderr) i guess
<vish> hmm , mesa in lucid is also 7.7 > I was earlier having this Bug #436546 , hence stopped using -edgers
<ubottu> Launchpad bug 436546 in mesa "X crashes when using compiz cube and cairo-dock" [Unknown,Confirmed] https://launchpad.net/bugs/436546
<Sarvatt> brb driving
 * vish checks mesa in -edgers
<vish> anyone know if the mesa 7.7 in lucid is same as mesa 7.7.0~git20090921.972e995b-0ubuntu0tormod ?
<Sarvatt> no, *alot* different
<Sarvatt> tons of changes in the 3 months between those
<Sarvatt> did you see what was said in #radeon vish?
<Sarvatt> <suokko> [12:19:03] Sarvatt: Looks like change to R500 video code and not adding extra bytes to reserved space
<Sarvatt> <suokko> [12:19:49] Without looking the code safe fix looks like adding 2 to reservation count in the line which error message complains about
<vish> Sarvatt: just joined #radeon
<Sarvatt> <suokko> [12:32:42] Sarvatt: http://sprunge.us/fBPB
<vish> Sarvatt: hmm , i'm not sure how to patch and run that :s 
<Sarvatt> can you add that patch to the package or do you want me to make you one with that patch?
<Sarvatt> okie one sec
<Sarvatt> taking ages to update my sources on this tethered connection, sorry
<vish> np... thanks for looking into it :)
<Sarvatt> hoping bryce reenabled the patch system in the lucid package to make it easier :D
<Sarvatt> uploaded it here vish https://edge.launchpad.net/~sarvatt/+archive/ppa
<Sarvatt> argh wait a sec
<Sarvatt> i have a ppa dependency on edgers there
<Sarvatt> putting it here https://edge.launchpad.net/~sarvatt/+archive/more-bugs
 * vish adds ppa and awaits upload
<bryce_> heya
<Sarvatt> heyo bryceh/bryce2/bryce_, sorry disconnected a few times there :)
<bryce2> :-)
<bryce2> Sarvatt, yeah at the developer's sprint right now.  I was actually surprised wireless worked right off the bat no prob.
<Sarvatt> bryce2: any chance replacing the ErrorF's in 100_rethrow_signals.patch with fprintf(stderr's might work? Does ErrorF try to write to the log?
<bryce2> yeah ErrorF does try to write to the log
<Sarvatt> I'm thinking its the ErrorF's in FatalSignal() causing the problem
<bryce2> ok, yeah I can give that a shot.  Getting that sorted out is on my todo for the week
<bryce2> I'm also wondering if that NoTrapSignals or whatever flag would be worth trying
<Sarvatt> yeah I'm going to try it out as well when I get a chance, just looking at logging problems vish is having and put two and two together
<bryce2> seems to me we tried that at one point but I don't remember
 * bryce2 nods
<bryce2> btw did my pm reach you?
<bryce2> freenode is such a pita
<vish> Sarvatt: i installed the updates , but the logging hasnt stopped... should i check after an X restart?
<Sarvatt> vish: yeah have to restart X, if possible could you pastebin your ~/.xsession-errors if it happens again with that patch before you reboot again?
<Sarvatt> looking now bryce2
<vish> hmm. , thats very odd...! it stopped just now... [/me wonders if it is scared of Sarvatt ]
<vish> ;)
<Sarvatt> the patch fixed it?
<Sarvatt> keep in mind I'm almost positive it only happens when you're watching videos
<vish> Sarvatt: i wasnt watching any videos now... [Was using Inkscape ] and after the update too , no videos but the logging was going on..   but just stopped now.. 
 * vish plays videos
<Sarvatt> nautilus thumbnailing videos would do it too
<Sarvatt> or having a video without a thumbnail in the directory when you go to open a file in inkscape or something
<vish> ha , might be that.. there were a few videos which wouldnt thumbnail
<Sarvatt> no videos but the logging was going on..   but just stopped now.. << that mean you were getting the cs errors?
<Sarvatt> with the patched driver?
<vish> it seemed to occur even after the patched driver , but it has stopped logging now... I trying to check if it starts again.. [havent restarted X yet] earlier it wouldnt stop logging unless i restart X
<vish> I'm*
<vish> hmm , started again :/
<Sarvatt> you need to restart X to use the new driver vish
<vish> Sarvatt: yeah.. i was just making sure :)
<vish> brb
 * vish now has a quiet gdm log , will be keeping an eye on it :)
<Duke`> ok, execbuf error still present
<Sarvatt> #0  0x00007fff160baf40 in ?? ()
<Sarvatt> #1  0x000000000045f4a0 in FatalError (f=0x579a98 "Server is already active for display %s\n%s %s\n%s\n") at ../../os/log.c:561
<Sarvatt> #2  0x0000000000469293 in LockServer () at ../../os/utils.c:374
<Sarvatt> #3  0x00000000004629c6 in OsInit () at ../../os/osinit.c:305
<Sarvatt> #4  0x0000000000425f06 in main (argc=1, argv=0x7fff160bd2f8, envp=0x7fff160bd308) at ../../dix/main.c:170
<Sarvatt> looks like it's dying in the AbortServer(); call in FatalError, AbortServer() just doing SigAbortServer(0) and the old AbortServer() was renamed to SigAbortServer()
 * Sarvatt is messing around with the rethrow signals patch
<bryce2> cool
<bryce2> sort of.  The old AbortServer() is still there and still works as it did before, it just calls SigAbortServer with a 0 argument
<bryce2> this way, the API doesn't break
<Sarvatt> so its going to FatalError, prints the FatalError messages, gets down to AbortServer() which calls SigAbortServer(0), thats supposed to call SigAbortDDX(0) which is in hw/xfree86/common/xf86Init.c why doesn't that show up in the backtrace? it's getting called because  ddxSigGiveUp: Closing log is in the output and thats an ErrorF string in that function
<Sarvatt> http://paste.ubuntu.com/367125/
<bryce2> yeah I suspect printing to the log after the log has been closed might be the source of the crash bug
<Sarvatt> the trash after ddxSigGiveUp and before the first backtrace is gone when I disable 168_glibc_trace_to_stderr.patch 
<bryce2> so if you spot anywhere that it is calling ErrorF after the point where the log has been closed, we may want to try disabling those ErrorF's
<Sarvatt>      xf86CloseConsole();
<Sarvatt>  +    ErrorF (" ddxSigGiveUp: Closing log\n");
<Sarvatt>      xf86CloseLog();
<Sarvatt> maybe move the ErrorF up above the xf86CloseConsole()?
<bryce2> Sarvatt, try commenting that out
<bryce2> in the patch change the line to  +    /* ErrorF (" ddxSigGiveUp: Closing log\n"); */
<Sarvatt> yeah thats building now
<mdeslaur> so, when is nouveau kms supposed to hit the lucid kernel?
<Sarvatt> darn, didn't fix it
<Sarvatt> dont think its ever going to hit the lucid kernel mdeslaur, they are working on making a linux-backports-modules-nouveau though
<mdeslaur> ah, that would do...I want to try nouveau again, but it only suspends with kms support, AFAIK
<bryce2> mdeslaur, I have it installed and running with kms
<bryce2> mdeslaur, I've a desktop box here in the desktop room hooked up to the projector if you want to tinker
<mdeslaur> bryce2: you have a special kernel?
<bryce2> mdeslaur, yeah the l-b-m ppa sarvatt mentioned
<Sarvatt> mdeslaur: it only works with KMS period right now, did you have to disable KMS to use nouveau before?
<bryce2> it's from apw's ppa
<Sarvatt> they ripped out non-kms support
<mdeslaur> Sarvatt: oh! I didn't know that...
<mdeslaur> bryce2: ah, cool, thanks
<Sarvatt> mdeslaur: https://edge.launchpad.net/~xorg-edgers/+archive/nouveau
<mdeslaur> thanks, I'll try that next week
<Sarvatt> can't say I feel comfortable with all the changes to accomidate l-b-m instead of just using nouveau-kernel-source and building it locally with dkms, i dont think either will coexist with radeon/intel either way and the xserver changes only really make sense if nouveau is there by default which it isnt with lbm
<Sarvatt> people wont be able to use updated kernels that have nouveau with the libdrm changes to accomidate lbm-nouveau too
<mdeslaur> ouch
<Sarvatt> no luck commenting out that ddxSigGiveUp ErrorF. one thing I noticed is with the patch and X -verbose its got an extra line (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor
<Sarvatt> (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor
<Sarvatt> (WW) xf86OpenConsole: VT_GETSTATE failed: Bad file descriptor
<Sarvatt> without the patch I just see (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor
<Sarvatt> (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor
<Sarvatt> its reopening the console after xf86CloseConsole and before xf86CloseLog because it said that before the ddxSigGiveUp ErrorF that was between them
<bryce2> hmm
<Sarvatt> hmm 121_only_switch_vt_when_active.diff 
<Sarvatt> yeah that xf86OpenConsole is from 121_only_switch_vt_when_active.diff which I had dropped in the xserver i'm using on this machine and not the other, dropped that patch and it still crashes the same though. darn red herrings
<bryce2> heh
#ubuntu-x 2010-02-02
<Sarvatt> vish, that was fast - http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=77b13a02c70842a58e0590d0243f0ae016c5a640
<Sarvatt> let me know if its working for you
<tjaalton> hmm, do we even have an fglrx that works in lucid?
<tjaalton> kinda funny to ask people test it..
<vish> Sarvatt: sure, it seems to be working fine.. [although i didnt know what triggers it to happen] I'll watch the gdm log for a week for any activity
<vish> also , shouldnt the errors go to Xorg.0.log ? i think that would need to be corrected too?
 * Ng spies an ubuntu job advert for an X integration engineer
<Sarvatt> yeah i was thinking the thing tjaalton :D
<Sarvatt> hmm
<Sarvatt> libdrm_radeon and libdrm_nouveau are missing from ia32-libs
<Sarvatt> bryceh: http://paste.ubuntu.com/367635/ :)
<Sarvatt> (with 100_rethrow_signals.patch)
<Sarvatt> uncommented line 302, stops segfaulting when things FatalError  http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/100_rethrow_signals.patch;h=97545e5e5e75151537e40ccd611ae3c5067d0797;hb=refs/heads/ubuntu
<tjaalton> Sarvatt: yeah, maybe I should merge mesa/libdrm so -ati can be synced. then we'd have preliminary r800 support..
<hyperair> hmm ubuntu-x-swat regression testing eh
<hyperair> but nvidia geforce 2 and above?
<hyperair> are we testing nouveau?
<hyperair> i mean nvidia hasn't exactly been very nice with their -96 drivers.
<jcristau> catching fglrx regressions early.  is that a joke?
<hyperair> they claim they maintain it, but it's still a pile of crap that makes my screen quiver like jelly.
<bjsnider> nvidia lacks the resources to properly maintain the old drivers
<Sarvatt> tjaalton: you dont even need to update libdrm or mesa, the r800 support is 2D non KMS only. i doubt r800 dri will make it until mesa 7.9 even since 7.8 is going to branch in a week or two to get ready for release
<Sarvatt> i was just guessing they have a fglrx that works with xserver 1.7 for people to beta test, don't know why they said geforce 2 or higher also since there is no nvidia proprietary driver that works for geforce 2's on xserver 1.7 as far as I know
<Ng> ask ara :)
<hyperair> too late.
<hyperair> 8 seconds too late ;-)
<Sarvatt> lol
<hyperair> i can't wait for nouveau to spawn proper 3D support for nv1X
<hyperair> then i won't have to put up with a jelly-like screen
<Sarvatt> i dont think it ever will?
<hyperair> =(
<Sarvatt> they were doing mesa classic for that
<hyperair> it said it was in progress
<Sarvatt> oh?
<hyperair> i mean..
<hyperair> WIP
<hyperair> in the feature matrix
<hyperair> http://nouveau.freedesktop.org/wiki/FeatureMatrix
<Sarvatt> ah I mean I dont think it'll be gallium based like nv20+ ones are, they're doing a classic mesa driver for those old ones as far as I know
<jcristau> Sarvatt: yep, looks like they're moving that way
<hyperair> i see.
<hyperair> but why separate them?
<hyperair> are the nv10+ ones so old that gallium just won't work or something?
<jcristau> yes
 * hyperair sighs =\
<Sarvatt> its a shame they sold nv1x cards for so darn long, people were buying up those geforce mx's for years and years after they were junk :D
<hyperair> heh lol
<hyperair> i think mine was bought while it was still one of the better cards around
<jcristau> i don't even know what family mine is.  10de:018a.
<jcristau> but then it's old enough that it may not see something newer than lenny, so.
<indus> hi
<indus> is this the ubuntu X team?
<tjaalton> Sarvatt: oh right, -ati only depends libdrm 2.4.17, not -1
<tjaalton> +on
<indus> hello
<indus> i read on phoronix about the fglrx driver and i would like to test it
<indus> i have a radeon 4850
<superm1> i dont think that article is accurate
<superm1> 8.660 is the same driver that was in karmic
<indus> i read the mailing list 
<indus> from ara
<superm1> did ara ever say there was a new driver though?
<indus> this one https://lists.ubuntu.com/archives/ubuntu-qa/2010-February/000775.html
<indus> hmm i guess no
<ara> indus, can you send me an email, instead, please
<indus> ara, yes sorry i wil;
<indus> will
<ara> indus, thanks
<indus> but just want to make sure if this is for lucid
<indus> ok nvm ill send an email
<ara> indus, yes ,it is for lucid
<indus> ok mail coming up
<indus> ara, sent
<ara> indus, thanks, I will get back to you later this week
<indus> ok no problem
<indus> bye then
<indus> thank you
<indus> one question about the open source driver, does it support the 4000 serries ATI
<jcristau> yes
<indus> hmm didnt think it did, i mean straight from the lucid repos or with ppa
<jcristau> no ppa.
<indus> ok cool i test lucid today then
<indus> bye and thanks
<tjaalton> ara: so there's a new fglrx for the testers to try?
<ara> tjaalton, not sure, but the point is that they don't get properly tested, anyway
<tjaalton> ara: the current one doesn't work with the xserver in lucid
<tseliot> ara, tjaalton: there's no new fglrx to test yet but we'll have something in time for the release. I don't think I'm allowed to say more about it
<tjaalton> tseliot: too late for testing though
<tseliot> tjaalton: I can't tell you when but yes, there might be little time to test it
<tjaalton> since I doubt they'll be able to fix it in time when issues pop up
<tseliot> tjaalton: well, they have their own schedule..
<tseliot> but of course I agree with you on this
<tjaalton> slackers :)
<tseliot> ;)
<bryce_> heya
<bryce_> tjaalton, yeah the purpose of the testing is not to do a one-off test of the latest, but rather to do regular weekly testing, so if some change elsewhere in the system breaks the proprietary drivers, we'll have a chance to catch it
<bryce_> tjaalton, this is to help us avoid the situation we hit last release where we didn't really notice -nvidia had been badly broken by the upstart changes until the week after release
<bryce_> so it's good they'll start testing before we get new -nvidia/-fglrx, so they can get a good baseline to compare against
<bryce_> ara, I noticed that this morning 5 people joined the Ubuntu-X team :-)
<ara> bryce_, I will pass you later on the list of volunteers... it's crazy... I have been all morning processing emails
<bryce_> wow
<bryce_> ara, good work :-)
<ara> bryce_, hopefully some of them will stick around :D
<bryce_> yeah
<tjaalton> bryce_: ok
<bryce_> tjaalton, btw for the shlibs stuff, what would be a good example package for me to look at?  I was modeling it after libxrandr, is there a better package to look at?
<Duke`> grumbl... google street map is really a killer feature
<tjaalton> bryce_: libdrm
<Duke`> "killer", that's the word
<tjaalton> bryce_: but maybe it's overkill if libeagle is going away anyway
<bryce_> ok
<superm1> tseliot, have you started any of the work to port fglrx packaging over to the new way of doing things?  I made some changes on phorogit, so just wanted to make sure you are set up and good to go with operating on there so we dont step on each other's toes if one another does a few more pieces
<tseliot> superm1: not yet. I'm in Portland at a sprint and I should be able to do it soon
<superm1> tseliot, okay well just make sure to check phorogit in case i get any of that in order before you do
<superm1> i switched the package name over to fglrx already
<tseliot> superm1: also, I will make additional changes to both jockey and nvidia which will apply to fglrx too
<superm1> Ok
<tseliot> superm1: sure
<tjaalton> why does jockey offer fglrx?
<tjaalton> even if it doesn't work
<tjaalton> there are several bugs against xorg-server because of that
<tjaalton> like bug 508860
<ubottu> Bug 508860 on http://launchpad.net/bugs/508860 is private
<tjaalton> duh
<tjaalton> bug 508860
<ubottu> Bug 508860 on http://launchpad.net/bugs/508860 is private
<tjaalton> like hell it is
<tjaalton> anyway..
<bjsnider> tjaalton, getting a bit upset with fglrx?
<bjsnider> it's the best option, after all of the others
<tjaalton> bjsnider: eh? I just don't like seeing dozens of crashers against xorg-server
<tjaalton> +filed
<jcristau> pretending fglrx doesn't exist works fine for me so far :)
<superm1> tjaalton, maybe it's a good idea to improve the xorg-server apport hook to go and change the package to fglrx-installer immediately if it sees *fglrx* installed on the system
<superm1> and likewise for nvidia
<superm1> that'll at least keep the bug reports clean
<tjaalton> superm1: true
<tjaalton> superm1: though now you can have them both installed at the same time, so why bother? :)
<superm1> haha. well then at that point - go and query if fglrx is modprobe'd or nvidia and adjust package accordingly
<tjaalton> yeah that's a better metric
<tjaalton> same goes for the virtualbox crashers
<tjaalton> there are maybe hundreds of dupes
<tjaalton> most moved to vbox of course
<superm1> tjaalton, okay well just piggyback that on https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/516264
<ubottu> Ubuntu bug 516264 in xorg-server "Xorg-server apport hook should detect fglrx/nvidia" [Undecided,New]
<superm1> might as well solve all those in one swoop if possible
<tjaalton> superm1: done
<bjsnider> does vbox take down the kernel that much?
<superm1> regardless of how often it's taking down xorg-server, if it's providing external pieces in, it shouldn't be lodging it's bugs in xorg-server's set of bugs
<RAOF> bjsnider: You were after 3D support in nouveau for your ancient nvidia card?  The DDX already registers a different glx provider on those old cards, and it looks like a sorta-functional nv0x - nv2x driver is on its way to be merged back into mesa.
<bjsnider> RAOF, i wasn't
<RAOF> Ah, sorry.  'twas hyperair.
<hyperair> RAOF: =O
<hyperair> that's great news!
<hyperair> what's DDX?
<RAOF> The X component of the driver stack.
<hyperair> ah
<RAOF> Current status of that 3D is apparently, and I quote: âHowever the killer feature is 'it actually draws stuff'â
<hyperair> xD
<hyperair> well isn't that nice.
<RAOF> (And some simple games may even run at a decent FPS)
<hyperair> oho, really?
<hyperair> it won't be outclassing my i965 anytime soon eh =p
<bjsnider> it wouldn't be very fast even if the code was a perfect as if god has written it, i imagine
<hyperair> well if compiz works i'm happy.
<hyperair> or would that be expecting too much? =p
<bjsnider> compiz, that thing that's being replaced by gnome-shell?
<hyperair> gnome-shell's not replacing compiz anytime soon on my macine(s)
<RAOF> Given that the much, much better developed nv4x & nv5x gallium drivers *mostly* run compiz, I think you may be expecting a liiiitle too much.
<hyperair> RAOF: heh figures. i'll just scrap GNOME and jump to LXDE or something on that machine.
<hyperair> bjsnider: i don't suppose nouveau would run the shell either, would it?
<bjsnider> it's opengl either way
<bjsnider> it's  not xrender
<hyperair> compiz is opengl too, isn't it?
<bjsnider> yeah, that's what i mean
<hyperair> so both won't work eh
<hyperair> well, at least compiz++ brings support for crippled drivers
<hyperair> gnome-shell doesn't, and probably will never
<hyperair> not to mention that it eats eats more RAM than firefox does >_>
<bjsnider> how do you know?
<hyperair> bjsnider: iirc there was an argument on some mailing list or other.
<hyperair> something about the shell not getting a backward compat mode, because of the way it's designed, blah blah blah drivers should have been fixed by then, blah blah something about we shouldn't hold ourselves back because of a few crap drivers
<bjsnider> i don't think anything's written in stone
<hyperair> but the most fun part is how they keep convincing themselves that compiz is a pile of bloated crap that brings nothing but eyecandy and no usability features when gnome-shell takes up 5x the amount of memory compiz does.
<bjsnider> compiz is bloated crap
<bjsnider> there's no question about it
<hyperair> well then, so is GNOME.
<hyperair> and the shell is 5x more bloated than compiz, so where does that put it?
<hyperair> bloated, incomplete, unusable crap?
<bjsnider> it's certainly incomplete
<hyperair> right, and while it's this incomplete, it's already eating up 5x the amount of memory compiz does.
<bjsnider> i'm using it right now, so it can't be considered unusable
<hyperair> when it's complete, how much will it take?
<hyperair> right, so it's "usable", but nowhere near the usability compiz gives me.
<jcristau> hyperair: when it's complete you'll have 1TB memory.  and a flying car.
<hyperair> just for the record, i like having my screen edge triggers at the bottom of my screen.
<hyperair> jcristau: that sounds about right, yeah.
<bjsnider> usability, like, animated transparent gears, snow, and fire on the desktop?
<hyperair> jcristau: no actually, i don't think it'll ever be completed. halfway along the line, they're going to decide that it's become very unmanageable, akin to gnome-panel, and scrap it for a... GNOME SHELL2!
<hyperair> bjsnider: there. that's the problem with you gnome-shell guys.
<jcristau> gnome-shell-ng
<hyperair> bjsnider: when i say usability, you pick the most useless plugins out of compiz and slam the entire compiz for it
<hyperair> bjsnider: open your eyes damnit.
<bjsnider> hahah
<bjsnider> so you admit that there is feature bloat in compiz
<hyperair> bjsnider: i disabled those plugins.
<hyperair> bjsnider: but that's all they are. "plugins"
<hyperair> if i toss them out the window, it means that they aren't running, they don't eat up space on my hard disk, and all in all, there is no bloat.
<jcristau> a few compiz plugins should be builtin, the rest should be thrown away.  and then you get something halfway sane.
<hyperair> i like my scale plugin.
<hyperair> it beats anything gnome-shell can offer me at the moment.
<bjsnider> i can't make out the useful ones from the bloat because they're all piled in there together
<hyperair> bjsnider: that's why i told you to open your eyes.
<hyperair> the more you look at those crap demo videos uploaded, the more you think "compiz is all bloat"
<hyperair> because those demo videos attempt to showcase all these useless effects while not actually showcasing any of the really useful ones
<bjsnider> it's not all bloat, only 95% of it is bloat
<hyperair> bjsnider: better than gnome-shell, which can't even match up to 5% of compiz's functionality.
<hyperair> assuming your figures are correct
<bjsnider> sure it does
<hyperair> oh right, if you want to count in memory usage, i suppose gnome-shell achieves 500%
<hyperair> yes
<hyperair> because some random joker decided "let's use javascript!"
<hyperair> and everyone was drugged so heavily that they all agreed >_>
<bjsnider> there's a gnome-shell irc channel where you can voice your complaints directly to the developers...
<hyperair> i nearly got kicked for "trolling"
<bjsnider> hahahaa
<bjsnider> i don't know *why* they would think that
<RAOF> FWIW, I quite like many of the ideas embodied in gnome-shell.
<hyperair> it's utterly ridiculous. they'll bar out your choices, in favour of theirs, and then when you don't agree with it, they blame you for trolling and ignore you.
<RAOF> I don't think that's an accurate description; certainly not of the mailing list.
<hyperair> RAOF: that was on IRC.
<Cobalt> Every new idea is not necessarily a good idea. Gnome-shell stinks a bit.
<bjsnider> new features have been added that you can check out in rico's ppa
<RAOF> Ubuntu-X: All gnome-shell, all the time. :/
<bjsnider> i think that's the one
<bjsnider> well, they kicked us out of the gnome-shell channel because they thought our hectoring and badgering was trolling, but we really have good ideas
<hyperair> don't get me wrong, i love GNOME and it pains me to have to move to anywhere else, but i want my panel, and i want my compiz. otherwise you let me have back my bottom screen-edge triggers, my infinitely customizable keybindings, and something akin to scale + scale addons + scale text filtering
<Cobalt> hyperair: Problem is, they'll dumb it down enough to the point of not giving you a choice of having it back.
<hyperair> Cobalt: yeah, exactly.
<Cobalt> And bill it to the price of progress. And brilliant new ideas. Of how to interact with your data. Never mind that over the years you already streamlined the way you do things, and are quite happy for things to go on the same way.
<bryce_>  tjaalton, superm1, I added a thingee to apport to detect if the user is running vbox and if so tell them the issue is unreportable
<bryce_> tjaalton, superm1, that's been in there for some months, so if we're *still* seeing vbox bugs filed against xorg-server we should see how those are coming in
<bryce_> I agree we should exclude them
<RAOF> bryce_: Did you get in contact with nvidia re: nouveau ctxprogs?  Have you heard back?
<bryce_> RAOF, not yet, I did just touch base with a couple of the kernel engineers
<RAOF> Did they have anything interesting to say?
<bryce_> yes
<RAOF> I'm currently preparing something approximating a debian/copyright for a nouveau-firmware package to add to the testing packages in xorg-edgers/nouveau.  Should I stop?
<bryce_> RAOF, the kernel team is looking at how it should be packaged, probably in some separate package.  andy will get back to us on it
<bryce_> RAOF, continue on with it
<bryce_> we're not taking it as a blocker at this time
<RAOF> Ok.  Once I've got that bit, I was thinking of writing a call-for-testing to ubuntu-x & ubuntu-devel; those bits in xorg-edgers/nouveau should (a) not break anything on non-nvidia hardware, and (b) work.
<bryce_> that sounds great
<bryce_> RAOF also andy said he can update the kernel
<bryce_> we also talked about supportability post-release
<bryce_> he said that the kernel team has an exception from having to do srus for linux-backport-modules
<bryce_> so if we take the approach of having nouveau in l-b-m then it gives the flexibility of putting out new git snap shots of the driver post-release if it looks sane enough to do so
<RAOF> That would be good.
<bryce_> I also asked if we can also include the nvidia binary package from l-b-m on the livecd, and he said that should be doable; we'd need to go through the foundations team for that
<RAOF> So we wouldn't have to try to backport commits.  Great.  I notice that there are a bunch of nv5x fixes pending on the nouveau mailing list already :)
<RAOF> Would that mean that l-b-m-nouveau would be pulled in by the kernel metapackage?
<bryce_> right
<RAOF> Excellent.
<RAOF> Ok.  I'm going to stop stressing about debian/copyright and just put in all the information I think is pertinent.  Someone else is going to need to go over it anyway!
<bryce_> sounds good
<bryce_> thanks for raising it as an issue, I've added to my todo list to follow up on it later on and make sure everything's square
<bryce_> RAOF, mirco's borrowing the desktop today but I think tomorrow I'll get nouveau going on it again and re-test stuff.  I'd really like to get compiz running successfully, and sort out why it's not vt-switching
<RAOF> bryce_: You'll need newer dri2 protocol headers if you want to build mesa from git (and it's really the only way to fly ;)).  If it's a GeForce8 or newer you'll also need the nouveau-firmware package before any acceleration works.
<bryce_> ok thanks, yeah it's a G86, so perhaps that's why compiz failed
<RAOF> Yes.  It might also be why VT switching is failing, but I'd hope not.
<bryce_> tseliot, <brian> bryce_: so my the usb id for my tablet isn't in 69-xserver-xorg-input-wacom.rules fwiw
<tseliot> bdmurray, bryce: does it work correctly if you add your id in the udev rule?
<bdmurray> tseliot: I haven't tried yet, add it and then what?
<superm1> bryce_, not sure if the vbox stuff is still showing up.  just know the fglrx/nvidia is
<bryce_> superm1, yeah I didn't fuss with that in the apport rule
<tseliot> on next boot (as you can't unplug it) the device should be detected and should show up in "xinput list"
<tseliot> and work
<bryce_> however I do have a script to process the xorg queue and look for nvidia/fglrx bugs and move them to fglrx-installer or nvidia-{mumble}
<jcristau> you can fake unplug it
<bryce_> superm1, I think we could probably improve the apport script itself to file the bug directly
<jcristau> udevadm trigger --action={add,remove} or something
<jcristau> or stuff an event in sysfs
<superm1> bryce_, so can't you just change the Package in the crash report in those scenarios?
<bdmurray> tseliot: so what would I use for SYMLINK in the udev rule then?
<bryce_> superm1, yep that's exactly what I meant
<superm1> cool, glad we're on the same page :)
<tseliot> bdmurray: I guess "input/tablet-$MODEL_NAME" should be fine
<tseliot> whatever your model iss
<tseliot> is
<tseliot> or you can simply call it "input/tablet-brian-test"
<bdmurray> tseliot: no change afaict
<tseliot> bdmurray: if that didn't do it, you might want to ask the kernel team about it
#ubuntu-x 2010-02-03
<ripps> lucid ati drivers still use mesa, right? I thought that gallium3d was ready for ati now.
<RAOF> radeon gallium is still pretty new; I don't think *any* of the gallium drivers are ready for primetime yet.
<RAOF> Including the intel one, which has been going the longest :).
<RAOF> I could be wrong, though.  I don't pay that much attention to the radeon side of things.
<jcristau> the intel one is probably the least ready
<RAOF> Which seems odd, but I presume is due to laribee slipping and slipping and slipping.
<jcristau> or maybe i don't know which one you're talking about.  there's probably a poulsbo gallium driver.  but meh, poulsbo.
<RAOF> Not one that we have the source to, I presume :)
<jcristau> right
<RAOF> My memory is correct, right?  Tungsten Graphics, of Intel-driver fame, started gallium?  As what seemed to me to be a project to make Intel's upcoming Larribee super-x86 GPU work?
<NoelJB> As of today, I have a situation where (and I have uninstalled and reinstalled to check), 2.6.32-11 works with nvidia-current, and 2.6.32-12 will start with it, but as soon as I open a terminal window and do nothing other than hit <cr>, the system hangs (requires hard power-off).
<NoelJB> weird thing is that it was working earlier today.
<tjaalton> bdmurray: if it's a serial tablet it won't work yet
<tjaalton> oh, usb id..
<tjaalton> nevermind then
<tjaalton> * Add klingon language definition.
<tjaalton> in libx11...
<tjaalton> like that's ever going upstream?
<tjaalton> and failed to build
<libv> that'll really help the spread of the linux desktop.
<tjaalton> "look, even trekkies love it"
<libv> the marketing potential of that is enormous.
<libv> trekkies are also a big and popular subculture
<libv> especially known for their low geek count :)
<libv> the uptake of free software with trekkies, since they spend soo much time watching telly and playing trekkie windows/console games, must be very low
<libv> so the potential of growth there is enormous!
<libv> and what young boy doesn't dream of being able to use the ever so popular "openoffice turned my homework into klingon" excuse
<tjaalton> tlhIngan maH!
<libv> is there a definition for vulcan?
<tjaalton> no, that should be fixed
<libv> right, because otherwise this whole brilliant world domination scheme will fail
<libv> s/world/space/
<Sarvatt> RAOF: need to have lbm-nouveau conflict with all the nvidia-stuff it looks like
<Sarvatt> [   26.151671] NVRM: The NVIDIA probe routine was not called for 1 device(s).
<Sarvatt> [   26.151675] NVRM: This can occur when a driver such as rivafb, nvidiafb or
<Sarvatt> [   26.151677] NVRM: rivatv was loaded and obtained ownership of the NVIDIA
<Sarvatt> [   26.151678] NVRM: device(s).
<Sarvatt> ah nevermind that was because of my xorg.conf from the nvidia package, thats why it was so late into the boot
<Sarvatt> hmm, why did X start with display :0 on vt1 with nouveau? http://sarvatt.com/downloads/nouveau.1.log
<Sarvatt> also, XAA? RAOF, how did you change the nouveau probe routine to always asume KMS?
<tjaalton> Sarvatt: the log is with -nv btw
<Sarvatt> argh thanks tjaalton
 * Sarvatt needs morning coffee before messing with these things :)
<Sarvatt> so the xserver patch didnt work there
<Sarvatt> ah my fault of course
<Sarvatt> thats the machine i was playing with 100_rethrow_signals.patch on so i had the same version
<_stink_> hey folks - i'm playing around with X drivers.  little question: i see that x drivers in packages are .so files.  when i compile a sort-of-obscure x driver, the ./configure;make ends up with a .la file.  i'm vaguely aware that these are different, but can X load the .la if i put it in the module directory along with the other .so files?
<jcristau> no
<jcristau> you should get a .so with the .la
<_stink_> ok.  any hint on the linking or whatever step that's missing that i need to get the .so?
<jcristau> there isn't one.  libtool gives you a .so together with the .la
<_stink_> ok.  thanks for the info!
<Sarvatt> http://sarvatt.com/downloads/nouveau.2.log
<_stink_> oh, huh, didn't even look at the .la.  silly me.
<_stink_> i thought it was binary.
<Sarvatt> things look good this time
<kklimonda> hey, how can I debug not working xv with nouveau driver in lucid? The one posted on mailing list today. xvinfo says no adaptors present but it worked just a moment ago (maybe a restart ago)
<Sarvatt> the lbm stuff is loaded unconditionally if you have nvidia hardware though, nvidia isn't working when its installed at the same time
<Sarvatt> what does cat /var/log/Xorg.0.log | grep Xv say?
<kklimonda> empty
<kklimonda> grep XV shows: (II) Loading extension XVideo
<kklimonda> (II) Loading extension XVideo-MotionCompensation
<Sarvatt> pastebin the whole log?
<Sarvatt> sarvatt@arcueid:/etc/X11$ cat /var/log/Xorg.0.log | grep Xv
<Sarvatt> (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video.
<Sarvatt> (II) NOUVEAU(0): [XvMC] Extension initialized.
<kklimonda> http://pastebin.com/f4d9e8f42
<Sarvatt> (EE) NOUVEAU(0): Error creating GPU channel: -16
<Sarvatt> (EE) NOUVEAU(0): Error initialising acceleration.  Falling back to NoAccel
<Sarvatt> do you have the nouveau firmware installed?
<Sarvatt> i had it installed before i installed the ppa packages so i'm not sure about that part, lets see
<kklimonda> yes, I have
<Sarvatt> dmesg | grep firmware show it loading both?
<Sarvatt> [    2.085401] nouveau 0000:05:00.0: firmware: requesting nouveau/nv86.ctxprog
<Sarvatt> [   13.683234] nouveau 0000:05:00.0: firmware: requesting nouveau/nv86.ctxvals
<kklimonda> yes - both
<Sarvatt> kklimonda: sorry, had to run to a job there, would you mind putting your dmesg on pastebin too?
<Sarvatt> kklimonda: don't know if you saw my message because of the split right after but would you mind putting your dmesg on pastebin too?
<kklimonda> Sarvatt: http://pastebin.com/f18c60795
<Sarvatt> hmm, and it happens every boot? [   17.394177] [lbm-drm] nouveau 0000:01:00.0: GPU lockup - switching to software fbcon is the only thing that stands out compared to mine
<kklimonda> well, not every boot because it worked once - but since then I get this GPU lockup every time
<kklimonda> once as at one boot :)
<Sarvatt> oh just realized i have quiet splash removed from the kernel command line still because nouveau had problems with it in the past, lets see if it works with it there now :) we have basically the same GPU
<Sarvatt> indeed thats the problem
<Sarvatt> (EE) NOUVEAU(0): Error creating GPU channel: -16
<Sarvatt> (EE) NOUVEAU(0): Error initialising acceleration.  Falling back to NoAccel
<Sarvatt> remove quiet splash from your /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="quiet splash whatever" line and update-grub after will fix it for now, I know thats no real fix
<Sarvatt> actually, I ran update-initramfs -u between those reboots as well, let me make sure it wasnt that first
<Sarvatt> i had that problem in the past for a long time though and i had to remove quiet splash to work around it
<Sarvatt> i did the update-initramfs because I noticed your ctxvals was getting loaded right after ctxprogs and mine was getting loaded 12 seconds after
<Sarvatt> and now its getting loaded at the same time
<Sarvatt> yep it was quiet splash, removed it again and it works
<Sarvatt> (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video.
<Sarvatt> (II) NOUVEAU(0): [XvMC] Extension initialized.
<Sarvatt> (this kind of defeats the whole purpose of nouveau KMS getting brought in so early for the nice splash across all the major GPU's though)
<Sarvatt> works fine with just quiet, just splash screwing with it
<Sarvatt>   else if (strcmp (driver_name, "nouveau") == 0)
<Sarvatt> yeah plymouth needs a little adapting for lbm-nouveau I think
<Sarvatt> http://cgit.freedesktop.org/plymouth/tree/src/plugins/renderers/drm/plugin.c
<Sarvatt> good news, the plymouth change fixed it
<Sarvatt> line 444 of http://cgit.freedesktop.org/plymouth/tree/src/plugins/renderers/drm/plugin.c
<Sarvatt> changing it to  else if (strcmp (driver_name, "lbm-nouveau") == 0)
<Sarvatt> probably better to just add a new elseif section for lbm-nouveau but I just wanted to see if it would work
<kklimonda> Sarvatt: ok, thanks
<Sarvatt> i'll upload a fixed plymouth to that PPA
<Sarvatt> if i can figure out a versioning change that wont screw with the shlibs..
<Sarvatt> http://sarvatt.com/downloads/patches/0001-src-plugins-renderers-drm-plugin.c-Add-check-for-lbm.patch
<Sarvatt> ^ non-intrusive plymouth patch to work with lbm-nouveau without wiping out normal nouveau support, works here
<Sarvatt> heyo bryce, if you were using the nouveau on edgers/nouveau ya have to remove splash to get acceleration it looks like, plymouth has to be adapted to the lbm-nouveau module name to use the drm renderer otherwise its screwing with the framebuffer and not initializing properly in X
<bryce2> Sarvatt, ok thanks
<Sarvatt> i'm not sure what version i should call the new plymouth in the PPA though, its really odd
<Sarvatt> plymouth (0.8.0~-8)
<Sarvatt> i get shlibs warnings with anything i try
<bryce2> why not 0.8.0~8 ?
<bryce2> or 0.8.0~0ubuntu1~sarvat~1 or similar
<Sarvatt> 0.8.0~-8ubuntu1 doesn't work at least
<Sarvatt> well i guess i'll just do it and ignore the shlibs warnings :D
<Sarvatt> oh weird dpkg-gensymbols: warning: new libraries appeared in the symbols file: libplybootclient.so.2
<Sarvatt> http://sarvatt.com/downloads/patches/0001-src-plugins-renderers-drm-plugin.c-Add-check-for-lbm.patch is the patch to fix it, i linked it on #ubuntu-devel since its not really upstream material since its specific to our nouveau rename just for one release
<bjsnider> refresh my memory: how much has to be removed for the nvidia installer to work? jockey and all of the packaged drivers isn't it?
<Sarvatt> i dont think it'll work at all regardless on lucid with the way things are done now, will it?
<bryce2> Sarvatt, sounds like you need to update the symbols file?
<bjsnider> well, it may not work afterwards, but i mean for the installer to run
<Sarvatt> maybe we should just disable glx-tls in mesa so we dont have to do the whole /usr/lib/mesa or /usr/lib/nvidia-current stuff and can just use an alternative for /usr/lib/libGL directly
<bryce2> Sarvatt, uhh
<Sarvatt> err so mesa's libGL doesn't have to get put in /usr/lib/mesa/libGL.so.1
<bryce2> Sarvatt, run this issue by tseliot first, he may have a better idea for solving that
<tseliot> Sarvatt: ??
<tseliot> why? What happened?
<tseliot> tjaalton: do you know if calibration works for wacom touchscreens? It doesn't seem to work here
<tseliot> it says the calibration property has no items
<tseliot> is it still WIP?
<Sarvatt> tseliot: I was just saying that because we couldn't leave libGL.so.1 in /usr/lib because it wouldn't take the alternatives due to the tags because of tls and I might be missing something but noone can install nvidia drivers directly from nvidia with how our libgl is an alternative always now
<Sarvatt> plus I have no idea about this - https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/259219
<ubottu> Ubuntu bug 259219 in mesa "Broken TLS support in libGL.so" [Undecided,Confirmed]
<tseliot> Sarvatt: right, I haven't worked on the installer yet
<tseliot> Sarvatt: that bug has been there since intrepid
<Sarvatt> ugh, I miss my htc dream, this new phone has horrible reception
<Sarvatt> bryce2: libplymouth2.symbols is entirely 0.8.0~ and I didnt touch any of these things getting shlibs warnings, i think the current package probably had the shlibs warnings.. i'll just version it 0.8.0~-9~nouveau I guess
<Sarvatt> spinfinity seems to be the best plymouth plugin IMO
<Sarvatt> solar has way too much cpu usage, spinfinity doesnt hardly use more than the default one and the progress bar looks muuch nicer
<Sarvatt> the bar takes up the whole bottom of the screen instead of being offcenter under the ubuntu logo
<tjaalton> tseliot: what tool are you using?
<tseliot> tjaalton: xinput
<tseliot> Sarvatt: we'll use our own plymouth theme
<tseliot> (not the one which is currently in Lucid though)
<Sarvatt> tried xsetwacom tseliot?
<tseliot> Sarvatt: with the new wacom driver? Would it work?
<tjaalton> tseliot: there are at least two calibration tools, recently discussed on xorg@. apparently they work and so should xinput
<jcristau> Sarvatt: did 259219 ever get forwarded upstream?
<tjaalton> tseliot: if you are using evdev..
<tseliot> tjaalton: I'm getting 3 wacom devices
<tjaalton> tseliot: so use the wacom tools
<Sarvatt> i dont think so, tjaalton brought it up on dri-devel a few years ago it looks like but no responses
<Sarvatt> ok uploaded the fixed plymouth to xorg-edgers/nouveau, should be fixed when you get that update kklimonda 
<kklimonda> Sarvatt: thanks
<tjaalton> bbl ->
<Sarvatt> kklimonda: no thank you for testing it, wouldn't have seen that bug otherwise :D
<Sarvatt> what do we want to do about nouveau coexistance with nvidia?
<Sarvatt> we need a conflicts somewhere, nvidia doesnt work with lbm-nouveau installed since that takes over the device before nvidia can, and there are a bunch  of libgl errors with the nvidia libgl still hanging around while using nouveau
<tseliot> tjaalton: I'm using xsetwacom but things such as Rotation don't seem to work
<tseliot> Sarvatt: I've just uploaded a fix for that
<tseliot> I'm about to do the same for -173 and -96
<tseliot> all we need to do is put the blacklist file in the initramfs
<tseliot> so that nouveau is blacklisted early
<tseliot> is this what you were referring to?
<Sarvatt> kind of
<Sarvatt> that'll fix nvidia to work but theres still the problem getting nouveau to work with nvidia installed
<tseliot> Sarvatt: why? If you switch to nouveau, do ldconfig and reboot it should work
<Sarvatt> are you blacklisting lbm-nouveau or just nouveau?
<tseliot> just nouveau
<tseliot> what's lbm-nouveau?
<Sarvatt> its called lbm-nouveau in what we're going with
<Sarvatt> linux-backports-modules-nouveau
<tseliot> aah, so you're backporting the whole thing
<Sarvatt> apw renamed all the relevant modules lbm-* to not interfere with the normal ones
<Sarvatt> thats why I had to do that change in plymouth since it was just looking for nouveau to use the drm renderer
<tseliot> let me correct myself: you should switch to nouveau, do ldconfig, update the initramfs and reboot
<Sarvatt> plus remove the xorg.conf..
<tseliot> Sarvatt: ah, do you mean it was trying to use plymouth+nouveau drm with nvidia?
<Sarvatt> right now i have nvidia-current and nouveau installed, if nvidia-current is installed ldconf is still going to prefer the nvidia-current libgl isnt it?
<tseliot> Sarvatt: it depends on what you set the alternative to
<tseliot> update-alternatives --display gl_conf should tell you what is set to
<Sarvatt> nope plymouth's nouveau drm renderer plugin was hardcoded to look for the nouveau module and i had to add another match for lbm-nouveau for it to use it -- http://sarvatt.com/downloads/patches/plymouth-lbm-nouveau.patch
<Sarvatt> do we want to allow nvidia and nouveau to coexist on the system? wont it always prefer the nvidia libGL.so.1 if nvidia is installed becaue of the priorities?
<Sarvatt> plus we dont want the nvidia xorg.conf to be there if someones using nouveau
<Sarvatt> I know they can change the alternative manually its just doesn't seem like something we should expect a normal user to do to me
<Sarvatt> are you using an intuos3 tseliot? spotted a kernel rotation fix for intuos3 tablets that might not be in 2.6.32
<Sarvatt> ah nope its in 2.6.32
<kklimonda> Sarvatt: still no luck - I've even removed quiet and splash.. It worked at least once but after reboot I'm still getting "GPU lockup" in my dmesg.
<Sarvatt> hmmm, odd because i could reproduce the exact errors and it was fixed here
<Sarvatt> might have screwed up the packaging
<Sarvatt> built it locally on another machine where i had the problem and packaged it on this one, wouldn't put it past me to have applied the patch in the wrong terminal :D
<kklimonda> Sarvatt: I've checked source package already and your patch is there
<Sarvatt> yeah indeed it is.. 
<Sarvatt> so its still giving the gpu channel -16 error in the Xorg.0.log?
<kklimonda> yes
<Sarvatt> unrelated but i just noticed a little problem with the nouveau detection patch for xserver RAOF is using
<Sarvatt>                 Screen  "Builtin Default fbdev Screen 0"
<Sarvatt>                 Screen  "Builtin Default vesa Screen 0"
<Sarvatt>                 Screen  "Builtin Default fbdev Screen 0"
<Sarvatt> (loading fbdev twice)
<Sarvatt> its odd its setting the resolution so late for you
<tseliot> Sarvatt: nvidia and nouveau can coexist and if you switch to the alternative provided by nouveau you will get mesa's libGL.so.1
<Sarvatt> yeah but do you really expect users to do that manually?
<jcristau> they can't really coexist because only one of the kernel drivers can own the device though
<kklimonda> Sarvatt: the whole boot is odd and random - after I press enter in grub I get either clean screen or a bit of color characters or the whole screen is set to the weird color (even before resolution is changed). Then either resolution changes and screen stays black or screen shuts down completely and It goes back on only a second before X kicks in.
<tseliot> Sarvatt: no, Jockey should deal with that
<tseliot> jcristau: a reboot will be required. And 
<tseliot> it works here
<jcristau> jockey adds the blacklist as needed when you tell it to switch?
<tseliot> yes, it will, I'm working on it
<Sarvatt> does it remove the xorg.conf too?
<jcristau> ok
<tseliot> Sarvatt: it switches back to whatever was there before. I can make sure that xorg.conf is removed when switching to nouveau 
<Sarvatt> i dont use jockey at all so all of this change just adds a ton more manual configuring to me but I guess I'm in the minority there
<bjsnider> is xorg.conf ever necessary when using nouveau?
<bjsnider> is there an option that needs to be passed to nouveau through xorg.conf?
<Sarvatt> not required with the xserver detection priority changes but plenty of people do use xorg.conf for other options and there is alot of stuff you can tweak in there for it
<bjsnider> maybe it should just be changed from nvidia to nouveau then
<Sarvatt> if you have an xorg.conf and dont specify the driver to use it'll only try to use nouveau and give up with the detection change, at least we dont ship the generic xorg.conf with one device section anymore
<Sarvatt> kklimonda: can you pastebin your dmesg with the newer plymouth? just curious at the changes since the other one
<kklimonda> Sarvatt: http://pastebin.com/f70276761
<Sarvatt> anyone know how to tell what plymouth theme is currently in use?
<Sarvatt> oh yeah both of us are using nouveau.modeset=1, that doesnt do anything so we can drop it :D
<Sarvatt> (the modules lbm-nouveau now and it only has KMS)
<Sarvatt> http://sarvatt.com/downloads/nouveau.3.log
<Sarvatt> theres my logs
<kklimonda> you don't have the huge gap after "[lbm-drm] Initialized nouveau"
<Sarvatt> reinstalling plymouth and libplymouth2 from the PPA just incase
<Sarvatt> had my locally built one installed still
<Sarvatt> because I got the exact same GPU lockup in dmesg and noaccel in X when I had the old plymouth installed
<Sarvatt> ok it works fine with the PPA plymouth here - (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video.
<Sarvatt> kklimonda: sudo update-initramfs -u -k 'all' and reboot
<Sarvatt> i just noticed you booted generic-pae that time and -generic before, plymouth might not have rebuilt all your initrds
<Sarvatt> more like, it DIDNT update all your initrd's, it only does 1 by default
<Sarvatt> so you had the old plymouth in the other kernel's initrd
<kklimonda> Sarvatt: I don't even have plymouth in initrd :)
<Sarvatt> parts of it go in there always afaik, it just doesnt stash the whole theme into it
<kklimonda> Sarvatt: I've done as you asked - no change - but it was just a slip on my part. I have both -generic and -pae installed and I've been testing both after you have uploaded new plymouth to see if there is something different between them. here is the last boot with -generic: http://pastebin.com/f174369d
<Sarvatt> darn, of course it wouldn't be that easy :D
<RAOF> Ah, good.  We're debugging the -pae weirdness?
<kklimonda> RAOF: no - I can't get it to work at all :/
<kklimonda> RAOF: and it worked twice just fine - I've even send you an email ;)
<RAOF> Why didn't I see the plymouth issue on my laptop, I wonder?
<kklimonda> hardware specific? or my gpu is dying again and that's some bizarre symptom..
<Sarvatt> i'm wondering if it has something to do with the mtrr allocation problem
<Sarvatt> you had splash enabled before RAOF?
<Sarvatt> we both had to remove splash from the kernel command line messing with nouveau before and it didnt happen with splash removed
<Sarvatt> thats why I didnt notice it at least
<RAOF> I had splash enabled!  I even switched the plymouth screen to spinfinity.
<RAOF> I *did* see some GPU lockups, but it seemed only when nv loaded, not nouveau.
<Sarvatt> wish we had an updated nouveau, it would display NV_WARN(dev, "failed to reserve VGA memory\n"); if its the MTRR problem
<RAOF> Which part is that?  The kernel module?
<Sarvatt> yeah was looking at this from just after rc4 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ac8fb975e8c88d312a376b035494be17548d01c6
<RAOF> There seem to be quite a lot of fixes streaming into the nouveau kernel module recently.  I could see how easy it is to update linux-backport-modules, if you like.
<Sarvatt> doesn't look too bad but i'm not sure, the scripts are just hardcoded for apw's machines paths
<Sarvatt> wonder why  he picked rc4 for nouveau
<RAOF> Probably because that was about the time we were talking about it.
<Sarvatt> shoot, hopefully I can continue booting with the lid closed after drm/nouveau: report LVDS as disconnected if lid closed since I use that machine headless, my intel doesnt start gdm until I open the lid if i boot closed
<RAOF> :)
<Sarvatt> oh nevermind it has a module option to ignore it too
<bryce2> I was talking with apw about it yesterday
<bryce2> he picked rc4 just because that's what he had at the time.  He hasn't updated it just because he was unsure if anyone was needing it for testing
<bryce2> I told him it'd be a good idea to update it since we're testing on it
<bryce2> he didn't seem to think it would be much work to do it, but I don't know if he's had a chance to look at updating it yet
<RAOF> I might have a look; it can't hurt to learn a little more about it :)
<RAOF> That seems pretty painless.
<Sarvatt> oh yeah looks really easy, updates/UPDATE-NOUVEAU then updates/MUNGE-NOUVEAU.. maybe we should stuff the firmware in there too?
<RAOF> I think the separate firmware package is a better idea for now; that makes it easier to strip out later should we want/need to.
<bryce2> agreed
 * RAOF test-builds the updated linux-backport-modules-nouveau.
<Sarvatt> already done it? i was doing the same
<RAOF> Hm.  Looks like I didn't do it quite right.
<Sarvatt> installing the -server headers to try building it here, you updated the paths in UPDATE-NOUVEAU, ran it then ran MUNGE-NOUVEAU and it didnt work?
<RAOF> When checking the diff against the current package it didn't appear to contain the changes I expected.
<Sarvatt> looks right here
<RAOF> Oh, no; they are there.  There just seemed to be lots of *-> lbm_* changes I wasn't expecting hiding them.
<Sarvatt> http://pastebin.com/f3a17357f
<Sarvatt> oh maybe it runs MUNGE-NOUVEAU in the build process
<RAOF> I think it might, yes.
<RAOF> My build failed looking for double-munged objects.
<Sarvatt> yep it does make[3]: *** No rule to make target `/home/sarvatt/source/linux-backports-modules-2.6.32-2.6.32/debian/build/build-generic/nouveau/lbm_lbm_drm_kms_helper.c', needed by `/home/sarvatt/source/linux-backports-modules-2.6.32-2.6.32/debian/build/build-generic/nouveau/lbm_lbm_drm_kms_helper.o'.  Stop.
<RAOF> Yup.  There it is in debian/rules.d/2-binary-arch.mk
<Sarvatt> makes sense why update wasnt executable and that one was then
<RAOF> Yeah.
<RAOF> Oh, yeah.  That's why it's building compat-wireless again.  Three different kernel flavours!
<RAOF> Delicious!
<tjaalton> tseliot: rotation isn't related to calibration :) and if it doesn't work it's a bug
<tseliot> tjaalton: yes, I know, they are separate issues
<Sarvatt> theres a bunch of rotation changes in wacom git since our snapshot, no idea if theres any fixes there though
<Sarvatt> http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=summary
<Sarvatt> hmm might just affect intuos4 mice
<Sarvatt> eww
<Sarvatt> it no likey the updated module
<RAOF> In what way?  I'm updating mine now.
<Sarvatt> http://sarvatt.com/downloads/nouveau.4.log
<Sarvatt> maybe because the lid is closed, trying with the module parameter now
<Sarvatt> ignorelid:Ignore ACPI lid status (int)
 * Sarvatt ponders making that default on if thats it
<RAOF> Also, FIFODEATH!
<RAOF> I'm not sure why X adds the vesa & fbdev sections to the default config; possibly it *always* adds them.  In which case we need to patch vesa to not blow up horribly in the presence of kms.
<Sarvatt> yeah it does always add those on pc arches
<kklimonda> Sarvatt, RAOF: well, rejoice - my problem disappeared on a clean install. At least for now.
<Sarvatt> oh?
<kklimonda> Sarvatt, my new dmesg looks more or less like yours
<Sarvatt> still would like to know what was hanging around to cause it
<Sarvatt> did you have nouveau-generic or nouveau-generic-pae installed?
<Sarvatt> do you still get the mtrr error?
<kklimonda> yes, I still get it
<RAOF> Does that mean suspend/resume & Xv works for both -generic and -generic-pae for you now?
<kklimonda> RAOF, both seem to work fine with -pae, I'll test -generic in a moment
<Sarvatt> lbm-nouveau.ignorelid=1 fixed my problem with the newer module
<Sarvatt> glad i looked at the changes beforehand
<Sarvatt> RAOF: how did you get in a situation where the servers autoconfiguration actually tried to use vesa or fbdev and caused a problem? you'd have to have nouveau and nv not installed
<Sarvatt> unless you mean in failsafe, thats a different script in /etc/gdm/ forcing vesa there, i have my /etc/X11/xorg.failsafe.conf usinf fbdev to make failsafe work
<RAOF> Sarvatt: For some reason in some cases I found vesa was binding before nv, producing a pretty bloom pattern on my lvds.
<kklimonda> RAOF, works fine now on both -generic and -pae - only issue I have is that before kms kicks in and sets the right resolution I see garbage on my screen
<RAOF> Sarvatt: Where's your newer plymouth?
<Sarvatt> xorg-edgers/nouveau
<kklimonda> and plymouth kicks in way too late
<Sarvatt> yeah nouveau is switching to high rez way too late here too
<RAOF> Hm.  Must be my apt proxy kicking in.  *Now* I can see that.
<RAOF> Plymouth kicks in pretty early for me.  That might just be my nv4x not needing firmware loaded, I guess.
<Sarvatt> RAOF: you said you were using spinfinity? did you plymouth-set-default-theme with --rebuild-initrd to do that? the --rebuild-initrd option seems to be making plymouth work for other people
<Sarvatt> [   14.962137] Console: switching to colour frame buffer device 160x50 14 seconds in :(
<RAOF> Faouwch.
<Sarvatt> trying to sudo plymouth-set-default-theme spinfinity --rebuild-initrd and see if it comes up earlier
<jcastro> hi jbarnes, I ran into this today: https://bugs.freedesktop.org/show_bug.cgi?id=26418
<ubottu> Freedesktop bug 26418 in Driver/intel "[i965] GPU hang on -intel 2.9.1 on Lenovo (triggered by GnomeDo?)" [Critical,New]
<jcastro> jbarnes: I am sprinting with bryce so I am able to do whatever you need
<RAOF> Sarvatt: Takes my laptop 2sec to switch to the colour framebuffer.
<Sarvatt> oh boy, think its hung in plymouth like my intel is doing sometimes, cant ssh in after that reboot :)
<Sarvatt> hopefully its just an extra long fsck
<RAOF> First reboot after rebuilding the initramfs again & plymouth hung before properly starting the spinfinity animation.
<Sarvatt> yeah the first boot after upgrading hung for me as well on 0.8.0~-8
<Sarvatt> looks like it hung on my nvidia laptop too after changing themes and rebuilding
<RAOF> But works the second time around.
<RAOF> Sarvatt: Are you going to uploaad the updated l-b-m-nouveau to xorg-edgers/nouveau?
<Sarvatt> second boot worked fine here too, had to dig that laptop out :D
<RAOF> Oh, man.  It takes so long to load the firmware for your card.
<Sarvatt> its a little screwy, i got the 80x25 text console for most of the boot, then it showed the spinfinity theme for about a second and went to X
<Sarvatt> no progress bar or anything
<Sarvatt> guess it is the firmware loading that slows it down so much :(
<RAOF> Well, that does take a whopping 6 seconds out of your boot time, yes.
<Sarvatt> think i'll try with the firmware-less patch
<RAOF> What's the firmware-less patch?
<Sarvatt> the blob takes 10 seconds to load too
<RAOF> You could try just removing nouveau-firmware for testing.
<RAOF> Everything should still work, as long as you don't mind not having accel.
<Sarvatt> argh didnt bookmark it
<Sarvatt> oh yeah good point
<Sarvatt> it was the patch so nv50 didnt need firmware
<RAOF> Oh?  The voodoo generator patch?
<Sarvatt> yeah
<RAOF> Sarvatt: You're after http://0x04.net/~mwk/gen.diff
<Sarvatt> thats it
<Sarvatt> thanks
<Sarvatt> btw theres a doc in his directory there where it looks like they are working on CUDA support and it says to expect major api breakage soon :P
<Sarvatt> no luck removing firmware
<Sarvatt> http://pastebin.com/f3ebbb01b
<RAOF> So they're working on the final set of ABI changes, then?  Woot.  Excellent timing.
<Sarvatt> in a few months after the other things in the TODO :)
<Sarvatt> its got timetables
<RAOF> It looks like it takes ages to timeout on fetching the firmware.  Maybe the voodoo generator will work better.
<Sarvatt> yeah going to try that now. did you want me to upload lbm or did you want to do it?
<Sarvatt> i'll just upload it and see if it clashes :D
<Sarvatt> just did ~pre2
<RAOF> If you're doing so now, I won't :)
#ubuntu-x 2010-02-04
<Sarvatt> building a new one now with that patch applied to see if it's any faster :)
<Sarvatt> plymouth is kind of useless as-is otherwise since it loads the firmware so slow :(
<RAOF> Yeah.
<RAOF> Checking out nouveau_grctx.c it doesn't look like anything amazingly wrong is happening.
<Sarvatt> sheesh this laptop is burning hot with nouveau
<Sarvatt> WHOOPS
<Sarvatt> nevermind, building the new lbm :)
<RAOF> You've already uploaded one based on rc6, and this is your personal voodoo-generator-patched version, right?
<Sarvatt> i'm just building this locally, wasnt planning on putting it on edgers/nouveau unless you think we should?
<RAOF> I don't think we should.  Unless someone stops us shipping nouveau-firmware, I think that's the right thing to use until the voodoo generator goes mainline.
<Sarvatt> yeah
<Sarvatt> have to try all of this stuff out on a non-nvidia machine still
<Sarvatt> dont have any ati that can use a PPA though (its a powerpc) and thats what i'm worried about
<RAOF> I'd also like someone to try it out on a PPC-nvidia machine, too.
<RAOF> My Intel laptop is perfectly happy running xorg-edgers/nouveau
<Sarvatt> you installed linux-backports-modules-nouveau on it?
<Sarvatt> is it using drm or lbm-drm if so?
<Sarvatt> this lbm stuff doesnt apply to ports arches it looks like anyway
<Sarvatt> rebooting into a voodoo generator lbm-nouveau now
<RAOF> I installed linux-backports-modules-nouveau on it; it's using standard drm.
<Sarvatt> http://pastebin.com/fc76bc53
<RAOF> That's freaky and weird.
<Sarvatt> only visual change was it had a black screen until plymouth instead of an 80x25 with a blinking cursor, no change in that plymouth wasnt up until right before X
<RAOF> It's pulled up fb0 @ 3sec, then waits until 13sec to actually finish probing your output & switching modes.
<Sarvatt> http://sarvatt.com/downloads/arcueid-lucid-20100203-6.png
<Sarvatt> yeah thats strange
<RAOF> You've got your display on, right?
<RAOF> Or is the laptop still headless?
<Sarvatt> yeah i'm on that machine now
<apw> RAOF, Sarvatt you are not menat to run MUNGE-NOUVEAU ... it occurs at build time
<Sarvatt> wanted to be sure that wasnt the problem
<RAOF> apw: Yeah, we figured that out pretty quickly.  Thanks anyway :)
<apw> you'll be telling me my shit makes sense next
<RAOF> Quite a lot of sense, yes. :)
<RAOF> Sarvatt: Feel like booting that laptop with some drm debugging enabled?
<Sarvatt> doing it now
<Sarvatt> http://sarvatt.com/downloads/nouveau.debug.log
<RAOF> apw: Is there any special reason that linux-backports-modules-nouveau is only i386 & amd64?  Nouveau should work - and there's relevant nvidia hardware - on PPC as well.
<RAOF> Sarvatt: I'm not sure that's actually nouveau's fault, now.  It looks like nouveau is set up & ready to go @ 3sec, then gets asked to do a modeset @ 13sec, and after that everything is right.
<kklimonda> Sarvatt, the new lbm you have uploaded looks broken - all .debs are 5KB
<Sarvatt> oh nasty
<Sarvatt> RAOF: mind uploading yours? looks like a bunch of files got corrupted on my filesystem
<Sarvatt> everything in updates/ is 0 bytes
 * RAOF bumps the version and uploads.
<Sarvatt> sorry about that :(
<RAOF> S'ok.
<Sarvatt> ok the plymouth problem isn't even nouveau specific, my intel machine is having the same problem since the update to plymouth 0.8.0~-8
<RAOF> I don't think I've booted this intel laptop recently enough to pick that up.
<RAOF> Also, I need to bust out the busybox to mount my dm-crypt home anyway.
<Sarvatt> can't shutdown or suspend or anything with this plymouth because it just hangs
<Sarvatt> which is the default plymouth theme again?
<Sarvatt> ah --reset works
<Sarvatt> theres nothing plymouth related in the initrd anymore when i extract it
 * kklimonda said so
<kklimonda> ;)
<Sarvatt> ugh, i haven't been following #ubuntu-devel today, alot of talk about it's broken-ness right now :D
<bryce2> pitti and I debugged the rethrow signals patch
<bryce2> it works now and I've uploaded it to lucid.
<bryce2> cya
<Sarvatt> so apparently the change to not having a splash for more than a second is an intentional change now
<Sarvatt> <slangasek> you could set the FRAMEBUFFER=y option in /usr/share/initramfs-tools/conf-hooks.d/ to force it
<Sarvatt> thats what we have to do to see the splash
<Sarvatt> no plymouth in the initrd so it's mountall (virtual-filesystems) -> udev -> udevtrigger -> plymouth-splash then X with it's less than 1 second start time now :)
<kklimonda> Sarvatt, dont forget about ureadahead
<RAOF> Ok.
<RAOF> I wonder why my laptop throws up the splash early, then.
<kklimonda> it does boot really fast though - but the experience sucks although the pre3 lbm package helped me - no londer weird colors at boot but the expected console
<Sarvatt> it's a shame because it was a really nice boot process yesterday and you didn't get to see it because of that :D
<Sarvatt> having the splash up at 2 seconds at full resolution was nice
<Sarvatt> phew yeah changing OPTION=FRAMEBUFFER to OPTION=FRAMEBUFFER=Y at the top of /usr/share/initramfs-tools/hooks/plymouth and doing an update-initramfs -u got it back in the initrd
<RAOF> Now, does that make nouveau bring up a nice framebuffer earlier?
<Takyoji> Looking for testers of proprietary drivers on 10.04?
<Takyoji> (just joined the mailing list, and noticed a message in the archives for the ubuntu-bugsquad mailing list)
<Sarvatt> http://paste.ubuntu.com/368600/
<Sarvatt> XD
<Sarvatt> rebooting now to find out
<Sarvatt> http://pastebin.com/f7a4c889e
<Sarvatt> 6 seconds in it showed up, udev starts like 10 seconds sooner this way too
<Sarvatt> it still waits for mountall and fsck checks where it didnt before
<Sarvatt> so its not as early as before, the fsck stuff happened underneath the splash before
<Sarvatt> but i get about 10 seconds of splash and can see the progress bar this way instead of just a flicker before X starts
<RAOF> Oh!  It's probably udev that triggers the console update.
<Sarvatt> we might get classic mesa drivers for nv0x-nv2x in edgers by the time lucid releases too :)
<Sarvatt> heck, i could import and build it now
<Sarvatt> http://cgit.freedesktop.org/~currojerez/mesa/commit/?h=mesa-next&id=9d4bcd1afb7b483954ef96af65397c2cf687eb65
<Sarvatt> vish: http://cgit.freedesktop.org/mesa/drm/commit/?id=1802e1a4e747b5906d3af10c4a53fd457eddcbb4
<Sarvatt> fix for your log spam if the ddx patch didnt fix it completely
<Sarvatt> maybe we should just do a git checkout of libdrm if nouveau is going in anytime soon
<RAOF> How easy is it to make mesa build the gallium drivers, too?
<RAOF> I guess it's easier to add a classic driver to the build than to work out how to make gallium fly.
<Sarvatt> its over my head, i dont know how it changes the resultant libGL.so.1 when you compile gallium into it and if things work with non-gallium when you build gallium stuff
<Sarvatt> i know it wants to use the gallium dri modules instead of the classic ones when i build it here but dont know if thats because of how i configured it
<Sarvatt> the mesa build system is a nightmare :(
<Sarvatt> would be super easy to add the classic mesa nouveau driver. just a patch and adding it on one line in the rules
<RAOF> Yeah.
<Sarvatt> they disable the gallium drivers to let the classic ones work it looks like in that branch so something tells me if you build gallium at all its gallium or nothing like I feared :(
<Sarvatt> with mesa being shoved away to /usr/lib/mesa for the alternative stuff maybe it'd be easier though, just throwing it in /usr/lib/mesa-gallium and setting up the alternatives for it
<RAOF> Mayhap.
<RAOF> This isn't urgent, though; it'll be MM stuff at best.
<Sarvatt> that actually doesnt seem *that* hard to do now that i think about it, I stopped messing with it because it seemed like they wouldnt coexist but i could reuse alot of the alternatives stuff already there that I was sketchy on. maybe if I get a day off of work someday I'll work on it :D
<Sarvatt> figuring out the right configure flags to use will be the hardest part
<Sarvatt> I bet I can snag that info off gentoo too
 * Sarvatt tries to dig up a nv0x-nv2x nvidia card to test the classic mesa nouveau drivers
<bjsnider> Danag can do it for you in the other channel
<bjsnider> he's got an old riva tnt or something
<Sarvatt> nv2x is geforce 5 isnt it? or geforce4?
<Sarvatt> thinking its 5 because 4 was just a speed bumped and rebranded 3 afaik
<bjsnider> i dunno. naming conventions are dull
<Sarvatt> woohoo, remembered i have a geforce4mx with a pci-agp adapter in my efika
<Sarvatt> geforce 5 was nv4x ah
<Sarvatt> err nv3x
<RAOF> The geforce4mx is actually a geforce2
<Sarvatt> yepyep
<bjsnider> then why is it called..
<bjsnider> never mind
<RAOF> bjsnider: BECAUSE
<bjsnider> there you go
<RAOF> It's higher-clocked, IIRC.  But it's a geforce2 core
<bjsnider> nvidia still does this stuff to this day
<Sarvatt> hmm libgl1-mesa-dri-gallium? libgl1-mesa-gallium-dri?
<Sarvatt> libgl1-gallium-dri? I dunno
<RAOF> libgs1-gallium-dri probably.
<RAOF> What do we do with the other statetrackers?
<Sarvatt> libgjs on the brain? :D
<RAOF> I FIXED THAT, DAMNIT!
<RAOF> :)
<Sarvatt> yeah I saw, and thank you :)
<RAOF> Do we care to split out the other state trackers?
<RAOF> Maybe it's just libgl1-gallium
<Sarvatt> i'm just going to start with the basics, was just using -dri as an example to try to figure out how to name it
<RAOF> Yeah.  I don't think we need the dri in the name; maybe libgl1-mesa-gallium?
<Sarvatt> well I mean I was thinking of building the gallium dri drivers too and putting them all in the seperate package, could just install everything in one package though to start
<Sarvatt> the radeong_dri.so is apparently in a usable state now
<RAOF> fun!
<Sarvatt> i need a complete configure flag that enables nouveau/intel/radeon gallium drivers and builds the gallium dri stuff too to make a new confflags target in the rules
<bryce2> https://wiki.ubuntu.com/X/Troubleshooting/NvidiaDriverSwitching#preview
<Sarvatt>  ./configure --with-state-trackers=dri --with-dri-drivers= --with-driver=dri --enable-gallium-intel --enable-gallium-radeon --enable-gallium-nouveau?
<RAOF> You can drop the --with-driver=dri bit.
<RAOF> I pass "glx,dri,vega" to --with-state-trackers, personally.  I'm not totally sure why, though :)
<Sarvatt> ah defaults to dri, I see
<Sarvatt> need --disable-gallium-svga now it looks like
<RAOF> I didn't think that actually built by default, did it?
<RAOF> You also need newer dri2 protocol headers, don't you?
<Sarvatt> they're in edgers
<RAOF> Nifty.
<Sarvatt> what does 101_ubuntu_hidden_glname.patch in mesa do?
<Sarvatt> "Re-add debian/patches/101_ubuntu_hidden_glname.patch since we use GLX_TLS now. An explanation of the patch would be nice though.." is all i see in the history
<Sarvatt> http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/patches/101_ubuntu_hidden_glname.patch;h=1d1d066c7e8b10bb594f7b3171b2bb3cb1d6ebdc;hb=0748753b1fbb808dc4a6e501a80b822dcea661ac
<RAOF> Sarvatt: That's a fine question.
<bjsnider> someone's not commenting a patch? unheard of
<bjsnider> doesn't the code itself provide some notion of what it's doing?
<RAOF> It looks like it's unhiding a function, but the source it's modifying is assembly, and it's been ages since I touched a microprocessor like that.
<bjsnider> no clue about who wrote it?
<bjsnider> or should it be who diffed it
<bjsnider> somebody had to originally post it to a mailing list right?
<RAOF> No.  We don't use revision control for packaging (yet).
<tjaalton> trying to trace the hidden_gl change, but it probably was split from the diff at some point
<tjaalton> should also add the Old changelog entries to git
<tjaalton> looks like fedora added nouveau dri to dri-drivers-experimental
<RAOF> tjaalton: Where do you see these things?
<tjaalton> RAOF: fedora cvs
<tjaalton> http://cvs.fedoraproject.org/viewvc/devel/mesa/
<RAOF> Are you subscribed to commits, or do you just browse every now and then?
<tjaalton> though it looks like they missed adding gallium/nouveau to the for-loop :)
<tjaalton> browse every now and then
<tjaalton> this time to see how they handle gallium
<tjaalton> looks like just the way the current dri drivers are handled..
<RAOF> Spec files are wierd!
<RAOF> But it does look like they don't do anything special.
<tjaalton> yeah I don't like how everything is in one file..
<RAOF> I guess the one file has its advantages, but once you're familiar with the various files in debian/ I think multiple files make it easier to understand what's happening.
<Cobalt> Sarvatt: I know the Intel driver Eee PC crashes have been fixed with the new Intel drivers of newer kernels, are there any plans to isolate what's causing the crashes in the newer Xorg drivers in older kernels?
<libv> Cobalt: check libv.livejournal.com and answer the question at the end of the post :)
<Cobalt> libv: Thank you.
<libv> it has no direct solution for this, but does point at the same fundamental issue you are pointing at
<Cobalt> libv: Latest post?
<libv> yes, it talks about the xorg devroom and the talk i will be holding there
<Cobalt> I'm sorry if I'm a bit slow with this, but I see no mention of crashes or the Intel driver... or have those issues been noted on other drivers as well?
<libv> "For those using, or those who have used, the nvidia or ati closed source drivers: how would you like it if nvidia or ATI told you that you needed the very latest upstream kernel, X, and mesa to be able to run the latest catalyst or nvidia driver, especially when you might need this version for its new hardware support or for bugfixes?"
<Cobalt> I see.
<Cobalt> Ah well, I'll follow that, I guess, and see what comes of it. Thanks.
<Cobalt> I can see a lot of people not liking the idea of upgrading their kernels. Especially if their distribution don't provide stable packages.
<libv> Cobalt: about the drm, until a year/year and a half ago, you could just grab the drm tree and build kernel modules
<libv> there was a small bit of compat code to level over the bumps in a few kernel versions
<Cobalt> Yes, but still, it's not within everyone's grasp to do that. I'd personally shun from compiling anything kernel-related. :S
<libv> Cobalt: make; make install
<Cobalt> You make it sound terribly easy.
<libv> it was
<Cobalt> Not anymore?
<libv> no, now it is assimilated in the kernel
<Cobalt> See?! Terribly complex stuff.
<libv> which they finally also mentioned to the BSD people a few months ago, and they were thrilled :)
<Cobalt> So that's a good thing?
<libv> telling the BSD folk to port their stuff directly from the linux kernel?
<Cobalt> No, that the thing was integrated in the kernel now.
<libv> some people say it is
<Cobalt> I suppose it's going to be a lot more stable and tested.
<libv> with graphics hardware?
<libv> graphics hardware is hugely complex and its drivers are in constant flux
<libv> part of why linus held off the boat for so long and treated the fb drivers that stepmotherly
<libv> but seems that his appreciation of that has changed
<Cobalt> You can hardly get anything out of the fb these days.
<Cobalt> Not such a dinosaur, then.
<Cobalt> Still, for him to have accepted, it's pretty big.
<libv> well, go back a few years, and you could hardly get anything out of X either
<libv> politics/money goes a long way
<Cobalt> That has moved quite a bit, now that you mention it. Drastically too. And for a bit, without much thought to the consequences.
<Cobalt> I use Ubuntu, I remember the hue and cry when Jaunty came out.
<libv> yes, and it is only going to become worse
<Cobalt> I thought things were evening out a bit.
<libv> this is what people say will happen
<libv> but there is a difference between what is stated and what is done
<Cobalt> Still, I'm not much in those circles, only started getting interested in the issue because of performance and stability hits on my EeePC.
<libv> next great idea is to move xorg drivers into the xserver tree again so the API "can get fixed"
<libv> first week and someone will run s/xf86/xorg/ on the whole thing
<Cobalt> That's the only way you'll get to debug it.
<libv> err... i am talking about exchanging the string xf86 to xorg on all the symbols in the xserver
<Cobalt> Oh. I'm not sure I understand what the consequences of that would be. Pretty much of a noob where all that stuff is concerned, I'm afraid.
<libv> Cobalt: this means that there will be a massive API breakage for no reason except for a lingering oedipus complex
<Cobalt> Well, at least, the sooner they get over that, the better, surely, even though it's going to be hell to go through the transition period?
<libv> it's a pointless transition
<Cobalt> Having said that, wouldn't they just stick to stability versus change? There's a lot of enterprise grade applications that depend on X.
<libv> well, i used to work for suse, and i had some of those big shots on the phone with suse management and his companies management
<libv> and he pretty much blatantly said that suse had to go change its business model to adapt to his way of working
<Cobalt> What'd come of it?
<Cobalt> Admin and bureaucracy (I think it's universal) has a way having their heads in the clouds. I have similar issues at work - at a hospital.
<libv> well, in normal business you expect things like that, 5 or so years ago i never though that open source software could be just as bad or even worse.
<libv> you'd expect technical stuff to be more important than politics and talking rubbish
<Cobalt> Not so good when you have a megalomaniac running the show.
<Cobalt> Well, that's the exact same thing with hospitals. Sometimes decisions coming form the top just does not make sense. Like painting over a whole A&E department (for only 2 hours, granted) while business is still ongoing.
<jcristau> libv: it's so much better to be able to hide a few bug fixes in lots of regressions!
<libv> jcristau: that's not regressions, thatt's progress :)
<jcristau> ah, right
<jcristau> easy to get confused..
<libv> too bad you're not there this weekend :)
<libv> i'll still mention your debianised git trees in my talk though :)
<jcristau> libv: do you know if any of the intel people will be at fosdem?
<Sarvatt> tjaalton: wow, interesting, looks like we can build nouveau gallium at least along with the rest of the dri stuff going by what they are doing, I guess the tricky part comes when you build gallium drivers for things that have classic mesa ones as well
<tjaalton> Sarvatt: I think those should be in another (libgl1-mesa-dri-experimental?) package that would provide/conflict with l-m-d, and when the gallium versions are considered stable, move them over
<tjaalton> though mesa supports an alternative path now
<libv> jcristau: i had to remove a talk in the wiki today
<libv> jcristau: anholt inserted one at 11:00on the second of february, never said a word to me
<libv> so yes, i guess so
<libv> but no talk, as the morning slots are all taken by openmoko
<jcristau> :/
<libv> serves him right though, it's thanks to stunts like this that we will not have a devroom next year
<vish> Sarvatt: hi... the two patches you showed me , have they landed in lucid or in the -edgers ppa?  [right now i have your ppa pinned and dont seem to have any trouble with it so far]
<vish> the patches for the gdm flood errors*
<Sarvatt> the ati patch is, i'm working on libdrm now to prevent the errors getting flooded under any circumstances also
<vish> you mean they are in the edgers ppa?
<Sarvatt> the ati fix is in the upstream git, the same fix i added as a patch to that -ati you used from my ppa
<Sarvatt> thats been in edgers for a few days now yeah
<vish> ah , cool , thanks
<Sarvatt> but the libdrm one isnt yet, i'm working on that right now, taking a bit of tweaking because of the ubuntu branch in debian git being a little messed up
 * vish nids
<Sarvatt> all done and it built fine, uploading now
<vish> nods*
<Sarvatt> are you on karmic?
 * Sarvatt forgot
<vish> no.. lucid
<Sarvatt> well, uploaded karmic too but that might not build right
<Sarvatt> ah ok
<vish> Sarvatt: would i have to watchout for Bug #436546 in the edgers ppa? last i heard was it[legacy_is_pending() or ? ] was required for some other bug
<ubottu> Launchpad bug 436546 in mesa "X crashes when using compiz cube and cairo-dock" [Unknown,Confirmed] https://launchpad.net/bugs/436546
<Sarvatt> i wouldnt expect cairo-dock to work right in any circumstances, all i've heard is bad things by the mesa devs about how it tries to do things :)
<vish> hehe  , i can switch to different dock , but If X doesnt crash that would be sufficient for me :D
<Sarvatt> i really dont have any idea though, if it doesn't work still just install ppa-purge and sudo ppa-purge xorg-edgers to go back to stock :)
<vish> yeah.. i'm already installing -edgers [thats the plan] 
<baptistemm> * Add klingon language definition. wtf???
<jcristau> baptistemm: wtf indeed.
<baptistemm> :)
<baptistemm> dear X developper, are you aware of a X corruption (on Intel at least) in lucid since yesterday
<seb128> baptistemm, what do you call corruption?
<bryce2> Sarvatt, hey you suggested something the other day to get vt switching to work on nouveau but I've forgotten
<bryce2> Sarvatt, btw just removing splash from the kernel boot line wasn't sufficient for getting 3D working.  but that's fine I think we're missing some more fundamental bits
<tjaalton> like the dri driver?-)
<bryce2> tjaalton, indeed
<Sarvatt> yeah bryce2 nouveau isn't going to have 3D support in lucid almost guaranteed, it would be easy to add nv0x-nv2x classic mesa 3D support if we go with mesa 7.8 though. removing splash was to fix the GPU hang and reset which was making the ddx use noaccel so there was no 2D acceleration happening but the fixed plymouth i uploaded there fixed that
<bryce2> heh, rotating screen upside down --> crash
<bryce2> ok
<bryce2> ideas on the vtswitching issue?
<Sarvatt> what happens when you try to VT switch?
<bryce2> it leaves the X graphics on the screen
<bryce2> doesn't show the console
<bryce2> vt switching back to vt7 gets back to functioning X
<bryce2> er, vt8 (ctrl-alt-f8) actually.  weird
<Sarvatt> got a dmesg handy? wondering if you are having a similar problem to kklimonda's
<Sarvatt> hmm /lib/udev/rules.d/78-graphics-card.rules needs an update for lbm-nouveau too
<bryce2> apw is working on a new lbm update, should be coming in soon
<bryce2> suspend resume failed on nouveau for me
<bryce2> (at least, I couldn't get it to resume)
<Sarvatt> theres going to be so many places we need to update the checks for nouveau to lbm-nouveau like this udev rule :(
<Sarvatt> http://paste.ubuntu.com/369097/
<bryce2> Sarvatt, might be useful to compile a list
<Sarvatt> is there any place I should mark changes that need to be made to accomidate lbm-nouveau? i've got a plymouth and a udev patch now that need to be added
<bryce2> nothing appears in dmesg after doing the vt switch
<bryce2> yeah, we've got a wiki page for tracking these tasks
<Sarvatt> dmesg | grep "GPU hang" return anything?
<bryce2> https://wiki.ubuntu.com/X/Nouveau
<Sarvatt> ok I'll add a TODO section there and start putting changes on it
<bryce2> nope, no GPU hang
<bryce2> great
<Sarvatt> oh should I add it to outstanding issues?
<bryce2> Implementation
<Sarvatt> I was going over libdrm to see if theres anywhere else we are missing that talks to the drm module instead of lbm-drm which is where i caught the udev thing
 * bryce2 nods
<Sarvatt> updated with what i have for now, the list is going to grow alot :D
<Sarvatt> i'm doing it headless for the most part so i havent tried suspend or vt switching to see if they're screwed up yet :(
<Sarvatt> we've got the newest nouveau in lbm in the xorg-edgers/nouveau ppa though, updated it yesterday. it's a piece of cake to update thanks to apw's scripts :D
<Sarvatt> oh boy
<Sarvatt> theres calls to /proc/dri all over the place that are screwed
<Sarvatt> because its /proc/lbm-dri/
<Sarvatt> RAOF: should we have the /proc/dri calls in xf86drm.c also check /proc/lbm-dri ?
<Sarvatt> hmm still some /proc/dri stuff in nouveau after munging, ./nouveau/drm_proc.c:		DRM_ERROR("Cannot create /proc/dri/%s\n", name);  ./nouveau/drm_drv.c:		DRM_ERROR("Cannot create /proc/dri\n"); ./nouveau/drm_proc.c:			DRM_ERROR("Cannot create /proc/dri/%s/%s\n",
<Sarvatt> just the error messages though
<Sarvatt> the udev rules change explains why plymouth was waiting for udev to finish at least
<Sarvatt> wonder how much it would break things if we just didnt rename everything to lbm-* with this
<Sarvatt> would be nice to add intel and radeon to this :D
<kklimonda> huh, has something broke in the last 24 hours or so? I can't boot with nouveau.. I even managed to get a dmesg without seeing anything. http://pastebin.com/f4ae73417
<apw> kklimonda, looks like plymouth had you for lunch
<apw> that has changed recently
<ara> tseliot, hi!
<Sarvatt> did you reboot since updating nouveau kklimonda or is that the first time? does it boot ok without splash in the kernel command line?
<kklimonda> Sarvatt, I've booted with lbm ~pre3 successfully, removing splash from command line doesn't change anything
<Sarvatt> could you try booting with plymouth:debug added maybe?
<Sarvatt> looks like thats a new option in the most recent one
<Sarvatt> just to be sure it was PAE it was working on before and PAE thats the problem now?
<Sarvatt> nothing else was updated in edgers/nouveau since the nouveau update you said was working :(
<tseliot> Sarvatt: shall I blacklist both nouveau and nouveau_lbm when using nvidia?
<Sarvatt> its lbm-nouveau, probably best blacklisting both yeah
<RAOF> That's probably a good idea.
<Sarvatt> kklimonda: booting with lbm-drm.debug=6 might have useful info too
<kklimonda> plymouth:debug or plymouth.debug ?
<kklimonda> Sarvatt, ^
<Sarvatt> plymouth:debug i think it is, let me check
<Sarvatt> ./src/main.c:     || (path = strstr (state->kernel_command_line, " plymouth:debug=file:")) != NULL)
<Sarvatt> =file is optional i'm pretty sure
<Sarvatt> btw might want to make this change to /lib/udev/rules.d/78-graphics-card.rules
<Sarvatt> http://paste.ubuntu.com/369097/
#ubuntu-x 2010-02-05
<kklimonda> http://pastebin.com/f3e32f86b
<kklimonda> Sarvatt, ^
<kklimonda> Sarvatt, I have a nvidia closed drivers no so you can see it at the end of dmesg but first time it crashed I haven't have it installed at all.
<kklimonda> I thought I've blacklisted nvidia before rebooting laptop but it seems the module is now nvidia-current and not nvidia..
<bryce2> Sarvatt, btw I talked to apw about the lbm-nouveau naming for the driver.  The alternative would be to include a full update of all the dri's (radeon and intel) at the same time, but it sounds like it'd make life hell on our end since we'd need to test all the various combinations of old and new drms for each driver, with mesa, etc.
<kklimonda> Sarvatt, also I don't see any plymouth debug messages (and I'm pretty sure I've run with plymouth:debug but I don't see a Command Line at all in this dmesg o.O)
<Sarvatt> yeah looks like it defaults to /var/log/boot.log which we dont use, ahh well
<Sarvatt> bryce2: that would be an awesome alternative in my opinion because there would be something in the archive we can point people to for fixes that dont make it to .32 :D but if we did that i doubt we could enable nouveau by default because everyone would have the newer things and wouldnt ever use the 2.6.32 ones if we did?
<bryce2> Sarvatt, well we'd only put the nouveau binary package on the livecd
<Sarvatt> i'm planning on doing a full lbm with intel and radeon on edgers at any rate just for that purpose
<bryce2> Sarvatt, but think about the mess it'd cause with mesa... wouldn't we end up needing to support two versions of mesa?  ick
<Sarvatt> what issues would it cause with mesa?
<superm1> tseliot, what's this plugin that plymouth falls back to when ubuntu-logo doesn't work?  
<tseliot> superm1: it's the text plugin
<tseliot> (at least currently)
<superm1> tseliot, hmm.  it seems to be misbehaving on text strings when I send multi line strings to it
<superm1> tseliot, forgive the crappy quality, but http://imagebin.org/83425 is what's happening
<superm1> when those should all be left oriented and lined up at the newline characters.  
<tseliot> superm1: I don't know much about that plugin but you can ask in #plymouth. Eventually we won't fall back on the text plugin any more
<Sarvatt> kklimonda: anything at /var/spool/plymouth/boot.log ?
<superm1> tseliot, you mean because of KMS being prevalent, or because the ubuntu-logo plugin will work on non KMS hardware too eventually?
<tseliot> superm1: I need to get plymouth to work with 16 colours fbs such as the one provided by vga16fb
<tseliot> so that non-kms drivers can have something better than the text plugin
<superm1> OK. if that's the case, then i wont really bother with trying to drive a solution into the text plugin at this point
<tseliot> ok
<superm1> the other thing I was seeing is that questions (ask-question) aren't working, which i suppose is just a deficiency where ask-question isn't yet implemented for ubuntu-logo
<tseliot> Sarvatt, RAOF: the name of that module is nouveau_lbm, right?
<Sarvatt> lbm-nouveau
<tseliot> superm1: yes, only ask-password is implemented. I'm working on the new theme so I might as well implement ask-question too
<RAOF> For some reason nouveau_lbm seemed more natural to me, too; the first libdrm patch I wrote was broken because of that :)
<superm1> tseliot, that would be spectacular :)
<tseliot> Sarvatt, RAOF: ok, thanks 
<kklimonda> Sarvatt, nothing - there is no boot.log nowhere in my /var/
<Sarvatt> oh RAOF, new xserver in lucid overwriting the PPA one
<Sarvatt> x2
<Sarvatt> so nouveau autodetection with no xorg.conf was broken
<RAOF> Ah.  Do you want to upload a new one, or would you like me to?
<Sarvatt> i dont have your patches, was going to grab your source off launchpad and pull it out if you weren't around
<Sarvatt> things are all kinds of screwed up here too it looks like
<RAOF> Ok.  I'm not currently near my nvidia laptop; I'll be leaving this rather pleasant cafÃ© soon, though, so I can have a squiz.
<Sarvatt> so much [   67.240647] [lbm-drm] nouveau 0000:05:00.0: PFIFO_INTR 0x00000010 - Ch 1 spam I don't have anything but that in dmesg
<RAOF> Ah, a FIFO storm.  Yay.
<Sarvatt> huh, did libdrm get updated in lucid or something?
<Sarvatt> (EE) [drm] Could not set DRM device bus ID.
<Sarvatt> (EE) NOUVEAU(0): [drm] error opening the drm
<Sarvatt> nope still using PPA ones, not that
<Sarvatt> cold boot fixed it :)
<Sarvatt> hmm this is new
<Sarvatt> [    0.509445] fb0: EFI VGA frame buffer device
<Sarvatt> [    3.335681] fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver
<jcristau> i had that too.  killed my console.  i blame grub2.
<Sarvatt> yeah i was just going to say, looks like the grub2 update
<RAOF> How are you getting an EFI framebuffer?
<Sarvatt> screen is black till nouveau kicks efifb out
<jcristau> RAOF: beats me
<RAOF> What crazy hardware do you have that actually has EFI enabled?
<Sarvatt> anything with insyde bios?
<jcristau> here inteldrmfb didn't actually kick efifb out, so i had a black screen until X started.  and even then no console.
<Sarvatt> like all laptops the past few years
<Sarvatt> how long ago did you have it start jcristau?
<jcristau> happened today, but last reboot was on Jan 23
<Sarvatt> jcristau: think this is it - http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/lucid/grub2/lucid/revision/1920/util/grub.d/10_linux.in
<jcristau> Sarvatt: seems likely
<Sarvatt> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567245
<ubottu> Debian bug 567245 in grub-pc "gfxpayload=keep broken" [Normal,Open]
 * jcristau upgrades the severity
<jcristau> sigh.  that moron closed the bug?
<Sarvatt> i have to cold boot the nouveau laptop, it cant handle a warm reboot with gfxpayload=keep
<Sarvatt> and no consoles at all on intel with KMS enabled, the same as you
<jcristau> there. reopened and set to 'grave'.
<jcristau> Sarvatt: thanks for the pointer
<Sarvatt> no worries! its fixed in ubuntu now \o/
<Sarvatt> bryce2: grub2 update in the past day making efifb load and breaking consoles with KMS
<bryce2> ah yes
<Sarvatt> kklimonda: that probably fixed your problem
<Sarvatt> https://lists.ubuntu.com/archives/lucid-changes/2010-February/004893.html
<Sarvatt> crazy week for bugs :(
<bryce2> fun fun
<Sarvatt> seems like its when ureadahead profiling  happens i get hung on a splash screen
<kklimonda> Sarvatt, i've also had to downgrade xserver to version from your ppa
<Sarvatt> you can just use the lucid stock xserver if you make an xorg.conf
<Sarvatt> Section "Device"
<Sarvatt>         Identifier      "Configured Video Device"
<Sarvatt>         Driver          "nouveau"
<Sarvatt> EndSection
<kklimonda> ach
<RAOF> Bah!  The latest xorg-core isn't in git yet.
<bryce2> xorg-core?
<bryce2> ah xorg-server.  pushed.
<bryce2> sorry, sprint is kind of a madhouse
<RAOF> That's ok.
 * tseliot packaged the latest beta of the nvidia driver: https://launchpad.net/~albertomilone/+archive/proprietary-video-improvements
<tjaalton> hmm the sprint-bryce left.. I don't know what he means by having to ship two mesa's
<tjaalton> having the .33 drm in lbm would be great
<tjaalton> all the drivers, not just nouveau
<RAOF> I guess that he might have been thinking that the .33 drm would require a different mesa as well?
<tjaalton> for instance intel 2.10 is happy with .33 and mesa 7.7?
<RAOF> From the looks of l-b-m-nouveau, adding intel & ati to that wouldn't be too hard.
<tjaalton> (.32 is enough for intel)
<virtuald> will lucid l-b-m-nouveau always be based on .33?
<tjaalton> probably
<tjaalton> doubt it'll get rebased
<virtuald> ok
<tjaalton> at that time there should be the kernel from MM backported to lucid
<RAOF> That's right; we're getting newer kernels in lucid, aren't we.
<tjaalton> that's the plan aiui
<tjaalton> I'll merge & upload new mesa & libdrm today, you can push whatever you have before that?
<tjaalton> new mesa = 7.7-branch snapshot from debian
<tjaalton> since nouveau is a go
<tjaalton> so libdrm is ok to go as well
<RAOF> libdrm is pushed to pkg-xorg git.
<RAOF> It includes a merge of 2.4.17-1, so I may have done some of the work you wanted to do already :)
<tjaalton> yeah I noticed, that's great
<bryceh> heya
<bryceh> yeah I assume if we upversion the drm, we'll need a newer version of mesa to go with it.
<tjaalton> aiui 7.7 is enough for 2.4.17
<tjaalton> newer nouveau ddx needs stuff on top of .17, but not mesa
<tjaalton> so the deps go the other way, ie. mesa/ddx depend on some libdrm version :)
<RAOF> I think we can probably take it as read that nouveau wants git HEAD of everything :)
<tjaalton> I hope they'll ship a release when .33 kernel is released
<RAOF> They've still got (at least) one ABI break pending; I don't think they want to release until they've done that.
<RAOF> At least, that's what I recall from previous discussions.
<tjaalton> ok
<RAOF> That said, they didn't want to be merged into mainline until after that ABI break.  Maybe that'll have changed their minds.
<bryceh> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/517430
<ubottu> Ubuntu bug 517430 in xserver-xorg-video-nouveau "[MIR] xserver-xorg-video-nouveau" [Undecided,New]
<RAOF> bryceh: Thanks for that.
<bryceh> starting to get a lot crossed off https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-driver-selection-for-nvidia-hardware
<bryceh> RAOF, is https://edge.launchpad.net/~xorg-edgers/+archive/nouveau just packages prepped for upload into lucid?
<bryceh> RAOF, tjaalton, for making xserver use nouveau over nv, should we just s/nv/nouveau/ in xserver, or should we look at resurrecting patch 104?
<bryceh> (...or something else...?)
<tjaalton> bryceh: I think the ppa version already has something
<tjaalton> fedora has a patch which doesn't use nouveau for all the chips, don't know if it's still relevant
<bryceh> tjaalton, which ppa?  I checked 2:1.7.4.901~git20100122+server-1.7-branch.d3e54304-0ubuntu0sarvatt 
<tjaalton> I don't know :)
<bryceh> daniels resigned from the x.org board?
<bryceh> aha, 106_nouveau_autodetect.patch in the nouveau ppa
<bryceh> ok looks like raof resurrected 104
<bryceh> ok good, looks like we can cross that item off too
<tjaalton> what's the url for that?
<bryceh> https://edge.launchpad.net/~xorg-edgers/+archive/nouveau/+packages
<bryceh> https://edge.launchpad.net/~xorg-edgers/+archive/nouveau/+files/xorg-server_1.7.3.902-1ubuntu12~ppa1.dsc
<tjaalton> that's not good enough though
<tjaalton> nvidia should be dropped from it
<tjaalton> because if there's an xorg.conf on the system and no nvidia installed, it'll try nvidia and only that
<bryceh> tjaalton, did you look at the patch?  nvidia isn't listed
<tjaalton> uh crap
<tjaalton> looked at the wrong patch :)
<bryceh> 106_nouveau_autodetect.patch
<tjaalton> yep
<tjaalton> looks ok
<bryceh> is nouveau only for i386 and amd64?  does it support any other arch's?
<bryceh> powerpc?
<bryceh> arm??  I see -nv is listed for arm...
<bryceh> well hell, -nv is listed even for alpha ;-)
<tjaalton> debian likes to torture the buildd's alot :)
<bryceh> ok so for now we only care about i386 and amd64 I guess
<bryceh> does -nv need to be removed from xserver-xorg-video-all or can -nv and -nouveau both exist side by side?
<tjaalton> bryceh: I noticed that ogra has tested touchscreens with the current stack. do you know if he used evdev or what?
<tjaalton> bryceh: no, nv is still needed for some chips, as noted in the patch
<bryceh> no I didn't talk to him about his testing
<tjaalton> maybe tseliot knows more
<tjaalton> the blueprint was updated recently
<bryceh> I saw martin marked the task done but dunno if he talked with ogra first or just figured it was already tested well enough
<bryceh> tjaalton, what I know is several people have tested and found it worked well (with -wacom)
<bryceh> bdmurray for instance
<bryceh> he's got an HP laptop with a touchpad screen that we worked on a bit
<tjaalton> wacom is not evdev though
<bryceh> turned out it just needed a kernel driver enabled
<tjaalton> nor is it replacing evtouch
<bryceh> tjaalton, hm what's your question?
<tjaalton> bryceh: that there is no evtouch driver in lucid anymore, and whether evdev is good enough
<bryceh> what I've seen is that people need -wacom
<RAOF> bryceh: nouveau definitely works with PPC; it should work on all archs which actually have nvidia hardware.
 * bryceh adds to vars.powerpc and vars.ppc64
<tjaalton> bryceh: some touchscreens have a wacom, yes. those need the wacom driver
<tjaalton> some (like the X61 tablet here) have a serial wacom, which doesn't work yet
<tjaalton> OOTB anyway
<bryceh> RAOF, sparc? arm?
<bryceh> I'm not sure what all platforms have nvidia hardware
<tjaalton> those three should be enough
<RAOF> I don't actually know.  arm certainly does; that's tegra, right?  I don't know if nouveau would drive that, though.
<tjaalton> lunch ->
<bryceh> hm, well guess we can add as we go
<RAOF> Oh, this is for the seeds?  Otherwise, is there any particular reason to do arch restrictions?
<bryceh> tjaalton, anyway yeah ask pitti or tseliot if you have questions about what this has been tested against
<bryceh> RAOF, right seeding
<bryceh> just getting the patch ready.  Figure I'll wait on uploading it until nouveau's in main
<RAOF> Does the nvidia binary driver still destroy the ability for other drivers to work with X, or has that been fixed by the alternatives work?
<RAOF> If so, xserver-xorg-video-nouveau should stop conflicting with nvidia-glx.
 * RAOF should test that.
<bryceh> tseliot was playing with that a bit today
<bryceh> http://launchpadlibrarian.net/38788005/nouveau.diff
<indus> hi
<indus> hello 
<indus> i have some questions
<indus> hello
<indus> hello
<indus> again
<Sarvatt> bryceh: linux-backports-nouveau is only i386/amd64?
<Sarvatt> meaning i dont think you want to add the nouveau ddx to the other arches yet.. 
<indus> anyone here
<vish> !ask | indus
<ubottu> indus: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<indus> vish, here too ?
<indus> vish, you might have guessed, its the fglrx question
<indus> :)
<indus> vish, you are on the art team isnt it
<vish> indus: I use ATI but havent used fglrx
<vish> indus: yup
<indus> vish, i saw your name on the membership wiki, that is approved?
<vish> indus: its the coming week , but kinda off topic here ;p
<indus> oops
<indus> iam looking for ara
<indus> or anyone really
<jcristau> then ask your question.  if someone can answer it they will.  if you don't ask, they won't.
<Sarvatt> odd  196_xvfb-fbscreeninit-handling.patch doesn't apply to server 1.7 branch even though hw/vfb/InitOutput.c hasn't changed in months, i must be missing something
<Sarvatt> guessing the git version is different than the one applied in the archives
<indus> a ny one know about the fglrx in lucid
<tjaalton> doesn't work
<indus> actually no, i have signed up for testing for the driver, so have some questions
<tjaalton> still, doesn't work
<Sarvatt> yep git version was for -p0 instead of -p1, i'll fit it in git
<indus> yes i know
<indus> so question is, if it doesnt work, how can you test it
<tjaalton> you can't
<Sarvatt> when there is one that you can test you'll get info on it, he sent out that email a bit too prematurely
<indus> ok thanks
<indus> ill wait for the email, just signed up today 
<indus> but it seems testing cases are valid 
<indus> installation etc
<tjaalton> it won't install
<indus> i installed already 
<indus> its available in hardware drivers
<indus> doesnt work is a different thing
<tjaalton> ah, so it doesn't provide the abi anymore.. nice
<tjaalton> breaks systems for no reason
<indus> tjaalton, whats abi
<Sarvatt> i wouldnt expect it in the near future though, its up to ATI to give us a driver that works and they aren't very good adopting changes in linux :D
<indus> but i say, it shouldnt be offered in hardware drivers if it wont work :)
<tjaalton> indus: the xserver conflicts with < xserver-xorg-video-6, which means that drivers providing -5 or earlier conflict with the server, and are removed on upgrade
<tjaalton> damn right it shouldn't
<indus> xorg is 1.7 i belive in lucid 
<indus> *believe
<indus> or is that 7.5
<jcristau> xserver is 1.7
<jcristau> xorg is something close to 7.5
<indus> i would like to kno w the difference between xorg and xserver
<vish> Sarvatt: hmm , with ati , the -edgers ppa hung on boot with > http://pastebin.com/m717b8ca3 , i was dropped into a console and the errors kept running at light speed.. had to hard shutdown  ,happened twice :( , but was able to boot the next time around... still it does a freaky sort of hang during boot  , I'll have to see if it happens again
<vish> s/with/in
<indus> in any case, i guess the nvidia tests can go on
<indus> ok another question i have is, about s3tc compression, i compiled it but doesnt seem to work
<Sarvatt> vish: have you updated grub to 1ubuntu3?
 * vish checks
<Sarvatt> 1ubuntu2 was breaking KMS all kinds of bad ways here on all my machines
<indus> is there a mesa channel?
<vish> ah , maybe , grub-pc is still ubuntu2
<Sarvatt> #dri-devel
 * vish reloads repos
<indus> Sarvatt, thank you ,btw do you know about s3tc ,probably yes
<Sarvatt> vish: open up your /etc/grub.d/10_linux and go down to where it says gfxpayload=keep
<Sarvatt> and delete that whole section
<Sarvatt> if you can pastebin your 10_linux i'll tell you the whole section to delete, its already deleted here so i dont have it
<Sarvatt> but you can do that then sudo update-grub and it should hopefully fix it
<Sarvatt> or just update grub2 to 1ubuntu3 if its available, thats the only change
<Sarvatt> was it a warm boot when it failed and a cold boot when it didnt? because thats what happened here, on warm boots i had all kinds of gpu resets and unable to talk to drm in X and no consoles because of that darn forced efifb change
<Sarvatt> i'm not using ati though, no idea what was happening there
<vish> Sarvatt: when i restarted , it hung , but when i hard shut it down and started it would boot
<Sarvatt> yeah thats what i was experiencing
<herman_> Sarvatt, hi
<Sarvatt> hello
<herman_> i was having problems with intel video graphic on ubuntu 9.04
<herman_> do you remember?
<Sarvatt> yep! greedy helping or did you upgrade to karmic?
<herman_> i upgrade to karmic
<herman_> and now, it's better
<Sarvatt> hopefully you're not going to tell me its worse? :D
<Sarvatt> phew
<herman_> but i'm having problems with web
<herman_> my icon don't give me option to see the conections
<tjaalton> not related to x
<Sarvatt> network-manager is what you're having a problem with then, I'm afraid I can't help too much in that area
<herman_> it saids something like this: "the device is not manageable"
<herman_> ok
<herman_> where can i find help about this
<vish> herman_: #nm
<herman_> anyway, thanks for the help
<Sarvatt> #ubuntu would be the best place probably, I would just google "the exact error string" karmic with the exact error message you get in quotes like that
<herman_> Sarvatt, yes, but my system is in portuguese
<herman_> and i don't know exactly how the string will be in english
<herman_> and my english is not so good
<Sarvatt> herman_ if you can type it in portuguese here I can tell you what it is in english
<Sarvatt> i've got network-manager-applet's pt.po open
<vish> Sarvatt: i think the update ubuntu3 removed the gfxpayload=keep section >  http://paste.ubuntu.com/369537/
<Sarvatt> yep thats what the 1ubuntu3 change did, hopefully that fixes things for you
<herman_> Sarvatt, my icon says: "rede com fio: o dispositivo nÃ£o Ã© gerenciÃ¡vel" 
<Sarvatt> ah thats pt_BR
<herman_> Sarvatt, yes
<Sarvatt> try googling network manager "device not managed" karmic
<herman_> a lot of people are having this problem on karmic
<Sarvatt> http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=network+manager+%22device+not+managed%22+karmic
<herman_> ok, i will see
<Sarvatt> hopefully one of those ubuntuforums posts can help you out
<Sarvatt> http://ubuntuforums.org/showpost.php?p=6975928&postcount=3 looks like the solution, people upgrading from jaunty to karmic had that problem
<Cobalt> Sarvatt: I had a talk with libv yesterday, from what he says, the Intel bugs aren't going to be fixed because things work fine with newer kernels, is that correct?
<Sarvatt> what intel bugs?
<Cobalt> Where you get thrown back to the gdm greeter.
<Sarvatt> I wouldn't say thats always true, there have been a steady stream of backported fixes from .33 to .32 upstream because its a LTS kernel for alot of distros
<Cobalt> I'm on .31.
<Cobalt> .32 works, but introduces another couple of issues, which makes using it a little tricky.
<Sarvatt> oh .31 is pretty much dead, I wouldn't expect anything more from it :(
<Sarvatt> the last point release was supposedly the final one
<Cobalt> Isn't the problem a regression introduced in the Xorg Intel drivers though, rather than a problem from the kernel itself?
<jcristau> it's all mashed up together
<Sarvatt> ^
<Cobalt> The 20100127 update caused a lock-up. Mouse was still working, but nothing else. Had to REISUB.
<Sarvatt> it seems like they are expecting newer kernels in the later git versions, i can't use git intel on .31
<Sarvatt> lots of random invalid bo alignment errors
<herman_> Sarvatt, i already get wired connection
<herman_> before, i didn't get
<Sarvatt> just stick with 2.9.1 Cobalt is my recommendation
<Sarvatt> i have to do that regardless even on lucid because things are broken on 945 since the beginning of december :(
<Cobalt> Fair enough.
<Cobalt> They seem to have moved weird interface names to sane defaults, my ra0 has become wlan0. Which is nice.
<Cobalt> Things should have evened out a bit though, right, for when Lucid will come out in April?
<Sarvatt> that sounds like you are using a mainline kernel that has staging disabled so you are using a different module for wireless
<Cobalt> No, all the kernels I've been using have been from the Ubuntu repos. The .32 kernel I used was in the Lucid repo.
<herman_> Sarvatt, i got it
<herman_> i solve all my problems now
<Sarvatt> good to hear :D
<Sarvatt> theres 2 different ralink drivers in the kernel for alot of chipsets last i looked, wlan0 one is using mac80211 instead of the ralink specific stuff
<herman_> i just era my file /etc/network/interface and i can acess my connections
<Sarvatt> is the module name the same Cobalt?
 * Sarvatt renames #ubuntu-x to #ubuntu-wireless :D
<Cobalt> Sarvatt: It is, yeah.
<Cobalt> rt2860sta.
<Cobalt> Although it loads the module fine, automatically, it does not put up the interface. I have to manually do that with ifconfig wlan0 up.
<herman_> Sarvatt, you are helping me a lot
<herman_> very thanks
<Sarvatt> mesa classic nouveau driver was pushed to master, time to enable it on edgers builds :D
<Sarvatt> RAOF: would you mind updating the nouveau ubuntu git branch with your latest changes in debian/ whenever you get a chance?
<vish> oh oh... "session active not inhibited" bug present in -edgers ppa :(
<Sarvatt> need to update it to build against the newer libdrm in xorg-edgers, figured i'd pull the xorg-edgers/nouveau stuff into xorg-edgers/ppa directly incase anyone wanted to use the newer mesa with nouveau
<Sarvatt> thats gnome-power-manager vish
<Sarvatt> which you also just updated
<vish> aw  , damn it.. gpm sneaked in an update :/
<vish> hehe , i was thinking Lucid cycle was too quite without gpm problems :p
<Solarion> did system76 die?
<Solarion> I can't reach their servers anymore
<Sarvatt> -rw-r--r-- root/root   2224748 2010-02-05 15:38 ./usr/lib/dri/nouveau_vieux_dri.so
<Sarvatt> built find, now to find someone to try it :D
<jcristau> heh, nouveau_vieux? :)
<Sarvatt> 3 feet of snow predicted... maybe I'll have time to package up nouveau_dri.so now :D
<tjaalton> we got almost that much already :)
<bjsnider> tseliot, what does envy do at this point? i thought it downloaded hte drivers from nvidia and installed them with its own packaging scripts. but i got an email from a guy who is using it to install drivers out of my ppa
<tseliot> bjsnider: I've removed envy from the archive
<tseliot> bjsnider: BTW I put the nvidia beta driver in my ppa
<bjsnider> tseliot, does it grab those extra files too?
<tseliot> yep
<bjsnider> how easy do you think it would be to take the new build scripts and replace the alternatives code with diversions code?
<bjsnider> tseliot, i meant that they ere using envy in karmic, not lucid
<tseliot> bjsnider: I think it's going to be bit of a mess but still doable
<bjsnider> tseliot, are you planning to have a beta driver more or less permanently in the archive?
<tseliot> do you mean a -beta flavour?
<bjsnider> well, i don't care what you name it, i just mean a package that's an option, whatever it's called
<bjsnider> but nvidia-beta would be good
<bjsnider> or nvidia-unstable
<Sarvatt> dunno how much of a point that would have since it probably wouldn't get updated post release :D
<tseliot> I think it would be better to keep that in a PPA, maybe xorg-edgers
<tseliot> Sarvatt: good point
<bjsnider> how hard is it to get a new driver pushed through after a release?
<tseliot> bjsnider: the SRU team would eat me alive ;)
<Sarvatt> sweet, thanks for making that newer nvidia-current tseliot
<bjsnider> what does that acronym stand for?
<Sarvatt> stable release update
<bjsnider> but it's nvidia that takes on the responsibility for supporting their driver
<tseliot> Sarvatt: I hope it fixes some issues with suspend/resume in lucid
<tseliot> bjsnider: if a package is in main, we take responsibility for it as it's officially supported (with the obvious limits of proprietary drivers)
<bjsnider> tseliot, how can you support prebuilt libs and stuff like that? it would be a copyright violation for you to support it
<Sarvatt> they throw lots of testing at it and verify the version shipped works, some people actually dont want to upgrade things like that that has the potential to break things (crazy I know)
<Sarvatt> especially when you dont have access to the code so you dont know what could be breaking (or fix it)
 * tseliot nods
<bjsnider> well, i've actually told people who have emailed me about issues specific to nvidia that they should go there and complain
<bjsnider> but they use vbulletin to manage bug reporting which is nuts
<bjsnider> but whatever
<LLStarks> bryce2. bryceh. is anyone else getting "libGL is too old"?
<LLStarks> i think the nvidia blob is getting installed on intel machines and its interfering
<bryce2> LLStarks, haven't heard that one before
<bryce2> do you have any ppas installed?
<LLStarks> not using edgers at the moment.
<LLStarks> but the blob was basically disabling direct rendering for intel
<LLStarks> entire screen would bug out and text flip if compiz was activated
<bryce2> LLStarks, you should probably talk to tseliot about it
<tseliot> LLStarks: what does "ldconfig -p |grep GL" say?
<LLStarks> it's fixed now because i purged the drivers
<tseliot> LLStarks: there's no need to do that. They can coexist with open drivers in lucid
<tseliot> disabling the driver with the latest release of jockey should do it. Or a simple command should do it too
<LLStarks> libGL.so (libc6) => /usr/lib/nvidia-current/libGL.so
<LLStarks> that doesn't belong.
<LLStarks> it's the only thing added.
<tseliot> LLStarks: sudo update-alternatives --config gl_conf (and select mesa)
<tseliot> then type "sudo ldconfig" and reboot
<LLStarks> http://img94.imageshack.us/img94/7263/ohgodo.png
<LLStarks> that's what was happening before
<tseliot> ouch, I've seen that already. I'm not sure if it's related to this problem though
<LLStarks> no, it is.
<LLStarks> that libgl causes it.
<tseliot> my two commands will fix it then
<LLStarks> i know.
<Sarvatt> i'm guessing you had a ppa enabled with that screwed up mplayer bringing in the nvidia-current driver
<Sarvatt> saw someone else that did that a few days ago
<LLStarks> probably.
<Sarvatt> anyone having problems with mutter on intel? http://pastebin.com/f726092cb
<Sarvatt> ahh was a driconf option i had set
<Sarvatt> mutter is absolutely killing graphics performance here, qgears2 render backend ~20 fps gl backend 9 fps, under metacity its 38 and 19
 * Sarvatt cant wait to see the bug reports about the 70 fps glxgears under mutter in UNE :)
<Sarvatt> gnome-shell has come quite a long way in the past few months it looks like, the menu is actually usable on this 8.9" screen
<AlanBell> hello
<AlanBell> I was just wondering if there is anything I can do to help progress Bug #428769 
<ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor" [Undecided,Confirmed] https://launchpad.net/bugs/428769
<Sarvatt> almost a 50% performance drop in openarena under mutter :(
 * Sarvatt starts liking compiz for some reason.
 * AlanBell likes compiz
 * AlanBell is stuck on 8.10 :-(
 * AlanBell doesn't like bug 428769
<ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor" [Undecided,Confirmed] https://launchpad.net/bugs/428769
<bjsnider> why be stuck on intrepid?
<bjsnider> is the nvidia-current driver broken?
<BUGabundo> evening fellows
<bjsnider> there he is!
<BUGabundo> lucid and nvidia
<bjsnider> rock and/or roll!
<BUGabundo> two failed reboots with X corruption
<BUGabundo> launched older kernel and got low resolution mode
<BUGabundo> pastebining X logs as we speak
<BUGabundo> $ pastebinit Xorg.0.log
<BUGabundo> http://paste.ubuntu.com/369761/
<BUGabundo> $ pastebinit Xorg.0.log.old 
<BUGabundo> http://paste.ubuntu.com/369762/
<BUGabundo> let me know if you prefer me to file a new bug, or if this is know 
<BUGabundo> thanks in advance
<bjsnider> alberto's not in here at the present time
 * BUGabundo goes into idle mode
<BUGabundo> well not much I can do, right
<BUGabundo> newest kernel seems unsuable
<BUGabundo> and older won't work very well
<BUGabundo> got some X updates, so let me do does and test again
<Sarvatt> i've seen that exact backtrace from people on ati intel and nvidia now since reenabling apport in xserver, hope thats not the cause :(
<jcristau> sigquit? wtf.
<BUGabundo> Sarvatt: me ?
<BUGabundo> Sarvatt: was that about my report ?
<BUGabundo> if so, I better file a bug
<AlanBell> bjsnider: the nvidia-current driver won't help much on my intel chipset :-)
<AlanBell> bjsnider: although actually I got it wrong, I am stuck on 9.04 Jaunty
<BUGabundo> FYI after last batch of updates, reboot went well
<BUGabundo> took a bit to show GDM with lot of IO (KMS?), and sheduler fallback to Performance 
<BUGabundo> other then that, everthing seems ok
<AlanBell> the intel driver in Karmic and Lucid won't do compiz with a 2048 wide monitor
<BUGabundo> ping me if anyone needs extra logs
<BUGabundo> thanks
<bjsnider> AlanBell, why won't it do that?
<AlanBell> I have no idea
<AlanBell> well 2048 is the max texture size of the card
<bjsnider> what an outrage
<AlanBell> so my monitor is equal
<bjsnider> violence must ensue
<AlanBell> if the monitor was any bigger then compiz wouldn't run at all
<AlanBell> but the test is for less than or equal to max texture size
<bjsnider> you don't really have a 2k monitor though right? it's two monitors
<AlanBell> so it runs. Successfully on 9.04 and not on 9.10
<merriam> yes, there are cheap 2048 monitors.
<merriam> I have one here.
<AlanBell> I do have a 2048x1152 single screen
<bjsnider> what's the physical size?
<AlanBell> and it was relatively cheap, but I don't want to toss it away :-)
<merriam> This one is 23 inch.
<AlanBell> err about so big
<AlanBell> yes 23 inches sounds about right
<AlanBell> it is a samsung
<bjsnider> what's the dot pitch? in the 120s?
<bjsnider> it sure isn't 96
<AlanBell> looks like 20 inches for the 2048
<AlanBell> wouldn't be surprised if it was exactly 100
<BUGabundo> I take back what I said
<BUGabundo> my system just log off
<BUGabundo> without no aparent reason
<BUGabundo> and went to GDM
<bjsnider> BUGabundo, alberto is here now
<bjsnider> AlanBell, what is the height of the screen in inches?
<AlanBell> about 11 1/4 inches
<bjsnider> dot pitch: 102.4
<AlanBell> it has lots of dots
<bjsnider> it's a little better than usual, not as good as an ebook reader or something
<AlanBell> it is ace in portrait mode with full screen gedit and a big page full of python
<AlanBell> just broken compiz in 9.10 makes me sad :-(
<AlanBell> I would be quite happy to dig about in some code to fix it, just I have no idea where to start
<bjsnider> did you tell intel about it?
<AlanBell> I am not even certain whether it is a compiz thing, an intel driver thing or even a kernel thing
<merriam> What makes me sad is that Compiz fails with a blank screen, so Ubuntu's install fails.  That may be less relevant here...
<AlanBell> how do I tell intel about it?
<bjsnider> AlanBell, i've never submitted a bug to intel
<AlanBell> it is an open source driver
<AlanBell> and I have a bug in launchpad
<bjsnider> it is created by intel developers
<bjsnider> kieth packard et al.
<AlanBell> ok, where do I go to hassle them?
<bjsnider> if you submit a bug to launchpad what happens is they'll wait until the intel guys fix it and then they'll close the bug
<bjsnider> AlanBell, packard runs freedesktop.org, so i'd start there
<jcastro> AlanBell: I just went through this, you make a bug report in the fdo bug tracker and link it in launchpad
<bjsnider> coolio
<jcastro> AlanBell: here's an example: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/516676
<ubottu> Ubuntu bug 516676 in xserver-xorg-video-intel "GPU hang on intel" [Unknown,Confirmed]
<bjsnider> there's another one other than packard...jesse something
<AlanBell> ok, so I did find a freedesktop.org bug that seemed similar (with some people on the thread reporting random different bugs)
<AlanBell> and I linked that
<AlanBell> https://bugs.freedesktop.org/show_bug.cgi?id=22996
<ubottu> Freedesktop bug 22996 in Driver/intel "[945GM] external lcd does not work on high resolution" [Normal,Reopened]
<AlanBell> I think I might file a new bug, that one is a bit confused
<AlanBell> do they have an IRC channel that you know of?
<bjsnider> dunno
<AlanBell> #intel-gfx would appear to be the place
<bjsnider> coolio
 * merriam again follows Mr Bell to a channel.
<merriam> I think the seriousness of the bug is underestimated.
#ubuntu-x 2010-02-06
<bryceh> tseliot and I got X running rootless today
<RAOF> Cool.
<twotwenty> Im having trouble isntalling XServer with no backfill on ubuntu 9.10
<bryceh> eh?
<twotwenty> I added this line to my sources deb http://ppa.launchpad.net/ubuntu-x-swat/xserver-no-backfill/ubuntu karmic main 
<twotwenty> but I dont know what to install, and there are no upgrades to xserver 
<twotwenty> this was the site I looked on, Im told it will help rendering problems with my HD 3xxx series radeon 
<twotwenty> says it had a differently built xserver , how do I force its install?
<bryceh> twotwenty, dpkg ${pkg}=${version}
<twotwenty> thank you 
<twotwenty> bryceh, will it be xserver core ?? to get xserver with no backfill?
<bryceh> yes
<bryceh> night!
<AlanBell> merriam: I found a better upstream bug https://bugs.freedesktop.org/show_bug.cgi?id=23718
<ubottu> Error: Could not parse XML returned by Freedesktop: timed out (http://bugs.freedesktop.org/xml.cgi?id=23718)
<AlanBell> wut?
<merriam> AlanBell, thanks.  Presumably that's just the invalid certificate.  http://bugs.freedesktop.org/show_bug.cgi?id=23718
<ubottu> Freedesktop bug 23718 in Driver/intel "[945GME] attaching external monitor causes black screen, with Compiz Fusion in Karmic" [Critical,Resolved: fixed]
<AlanBell> merriam: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/419328?comments=all
<ubottu> Ubuntu bug 419328 in xserver-xorg-video-intel "[i945gme] attaching external monitor: laptop display is black, external monitor too, with frozen mouse coursor" [Unknown,Fix released]
<AlanBell> I think that is the same bug
<AlanBell> the people on that bug have an issue with external monitors
<AlanBell> I think that is because they have something like a 1024x768 screen and then add a 1024x768 screen as an external (or higher resolutions)
<AlanBell> we can just reproduce the issue on a single monitor
<AlanBell> so it might be fixed in Mesa 7.7 which may or may not make it into Lucid
<jcristau> lucid has mesa 7.7 already
<AlanBell> jcristau: was it in Alpha 2?
<jcristau> dunno
<jcristau> probably
<AlanBell> ok, I tested Alpha 2 and the issue was there, boots to a black screen
<AlanBell> I will grab a daily and test again
<merriam> Bug 419328 looks similar but more serious in its symptoms.  I also get occasional x11 freezes with Compiz off, but the mouse cursor isn't frozen with bug 428769.
<ubottu> Launchpad bug 419328 in xserver-xorg-video-intel "[i945gme] attaching external monitor: laptop display is black, external monitor too, with frozen mouse coursor" [Unknown,Fix released] https://launchpad.net/bugs/419328
<ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor" [Undecided,Confirmed] https://launchpad.net/bugs/428769
<hyperair> $ ps -C Xorg -o rsz=
<hyperair> 268172
 * hyperair whistles
<BUGabundo> good afternoon guys
<BUGabundo> I'm getting X freezes again
<BUGabundo> bug 518058
<ubottu> Launchpad bug 518058 in linux "[lucid] system freezes after GDM with nvidia and 2.6.32-12and " [Undecided,New] https://launchpad.net/bugs/518058
<BUGabundo> Sarvatt: ^^^^^
<Cobalt> I don't have an NV card. Why do I have to have to have to install libdrm-nouveau1 as a dependency?
<jcristau> why do you care?
<Cobalt> jcristau: Clutter?
<Cobalt> Also, if I have a 14.4kbps modem :P.
<Cobalt> Still, if it's not required... what's the need to have it there?
<jcristau> same reason your kernel gets installed with drivers for hardware you don't have at the moment
<Cobalt> jcristau: Somehow, that's not related to what I was saying either.
<Cobalt> (Also, Xorg gets installed with a whole bunch of other video drivers I don't need, if you're looking for other examples).
<jcristau> right.
<jcristau> and one of those drivers has libdrm-nouveau as a dependency
<Cobalt> Hm. Never used to be there before. I was just wondering about the change, is all, to be honest.
<Sarvatt> its not used,  its not slowing you down, and its giving you the ability to use it in the future if you ever need to instead of things just plain not working. I think you're in gentoo's target audience if you care about that 17k of hdd space being wasted :)
<Cobalt> Hahaha. No, not a Gentoo afficionado.
<Sarvatt> you can remove the xserver-xorg-video-all as well as the xserver-xorg-video-* drivers you dont use though to to free up some space
<Cobalt> I need space in the order of GBs. Not KBs. :( Micromanagement is not really going to help me. I might have been concerned if my EeePC had a SSD. But I've got a hard disk.
<Sarvatt> well if you were on a 14.4k modem and didn't want to update stuff you dont need rather
<Cobalt> Fortunately, I've got a 512kbps line. :D
<tjaalton> bryceh: I merged xserver 1.7.4 yesterday, so please rebase -1u12 against it :)
<AlanBell> jcristau: Lucid daily boots to a black screen on a 2048 wide monitor :-(
<Cobalt> Since your monitor is now a brick you can give it to me.
<AlanBell> when you pry it from my cold dead fingers :-)
<bjsnider> AlanBell, what did the intel guys say in the irc channel?
<AlanBell> bjsnider: nothing whatsoever
<AlanBell> I am not sure how to validate whether the fix suggested in http://bugs.freedesktop.org/show_bug.cgi?id=23718 is in Lucid and not working, or not in Lucid.
<ubottu> Freedesktop bug 23718 in Driver/intel "[945GME] attaching external monitor causes black screen, with Compiz Fusion in Karmic" [Critical,Resolved: fixed]
<bjsnider> meaning what, that you asked them about it and no one responded?
<AlanBell> yes, no response
<bjsnider> well, it was friday night
<AlanBell> I haven't updated them on the Lucid daily test result though
<AlanBell> will do that now
<AlanBell> and now I have
#ubuntu-x 2010-02-07
<Sarvatt> took 14 tries to actually get X up that time, what the heck is going on
<Sarvatt> [  260.085195] [drm:i915_gem_do_execbuffer] *ERROR* Invalid object handle 1073741824 at index 1
<Sarvatt> [  260.085230] BUG: unable to handle kernel paging request at 00100150
<Sarvatt> [  260.085243] IP: [<f8414ccf>] i915_gem_do_execbuffer+0x20f/0x780 [i915] :(
<Sarvatt> plymouth segfaulted a few of those times
<RAOF> Sarvatt: Why did you delete the Karmic packages from xorg-edgers/nouveau?
<Sarvatt> they were very out of date and didn't work, didn't want anyone to think we wanted them to test that as part of your email :)
<Sarvatt> bryce updated the ddx in there in karmic but the libdrm was still really old and couldnt handle it, it'll need all new packages if you want karmic in there now
<Sarvatt> RAOF: sorry, meant to ping you with that response :)
<Sarvatt> bryceh: nouveau actually requires xserver 1.7+ as of the beginning of january btw, a karmic backport wouldn't be that easy
<Sarvatt> we need some kind of generic lbm-nouveau package we can make the ddx depend on, right now the ddx is depending on linux-backports-modules-nouveau-2.6.32-12-generic | linux-backports-modules-nouveau-2.6.32-12-generic-pae | linux-backports-modules-nouveau-2.6.32-12-server  so its going to break every abi bump
<Sarvatt> RAOF: whats up with http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-nouveau.git;a=blob;f=debian/patches/01_include_snapshot_date;h=76fb0c0f64dc4e401131d53972d49ef03f42245b;hb=refs/heads/ubuntu ? you're patching configure directly before autoreconf runs and it doesnt exist? thanks for updating git btw, working on getting everything in the main PPA so people can try 3D
<Sarvatt> hyperair: did you upgrade your geforce mx machine to lucid?
<Sarvatt> xorg-edgers is all set up for 3D acceleration for your card now if so, just install xserver-xorg-video-nouveau
<Sarvatt> hmm, guess I do need that plymouth update as well actually, its disabling render acceleration without the patch on nouveau
<hyperair> Sarvatt: it's at home, i can't really testi t.
<hyperair> Sarvatt: think 5 hours away by bus
<tjaalton> isn't it true that radeonhd is useless in lucid since we use kms for ati?
<jcristau> i suppose you could still boot with nomodeset to use radeonhd
<tjaalton> well yes
<tjaalton> but I guess it's too much to educate people to do that :)
<tjaalton> and in the meantime close bugs filed against it
<jcristau> yeah
<jcristau> i think it's better to remove it
<tjaalton> yep, I'll file a bug about it..
<jcristau> which probably means removing it from -video-all, if that hasn't been done yet
<tjaalton> yeah it's dropped from ubuntu
<tjaalton> I mean -video-all
<jcristau> good :)
<tjaalton> since intrepid, actually
<jcristau> heh
<jcristau> was in universe then i guess
<tjaalton> yep
<Sarvatt> shoot, this isnt good enough http://pastebin.com/f56c3e6cc
<Sarvatt> just looked and the actual device is SUBSYSTEM=lbm-drm
<Sarvatt> some people might want to use radeonhd still for audio over hdmi, might be better to just add a note in the man that KMS needs to be disabled to use it?
<superm1> Sarvatt, well if it's (radeonhd) not installed by default, why not just have the postinst set up something to blacklist the radeon drm module?
<Sarvatt> yeah a postinst installing a modprobe conf to have options radeon modeset=0 would be a good option
<Sarvatt> i think 70-acl.rules and 50-udev-default.rules need to be adjusted for lbm-drm as well in udev
<tjaalton> bah
<Sarvatt> ./rules/rules.d/50-udev-default.rules:SUBSYSTEM=="drm",		GROUP="video"
<Sarvatt> ./extras/udev-acl/70-acl.rules:SUBSYSTEM=="drm", KERNEL=="card*", ENV{ACL_MANAGE}="1"
<tjaalton> Sarvatt: you mean that radeonhd is better with audio-on-hdmi than ati?
<jcristau> there was no audio-on-hdmi with radeon ums
<jcristau> only radeonhd
<jcristau> not sure what's state it's in with kms
<tjaalton> ok
<tjaalton> looks like it was merged before christmas
<Sarvatt> SUBSYSTEM!="drm|lbm-drm", GOTO="drm_end" -- is that udev rules syntax right?
<jcristau> looks ok to me
<Sarvatt> there we go - http://sarvatt.com/downloads/patches/udev-lbm-nouveau.patch
 * Sarvatt hates working with bzr
<Sarvatt> anyone know if there is the equivalent to git format-patch for bzr?
<Sarvatt> ahh ok bzr diff -p1 is good enough
<RAOF> Sarvatt: autoreconf isn't run as a part of the build, it's run as a part of get-orig-source.
<RAOF> Sarvatt: We could re-jiggerit so that it autoreconfs at build time instead.
<Sarvatt> wow, looks like nouveau gallium was this easy to build.... - http://paste.ubuntu.com/371223/
<kklimonda> Sarvatt, are you going to upload it to xorg edgers ppa?
<Sarvatt> yep as soon as i'm sure its working :)
<RAOF> Sarvatt: Sweet :)
<Sarvatt> it only oh... doubles the build time though :)
<RAOF> How could the xserver-xorg-video-nouveau packaging be made more obvious to you?
<Sarvatt> it's just you can't build it without manually running autoreconf if you checkout from git, the other ones dont work like that so I have to disable that patch thats expecting a file thats not there to use the scripts
<RAOF> I think it might just be that the pristine-tar branch has the wrong version.  Maybe.
<Sarvatt> argh, gotta run out for a bit and mesa still didn't finish :( if anyone wants to try it you can have edgers and edgers/nouveau both activated right now then grab the source and apply that patch i pasted
<Sarvatt> i patched the xserver in edgers with the nouveau patch and have a newer ddx in edgers that's needed for the newer libdrm
<RAOF> Ah, you've got a newer libdrm in there?  Yeah.  Needs a newer DDX :)
<RAOF> Hurray for mass register renames!
<Sarvatt> looks like it worked
<Sarvatt> http://paste.ubuntu.com/371258/
<Sarvatt> sarvatt@arcueid:/opt$ glxgears
<Sarvatt> 7712 frames in 5.0 seconds = 1542.342 FPS
<Sarvatt> :D
<Sarvatt> compiz is working too
<RAOF> Gallium 0.4!  Another minor version bump :)
<Sarvatt> http://pastebin.com/f4706fe37
<Sarvatt> nouveau_dri.so working fine too
 * Sarvatt cheers
<RAOF> Yay!
<Sarvatt> i dont know if its broken on non-nouveau though, i'll upload it to edgers and find out though :)
<Sarvatt> that was so easy compared to how hard i was making it out to be :D
<RAOF> :P
<RAOF> Hush!
<RAOF> You had a valiant and protracted struggle with mesa, only triumphing after great effort! :)
<Sarvatt> uploading it now, its expected to use both PPA's at the same time for now for anyone that wants nouveau gallium :D'
<Sarvatt> not sure i want to put the udev/plymouth stuff into edgers yet
<Sarvatt> 7.8.0~git20100207.1a45c2bc-0ubuntu0sarvatt2 is the mesa version with gallium
<Sarvatt> _very_ interested in hearing anyones experiences with it if they use it
 * RAOF shall fire up his nvidia laptop forthwith.
<johanbr> Sarvatt, I'd be very interested in testing it... which is this other PPA you speak of?
<fmarl> johanbr, https://launchpad.net/~xorg-edgers/+archive/ppa/+packages
<RAOF> Oh, yeah.  You want !nvidia testers, too, don't you?  Let's offer up this intel laptop to the altar of xorg-edgers.
<johanbr> fmarl, but I got the impression there was another one? (not xorg-edgers)
<fmarl> johanbr, there are some PPA card specific IIRC.
<johanbr> ahh, alright, I think I've seen that somewhere
<johanbr> thank you
<RAOF> Sarvatt: Incidentally, I understand the plan is that linux-backports-modules-nouveau will be added to the linux-* metapackages; thus the DDX won't actually have to depend on any particular package.  The current state is temporary.
<RAOF> Sarvatt: Mesa is missing some build-depends.
<RAOF> Stupid configure script not picking it up.
<johanbr> hmm... what am I missing if I get Mesa rendering rather than gallium?
<johanbr> glxinfo output: http://pastebin.com/f35fd9cf
<RAOF> johanbr: You'd be missing the fact that mesa FTBFS :)
<RAOF> I'm test-building a new package here; I think it'll build, then I'll re-upload to xorg-edgers.
<johanbr> ahhh :)
<johanbr> thank you :)
<Sarvatt> huh? missing build depends? just got home, lets see
<RAOF> Sarvatt: Missing xserver-xorg-dev, libpixman-1-dev, x11proto-core-dev
<RAOF> (At least).
<RAOF> Sarvatt: My local copy's test-building in a pbuilder right now; you don't have to trouble yourself :)
<Sarvatt> oh sheesh, xorg state tracker depends
<jcristau> xserver-xorg-dev for mesa?
<RAOF> Yes.  xorg state tracker depends.
<RAOF> Cunningly concealed inside a $(shell pkg-config ...) call in the Makefile.
<jcristau> who needs the xorg state tracker?
<RAOF> Because testing for things in configure, where you can usefully override them, is for chumps.
<Sarvatt> i'll just add the depends for now so it builds and start seeing how much i can trim it down
<Sarvatt> it built locally because i have xorg-server build depends installed, sorry about that
#ubuntu-x 2011-01-31
<bryceh> heya
<RAOF> Good morning!
<RAOF> Or possibly evening?
<RAOF> You crazy past-livers :)
<bryceh> heh, yeah it's Sunday evening, just got back from trip to the park with my son
<RAOF> Sounds fun!
<bryceh> RAOF, btw I disabled the gestures patch (101) in -evdev.  It was causing major X crashing fun
<RAOF> bryceh: Yeah, I noticed the bug.
<bryceh> seems to be an amd64 specific bug, which may explain why I didn't see it when I tested
<RAOF> Pity the backtrace is so anaemic :(
<RAOF> I tested on amd64
<bryceh> hm
<bryceh> if you look at the bug report, one of the commenters suggested the issue was an abi incompatibility.  you might take a peek at the comments
<bryceh> it was a bit speculative, I decided to just flip it off until someone could investigate more thoroughly
<RAOF> Yeah, I agree with that call.
<bryceh> probably best to leave it off until post-alpha-2
<RAOF> It'd be nice if cnd would pop up, be a dear, and look at his gesture patches :)
<bryceh> fwiw, I didn't see the synaptics misbehavior LLStarks mentioned, but did mention the possibility for issues in the a2 release notes
<bryceh> RAOF, yah
<LLStarks> duly noted
<RAOF> Their problem is that synaptics just isn't being loaded for their touchpad.  I'm not sure why.
<LLStarks> btw guys, is tty broken? i can't drop to tty1 or tty2.
<LLStarks> blinking cursor only
<RAOF> Not broken on any of my systems.
<bryceh> was talking to the AMD guys friday, they're a bit concerned if xserver 1.10 goes in today, and there are any respins required for subsequent bug fixes, it could throw off their build schedule
<LLStarks> can't kill x by killing gdm either
<bryceh> LLStarks, are you running xorg-edgers?
<LLStarks> no
<bryceh> LLStarks, natty current has been working fine for me
<LLStarks> i flip-flop as needed
<RAOF> bryceh: As in - if there are any further ABI respins required?
<bryceh> RAOF, as in, any bug fix uploads to xserver or mesa
<RAOF> How do non-ABI-changing bugfix uploads interfere with their build schedule?
<bryceh> they have to start it over
<RAOF> Because they need to certify it against a particular upload?
<bryceh> I guess so; they were complaining about it but was hard for me to get specifics
<RAOF> That'sâ¦ awkward.  How have they handled these things in past releases?  We upload bugfixes all the time!
<RAOF> Perhaps they're wary about further ABI breaks?  There's an ABI break between RC1 and master, and *possibly* another one between master and RC2.
<bryceh> nah, there's always been a window where we're frozen for a day or so leading up to the alpha release
<bryceh> apparently arm builds take longer than x86 ones
<LLStarks> why can't ati devs be less anal and put out more releases like nvidia?
 * RAOF will take specs and full-time open-source devs over a more responsive binary driver team anyday.
<bryceh> RAOF, anyway as a compromise I took out some of the drivers from the video-all arm script 
<LLStarks> waiting for their advance releases less than 2 weeks from an ubuntu release isn't fun
<bjsnider> RAOF, you mean like the way intel handles things. that works really well.
<bryceh> RAOF, anyway my feeling is if we need a bug fix in, we need a bug fix in.  But I suppose if we can batch up patches and minimize uploads it might make them a little happier :-)
<RAOF> Yeah.
<bryceh> I think the key thing is to get xserver in asap before the alpha-2 freeze is announced
<bryceh> RAOF,  btw it looks like the .38 kernel upload Thurs/Fri nuked fglrx
<RAOF> I'm a bit concerned about further ABI breakage in xserver now.  Keith's âI'm sickâ email promised to pull an ABI-breaking DGA branch sometime; I need to see how much that breaks ABI we care about.
<bryceh> hrm
<RAOF> If it *is* ABI breakage we need to care about, is it worth uploading Xserver pre A2, only to need another rebuild of the world post A2?
<bryceh> well, it simplifies a few things if we postpone xserver update 'til after alpha2
<bryceh> but it somewhat reduces testing coverage we'll get
<bryceh> RAOF, how much is left to do to get xserver in?
<RAOF> Finish updating the gesture extension patch, or getting one from Chase.
<RAOF> I wonder if he's jetsetting, or just not checking email/irc :/
<bryceh> RAOF, aside from that, any other packaging work to do or is the xserver git tree good for upload?
<RAOF> It needs a changelog entry; that's it.
<bryceh> RAOF, I'm leaning towards just leaving the gesture stuff disabled if we don't hear from him by, say, morning my time, and uploading
<bryceh> then when 1.10 is officially released we can do another mega-driver rebuild
<RAOF> bryceh: Wilco.  I'll have a package ready for you then, then :)
<bryceh> alrighty, I can upload if you want to do it now
<RAOF> Nah, I'll give cnd until your morning.
<bryceh> ok
<bryceh> wow take a gander - http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<RAOF> Incidentally, were you planning to push wayland and/or libxkbcommon to pkg-xorg git?
<bryceh> Spikey McSpike visited our graph
<RAOF> Is that Maverick trend the line at the same stage of release?
<bryceh> no, I might put it in bzr
<bryceh> yeah
<RAOF> Why do we have so many fewer open bugs?!  Hurray!
<bryceh> I credit that to there being 2 X guys ;-)
<RAOF> Looks like Spikey McFglrx happened :)
<RAOF> And I see we've got some intel testers finally :)
<bryceh> I've been going through all the open natty bugs every morning, so that's kept things better under control than any release before
<RAOF> Aaah, yeah.  That'll do it.
<bryceh> yeah the fglrx bugs are all dupes of "kernel broke it"
<bryceh> a bunch are probably from the evdev crash
<bryceh> we may also have a few of "xchat shows corruption with latest intel
<RAOF> KiBi's doing some wayland/xkbcommon packaging in pkg-xorg git; it might be nice to help him if you've got time.
<RAOF> Oh, yeah.  That intel bug.
<cnd> RAOF, I'm popping up :)
<bryceh> ah no, looks like mostly GPU lockup bugs
<cnd> got back from bangalore yesterday
<RAOF> cnd: Time to make good on those âyou'll not need to forward-port patches for usâ promises :)
<cnd> still beating back the remnants of a fever suffered while there
<bryceh> RAOF, is KiBi aware of my packaging?
<RAOF> Oh, sucks.
<cnd> RAOF, yeah, so, things have changed recently in the utouch world
<RAOF> bryceh: Yeah, I think so.
<cnd> rydberg is unfortunately no longer on contract with us
<cnd> so we've had to scrap our plans to put the gesture recognition on the client side of X
<RAOF> Oh.  So we'll still have a gesture extension for 1.10?
<cnd> we will be forward porting the maverick gesture patches for xorg-server and xserver-xorg-input-evdev to 11.04
<cnd> I have begun this work
<cnd> got started while I was in india
<cnd> so here's the good news: everything forward ports pretty easily
<cnd> here's the not as good news: it needs to be reworked a little if it's going to sit along side XI 2.1
<cnd> though mostly that rework sits in utouch-grail
<cnd> not in any x components
<RAOF> (Although *my* attempt at forward-porting it in evdev results in Xserver crashes on hardware that isn't mine)
<cnd> RAOF, my forward port was also based on evdev master
<cnd> which has a *huge* masked valuators patch from me in it now :)
<cnd> well, series of three patches
<RAOF> So we need a newer snapshot of evdev also?
<cnd> RAOF, lets first go over what we need to accomplish, and by when
<cnd> when are you wanting to push things to ubuntu?
<RAOF> We'd like to push xserver in before A2 freeze, so soon.
<cnd> RAOF, can you be more specific?
<cnd> just so I know
<RAOF> A2 freeze will be Tuesday.
<bryceh> *early* Tuesday
<cnd> oh, so soon really means about 24 hrs :)
<bryceh> cnd, yep, preferrably more like 15 hrs
<cnd> so here's two routes:
<cnd> a. gestures in xorg-server and evdev
<cnd> b. gestures and xi 2.1 in xorg-server and evdev
<cnd> I feel about the same confidence in both at this point
<cnd> mostly because I haven't tried a
<RAOF> b. also requires an xi 2.1 patch series, right?
<cnd> however, b would require a new min version of utouch-grail, which would need to be pushed in as well
<cnd> yes
<cnd> RAOF, I would be happy to add the patches to xorg-server and evdev myself
<cnd> to the git repo
<cnd> so you would only need to verify and upload
<RAOF> That would be nice.  I'm perfectly happy to apply patches myself if that's easier.
<cnd> it's probably easier if I do it anyways
<cnd> and I don't mind
<RAOF> Is the utouch-grail min version the one in bug #702637 ?
<ubot4> Launchpad bug 702637 in utouch-grail (Ubuntu) "Upload utouch-grail 1.0.18 to Ubuntu (affects: 1) (heat: 186)" [Undecided,Confirmed] https://launchpad.net/bugs/702637
<cnd> no, it would need to be 1.0.19, which doesn't even exist yet
<cnd> without changes I made, touchscreen devices would no longer work
<cnd> they wouldn't move the pointer
<cnd> but they aren't huge changes
<cnd> I can try to make the packages tonight
<cnd> what do you think? a or b?
<cnd> it's really ok if you want a for alpha 2
<cnd> the xi 2.1 work isn't final yet either
<cnd> still some bits needing implementation
<RAOF> Are we more likely to get more useful testing out of (b) than (a)?  I think we will, but I think that's the main criterion at this point.
<LLStarks> bryceh, any news about the 16-bit color appearance on intel with .38?
<bryceh> LLStarks, news?
<cnd> RAOF, there's already someone on our multitouch mailing list asking about xi 2.1 for games
<cnd> he's just waiting for it to hit
<LLStarks> x session-wide color banding
<RAOF> That sounds fun.  Would you *like* his testing at this point?
<cnd> the sooner the better :)
<bryceh> cnd, are a and b about the same level of risk of breakage?
<RAOF> LLStarks: Sounds like a failure to set an appropriate dither mode.
<cnd> bryceh, b would be slightly more risky for MT touchscreens
<cnd> I don't think it should be any more for MT touchpads
<bryceh> LLStarks, since it's the weekend I've only been looking at critical bugs, but don't recall seeing that one.  bug #?
<cnd> and should not be a factor for non-mt devices
<LLStarks> ****
<LLStarks> i never filed one
<bryceh> LLStarks, ah, then that would be your next step
<LLStarks> i'll do it after the ppv ends
<LLStarks> need to boot into .38 anyway
<bryceh> ok
<RAOF> LLStarks: FWIW I don't get it on my 6-bit panel.
<bryceh> .
<LLStarks> i'd post camera pics, but it's kinda hard even with a 14mp one
<cnd> bryceh, if we go with b and find it breaks things, we should be able to revert to a before alpha 2 actually ships
<RAOF> cnd: And the risk on those MT touchscreens is that the pointer doesn't work on the touchscreen, yes?  Rather than it causing puppies to combust?
<cnd> RAOF, yes
<cnd> so you could just use a mouse or trackpad if something is awry
<RAOF> As someone without access to a MT touchscreen, that sounds an acceptable risk :)
<cnd> it's just cause of the interaction between utouch-grail and xi 2.1
<bryceh> yeah at this stage the risks we're mostly averse to is risks of widespread breakages (ala the -evdev breakage)
<cnd> bryceh, which evdev breakage?
<bryceh> but also we want to minimize the number of times we upload xserver between now and alpha-2, so the fewer bug fixes needed the better
<RAOF> I forward-ported the gesture patch to 2.6 in such a way that caused flaming destruction on !my hardware.
<cnd> ahh, that breakage :)
<bryceh> cnd, oh yeah you need to take a look - the gestures patch hosed the evdev upload
<RAOF> (bug #709977 for your delectation)
<ubot4> Launchpad bug 709977 in xserver-xorg-input-evdev (Ubuntu Natty) (and 1 other project) "Xorg crashed with SIGSEGV in RemoveDevice() - segfault at 1010 error 4 in evdev_drv.so (affects: 37) (dups: 15) (heat: 210)" [Critical,Fix released] https://launchpad.net/bugs/709977
<cnd> RAOF, ahh yes, I know exactly where the forward port went wrong :)
<bryceh> unfortunately I didn't catch it before uploading (but I *did* test this time!)
<RAOF> I tested on multiple machines, none of which exploded.
<RAOF> On the other hand, none of which had anything multitouch, either.
<cnd> anyways, if you guys give me the thumbs up I'll go make gesture + xi 2.1 packages for you
<RAOF> You have a go from me.
<bryceh> yeah I'm ok if we can get it in quickly
<cnd> RAOF, would it be reasonable to collapse all the xi 2.1 git commits into one big uber-patch in our package?
<cnd> that uber-patch would then be updated as we update xi 2.1 work
<RAOF> I don't have any real feelings either way.  I expect that you'll be the one dealing with any fallout from that patch, so I think do whatever is most convenient for you.
<cnd> k
<cnd> that would be it
<cnd> I will go cook some packages
<RAOF> Thanks.
<cnd> btw, don't announce xi 2.1 support if it does go in
<bryceh> alright, gonna go play with some blocks and crayons.  I'll check back in later.
<RAOF> We should stop getting you to jetset around.
<cnd> heh, talk to marketing :)
<cnd> and I found out after the fact that qatar airlines isn't actually in star alliance, so I don't get my 16,000 status miles either...
<RAOF> Or maybe hire a clone of you.  Or, maybe, even Rydberg.
<RAOF> cnd: I was discouraged to find that I'm the person with the most miles logged in the Canonical tripit group :)
<cnd> heh, no comment on that, other than that I wish we still had him around
<cnd> RAOF, you're in australia!
<cnd> every time you travel for canonical it's gotta be 20,000+ miles
<RAOF> Not quite, but close :)
<cnd> RAOF, how long are your longest flights in hrs?
<RAOF> 16, I think.
<cnd> from washington, dc to doha qatar was 13:30 for me, the longest I've ever been on
<cnd> eek
<RAOF> That's longest *continual* flight.  SydneyâHeathrow is like 22
<RAOF> But with a stop in Singapore.
<cnd> yeah
<RAOF> I suspect I'll beat that if we go to Dallas again.  Qantas now flies SydneyâDallas direct.
<cnd> cool
<RAOF> Yeah.  That'll be much more fun than SYDâLAXâDFW
<cnd> RAOF, bryceh: I realized that the new grail depends on a new package called utouch-frame
<cnd> it would require an upload, a review, a MIR request and review, etc
<cnd> hmmm
<RAOF> â¦which isn't all going to get done before A2 freeze.
<RAOF> Is that a new source package, or new binary package?
<cnd> I might need to branch off utouch-grail 1.0.16
<cnd> which is in maverick
<cnd> and I guess currently in natty
<RAOF> Right.
<RAOF> Is utouch-frame a new source package, or a new binary package of the existing utouch sources?
<RAOF> If the latter, that'd only require an upload + archive admin prod.
<cnd> new source package
<cnd> I'm not sure I like the proliferation of utouch source packages
<RAOF> Urgh.  Ok, that's not going to fly.
<cnd> but I was apparently the only one on the team who felt so
<cnd> as I look more closely at all this, I don't think the xi 2.1 + gesture work will be well tested enough
<cnd> due to requiring some last minute changes
<cnd> if we go with just gesture support
<cnd> then I just need to add the gesture patches into xorg-server and evdev
<cnd> I would like to update evdev to master though
<RAOF> How risky is that?
<cnd> which part?
<RAOF> evdev â master.
<RAOF> I'll look at the git log.
<cnd> let me check what's all in there
<RAOF> Hm.  Looks to me like master is 2.6.0.
<RAOF> Lucky you!  That's what we've got in Natty.
<cnd> hmm... I guess peter hasn't pushed my patches yet
<cnd> then I would like to add my patches in
<cnd> they're the foundation of xi 2.1, and have been working well for quite some time now
<RAOF> On lots of MT and non-MT hardware?
<cnd> RAOF, take a look at whot's evdev repo
<cnd> RAOF, yes, both
<cnd> at least, on trackpads and touchscreens
<cnd> and if it breaks others I'd rather know sooner than later
<RAOF> Wow.  That's a lot of deletions.
<cnd> heh
<cnd> actually, what is the server at for input abi
<RAOF> Yeah, Mr Remove Support for ABI < 12.2
<cnd> it's at 12.2 in 1.10 right now I think
<cnd> I just want to be sure
<cnd> anyways, I'll double check it
<cnd> the patches add in masked valuator support
<cnd> in xi 2.1 you can give incremental updates on valuators
<cnd> so if the pressure hasn't changed, then that valuator axis isn't sent in the device event
<RAOF> That makes sense.
<cnd> it's mostly a bandwidth save in the x protocol
<cnd> not huge for ST devices
<cnd> but pretty good for MT devices that support tens or more pointer
<cnd> points
<RAOF> Woah!  I just managed to crash zsh.
<cnd> heh
<cnd> did it give you a quip out of a dungeon crawler game?
<cnd> I can't remember what utility does that, maybe screen?
<RAOF> No, it just SEGVd
<RAOF> Screen, in nethack mode?
<cnd> I'm unaware of a nethack mode
<cnd> but if screen crashes it gives a nethack-like message
<RAOF> Hm.  1.10RC1 has input ABI 12.0, master as of not a long time ago has 12.1, and I'm fetching a fresh master...
<cnd> RAOF, well, if we're using 1.10RC1, then I'll just leave the patches alone for now
<RAOF> We're not using 1.10
<cnd> it would be nice to have, but I don't want to deal with breakage
<RAOF> RC1
<cnd> what are we using?
<cnd> some snapshot of master?
<RAOF> Yeah.
<RAOF> Master as current as possible.
<cnd> ok
<RAOF> Because there are ABI breaks between 1.10 and master, and I don't particularly want to rebuild the world more times than necessary.
<cnd> yeah
<cnd> in that case, it may be easier for me to give you an updated gesture patch
<cnd> unless you've already forward ported it
<RAOF> I have not.
<cnd> that one forward ported with ease
<cnd> just conflicts in configure.ac that wiggle handled
<cnd> hmm... master is still at 12.1
<RAOF> Ah, yes.
<cnd> I think peter has been meaning to bump it to 12.2, and the stuff in evdev is in xserver master
<cnd> but it's just not worth fiddling with that much
<cnd> if I can't git format-patch and shove it in debian/patches, it's too much work :)
<RAOF> Looking at the patch, it didn't seem to actually check for 12.2, just use things unconditionally.
<RAOF> Which means that if you're right, and master has what evdev needs, it'll just build?
<cnd> hmmm, let me double check
<cnd> RAOF, no, check evdev.h
<RAOF> Yeah, just saw it.
<RAOF> Although if you don't feel like fixing *that* up, I'd suggest you're feeling quite lazy :)
<cnd> heh
<cnd> well, I don't want to be patching things in and out as numbers change upstream
<cnd> and it's 10:18 pm here
<cnd> RAOF, so here's what I suggest:
<cnd> I can forward port the gesture patch for xorg-server and xserver-xorg-input-evdev tonight
<cnd> are the debian git repos up to date?
<cnd> if so, I can push the updated patches in there once I've got them working
<RAOF> Evdev is up to date, xserver is a couple of commits behind.  If you push to xserver I can happily just merge those changes in, though.
<cnd> ok
<RAOF> Oh, no.  It's not based on RC1+git in git.  I'll push that for you first.
<cnd> gah, apt-get is useless if you have broken deps
<cnd> anyone know how to tell it to stfu and do what I say?
<RAOF> No, sadly.
<RAOF> I either apt-get -f install to resolve things, or just apt-get download + dpkg --install
<cnd> RAOF, so what's going on with vmmouse and wacom?
<cnd> they still seem to have broken depends in xorg-edgers
<RAOF> Oh, really?
<cnd> at least on my computer
<cnd> which just as xorg-edgers and I just ran apt-get update
 * RAOF checks.
<cnd> vmmouse depends on xorg-input-abi-12.1
<cnd> wacom depends on xorg-input-abi-11.0
<RAOF> Aaah, yeah.  I see what's happened there.
<RAOF> wacom in edgers has been superceded by the archive version, which unsurprisingly isn't build against ABI 12.1
<cnd> yeah, I just noticed that too :)
<cnd> ok, I can get around this
<RAOF> Remove wacom?
<RAOF> And, looking at that list, I suspect synaptics, too?
<cnd> no, not good enough
<cnd> because xserver-xorg-input-all
<cnd> yada yada
<RAOF> Just remove -input-all
<cnd> but that's a dependency of something else
<cnd> hmm... maybe not
<cnd> maybe things just got in such an inconsistent state that I had to install it for some reason
<cnd> anyways, my machine is back to what it should be again
<cnd> RAOF, looks like there's another abi breakage
<cnd> I can't build the xorg-server package that exists in git.debian.org
<RAOF> cnd: In master right now, or the upcoming DGA thingy?
<cnd> in the ubuntu branch
<cnd> I'm hitting a build error in hw/vfb/InitOutput.c
<RAOF> That's odd.  It's *just* finished building right now locally.
<cnd> struct _Screen has no member named index
<cnd> RAOF, from the ubuntu branch?
<RAOF> Yeah.
<cnd> hmm...
<RAOF> I, um, think so?
<cnd> RAOF, what's your top commit hash?
<RAOF> fbfe7a1ec506
<cnd> that's not what I have...
<cnd> I have ef7a6ac...
<cnd> Set UNRELEASED; this isn't yet releaseable
<RAOF> You may have pulled before I pushed the update to the master snapshot?
<RAOF> Ah, yeah.  That's it.
<cnd> oh, ok
<RAOF> Hm.  To make it easy I should import the orig into the pristine-tar branch.
<RAOF> There you go.  Now with pristine-tar goodness.
<cnd> ok, hopefully I will finally have a tree that will build
<cnd> RAOF, I'm still hitting that doxygen bug
<cnd> how are you able to build it?
<RAOF> If you use git-buildpackage it should pull the .orig.tar.gz out of the pristine-tar branch?
<cnd> so I need to git fetch origin
<cnd> to get the new branch
<RAOF> Yeah.
<cnd> then do I need any options for git-buildpackage?
<cnd> I've never used it before
<RAOF> It should just work.
<RAOF> Although you might want to pass --git-ignore-new to it, otherwise it gets narky if you're not in an absolutely pristine git tree.
<RAOF> How's that going?
<cnd> well, it's still building
<cnd> but the doxygen isn't till the end
<RAOF> Ah.  You're not building in a chroot?
<RAOF> That *might* be why it built for me, then.
<RAOF> That'll be annoying if it is the case.
<cnd> no, I don't usually bother
<cnd> and it might explain it
<RAOF> I have a tmpfs chroot, which makes it nice and fast to sbuild, so that's what I tend to do.
<cnd> well, I can work around it for tonight
<cnd> so I can test and push
<RAOF> Yeah.
 * cnd is turning off his alarm tomorrow
<RAOF> Sorry for pulling you into a firedrill :(
<cnd> heh, this is basically payback
<cnd> remember when we pulled your out of your sleep for maverick feature freeze?
<RAOF> Yeah.
<cnd> really sorry bout that one
<cnd> :)
<cnd> got some wrong info and it caused a big mess
<RAOF> That's ok.
<RAOF> It didn't end up being *that* late for me.
<RAOF> I can pull through 2am once a cycle :)
<cnd> heh
<cnd> so, ubuntu doesn't use udebs anymore
<cnd> what would you think about patching out building them
<cnd> ?
<RAOF> We don't use udebs?  When?
<RAOF> Or do you mean -dbg packages.
<cnd> our installer isn't based on debian-installer
<cnd> hasn't been for quite some time
<RAOF> Even our alternate-cd?
<cnd> according to cjwatson
<cnd> hmm, don't know, but he said we didn't actually need utouch udebs
<cnd> and without those, you'd get no X evdev either
<RAOF> Maybe we don't use *X* in our alternate installer, and so don't need *X* udebs?
<RAOF> That would make sense.
<cnd> that could be?
<cnd> anyways, building these udebs all the time is annoying
<RAOF> So, you can avoid building the udebs with an environment variable...
<cnd> so if we don't need them, maybe we should set a work item for O
<cnd> yeah, I can
<cnd> if I remember
<RAOF> Indeed.
<cnd> but the buildd's can't
<cnd> it just sucks power and time
<RAOF> Yeah.  If we really don't need the udebs, then that's a reasonably small diff to carry for quite a lot of buildd time.
<cnd> ok, I got some debs for the server now
<RAOF> In a chroot, or does it build outside now?
<cnd> nah, I hacked it
<RAOF> Heh.
<cnd> gah!
<cnd> the xf86CoordinatesToWindow patch is fubar'd
<cnd> gotta fix it and redo it all again
<RAOF> Fubar'd, or just sticks the function definition way out in nowhere?
<RAOF> (In the header)
<cnd> yeah
<cnd> but in a location that breaks things
<RAOF> :(
<RAOF> At least ccache?
<cnd> hmmm... I don't think I have it installed...
<cnd> but I will use noudeb this time :)
<RAOF> Better than ccache!
<cnd> did you know that patch has been misnamed this whole time!
<cnd> 202_xf86CoordinationsToWindows.patch
<cnd> Coordinations?!
<RAOF> What, really?
 * RAOF loks
<cnd> yeah
<cnd> I'm fixing it
<RAOF> that's awesome.
<cnd> hrm, odd linking issue:
<cnd> /usr/bin/Xorg: symbol lookup error: /usr/lib/xorg/modules/input/evdev_drv.so: undefined symbol: grail_open
<cnd> I might know what's wrong though
<cnd> RAOF, success!
<cnd> I tested with ntrig touchscreen and magic trackpad
<cnd> including adding and removing the trackpad
<cnd> I just pushed the changes
<cnd> I hope they work for you :)
<cnd> cause I'm going to bed
<cnd> good night!
<RAOF> cnd: Awesomesauc.
<RAOF> cnd: Sleep well!
<RAOF> Um, what the hell?  I think I'm going to declare the inablility to click anywhere on the left-most ~150px of my dual head setup as a part of unity's general hatred of xrandr.
<RAOF> Since it goes away in metacity, and doesn't re-occur once I run âunity --replaceâ
<RAOF> Man.  We are the masters of not quite making 1.10's video ABI work.
<bryceh> RAOF, heya
<bryceh> RAOF, what's the problem?
<RAOF> bryceh: Oh, my plymouth patches cause xserver 1.10 to SIGSEGV because of stupidity and your ati patch FTBFS because you missed a semicolon :)
<RAOF> Bah.  I *hate* the way git doesn't update local branches unless you go crazy on it.
<tjaalton> RAOF: like, running 'git pull'?-)
<RAOF> tjaalton: No, like âgit checkout ubuntu ; git pull ; git checkout debian-unstable ; git pull ; git checkout debian-experimental ; git pull ; â¦â
<tjaalton> riight, that coulde be more straightforward
<tjaalton> -e
<RAOF> It's particularly annoying when you go âgit merge debian-unstable ; hack hack hack ...ââ¦
<RAOF> Whoops, obsolete branch!
<lool> Hi folks
<lool> I get corruption in xterm with latest natty packages
<lool> I guess it could be a -intel bug
<RAOF> There's a damage bug with -intel, I think.  It could be the same one.
<jcristau> there's https://bugs.freedesktop.org//show_bug.cgi?id=33253
<lool> RAOF: Sounds likely
<ubot4> Freedesktop bug 33253 in Driver/intel "[945] Left over damage in Emacs under Compiz" [Normal,New]
<lool> I found LP #665711 this morning, but the reporter says it's fixed for him and it's from November
<ubot4> Launchpad bug 665711 in xserver-xorg-video-intel (Ubuntu) "rendering bugs with xserver-xorg-video-intel (affects: 1) (heat: 33)" [Undecided,New] https://launchpad.net/bugs/665711
<lool> plus it's 10.10
<lool> closing this bug
<seb128> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/707236
<ubot4> Launchpad bug 707236 in xserver-xorg-video-intel (Ubuntu Natty) (and 2 other projects) "corruption in xchat-gnome window (affects: 1) (heat: 802)" [High,Confirmed]
<seb128> speaking of corruption
<lool> jcristau: Thanks, could be the same thing
<lool> LP #707236 is actually forwarded to http://bugs.freedesktop.org/show_bug.cgi?id=33650
<ubot4> Launchpad bug 707236 in xserver-xorg-video-intel (Ubuntu Natty) (and 2 other projects) "corruption in xchat-gnome window (affects: 1) (heat: 802)" [High,Confirmed] https://launchpad.net/bugs/707236
<ubot4> Freedesktop bug 33650 in Driver/intel "[965GM] Relocation beyond target object bounds" [Major,New]
<lool> seb128: Actually don't get these lines in dmesg
<RAOF> Oh!  Where did Bryce go?
<lool> I also have a 35M /var/log/gdm/:0.log full of:
<lool> (WW) intel(0): I830DRI2GetMSC:1062 get vblank counter failed: Invalid argument
<lool> (WW) intel(0): I830DRI2ScheduleWaitMSC:1118 get vblank counter failed: Invalid argument
<RAOF> Odd.
<kvalo> hi, I'm trying update a maveric laptop to natty, but get "E:Couldn't configure pre-depend x11-common for x11-xkb-utils, probably a dependency cycle."
<kvalo> I saw that this was already happening with maverick: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/639933
<ubot4> Launchpad bug 639933 in x11-xkb-utils (Ubuntu) (and 2 other projects) "10.04 -> 10.10beta: could not install the upgrades - Couldn't configure pre-depend x11-common for x11-xkb-utils, probably a dependency cycle. (affects: 41) (dups: 23) (heat: 288)" [High,Invalid]
<kvalo> I guess best workaround is to force remove x11-xkb-utils?
<cnd> RAOF, I don't imagine you're still up?
<bryceh> rats, system froze up again at 2:30am last night.  Did I miss anything?
<LLStarks> there was a sexy party
<LLStarks> you missed it
<bryceh> Sarvatt, uh oh - http://techreport.com/discussions.x/20326
<LLStarks> just read about that
<LLStarks> intel dun goofed
<LLStarks> might as well just wait for ivy bridge now
<LLStarks> "Intel said it expects to deliver the updated version of the chip set to customers in late February and expects a full recovery of production volumes by April. Intel said it would accept the return of the Cougar Point chip sets."
<LLStarks> ouch
<cnd> bryceh, what would you think of manually bumping the input abi to 13.0 in alpha 2?
<cnd> the reason I suggest this is so when we actually push in the xi 2.1 work all the drivers don't need to be rebuilt at once
<cnd> there won't be any backwards compat breakage
<cnd> right now the input abi is a huge test and development issue, as I have to tell people to apt-get remove xserver-xorg-input-all and all the old drivers other than evdev when they test
<cnd> at least, I think it should work ok
<cnd> there's a couple very minor changes in the abi that I don't think would be used by any drivers
<bryceh> cnd, hmm, couldn't that just be staged in a ppa?
<cnd> bryceh, I would have to stage every package
<cnd> though maybe that's not so hard
<cnd> I can copy the package from natty and tell the ppa to rebuild it
<cnd> yeah, that's probably a better solution
<bryceh> cool
<bryceh> could be less risky, and may give you a bit more flexibility in rolling out changes you need
<cnd> yeah
<LLStarks> bryceh, how can i force my touchpad to use synaptics instead of evdev?
<bryceh> llstarks, I'd set it in xorg.conf
<bryceh> hmm
<bryceh> The following packages have been kept back:
<bryceh>   libplymouth2 plymouth xserver-xorg-video-nouveau
<tjaalton> hmm, how do I change the address for ubuntu-x-swat -mail?
<tjaalton> it doesn't seem to obey the "normal" lp mail rules
<bryceh> tjaalton, I set it to send to a mailing list, which you can sub/unsub from
<bryceh> tjaalton, I just use procmail to filter it down myself
<tjaalton> bryceh: ah, looks like I got it now.. will see
<RAOF> cnd: Your 2am ping is unlikely to rouse me :)
<cnd> heh, no worries :)
<cnd> I can't even remember what I pinged you for now
<RAOF> For the Xi 2.1 transition, as that breaks the input ABI, right?
<cnd> yeah
<cnd> slightly
<cnd> iirc, just a few struct element rearrangements
<RAOF> Everything needs a rebuild?
<RAOF> Oh, goodie. *Silent* corruption :)
<cnd> yes, it will need it since all the dpkgs depend on a specific abi
<cnd> but I think we're ok for now
<RAOF> Yeah.  When we do that, if we need to rebuild all the input drivers, we should add a Breaks: on abi-12 and set the server input abi to something like 12+multitouch.
<bryceh> morning RAOF
<cnd> I'd say 12.99.1
<cnd> if you want to go with X numbering :)
<cnd> but I don't think that works
<cnd> so lets say 12.901
<RAOF> bryceh: Morning :)
<RAOF> I was actually just thinking of the input abi as specified in xorg-server/debian/inputabi
<RAOF> Rather than the actual searchable #define.
<cnd> RAOF, the abi is gathered from the x source code
<RAOF> Not the one in debian/inputabi.
<cnd> oh, you're thinking of *that* one
<cnd> well, that one will need to be bumped too
<cnd> but there's the other virtual package for input abi
<cnd> based on the source code
<RAOF> Yeah.
<RAOF> Oh, right.  And the one I'm thinking of isn't the one that produces the dependencies.
<cnd> well, as I found out today, it does produce some dependencies
<cnd> that are rather hard to track down :)
<RAOF> From memory, debian/inputabi is used to generate the Provides:
<cnd> yes, but what good is a provides if there's no depends? :)
<cnd> it turns out that the xorg-server binary package depends on those provides
<RAOF> It allows the xserver to Breaks on that provides.
<cnd> that may be too
<LLStarks> raof, that synaptics issue seems to have disappeared
<LLStarks> it had been bugging me for a few days though
<RAOF> Hurray!
<LLStarks> there was no obvious update that would've fixed this though
<RAOF> cnd: Oh, yeah.  xserver-xorg (prior to the most recent upload) Depended on x-x-{input,video}
<RAOF> cnd: Oh, yeah.  xserver-xorg (prior to the most recent upload) Depended on x-x-{input,video}-all | xserver-xorg-{input,video}-$ABI
<LLStarks> nonetheless, i think it's still worth keeping in the a2 notes. it could come back and i was even affected by it until about an hour ago.
<LLStarks> i didn't do anything beyond my normal laptop use routine
<RAOF> Is it now persistent across X server starts?
<RAOF> bryceh: So where are we vis-a-vis the xserver?
<bryceh> RAOF, I've got the packages built and have reviewed changelogs.  Tested some of them.  Trying to install xserver manually but having to force things a bit
<RAOF> Ah, of course.  Because I added a Breaks: to xserver-xorg-video-8 it won't install while you've got a video driver installed.
<bryceh> yeah
<bryceh> tried --force-breaks but that seems to have dug my hole deeper :-)
<RAOF> Just uninstall all your video drivers :)
<bryceh> ok
<RAOF> Hm.  --force-breaks *should* work.
<RAOF> Let me try again on a cleanish system...
 * cnd waits patiently too
<cnd> I'd like to move off of depending on xorg-edgers
<bryceh> making progress...
<cnd> and then I can just add patches in debian/patches for changes
<bryceh> cnd, that's a good idea
<bryceh> hmm, I seem to be in a dependency mess
<bryceh> ahh there we go
<bryceh> dah nope
<bryceh>  xserver-xorg-core (2:1.9.99.901+git20110131.be3be758-0ubuntu1) breaks xserver-xorg-video-8 and is unpacked but not configured.
<bryceh>   xserver-xorg-video-intel (2:2.14.0-1ubuntu3) provides xserver-xorg-video-8.
<bryceh> hmm I probably should have shoved all this into a ppa
<bryceh> it's like xserver doesn't want to install without a video driver, but the video drivers don't want to install without the xserver, and they won't install all-togther
<bryceh> http://paste.ubuntu.com/560766/
<Sarvatt> bryceh: need to rebuild everything against that new xserver's dev packages
<bryceh> Sarvatt, ah right, the pbuilder would have built -intel against the repo xserver
<bryceh> hrmm
<bryceh> but if I can't install it, how can I rebuild the driver?
<Sarvatt> bryceh: I use schroot to make it easier instead of pbuilder, you could add a local package repository to the pbuilder though
 * bryceh --force-depends
<lool> Hmm xserver-xorg-video-intel Recomends python-dev, isn't that a bit strong?
<lool> This pulls libssl-dev, zlib1g-dev...
<bryceh> lool, it might be overmuch; it's for the gpu freeze apport hook
<bryceh> lool, is there a better dependency for "this package has a python script"?
<RAOF> Shouldn't we actually declare a depends on apport instead?
<RAOF> And then override that lintian warning?
<bryceh> or we could move that script I guess
<bryceh> put it with the xorg apport hook
<lool> bryceh: python script should just be python?
<lool> bryceh: But apport implies that already
<lool> I mean, if people run apport, by definition they have support for apport hooks
<lool> I basically wouldn't declare any dep; just ask people to run apport / ubuntu-bug
<bryceh> lool, no the gpu hook fires off automatically when the gpu freezes
<lool> The intel_gpu_dump Recommends seems more adequate
<bryceh> at least, it's supposed to; it doesn't seem to work in all cases
<lool> bryceh: Where is this gpu hang hook?
<lool> Is it debian/apport-gpu-error-intel.py ?
<bryceh> lool, yes
<lool> SUBSYSTEM=="drm", ACTION=="change", ENV{ERROR}=="1", RUN+="/usr/share/apport/apport-gpu-error-intel.py"
<lool> bryceh: Yeah, so you definitely want an apport dep of some sort
<lool> It doesn't really matter too much that you use Suggests or Recommends; it only makes a difference for the case where people install their system without Ubuntu tasks like the desktop task since the task will pull apport
<lool> But since you will want to be the package pulling intel-gpu-tools by default, I'd probably recommends apport + intel-gpu-tools
<bryceh> RAOF, ok the -intel and -radeon packages look fine and boot into the old xserver ok (on two machines), I can upload those directly.  Not sure how to test mtdev but that looks safe to go in too.
<lool> and you could add an explicit python Recommends since the script is /usr/bin/python
<RAOF> I think mtdev has already happened.
<bryceh> lool, ok thanks
<RAOF> bryceh: Yup.  Someone's sponsored mtdev already.
<bryceh> RAOF, yep
<bryceh> RAOF, I can't easily test -nouveau but it looks sane, I can upload that too
<bryceh> looks like the same change as done in the others
<RAOF> Yeah.
<RAOF> I'll do some more testing on my other nouveau system.
<bryceh> alright, the three drivers are uploaded
<bryceh> -evdev seems not to have done anything obviously bad on my systems, I'll upload that too
<bryceh> [ubuntu/natty] xserver-xorg-video-intel 2:2.14.0-1ubuntu3 (Accepted)
<bryceh> [ubuntu/natty] xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu2 (Accepted)
<bryceh> [ubuntu/natty] xserver-xorg-video-ati 1:6.13.2+git20110124.fadee040-0ubuntu2 (Accepted)
<LLStarks> is nouveau gallium scheduled for natty or natty+1?
<LLStarks> *gallium 3d
<RAOF> It's already available in the form of libgl1-mesa-dri-experimental.
<RAOF> And has been for some time :)
<LLStarks> default seed?
<LLStarks> or rather, used by default?
#ubuntu-x 2011-02-01
<bryceh> [ubuntu/natty] xserver-xorg-input-evdev 1:2.6.0-1ubuntu4 (Accepted)
<RAOF> LLStarks: I guess we'll be discussing it (again) at UDS
<LLStarks> uds-o?
<LLStarks> regardless of what happens with nouveau 3d, 2011 needs to be the year of flawless switchable graphics on linux.
<tjaalton> what happened to the year of linux on the desktop?-)
<LLStarks> i couldn't give two ****s about optimus, but i want to be able to use a 540m if i buy a laptop with one
<LLStarks> tj, we can put that on hold for another 2 or 3 years like always
<RAOF> Flawless switchable graphics?  I wouldn't hold my breath.
<LLStarks> will linux-hybrid-graphics ever materilize into something usable, or do we have to wait for nvidia?
<LLStarks> wth jeopardy... you have a category called "good gnus" and not even a single gnu/linux question?
<bryceh> LLStarks, fairly certain they're waiting on patches from you
<LLStarks> lolno.
<RAOF> It's an interesting problem, patches could be fun.
<bryce_> X.Org X Server 1.9.99.901 (1.10.0 RC 1)
<bryce_> yay
<bryce_> synaptics acceleration is pretty crazy here though
<RAOF> Of *course* my hardware is magical.
<bryce_> yep and got the xchat corruption
<bryceh> alright, xorg-server and xorg packages have been uploaded
<RAOF> And they're built we'll need to rebuild the world.
<RAOF> s/And /And once/
<bryceh> yep
<bryceh>  RAOF, that script rocks
<bryceh> ok, messful of .changes ready to go
<RAOF> Which one?  The little bit of shell to grab the world?
<bryceh> yep
<RAOF> A little bit of judicious seddery can be a wonderful thing :)
<bryceh> had a minor bug (had to use '--rebuild' instead of '--build')
<RAOF> Oh, whoops.  EUNTESTED :)
<RAOF> We should hold off until xserver is bulit on at least i386, right?  Do the buildds guarantee build ordering?
<bryceh> we've needed to wait in the past
<bryceh> so, good time for a short break, than back at it
<bryceh> [ubuntu/natty] xorg 1:7.6~3ubuntu1 (Accepted)
<bryceh> [ubuntu/natty] xorg-server 2:1.9.99.901+git20110131.be3be758-0ubuntu1 (Accepted)
<bryceh> 3 of 4 builds finished https://launchpad.net/ubuntu/natty/+source/xorg-server/2:1.9.99.901+git20110131.be3be758-0ubuntu1
<RAOF> Hello, armel. Nice to see you keeping up :)
<RAOF> Hm.  And I've now got an sbuild capable of optionally building against the contents of ~/Builds.  Neat!
<bryceh> boy they weren't kidding about arm being slow
<bryceh> however looks like it published
<RAOF> I suspect it would be faster to virtualise on the insanely fast buildds.
<bryceh> alright, pulling the trigger on these rebuilds
<RAOF> Woot!
<bryceh> found another bug in your script ;-)
<Amaranth> bryceh: Did you say these uploads fix the xchat-gnome corruption? The screen is too distorted for me to tell for sure :)
<bryceh> Amaranth, no it causes the corruption (or at least, I can reproduce it now)
<Amaranth> oh, dang
<bryceh> yeah
<Amaranth> Wait, you couldn't reproduce with just the 2.14 intel driver?
<Amaranth> I'm tempted to hack up xchat-gnome to draw solid white before drawing anything else, I'll take the performance hit if it works around the issue
<bryceh> I hadn't happened to test it on this particular machine
<bryceh> until just today
<RAOF> Hm.  I can see that with emacs now.
<Amaranth> uh oh
<bryceh> alrighty, drivers going in
<RAOF> What was the additional bug in my script?
<bryceh> I needed to have --distribution specified; it was setting all the .changes to UNRELEASED ;-)
<RAOF> Whoops :)
<bryceh> also, good to note that the script pulls in xorg as well as drivers, so had to manually slice that out; no need for a rebuild there
<RAOF> Oh, dear lord qemu-arm is slow.  It's *almost* finished ./configure ing xserver.
<Amaranth> RAOF: Any this is why we use actual devices ;)
<Amaranth> The devices are getting faster, qemu not so much
<RAOF> Sadly I don't have an A9 device lying around to sbuild on :P
<RAOF> Although I guess I could ssh into a porter boxâ¦
<Amaranth> I have one, not going to try to build anything on it if I can help it
<Amaranth> yay cross compilers
<RAOF> Ah.  The other option :)
<Amaranth> I haven't played with dpkg-cross yet but from what I understand it'll let you build an armel package on x86
<Amaranth> But I suppose that's never going to be a good as building natively so I doubt we'll see armel builds happening on the x86 buildds
<RAOF> The buildds have insanely more powerful CPUs than an arm chip, though.  Could you get better performance by running qemu-arm on one of the i386 buildds?
<Amaranth> RAOF: You just saw how that works
<RAOF> Well, the buildds are much faster than my laptop.
<RAOF> Also, s/saw/seeing/.
<RAOF> :)
<Amaranth> RAOF: I dunno, they run the build in a VM
<Amaranth> VM on top of VM is usually incredibly slow
<RAOF> They could drop the outer VM, though.
<bryceh> wow slew of rejects
<bryceh> actually, slew of accepts, with a scant few rejects
<bryceh> RAOF, -vmmouse and -geode got build failures
<RAOF> Hm.  Did my -vmmouse sync request not go throughâ¦
<RAOF> Ah, no.  bug #709134 will fix vmmouse.
<ubot4> Launchpad bug 709134 in xserver-xorg-input-vmmouse (Ubuntu) "Sync xserver-xorg-input-vmmouse 1:12.6.99.901-1 (main) from Debian experimental (main) (affects: 1) (heat: 10)" [Wishlist,New] https://launchpad.net/bugs/709134
<bryceh> ok think we're done
<bryceh> no other failures except -geode
<bryceh> https://launchpad.net/ubuntu/+source/xserver-xorg-video-geode/2.11.11-1build1/+buildjob/2235710/+files/buildlog_ubuntu-natty-i386.xserver-xorg-video-geode_2.11.11-1build1_FAILEDTOBUILD.txt.gz
<RAOF> I'm on the geode failure.
<bryceh> awesome, thanks
<RAOF> I didn't pick it up, beacause !amd64
<bryceh> aha
<bryceh> RAOF, ok gonna go EOD for a bit; keep an eye on things, I'll check back in a couple hours or so in case of emergencies
<RAOF> bryceh: Ta.   Have a relaxing evening!
<bryceh> the dependency change for -intel that lool mentioned still needs done; I'll tackle that this evening but feel free to beat me to it ;-)
<RAOF> I may well :)
<bryceh> also, I stuck the build changes for -evdev into its git, but didn't do it for -intel
<RAOF> Ok.  I can fold that in, too.
<bryceh> ah -nouveau needs it too
<bryceh> bbl
<bryceh> RAOF, how's things stand?
<RAOF> bryceh: I've just figured out precisely what's wrong with geode.  http://cooperteam.net/Packages/xserver-xorg-video-geode_2.11.11-1ubuntu1_source.changes is ready for sponsoring.
<bryceh> thanks
<bryceh> RAOF, ok uploaded
<bryceh> ztv eh?
<bryceh> ok, speaking of tv, if there's nothing else, gonna go watch a movie
<RAOF> I guess you could mark bug #709134 as ready to upload.
<ubot4> Launchpad bug 709134 in xserver-xorg-input-vmmouse (Ubuntu) "Sync xserver-xorg-input-vmmouse 1:12.6.99.901-1 (main) from Debian experimental (main) (affects: 1) (heat: 10)" [Wishlist,New] https://launchpad.net/bugs/709134
<RAOF> s/upload/sync.
<bryceh> ok
<LLStarks> btw, i think i've only seen the 945gm graphical corruption once, if at all
<LLStarks> might've been too drunk
<bryceh> Amaranth mentioned it too; I suspect you and he both have the same bug.  
<LLStarks> raof or bryceh, can i do a safe-upgrade? some x packages are being upgraded.
<LLStarks> will i have abi issues?
<RAOF> You shouldn't be able to break things without removing packages.
<RAOF> So a safe-upgrade should be safe.
<bryceh> alrighty, will check back in a couple hours
<LLStarks> so, if i let intel and evdev update, it's fine?
<RAOF> Modulo, as always, proprietary drivers!
<RAOF> If they can without removing other packages, yes.
<bryceh> back
<RAOF> Is there *really* anyone insane enough to want to pair an Intel i740 chip with an arm CPU? :)
<tjaalton> heh, it's built on arm?-)
<RAOF> Yes ):
<RAOF> :)
<tjaalton> maybe the right thing to do is to drop the driver altogether :)
<RAOF> But how will users with 20 year old hardware use it to its full potentialâ½
<RAOF> Dear lord.  That *is* 20 year old hardware, isn't it.
<tjaalton> hmm, lets see
<tjaalton> actually only 13y old
<tjaalton> seems to be the first to use agp
<RAOF> Oh, yeah.  That's right.
<tjaalton> well, according to wikipedia
<RAOF> So 1998?
<tjaalton> yep
<tjaalton> sooo 90's..
<RAOF> Hm.  I thought it was older.
<tjaalton> yeah, not like tseng which is pci (had an ET6000 on my first pc)
<RAOF> I had a kick-arse pentium 90, with a... S3 virge?
<RAOF> A full 2MB of video ram, too.
<RAOF> Or maybe it was 4?
<tjaalton> my first one was with k6-200
<lool> xserver-xorg-input-mouse seems to either need a rebuild or be dropped from input-all?
<RAOF> lool: Need a rebuild.  I'm on it.
<RAOF> It also needs people to stop using it, but it's probably useful to some arcane hardware, like -keyboard is.
<lool> RAOF: You might want to drop it from -input-all in the latter case?
<RAOF> lool: It isn't *in* input-all.  At least on amd64.
<lool> While I found the -video-all and -input-all approaches elegant, it would make more sense to treat these as -popular or something since we're effectively providing a subset
<RAOF> -video-all-that-we-care-about :)
<lool> RAOF: Oh right, vmmouse is; I'm not sure why my upgrade wanted to remove input-all, will tell you once I finish it
<lool> RAOF: Yeah something like this  :)
<RAOF> We'd need to drop a *lot* of drivers to get to -video-all-that-we-care-about :)
<RAOF> For an example currently in my attention, I give you tdfx.  A card highly likely to be paired with an arm processor... :)
<lool> RAOF: Ah vmmouse is what caused -all to go away
<RAOF> Yeah.
<RAOF> There's a big stack of rebuilds queuing up.
<lool> RAOF: Queue seems empty
<lool> 1 job
<RAOF> Not at http://cooperteam.net/Packages
 * lool is looking at https://launchpad.net/builders
<lool> RAOF: what's this repo for?
<RAOF> It's my staging sponsorship queue.
<RAOF> Once I've got _all_ the needed rebuilds in there and tested, I'll dump it on pitti or cjwatson and go to sleep. :)
<lool> Ah; I could offer sponsorship, but given the size and hence complexity of the Xorg transition and the fact we're in freeze already, I will leaveit to your regular sponsors
<RAOF> Thanks.  Colin's already volunteered; I suspect he'd like the archive installable pronto :)
<lool> eh
<tjaalton> RAOF: I can sponsor as well
<RAOF> tjaalton: That'd be nice.  I'm on -vesa now, so there's not much more to go in there.  I'll finish up, test build everything, and poke you?
<tjaalton> sure
<mdeslaur> It would appear I can't dist-upgrade at the moment. Is this known? http://paste.ubuntu.com/560951/
<mdeslaur> ah, never mind, I just noticed all the uploads
<tjaalton> yeah rebuilds needed
<tjaalton> RAOF: so you got everything uploaded that was needed?
<LLStarks> raof, are we still waiting for mouse and vmmouse to build?
<tjaalton> mouse is fine
<tjaalton> dunno about vmmouse
<tjaalton> vmmouse built too
<LLStarks> aptitude wants to remove both
<tjaalton> your mirror isn't uptodate
<LLStarks> main archive
<LLStarks> wait, us archive
<tjaalton> i bet it's lagging behind
<LLStarks> switching
<LLStarks> same prob with main
<tjaalton> it could take an hour or two until they are moved there
<bryceh> tjaalton, welcome to canonical :-)
<tjaalton> bryceh: thanks :)
<bryceh> tjaalton, did RAOF get everything uploaded he needed?
<tjaalton> bryceh: I think so yeah
<Sarvatt> bryceh: why do we always end up updating intel just in time for a new horribly busted kernel upload? :)
<bryceh> Sarvatt, what's up?
<Sarvatt> (2.6.38)
<Sarvatt> last time we did it was 2.6.37 rc1 and we got a bunch of bugs that were kernel problems on intel too
<bryceh> tjaalton, Sarvatt btw were you guys able to successfully upgrade to the new X via the archive?
<Sarvatt> vmmouse and mouse still holding it back here
<bryceh> hrm
<Sarvatt> i need to set up another natty machine, got everything but my main laptop reinstalled to maverick at the moment for this hibernate issue
<bryceh> Sarvatt, any chance you could pastebinit the failure messages?
<Sarvatt> bryceh: AH mouse and vmmouse just updated in the last few minutes on us.archive.ubuntu.com
<bryceh> sweet
<tjaalton> I haven't tried upgrading yet
<bryceh> tjaalton, yeah right now's not a great time to be upgrading :-)
<LLStarks> uwaa
<LLStarks> is there breakage?
<bdmurray> might bug 711284 be X related?
<ubot4> Launchpad bug 711284 in linux (Ubuntu) "After natty update today, system is unresponsive and freezes often (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/711284
<bryceh> bdmurray, hmm not the typical characteristics of an X bug but its possible
<bryceh> bdmurray, we've not had other reports of an issue like that
<bdmurray> bryceh: okay thanks
<bryceh> RAOF, btw when you're online, rickspencer ran into an upgrade conflict that you might want to take a look at
<bryceh> RAOF, looks a lot like what happens when you have xorg-edgers installed, but he says he doesn't so I'm not sure what is wrong
<RAOF> bryceh: Where's Rick's report?
<bryceh> http://paste.ubuntu.com/561141/
<RAOF> Thanks.
<bryceh> RAOF, I should have had him file an actual bug, but not sure if it was just configurational stuff
<RAOF> Oooh, xserver-xorg-video-v4l
<RAOF> That's not going to work, as V4L has been removed from the kernel.
<RAOF> That could be it, or a part of it.
<bryceh> driver rebuilder lives here now:  https://code.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools
<bryceh> I stuck the todo's in there, feel free to hack on it if you want.  converting it to python wouldn't be a bad idea either
<bryceh> figure we can maybe work on it as we go through this again in the future
<bryceh> btw I've done the xkeyboard-config merge
<bryceh> too late for alpha2 (plus not really that critical anyway), but will shove it in after
<RAOF> Great.
#ubuntu-x 2011-02-02
<LLStarks> so, ubot: bug 711568
<ubot4> Launchpad bug 711568 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "Dithering regression on Intel graphics with .38 Natty kernel (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/711568
<LLStarks> gonna do some upstream testing
<RAOF> The obvious interesting testing would be to find the commit which regressed things.
<RAOF> There wouldn't actually be *that* many commits to the relevant code between the last working kernel and the first one that fails.
<NCommander> If I have a segfault on startup with X, what's the best way to obtain a GDB trace? I tried to get a corefile, but failed miserably
<bryceh> NCommander, https://wiki.ubuntu.com/X/Backtracing
<tjaalton> hmm, upgrading would remove -nv and -nouveau
<tjaalton> and plymouth, by the looks of it
<tjaalton> oh right, xorg-edgers fallout
<gaelle_> hello, i have a problem with the intel driver in the xswat repository. I solves a big rendering bug i'm having with 10.10, but i can not use a dual screen setup anymore
<gaelle_> the problem is, the second screen is working correctly, but the primary screen is shifted to the left by around 200 pixels. those 200 pixels on the right side of the screen that "should" be black, are filled with the leftmost 200 pixels of the second screen
<gaelle_> the second screen is on the left of the first screen
<gaelle_> i can't take a screenshot because on the screenshot everything looks correct
<gaelle_> i could take a photograph if somebody would be interested
<tjaalton> what's the original bug#
<tjaalton> and the commit that claimed to fix it
<tjaalton> and do you mean xorg-edgers or x-updates?
<gaelle_> i mean x-updates. i don't have a original bug, never searched for it actually, just tested if the x-updates ppa would solve my problem
<tjaalton> well, looks like it's a backported package from natty, and it's not generally supported
<tjaalton> and it's an old release
<tjaalton> the backported driver that is..
<gaelle_> i see, so i should not use x-updates in 10.10
<gaelle_> would xorg-edgers be better?
<tjaalton> probably not :)
<tjaalton> since it tend to follow the crack-of-the-day
<tjaalton> tends
<tjaalton> though I'm not sure how it is right now
<tjaalton> you could try natty alpha2 once it's ready, and see if both of those are fixed
<tjaalton> ..with no new regressions :)
<gaelle_> i will do that. thanks for your help :) helps me to save some time ;)
<tjaalton> np
<bryceh> morning
<tjaalton> evening :)
<bryceh> tjaalton, how was your first day?  exciting?  dreadful?  mired in paperwork and subscription forms?
<tjaalton> bryceh: just pending on getting shell access so I can configure procmail
<bryceh> btw some of the internal lists are rather chatty, sometimes mindlessly so ;-)
<tjaalton> filters will take care of it :)
<tjaalton> I upgraded to current natty, seems to work ok
<tjaalton> suspend still doesn't though
<bryceh> tjaalton, nvidia?
<tjaalton> nope, intel
<bryceh> hmm, it's been working for me ok
<bryceh> actually been quite reliable on several machines
<tjaalton> mine just reboots on resume
<tjaalton> on kernels newer than 2.6.35
<bryceh> tjaalton, ok that sounds bad.  I'd suggest filing a kernel bug
<tjaalton> done that some time ago
<tjaalton> I'll poke people again after the .38-rc3 kernel is in the archive
<bryceh> tjaalton, bug #?
<bryceh> ok, that sounds good
<bryceh> tjaalton, by the way, the technique for getting the kernel team to look at bugs is to pm JFo and ask him to "put it on the kernel team's review list"
<bryceh> and then buy him a beer if it works ;-)
<tjaalton> alright, brian already assigned it to the team (well, mine ;)
<tjaalton> will make sure JFo knows about it if I can reproduce it with the post-alpha2 kernel
<bryceh> tjaalton, exellent, good luck
<bjsnider> Sarvatt, do you think it would be worthwhile to rebuild the 270 blob to account for the changes in natty?
<Sarvatt> bjsnider: I dropped the abi stuff in the x-updates one so it'd work, it doesn't work with this xserver though
<bjsnider> i thought they added support in the 270 blob?
<Sarvatt> for xserver from december 7th, there have been 2 abi breaks since then
<bjsnider> well, that's the end of that idea
<Sarvatt> shouldn't be too much longer hopefully, they said the next 270 beta would work
<LLStarks> http://linux-hybrid-graphics.blogspot.com/2011/02/update-on-hybrid-graphics-linux.html
<LLStarks> D: and :D
<bdmurray> bryceh: okay, you got me.  I have a terrible work around for bug 710630
<ubot4> Launchpad bug 710630 in xorg (Ubuntu) "fglrx apport hook AssertionError in __setitem__ (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/710630
#ubuntu-x 2011-02-03
<bryceh> bdmurray, aha, awesome
<bdmurray> bryceh: its not a good solution but something to get the data right now
<bryceh> bdmurray, do you think this issue is important enough to put in for alpha-2?
<bdmurray> bryceh: I forget it doesn't block bug reporting for X right?
<bryceh> bdmurray, not that I know
<bryceh> actually it might for some cases
<bryceh> bdmurray, I take it you're alluding to say, "Dummy, people being unable to report bugs kinda undermines the whole idea of having an alpha release"
<bdmurray> bryceh: well more like "If it prevents getting useful data then yes its important for A2"
<bdmurray> bryceh: or if it makes people goto +filebug instead of using ubuntu-bug ;-)
<bryceh> bdmurray, how's this look:
<bryceh>         if os.path.lexists('/usr/lib/nux/unity_support_test'):
<bryceh>             try:
<bryceh>                 ust = command_output_quiet([
<bryceh>                     '/usr/lib/nux/unity_support_test', '-p'])
<bryceh>                 ust = ust.replace('\x1b','').replace('[0;38;48m','').replace('[1;32;48m','')
<bryceh>                 report['UnitySupportTest'] = ust
<bryceh>             except AssertionError:
<bryceh>                 report['UnitySupportTest'] = 'FAILED TO RUN'
<bdmurray> testing it without the work around - I can still report a bug
<bdmurray> but that looks fine to me
<bryceh> alrighty
<bryceh> bdmurray, uploaded
<bryceh> might be too late for alpha-2 but we'll see
<bdmurray> have you thought about moving the hook to a "smaller" package at all?
<bryceh> the xorg package is actually quite small
<bryceh> but yeah I've thought of maybe moving this apport hook and the intel gpu hook (and maybe the old bulletproof-x bits) out into a separate package
<bryceh> -ENOTIME ;-)
<bryceh> if nothing else, doing so would help to minimize our diff against the debian upstream packages.
<bryceh> but I think there might also be some potential for shared code between the three scripts
<bdmurray> I thought the 'Unsupported Ubuntu Release' bit would be good in apport proper
<bryceh> bdmurray, thanks yeah I think so too
<bryceh> there is some logic for figuring out what kind of regression the bug is, which I think might be a bit better than what's in the kernel apport hook as it has less user prompting
<bryceh> feel free to cherrypick.
<bryceh> I eventually plan to try submitting some of it back to apport, if/when we ever get caught up on the X bugs
<bryceh> RAOF, I'm losing steam as EOD approaches but have hammered the tip off of Spikey McSpike - http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<bryceh> RAOF, if you get a chance today could you look at bugs #707236 and #710961 - two corruption regression bugs
<ubot4> Launchpad bug 707236 in xserver-xorg-video-intel (Ubuntu Natty) (and 2 other projects) "corruption in xchat-gnome window (affects: 3) (heat: 26)" [High,Confirmed] https://launchpad.net/bugs/707236
<ubot4> Launchpad bug 710961 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack (affects: 2) (heat: 14)" [Undecided,New] https://launchpad.net/bugs/710961
<RAOF> Certainly.
<bryceh> thanks, I'm going to try focusing on forwarding the new bugs and patches upstream tomorrow.
<bryceh> if there's any you already have an inkling about please put a comment on them - here's a report that might be easier to work from: http://blumonc/Arsenal/Reports/ubuntu-x-swat/workqueue-natty.html
<RAOF> blumonc?
<bryceh> dah
<bryceh> http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/workqueue-natty.html
<bryceh> if there's any you want to look into yourself, assign yourself and I'll skip upstreaming them for now
<RAOF> Ok.
<bryceh> the couple tagged iso-testing and pcert are also probably high priorities for us
<RAOF> Ok, I think I'm closing in on bug #707236.  Interested parties should try reverting 1ba983034 from xserver-xorg-video-intel. :)
<ubot4> Launchpad bug 707236 in xserver-xorg-video-intel (Ubuntu Natty) (and 2 other projects) "corruption in xchat-gnome window (affects: 3) (heat: 26)" [High,Confirmed] https://launchpad.net/bugs/707236
<Amaranth> RAOF: Yeah, that looks likely
<RAOF> Well, not only likely, but reverting it fixes emacs for me.
 * Amaranth kicks qwest
<Amaranth> I may not be able to test for a while, internet is like dialup with slightly better ping right now
<RAOF> Yay.
<RAOF> Anyway, I'm working out whether that commit was always broken, or is interacting with the damage updates in Xserver 1.10
<Amaranth> yay it sped up, building now
<Amaranth> test
<Amaranth> hrm, need a long line first
<Amaranth> test again
<Amaranth> yay
<Amaranth> RAOF: Confirmed, that fixes the problem
<RAOF> Amaranth: Nifty.
<Amaranth> hmm, got an apport report for memcheck-amd64
<Amaranth> that's scary
<Amaranth> odd that regular xchat didn't have the problem, I guess they've gotten out of sync
<RAOF> Maybe.  Emacs has a similar problem.
<RAOF> It's probably only things which draw in specific ways.
<RAOF> Hm, no.
<RAOF> Looks like that commit is just broken.
<bjsnider> Amaranth, i have been trying to tell you that xchat is better
<Amaranth> bjsnider: Oh no, I used it for a couple hours to see if it had gotten better
<Amaranth> It's ugly
<bjsnider> what?
<Amaranth> It doesn't sort networks alphabetically, uses colors instead of icons to represent incoming messages, you have to show the user list to see the lag stats, and I always had to right click a URL to open it
<bjsnider> wow
<bjsnider> all of the things you just mentioned would irritate me in reverse
<bjsnider> i find the colors better for incoming messages than the icons in xchat-gnome
<bjsnider> i don't want every stray click opening a url
<bjsnider> the networks don't have to be sorted at all
<bjsnider> i thought your original objection to it was that it didn't have support for any gnome themes and so forth.
<Amaranth> bjsnider: Not themes, integration (using gconf, HIG, etc)
<LLStarks> stupid question. is it possible to have a task started in an ssh session continue after that session ends?
<soren> LLStarks: Not really on-topic in here, but look at nohup's man page.
<ara> bryceh, hello!
<bryceh> ara, hi
<ara> bryceh, we got a similar bug about xorg crashing for intel during ubiquity installation
<ara> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/708744
<ubot4> Launchpad bug 708744 in xorg (Ubuntu) "Xorg segfaults during installation process (affects: 1) (heat: 10)" [High,Triaged]
<ara> we opened a new one, but it seems to be quite similar to https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/705078
<ubot4> Launchpad bug 705078 in xserver-xorg-video-intel (Ubuntu) "Xorg crashed with SIGSEGV in pixman_image_set_has_client_clip() (affects: 9) (dups: 2) (heat: 64)" [High,Fix released]
<bryceh> ara, what I think would help would be to gather a full backtrace
<bryceh> ara, I can look into it more tomorrow; it's late for me
<ara> bryceh, sure, good night!
<bryceh> ara, probably what I should do is figure out how to reproduce it on my own hardware
<bryceh> ara, any tips on how to reproduce it could probably help
<bryceh> ara, ultimately I suspect that the crashes are symptomatic of a deeper issue at work, which remains mysterious
<bryceh> ara, I'm also somewhat wondering if it may be a peculiarity of the testing environment, because I've not seen similar reports from ordinary users installing normally
<ara> bryceh, no idea, for us it always happens (using a preseeded installation over the network)
<bryceh> it makes me wonder if this is dependent on some characteristic of how these tests are being installed
<ara> bug https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/706117 contains the preseed file
<ubot4> Launchpad bug 706117 in ubiquity (Ubuntu) "Installation fails using preseed file and network install (affects: 1) (heat: 10)" [Undecided,New]
<ara> it may help you trying to reproduce it
<seb128> bryceh, hey, thanks for the dx reports
<seb128> bryceh, thanks for sending the email to the list as well
<bryceh> ara, unfortunately I don't know how to make use of "preseed files" - if you can explain further on the bug report it might help me
<bryceh> seb128, heya, yep glad they're of use
<ara> bryceh, sure, will do 
<seb128> bryceh, do you think having a summary of natty tasks would be useful as well?
<seb128> it's a bit similar to the milestoned list
<bryceh> seb128, you mean bug tasks targeted to a particular release, yeah I think that could be of use
<bryceh> seb128, I don't have that hooked up yet though
<seb128> bryceh, right, I wanted the milestone list to build a list of things we (desktop or contributor) should work on if they want to help unity
<seb128> but I figure that "bugs that would be nice to fix for natty" are either milestoned or have a natty task
<bryceh> seb128, could you file a bug against arsenal requesting this?  It can be done but might take a bit before I get to it.
<seb128> so we might still miss the ones without a milestone
<seb128> bryceh, ok, will do
<bryceh> seb128, yeah agreed
<seb128> the workaround would be milestone all the bugs we are about for beta or natty
<seb128> are->care
<bryceh> I've been lucky with xorg to not have so many bugs (yet) to need to filter on that, but for unity I can see that would be quite handy
<bryceh> seb128, btw with the 'workqueue' report, a technique for managing it is to be very aggressive at setting bugs to Incomplete.  Since the report excludes bugs waiting on responses, that can help keep the report useful.
<bryceh> plus it has the pleasant side effect of making reporters feel they're getting quick responses ;-)
<bryceh> night (dead tired)
<seb128> bryceh, right, thanks for the hint, 'night!
<mvo> hey guys, anyone minds if I upload http://paste.ubuntu.com/561936/ ? (xserverxorg-video-intel)
<tjaalton> mvo: pretty sure it's ok
<alf_> Hi! I am using the xorg-edgers PPA. For r600 the classic driver is the default for GL, although when running GLES2 apps the gallium driver is used.
<alf_> The problem is that when forcing gallium (ForceGallium="true" in xorg.conf) GLES2 apps now complain with "libEGL warning: DRI2: could not open  (No such file or directory)"
<alf_> GLES2 apps run fine with gallium when not forcing it in xorg.conf
<alf_> Any ideas?
<Sarvatt> EGL_DRIVER=egl_gallium yourapp work?
<Sarvatt> there has been a bunch of changes for the egl stuff recently in 7.11 and i haven't had time to fix it all up
<alf_> Sarvatt: http://paste.ubuntu.com/562094/
<alf_> it uses the softpipe, while when not forcing gallium it correctly uses the hardware driver
<Sarvatt> its because we're renaming the dri2 driver name for the forcegallium thing
<Sarvatt> (to r600g)
<Sarvatt> natty mesa doesn't work either right?
<alf_> Sarvatt: haven't checked, I was following the +gallium PPA before and now switched to the main xorg-edgers one
<Sarvatt> hmm, looking at it I'm not sure how to fix that
<Sarvatt> alf_: to work around it you could just drop forcegallium and make /usr/lib/dri/r600_dri.so the gallium version
<bryceh> RAOF, another funky upgrade blockage - https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/712640
<ubot4> Launchpad bug 712640 in xorg-server (Ubuntu) "package xserver-xorg-core 2:1.9.0.902-1ubuntu4 failed to install/upgrade: ErrorMessage: installing xserver-xorg-core would break existing software (affects: 1) (heat: 6)" [Undecided,New]
<Darxus> How much of wayland's dependencies made it into alpha 2?  Should a pre-BGRA version build and work, but not the latest with BGRA?
<Darxus> And is it appropriate for me to ask here?
<bryceh> Darxus, some deps didn't make it; I've been waiting on cairo in particular which is still tbd
<Darxus> Thanks.
<bryceh> it was my goal to have it all in by alpha-2 but just didn't have time, too many other priorities
<Darxus> I understand.
<Darxus> I appreciate that it's on your list.  And I'll care more when wayland is actually usable :)
<jcristau> that'll take a while
<Darxus> jcristau: Yup.
<alf_> Sarvatt: Yes, I think I'll do that and keep the old version around to use it with LIBGL_DRIVERS_PATH if needed
<alf_> Sarvatt: though it complicates upgrading as I have to do this everytime I upgrade :(
<Sarvatt> yeah :(
<Sarvatt> I'm not sure how to fix it properly, it's broken in natty too from what I can see
<Sarvatt> need to make the r600 gallium driver accept a r600g dri driver name too
<alf_> Sarvatt: was the idea of having an r600_dri symlink to either r600c or r600g considered as a solution to gallium vs mesa selection?
<alf_> I mean gallium vs classic
<Sarvatt> yeah it was but no one wanted to implement all the extra complexity in the mesa packages and you lose the ability to have automatic fallbacks to the other driver if you switch to UMS for example
<Sarvatt> that option is starting to grow on me though :)
<jcristau> what about just shipping one driver?
<jcristau> and if you want ums, then tough, you don't get 3d.
<Sarvatt> next cycle
<jcristau> k
<Q-FUNK> howdy! seems that X upgrade from maverick barfs majorly.
<Q-FUNK> everything correctly depends upon video driver 9, but dpkg refuses to deconfigure older drivers during the upgrade, because it would break them
<Q-FUNK> seems that we need to remove xserver-xorg-video-v4l before we do anything else
<RAOF> Woot!  Intel corruption fixed.
<Q-FUNK> RAOF: where? :)
<RAOF> Upstream, and cherry-picked by mvo.
<Q-FUNK> nice
<Q-FUNK> already in natty?
<bryceh> yep
<bdmurray> bryceh: xorg package hook has CompositorRunning and CompisitorRunning keys in it
<bryceh> heh
<bdmurray> also I'm not sure report[compiz_version] gets set anywhere
<bryceh> fixed the misspelling
<bryceh> yeah that should just be 'compiz_version', darn
#ubuntu-x 2011-02-04
<RAOF> Hm.  My mesa patches _look_ like they're getting to the mailing list...
<bryceh> hi RAOF
<RAOF> bryceh: Heya.
<RAOF> Oh, man.  Quater to 7?
<RAOF> Or ever quarter.
<RAOF> Quark ot 7!
<bryceh> nipping the rum a touch?
<bryceh> whew, I might have fixed #705078... that's a tough one
<bryceh> RAOF, btw thanks for fixing that intel corruption, that was nice getting that patch in this morning
<RAOF> I didn't fix it, I just identified the problem.  The other Chris fixed it :)
<bryceh> ok well facilitating getting it fixed.  :-)  fixed is fixed
<bryceh> RAOF, I've been hammering at the xserver crashes pretty heavily and squished nearly all the crashes - https://bugs.launchpad.net/ubuntu/+source/xorg-server?field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.tag=natty+-kubuntu+-xubuntu+-ppc+-omit&field.tags_combinator=ALL
<bryceh> RAOF, bug 711422 appears to be something in the glx code
<ubot4> Launchpad bug 711422 in xorg-server (Ubuntu) (and 1 other project) "Xorg assert failure: X: double free or corruption (!prev): 0x089f5b20 *** (affects: 7) (dups: 6) (heat: 1767)" [High,Triaged] https://launchpad.net/bugs/711422
<bryceh> RAOF, and bug 712640 is another xserver upgrade glitch, perhaps similar to the one you helped rick with.  Guessing its a user configuration problem.
<ubot4> Launchpad bug 712640 in xorg-server (Ubuntu) "package xserver-xorg-core 2:1.9.0.902-1ubuntu4 failed to install/upgrade: ErrorMessage: installing xserver-xorg-core would break existing software (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/712640
<lool> Oy
<lool> Could we get the patch from freedesktop #32734 into Ubuntu?
<ubot4> Freedesktop bug 32734 in Driver/intel "Lost damage with compiz" [Major,Resolved: fixed] http://bugzilla.freedesktop.org/show_bug.cgi?id=32734
<lool> da990536eca09c6de74627541cd56ecfad925eda upstream
<lool> uxa: Undo damage translation before appending
<seb128> lool, hey, isn't that the patch mvo uploaded yesterday?
<seb128> lool, seems similar
<lool> Oh yes
<lool> Cool, thanks
<mvo> lool: that should be in already, could you please check if your xserver-xorg-video-intel in up-to-date
<lool> I was going over my bugzilla mail and noticed the fix, but hadn't upgraded this morning
<tjaalton> :)
<lool> \o/   solves the xterm issues as well
<lool> lovely
<lool> mvo, seb128: Thanks  :-)
<seb128> lool, yw
<mvo> yw
<LLStarks> bryceh, is this good enough? http://launchpadlibrarian.net/63566988/banding.jpg
<LLStarks> tilt your screen if it's hard to see
<bryceh> LLStarks, yep that'll do it
#ubuntu-x 2011-02-05
<Gumby> hi all.  I've added the ubuntu-x server and upgraded the nvidia packages in natty.  X fails to start afterwards and Xorg.0.log mentions that I need to use --ignoreABI because of the unsuppoted X version.  Where exactly do I add this?
<bryceh> Gumby, can't use proprietary -nvidia on natty for now
<bryceh> Gumby, see release notes
<Gumby> ah, so no 3d or Unity?
<Gumby> I tried also using the default development driver as well but that didnt seem to work either
<bryceh> there's an experimental 3d mesa package that adds 3d to nouveau
<bryceh> it's not supported though, but might work
<bryceh> we'll get a fixed -nvidia within a month or so
<Gumby> ok.  thanks for the info
<hifi> hey, why the newest savage ddx ain't pulled to natty?
<hifi> it's only a bugfix release that is required for it to work properly
<tormod> hifi, the bug fix in savage 2.3.2 was cherry-picked to maverick/natty 2.3.1
<tormod> hifi, but there is nothing against merging 2.3.2-1
<hifi> tormod: oh, good to know, thanks
<tormod> hifi, what card do you have?
<hifi> thinkpad t23, it has a supersavage, can't remember the exact model
<hifi> I did the original bug report to upstream
<tormod> hifi, alright. btw, does glxblur work on it?
<hifi> blur? never used it
<tormod> it's an xscreensaver hack
<vish> ooh! kernel .38 with ati makes we feel funky :D , weird flashes/glitches with compiz.. ;)
<hifi> not even any desktop effects work, like compositing
<hifi> as far as I've tested
<hifi> the only thing the card is good for is xmoto
<tormod> hifi, yes, compiz won't work, missing support for NPOT textures
<hifi> I mean not even xcompmgr
<tormod> vish, for me the .38 work fine in lucid, but natty is a bit unstable, probably the new ddx enabling new features (pageflip)
<vish> on maverick here, cube and anything triggering fullscreen changes causes odd effects..
<vish> not permanent, i'd just have to switch views to something else and back, it clears up
<vish> changing workspaces with the cube is the best, its like a disco flashing :D
<tormod> hifi, Alex V.L. was looking at composite for savage once (http://lists.x.org/archives/xorg/2008-April/034441.html) but I would not hold my breath
<tormod> the card is good for some 3D screensavers :)
<hifi> if you can stand the high pitch noise :p
<hifi> at least my T23 puts out one when it's rendering 3D
<alex_mayorga> Any reports of video corruption in 2.6.38 on nvidia cards?
<alex_mayorga> Can I get some pairs of eyes on bug 713781 please?
<ubot4> Launchpad bug 713781 in xorg (Ubuntu) "[natty] Video corruption on kernel 2.6.38-1-generic and nVidia Corporation GT216 [GeForce GT 230M] (rev a2) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/713781
<alex_mayorga> What else should I provide?
#ubuntu-x 2011-02-06
<onebitxajax> hi to all
<onebitxajax> how can i add the repo to my ubuntu?
<onebitxajax> it give me error readerng https://launchpad.net/api/1.0/..... HTTP error 404
<tjaalton> RAOF: hey, opinions on bug 652467 before I decline it?
<ubot4> Launchpad bug 652467 in xorg (Ubuntu) "xerver-xorg-video-ati dependancies need changing (affects: 1) (heat: 28)" [Undecided,New] https://launchpad.net/bugs/652467
<tjaalton> 1) is not possible, -ati is just a wrapper
<tjaalton> 2) would mean (AIUI) bigger static mappings to the server, which is pointless
<tjaalton> 3) then reveals the true nature of the bug (micro-management), so it's just silly
<tjaalton> mach and r128 add 400kB to the install
<tjaalton> in total
<RAOF> Yeah.  I don't think that's worth doing.
<tjaalton> thanks, I'll close it as wontfix
<RAOF> That micro-management *is* possible, too - it just requries an xorg.conf
<tjaalton> yeah
<RAOF> Hm.  Is there any reason we shouldn't follow Debian in removing a bunch of unmaintained drivers from the archive?
<tjaalton> no
<tjaalton> there was some talk about it on #debian-x earlier today
<tjaalton> I've yet to re-joing the ml so haven't been following what's going on there
<RAOF> The list of removed drivers is: xserver-xorg-video-v4l, xserver-xorg-video-radeonhd, xserver-xorg-video-nv, xserver-xorg-input-hyperpen, xserver-xorg-input-fpit, xserver-xorg-input-evtouch, xserver-xorg-input-citron
<tjaalton> all good to go
<RAOF> I think the only one we might possibly want out of that is -nv.
<tjaalton> :)
<RAOF> Heh.  We're well ahead on -citron.
<tjaalton> right, I'm not quite uptodate on that, at some point nouveau didn't support all of -nv
<tjaalton> but I guess the devices in question are either very rare or old, or both
<RAOF> I think TNT and riva128 cards aren't supported by nouveau, and nv supports at least one of them.
<RAOF> Of course, so does -vesa :)
<tjaalton> heh, right
<RAOF> We should also remove -gevdev, since the gestures stuff is in evdev now.
<RAOF> Also, it's uninstallable :)
<tjaalton> I've so much to catch on..
<tjaalton> +up
<RAOF> :)
<RAOF> Managed to get all the adminy stuff out of the way yet?
<tjaalton> most of it yeah
<tjaalton> i hope
<RAOF> There'll be some lingering tentacles :)
<tjaalton> I bet..
<RAOF> tjaalton: Incidentally, are you subscribed to mesa-dev?  If so, have you seen my dricore patches appear there?
<RAOF> They seem to have made it to the mailing list archives, but I'd just like to be sure, given the lack of response.
<tjaalton> RAOF: when did you send them?
<tjaalton> I only have the archive since Jan 31st
<tjaalton> ah got it
<tjaalton> v3
<RAOF> Yeah, there it is.
<RAOF> Actually, that seems to have only been Thursday.  I thought it was longer.
<tjaalton> doesn't fedora have something similar? you could try poking ajax/airlied to review and ack
<RAOF> Fedora had something similar in the dim distant past.  I might start prodding soon, yeah.
<tjaalton> are gallium drivers smaller than the classic ones (one could assume so..)?
<RAOF> They're actually of comparable size.
<tjaalton> ah, ok
<RAOF> But it's more of a pain to make a dricore for gallium.
<RAOF> Quite a lot more of a pain, and we only install 2 gallium drivers.
<tjaalton> yeah now that I think of it the shared parts are probably built in the drivers?
<tjaalton> just like before, only that the code is more modular
<tjaalton> or the functionality
<tjaalton> bah, too late to function myself :)
<RAOF> mesa, and gallium even more, create a whole bunch of static libraries which the dri drivers link in.  That's why each DRI driver goes from ~3MiB to ~400KiB when you factor out dricore.
<tjaalton> yeah
<RAOF> If I wanted to be really invasive I could do better, but the patch as written is, I think, the sweetspot for time spent/size opimisation.
#ubuntu-x 2012-01-30
<FernandoMiguel> bRoas
<Sarvatt> tjaalton: http://kernel.ubuntu.com/~sarvatt/patches/116_use_shared_galliumcore.diff actually does work with 8.0 branch, just need to fix up the mesa-egl crap
<tjaalton> oh, cool
<Sarvatt> http://paste.ubuntu.com/823052/ should be the last problem that needs fixing
<tjaalton> is this only on the ubuntu branch?
<Sarvatt> yup
<tjaalton> ok, so no need to bug kibi about it :)
<tjaalton> oh right, it's due to moving the libs around
<Sarvatt> maybe ya did something in the merge i'm glossing over and might remember it better :)
<tjaalton> you mean i botched the merge? totally plausible
<tjaalton> since this shouldn't be any different really
<tjaalton> than what it was
<Sarvatt> oh the mesa-egl crap completely isnt in debian
<Sarvatt> no wonder it works there
<Sarvatt> haven't seen that before and thought we inherited it in the merge
<tjaalton> well it's possible that I missed something from rules when merging from debian
<Sarvatt> rules merge looks fine to me looking at a399f4dab2de48673bf6da34dd10c4ff176dfbd3..HEAD :(
<tjaalton> i bet it's dh_makeshlibs that's to blame
<tjaalton> Sarvatt: check what's in the mesa-egl/ld.so.conf -file
<Sarvatt> tjaalton: wait, i just managed to fix it but dont remember what i did
<Sarvatt> too many context switches
<tjaalton> haha
<tjaalton> git diff!
<Sarvatt> reverting this hunk of debian/rules
<Sarvatt> -       dh_shlibdeps -s -l/usr/lib/$(DEB_HOST_MULTIARCH)/mesa:\
<Sarvatt> -/usr/lib/$(DEB_HOST_MULTIARCH)/mesa-egl
<Sarvatt> +       dh_shlibdeps -s \
<Sarvatt> +               -l/usr/lib/$(DEB_HOST_MULTIARCH)/mesa:\
<Sarvatt> +               /usr/lib/$(DEB_HOST_MULTIARCH)/mesa-egl
<tjaalton> uh oh
<Sarvatt> yay she built
 * Sarvatt does a happy dance
<tjaalton> of course
<tjaalton> stupid me
<Sarvatt> -rw-r--r-- 1 sarvatt sarvatt 4.5M Jan 30 21:19 libgl1-mesa-dri_8.0.0+git20120126+8.0.19f88670-0ubuntu0sarvatt_i386.deb
<Sarvatt> it grew almost 2MB though
<tjaalton> and all that for making it a tad nicer looking :)
<Sarvatt> still better than the 27MB one without dricore and galliumcore
<Sarvatt> i'll fix it in git
<tjaalton> cool
<Sarvatt> tjaalton: so mesa's good to go after the merge :)
<tjaalton> eeexcellent
<Sarvatt> merge now or wait for vdpau stuff to go in ya think?
 * Sarvatt would prefer not bothering with vdpau because mesa's build system is already so freaking fragile but oh well
<jcristau> +1
<jcristau> does any app actually use these shiny video apis?
<tjaalton> yeah maybe postpone it for now
<tjaalton> sure does, but dunno how the gallium drivers work
<tjaalton> at least nvidia blob vdpau is widely used (on my PVR for instance ;)
<Sarvatt> i have no clue either
<Sarvatt> (if it even works)
<Sarvatt> tjaalton: oh yeah, you said you had a problem with xa on amd64? i'm building on i386 so didnt notice that
<tjaalton> maybe I didn't, can't remember anymore
<tjaalton> *did
<RAOF> I we've had some inquiries about whether or not we support vdpau/vaapi; while there's not *that* much that uses it right now, there does seem to be a reasonably complete gstreamer element with support.
<Sarvatt> RAOF: you use ati at all to test it?
<Sarvatt> oh actually I have an ati in a desktop I run headless, can test it out there
<RAOF> I do have an ATI to test it; I need to spin that machine up anyway, to update it.  It'll take *some time*
<Sarvatt> ah no worries, vdpau stuff isn't in git
<RAOF> What cards does it run on, anyway?
<Sarvatt> doing the wayland merge
<Sarvatt> RAOF: I dunno at all
<RAOF> :)
<Sarvatt> will look after this, imagine just radeon/nouveau
<Sarvatt> r300+
<RAOF> Oh, I mean: what chip generations.  Good, my 5450 should cover that :).
<Sarvatt> should the wayland update wait until after A2 too?
<Sarvatt> the wiki says soft freeze in effect today but haven't seen any announcements
<Sarvatt> well yesterday for RAOF :P
<tjaalton> wayland is not on the images, so it shouldn't matter
<tjaalton> what about libxcb?
<tjaalton> it surely is :)
<RAOF> The archive still seems to be open; go for it.
<FernandoMiguel>  1177    root         root            1      0.11s       1.34s       172K        0K         0K         0K    --       -     R        1      75%     Xorg
<FernandoMiguel> this isn't normal :S
<Prf_Jakob> tjaalton: Hey, I heard you wanted a Workstation Key?
<Prf_Jakob> Anybody else want one (or Fusion for that matter)?
<tjaalton> Prf_Jakob: well, I could test the new stuff yeah
<Prf_Jakob> Ok, I'll fix one for you.
<tjaalton> I only have precise to run it on though
<Prf_Jakob> which hw/driver?
<tjaalton> intel
<tjaalton> sandybridge
<Prf_Jakob> 7.10, 7.11 or 8.0?
<tjaalton> oh mesa? 7.11 for the time being, hopefully 8.0 tomorrow
<Prf_Jakob> I actually had a reports of 7.10 being slow on sandybridge, 7.11 and 8.0 should be fine.
<Prf_Jakob> Oh you are probably good.
<tjaalton> as long as the kernel module builds on 3.2 ;)
<Sarvatt> yeah thats typically the problem I run into, hunting down kernel patches :)
<Sarvatt> patches so the guest additions build against newer kernels i mean
<Prf_Jakob> Running w/o tools work fine, if I have problems its with the host kernel modules Workstation wants to build.
<RAOF> I could do with a key, if you'd like me to test stuff :)
<Prf_Jakob> Just WS or does anybody want a Fusion key as well?
<Prf_Jakob> Then again I guess nobody here runs Mac on thier computers ;)
 * Sarvatt paid for fusion, its actually decently priced :)
<Prf_Jakob> Yeah
<Prf_Jakob> WS is a wee bit expensive.
<Sarvatt> thank you for offering though Prf_Jakob
<Sarvatt> bryce, RAOF, tjaalton: which ppa should I shove new wayland and mesa in?
<Sarvatt> x-updates?
<broder> RAOF: would it make any sense if that GPU hang i ran into was connected to the weird hsync/vsync issue with GnomeRR? i seem to only see it if i use GnomeRR to switch from internal-display-only to external-display-only
<RAOF> broder: It would indeed make sense; GnomeRR is a wee bit crazy about that.  In particular, it'll switch the CRTC from internal to external, whereas the xrandr tool generally won't.
<tjaalton> Sarvatt: x-staging imo
<RAOF> It's entirely plausible that GnomeRR exposes a bug that you would be difficult to trigger in any other way.
<tjaalton> and 7.11.2 in x-updates?
<Sarvatt> oh 7.11.2 in x-updates for oneiric would indeed be a good idea
<RAOF> Sarvatt: I concur; we might as well continue using x-staging.
<Sarvatt> alrighty!
<RAOF> I'd *like* 7.11.2 to be suitable for oneiric-updates; I don't know that it is, though. :/
<bryce> Sarvatt, x-staging sounds good to me too
 * Sarvatt is seriously sick of looking at mesa for tonight so task for tomorrow or something :)
<tjaalton> Sarvatt: I can shove stuff somewhere too
<tjaalton> also, wayland should be good to push straight to precise, right?
<Sarvatt> still have to adapt all this crap to mesa master to get xorg-edgers building again, major changes in master after automakification
<Sarvatt> well the merge is pushed to git, it needs a changelog still
<Sarvatt> we have a pretty huge diff in debian/, this stuff needs to be pushed to debian
<tjaalton> multiarch stuff yep
<Sarvatt> ok got http://kernel.ubuntu.com/~sarvatt/wayland/ and pushed it to git, totally untested until i eat dinner :)
<tjaalton> hum, wonder why we've had to add the COPYING.GPL-2 there
<Sarvatt> tjaalton: wayland isn't in the images? huh?!
<Sarvatt> oh
<Sarvatt> forgot edgers is "special" due to newer cairo
<Sarvatt> wayland-demos will need an update too, rrgh
<Sarvatt> libwayland0 (= 0.1.0~0.2-0ubuntu3)
<Sarvatt> that needs some drastic changes and it's in universe though
<Sarvatt> with the weston rename
<Sarvatt> are the cd images going to be in crisis mode if they grow 2MB?
<Sarvatt> thats how much bigger libgl1-mesa-dri is compressed in 8.0
<RAOF> We can see.
<RAOF> :)
<RAOF> Failing anything else, I believe we've got the leeway to grow to 750MB.
<Sarvatt> i'll see if any of the other packages increased too
<Sarvatt> http://paste.ubuntu.com/823262/
<Sarvatt> thats rc2, i just hadnt bumped the changelog yet
<Sarvatt> 30-Jan-2012 08:28  712M  Desktop CD for 64-bit PC (AMD64) computers (standard download)
<Sarvatt> oh cool
<RAOF> Yeah; we're already oversize :)
<Sarvatt> maybe they should stop calling it "CD" on the download page
<Sarvatt> and saying its a bug that its oversized :P
 * Sarvatt installs newer mesa to his wife's laptop
<Sarvatt> that's always a good stress test
<Sarvatt> lots of reports about nvidia-current being hosed in current precise btw
<Sarvatt> although two of the people hitting it were hit by busted unity-greeter in the end and blaming nvidia
<Sarvatt>  /X
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/921998 is pretty nasty
<ubot4`> Launchpad bug 921998 in unity-greeter (Ubuntu Precise) (and 1 other project) "unity-greeter crashed with SIGSEGV in indicator_object_get_entries() (affects: 23) (dups: 7) (heat: 124)" [High,Confirmed]
#ubuntu-x 2012-01-31
<cnd> RAOF, I realized that my last email about the pointer barrier work didn't make sense in hindsight
<cnd> well, it might, but it's only half the picture
<cnd> if the libxfixes library (or whatever library it is) has the symbol, that still doesn't guarantee that the server supports the request
<cnd> I don't know how to handle that without an extension version bump unless you check for XError messages
<RAOF> cnd: Right.
<RAOF> Well, what you *could* do is something crazy, like bump the extension version to 12.04 and only offer those if the client asks for exactly 12.04.
<RAOF> And by you, I of course mean me.
<cnd> heh
<cnd> can you cram a '~ubuntu1' into an integer version?
<RAOF> Yes!@
<RAOF> You might notice that ~ubuntu1 is 8 bytes :)
<cnd> heh
<Sarvatt> but really, just poke ajax instead and get it upstream? it's not an input change :)
<RAOF> It turns out we're still doing a little bit more prototyping, now that we've tried it on a variety of hardware :)
<cnd> Sarvatt, we're well past the closure of the merge window, so it may not get in
<Sarvatt> yeah but march isn't that far away, better to ping now before 6.0 is released without it and having it end up being 7.0
<Sarvatt> thats gonna be a pain in the ass if it happens
<RAOF> Yeah.  *If* an alternate XFIXES 6.0 is proposed on the list I'll certainly be calling for this stuff to be folded in.
<RAOF> I'm not going to prod too strenuously until I'm reasonably certain that this is ok for us, though.
<Sarvatt> swear there was new xfixes stuff queued up from nvidia guys for a long time now but heck if i've been able to find it
<RAOF> That's XSync.
<RAOF> You're thinking of the Sync Counter stuff for GLX/X rendering synchronisation.
<Sarvatt> oh xext, indeed!
<Sarvatt> ok enough anno 2070, uploading wayland/mesa to x-staging now :P
<cnd> RAOF, Sarvatt: there are proposals to extend xsync?
 * cnd is trying to debug xsync right now
<Sarvatt> its already done and released
<Sarvatt> i was remembering old stuff
<RAOF> Oh, yeah.
<RAOF> cnd: What are you trying to debug in xsync?
<cnd> the fact that it doesn't really work? :)
 * RAOF also forgot that it was implemented, and Google found the 2010 commit that did it
<cnd> we set asynchronous timers, but they don't fire until some other event happens
<cnd> so you do get a timer event, but it usually occurs well past when it was supposed to
<RAOF> I've done some debugging in there, for the screensaver stuff.
<Sarvatt> RAOF: hmm, now that I look, did you want to enable llvm-3.0 in mesa 8?
<RAOF> Sarvatt: That seems like the prudent choice.
<RAOF> Sarvatt: It's already in main, and I believe that more developers use it than 2.9
<Sarvatt> it's in main, lets rock
<Sarvatt> glad i didnt upload yet
<Sarvatt> need to edit 2 patches and debian/control, nice and easy
<Sarvatt> I wonder if anything else is pulling llvm-2.9 onto the cd though, having both might be an issue
<cnd> Sarvatt, it would just be the library part of llvm
<cnd> maybe that's not too big?
<cnd> I guess we're talking about jit though
<cnd> so library part == compiler
<Sarvatt> cnd: Compressed Size: 7,407 k
<Sarvatt> thats kinda big :P
<cnd> yeah
<Sarvatt> libgl1-mesa-dri pulls in libllvm3.0
<cnd> we got rid of mono :)
<Sarvatt> Compressed Size: 6,559 k for 2.9
<RAOF> Sarvatt: mesa appears to be the only rdepend of libllvm, apart from the openjdk-7-zero runtime, which isn't shipped on the CD.
<Sarvatt> its amazing so many dri drivers were dropped and it grew so much
<Sarvatt> maybe libgallium core isn't as optimized as it used to be
<RAOF> The non-big-three dri drivers were pretty small after dricoreing.
<RAOF> Like 15-200K
<Sarvatt> RAOF: hmm 2.9 is still the default llvm-config in precise
<RAOF> But we're not using llvm-config, right?
<RAOF> We're specifying an explicit llvm-config to use; that's probably the right behaviour, as it's not guaranteed to build against anything but the exact versions.
<Sarvatt> yepyep, it would just be more future proof to have it call llvm-config --version in the patch instead of hardcoding it but that wont work, dont mind me just thinking out loud
<RAOF> :)
<RAOF> Huh.  Xserver dying with SIGBUS?  That's a new one on my hardware.
<Sarvatt> ohhai plymouth
<RAOF> Wasn't that SIGQUIT?
 * Sarvatt has nightmares about SIGBUS when pressing enter on lucid
<Sarvatt> oh yeah it was
<Sarvatt> RAOF: netbook?
<RAOF> Bah, and apport doesn't catch it.
<RAOF> Sarvatt: SandyBridge.
<Sarvatt> of course, apport doesn't catch crap
<Sarvatt> except evdev or proprietary driver crashes
<RAOF> We should totally fix it so apport catches this.
<Sarvatt> 100_rethrow_signals.patch really doesn't work since jaunty
<Sarvatt> we used to get such nice apport filed bugs against xserver, I miss it :(
<RAOF> As I say, we should fix it.
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/705078 hey moderately recent one
<ubot4> Launchpad bug 705078 in xorg-server (Debian) (and 2 other projects) "Xorg crashed with SIGSEGV in pixman_image_set_has_client_clip() (affects: 53) (dups: 7) (heat: 145)" [Unknown,Fix released]
<broder> i was actually just experimenting with this in one of my programs. it seems like the most reliable way to have a custom sigsegv/sigabrt signal handler and still have it generate a core dump is to use sigaction() with sa_flags == SA_RESETHAND and then just do raise(signum) from the handler
<Sarvatt> it's over my head, I really tried
<broder> ...but i haven't been able to verify if the core dump makes it to apport yet (i was testing with ulimit -c unlimited)
<Sarvatt> I can find the refresh where it broke though
<Sarvatt> will just take some time since it was years ago
<RAOF> broder: Huh, interesting.
<RAOF> I know quite a bit more about posix signal handling since last I touched that code; maybe we can get it to reliably work now :)
<Sarvatt> I remember pitti refreshed it when it stopped working, hmmmmmm
<broder> i think most of what i've learned so far is "it sucks" :)
<Sarvatt> http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=7d65b7d399f5902cb3a3153b43dd8f3e627b7d08
<Sarvatt> oh that was easy to find
<Sarvatt> actually it might have been http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=history;f=debian/patches/100_rethrow_signals.patch;h=ffbc4b09cd498f0e69cd2ea5480a3ebf0afeeca1;hb=refs/heads/ubuntu
<Sarvatt> since i remember it not being 100_rethrow_signals.patch when it did work and thats the first 100 version in git history
<Sarvatt> http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/135_rethrow_signals.patch;h=271ff49504e46d252175107feb0b19387b5d002d;hb=686f7d30ba19862bced1d8c3a48abfc5e7ed41f6 was the working one that only applied to xserver 1.6
<broder> oh hey - apport has a log file. so yeah, it is getting notified when i core dump
<broder> i *think* you could drop the patch as it exists now, add SA_RESETHAND to act.sa_flags on line 178 of os/osinit.c, and add raise(signo); to the end of OsSigHandler
<RAOF> Right.  Modifying the signal handler seems like a more robust solution.
<broder> alternatively, you might be able to not change act.sa_flags and instead do signal(signo, SIG_DFL); raise(signo); from the handler
<broder> but i wouldn't swear to it
<tjaalton> Sarvatt: "failed to upload", whatever that means
<Sarvatt> tjaalton: looks like debian-experimental branch needs http://lintian.debian.org/tags/data.tar.xz-member-without-dpkg-pre-depends.html
<tjaalton> ok..
<Sarvatt> Rejected:
<Sarvatt> Require Pre-Depends: dpkg (>= 1.15.6~) when using xz compression.
<Sarvatt> could be wrong, its really late here
<Sarvatt> thats what launchpad said about the fail to upload, we used lzma for 7.11..
<tjaalton> push the release too, btw ;)
<Sarvatt> maybe just the ubuntu branch? dunno
<Sarvatt> i did
<Sarvatt> well except for the s/UNRELEASED/precise/
<Sarvatt> just pushed the llvm change
<tjaalton> right
<broder> RAOF: i'm unlikely to see a fix for bug #861426 that's not "switch GnomeRR to use libxrandr-util", right?
<ubot4> Launchpad bug 861426 in gnome-desktop3 (Ubuntu Oneiric) (and 1 other project) "[Oneiric] [Regression] When disabling onboard LVDS display and just using external VGA screen corruption occurs (affects: 7) (heat: 20)" [High,Triaged] https://launchpad.net/bugs/861426
<tjaalton> uploading libxcb to x-staging
<tjaalton> well, "syncing"
<Kimal73> goodmorning. Are there drivers for ubuntu of Radeon HD 6520M?
<tjaalton> Kimal73: have you tried?
<tjaalton> yeah something weird with scrolling
<tjaalton> for instance if I scroll down, it'll first jump up
<tjaalton> sometimes
<tjaalton> mmh libx11 multiarch fail
<jcristau> hmm?
<tjaalton> changelog different
<tjaalton> might be just ubuntu
<tjaalton> mesa upgrade pulled libx11-xcb1:i386
<tjaalton> ah, caused by the symlinking
<tjaalton> or not
<Sarvatt> tjaalton: you have libegl1-mesa:i386 installed?
<tjaalton> Sarvatt: no, libgl1-mesa-dri:i386 and some others
<Sarvatt> whats aptitude why libx11-xcb1:i386 say?
<tjaalton> libgl1-mesa-glx
<tjaalton> http://paste.ubuntu.com/824024
<tjaalton> ??
<tjaalton> ok so the ppa or the main archive mangles the changelogs somehow, resulting in that upgrade error
<tjaalton> I've tried purging the packages and still the same
<Prf_Jakob> Anyway I can get the Ubuntu kernel to not use nouveau?
<Prf_Jakob> Via the kernel command line?
<Prf_Jakob> There we go.
<Prf_Jakob> FYI Nouveau is broken on MacBookPro5,1 in 11.10.
<Prf_Jakob> Â§#%#Â§&Â§#"Â§#" I see the Keyboard layout select is still a big pile of poo.
<Prf_Jakob> It hangs if you select to many keyboard layouts before selecting the one you want.
<tjaalton> ok, so my "multiarch fail" was due to the ubuntu-x/x-staging ppa not mangling the changelogs like the main builders (and canonical-x/) do
<tjaalton> what a pain
<tjaalton> OpenGL version string: 3.0 Mesa 8.0-rc2
<tjaalton> finally
<Sarvatt> Prf_Jakob: looks like nouveau.noaccel=1 is needed on that machine from a quick glance :(
<Sarvatt> tjaalton: now try running unigine games! :P
<Sarvatt> going to be fun getting all the QA bugs about unigine benchmarks not working after 12.04 releases
<tjaalton> Sarvatt: doesn't it need server support too?
<tjaalton> heh, at least unigine-heaven fails to run
<orated> Hey tjaalton
<orated> tjaalton: : If you remember helping me with optimus related issue on XPS 15, you said Thinkpad BIOS allows to disable nvidia graphics card. I was wondering if there exist a way to flash open source BIOS or any custom BIOS which could detect hardware properly and allow such features
<tjaalton> orated: don't think so
<orated> tjaalton: So there seems to be no option to use second gfx nor to disable it
<tjaalton> i don't know
<orated> Umm
<tjaalton> try asking on #bumblebee
<Prf_Jakob> Sarvatt: looks like noaccel wasn't needed.
<FernandoMiguel> evening
<Prf_Jakob> no wait I'm using nvidia.
<Sarvatt> RAOF: llvm-3.0 transition looks fine
<Sarvatt> RAOF, tjaalton: weren't we going to llvmpipe default this time though?
<RAOF> Sweet.
<Sarvatt> its just completely not shipped at all anymore now
<RAOF> Sarvatt: That's the default software renderer for 8.0, isn't it?
<Sarvatt> nope swrast getting shipped
<Sarvatt> OpenGL vendor string: Mesa Project
<Sarvatt> OpenGL renderer string: Software Rasterizer
<Sarvatt> OpenGL version string: 2.1 Mesa 8.0-rc2
<Sarvatt> OpenGL shading language version string: 1.20
<RAOF> Huh.  I think we do want to be shipping llvmpipe.
<Sarvatt> we could put the dri-alternates handling back in and ship it in -experimental at the very least..
<Sarvatt> ah I see the confusion
<Sarvatt> http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=commit;h=760ae1c2a9de9c6ac253d357f631b295a2a8b246
<tjaalton> yep
<Sarvatt> it was renamed swrast_dri in the same place instead of swrastg_dri, its still not in the path classic mesa swrast_dri is that we're putting in
<RAOF> Is there a way to just not build classic swrast?
<RAOF> We don't want to ship it, could we please not build it? :)
<tjaalton> yes, drop it from DRI_DRIVERS
<tjaalton> so it's being copied over the gallium one?
<Sarvatt> yep its an easy change, drop it from DRI_DRIVERS and install build/dri/${DEB_HOST_MULTIARCH}/gallium/swrast_dri.so  usr/lib/${DEB_HOST_MULTIARCH}/dri in libgl1-mesa-dri
<tjaalton> or move it in rules
<tjaalton> like the others
<tjaalton> well, r300
<tjaalton> oh wait, there was linux.install.in
<tjaalton> swrast would go in libgl1-mesa-dri.install.in
<RAOF> Yeah.
<RAOF> Well, it *also* needs to go in .linux.install.in, because those files aren't cumulative.
#ubuntu-x 2012-02-01
<tjaalton> RAOF: heh, indeed
<tjaalton> merged -wacom 0.13 in git
<tjaalton> ..which doesn't build
<tjaalton> ../../test/fake-symbols.c:467:16: error: redefinition of 'struct _InputOption'
<tjaalton> /usr/include/xorg/input.h:226:16: note: originally defined here
<tjaalton> ../../test/fake-symbols.c:471:3: error: conflicting types for 'InputOption'
<tjaalton> /usr/include/xorg/input.h:230:3: note: previous declaration of 'InputOption' was here
<tjaalton> ahah, need to add more stuff to the buildfix patch
<tjaalton> yep, worked
<tjaalton> uploaded -wacom to canonical/x-staging
<mgariepy> I'm having issue with a machine that X won't show on the screen (monitor is going to sleep) sometime, the only way to ""fix"" it is to reboot until it works.
<mgariepy> i'm on lucid 10.04 fully updated, i have those message in dmesg : http://paste.ubuntu.com/824176/
<mgariepy> the one on top doesn't work and the one on the bottom works.
<mgariepy> When i do xrandr, on both machine by ssh, both seems to be configured correctly.
<tjaalton> mgariepy: try a newer kernel, you have plenty to choose from
<tjaalton> linux-image-generic-lts-backport-*
<mgariepy> tjaalton, i tried oneiric one and it didn't fix the issue.
<tjaalton> then try 3.2 from the kernel mainline ppa
<tjaalton> do you have to run 10.04 btw?
<mgariepy> tjaalton, yes i do
<tjaalton> sorry to hear :)
<mgariepy> tjaalton, this kernel ? http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-precise/
<mgariepy> 3.2.2? 
<tjaalton> yes
<mgariepy> ok
<mgariepy> tjaalton, the machine was working fine on karmic
<tjaalton> which chip is it?
<mgariepy> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 09)
<mgariepy> what i find weird is that it boots a RO filesystem and sometimes it works but not other.
<tjaalton> maybe best to file a bug upstream if 3.2 doesn't work
<tjaalton> hm?
<tjaalton> stock lucid or 3.2?
<mgariepy> stock lucid
<mgariepy> X starts with the right resolution and all be the monitor goes to sleep
<tjaalton> ok then. might test karmic to see if it still works, and if not it's your hw failing
<mgariepy> i got a lot of machine that does that.
<tjaalton> so you're on #intel-gfx, tried asking there, or better yet, filed a bug upstream?
<mgariepy> might be KMS that does something weird?
<tjaalton> it's all it has
<tjaalton> no ums for intel
<mgariepy>  #intel-gfx didn't answer yesterday
<tjaalton> try a daily livecd?
<mgariepy> tjaalton, linux-image-generic-lts-backport-natty seems to do the trick
 * apw has just updated a nvidia box with a GeForce GTX 580 (GF110) in it, and its hanging at the login screen with PFIFO: read fault, ringing any bells ?
<apw> (and indeed any suggestions?)
<apw> (and update to precise)
<bryce> hi apw, 
<bryce> not ringing any bells for me.  tried removing and reinstalling nvidia?
<bryce> apw, there've been some problems with people who had installed nvidia-173 instead of nvidia; I might doublecheck that.  (jockey-text should reveal it)
<achiang> hello, some time around last week in Precise, the scroll area of my trackpad went a little crazy
<apw> bryce, will do thanks
<achiang> if i don't use the scroll area for a while, the next time i use it, the acceleration is extreme
<achiang> and i'll scroll half a page at a time
<achiang> after the first touch, then scrolling goes back to "normal"
<apw> bryce, so the only nvidia i have is nvidia-common, is that right or am i missing something
<bryce> that is right
<bryce> wait, no
<bryce> you should also have nvidia-current installed
<bryce> (I think you can do it manually, but it's better to do via jockey if possible)
<bryce> apw, does jockey indicate that nvidia is installed?  If so, may need to forcibly uninstall more nvidia bits.  If not, then try reinstalling
<tjaalton> mgariepy: nice. but you said the oneiric one didn't work, meaning it has regressed again since natty?
<apw> bryce, i actually have a held xserver-xorg-video-all
<apw> depending on a bunch of -xxx h/w specific drivers
<mgariepy> tjaalton, maybe, i need to do more testing.
<bryce> apw, aha
<mgariepy> i'll skip oneiric tho, i'll go with precise since i won't work with oneiric..
<bryce> apw, prior to this last update had you updated the system within the last week or so?  might be you're just still hung up on the transition
<apw> bryce, nope this was very old, i booted it and updated it
<bryce> apw, uninstall those h/w specific drivers and then make the update complete
<tjaalton> mgariepy: good plan
<bryce> apw, lately there've been a handful of dropped drivers; theoretically they should have automatically been purged
<bryce> presumably they weren't for some reason in your case (I've run into this myself in the past)
<apw> bryce, yeah, i presume this is something missing on the new packages to make it occur if you have a release cd level version
 * bryce nods
<apw> bryce, i will also note that nothing told me this had occured
<bryce> apw, it's hardly likely worth your time to debug it; if it looks like it's going to be a hassle I would just backup user files and do a fresh install
<bryce> apw, that's ungood
<apw> bryce, is there any way to tell which is the broke -video- thats installed
<bryce> apw, with these installation problems, usually the apt guys want to have a reproducible test case.  If you think you can reconstruct it, it may be worth reporting
<bryce> apw, hmm
<bryce> apw, not sure, other than individually removing them until you've purged enough
<apw> bryce, i suspect a scratch to the oneiric release cd and then an update will repro it
<apw> bryce, but will prove that this is the issue first
<bryce> apw, are you attempting apt-get install -f ?
<apw> install -f is happy
<apw> it just says 13 not upgraded
<apw> bryce, getting the errors when i attempt to install ubuntu-desktop^
<bryce> apw, if it can be repro'd from a stock oneiric release, that would be double bad.  However, I would expect we'd have other reports in that case (but possibly you're just the first?)
<apw> most of us update more regularly, this being unpdated for months is unusual
<apw> bryce, so basically uninstall *-video-* and then reinstall ubuntu-desktop^
<bryce> apw, yep
<tjaalton> apw: do you get plymouth/kms?
<tjaalton> ie. does nouveau work
<bryce> tjaalton, yeah he gets to the login screen
<bryce> "PFIFO: read fault"
<tjaalton> console?
<tjaalton> nevermind
<apw> tjaalton, yep
<apw> bryce, but till i have X all at the same level i am ignorign the error
<apw> bryce, ok didn't improve anything any
<bryce> apw, ok at this point I need logs and such
<bryce> apw, either do up a ubuntu-bug xorg or pastebin the usual stuff
<bryce> the PFIFO: read fault error message appears to be a nouveau-specific message
<bryce> so presumably you have two problems, a) nouveau is busted, and b) nvidia isn't running properly
<apw> bryce, i am not expecting to have binary drivers on here
<apw> bryce, should i install them ?
<bryce> apw, yes
<bryce> apw, well let me ask - you said "this is an nvidia box" initially, by which I mean your intention is to have binary drivers installed.
<bryce> if that's not the case, then I've been woefully misleading you
<apw> bryce, no my intenton is to use the graphical interface... i've not used nvidia drivers before on it though
<apw> bryce, jockey-text offers nothing anyhow
<bryce> ah, ok nouveau then
<bryce> apw, can you pastebin your Xorg.0.log or file a bug report?
<apw> bryce, whats the incantation for a nvidia bug report
<bryce> ubuntu-bug xorg
<apw> bryce, http://paste.ubuntu.com/825488/
<bryce> (there is a separate command for making nvidia binary driver bug reports, but that's not used for nouveau problems)
<bryce> gpu lockup on nouveau
<bryce> where did you see the PFIFO error? dmesg?  pastebin that too
<bryce> [   100.328] [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack.
<bryce> [   100.328] [mi] mieq is *NOT* the cause.  It is a victim.
<bryce> heh
<apw> bryce, http://paste.ubuntu.com/825492/
<tjaalton> apw: you have the drm-next mainline builds, try one ;)
<FernandoMiguel> evening!
<apw> tjaalton, heh thanks
<bryce> apw, I dug through the kernel code and drm-next changelogs but didn't spot anything that'd give hope.  I think you need to go to ben skeggs, but testing drm-next first is not a bad idea.
<bryce> apw, I've forwarded your bug to fdo, in case you want to ref it when talking with him
<RAOF> I'm not fully up with the context, but are we building nouveau's next tree, too?  There's generally a bunch of stuff on there that's not in any of the drm-* kernels.
<Sarvatt> mesa 8 from ppa:canonical-x/x-staging might be worth trying too (but it will be a PITA to remove if you're on x64), it could very well be mesa 7.11 causing it :)
<bryce> RAOF, we are not.  git.freedesktop.org has been down so I couldn't review it
<RAOF> Yay infrastructure!
<bryce> Sarvatt, however the freeze occurs on the login screen.  guessing it to be occurring before the fun 3d stuff kicks in
<Sarvatt> oh, i was equating 100 seconds after boot to possibly being when unity started
<bryce> I assume it freezes before he types login
<RAOF> Hm, nvc8
<bryce> nvc0
<RAOF> IIRC, that's a sufficiently-different nvcX, and there's not been much testing of it.
<RAOF> It's nvc0 generation, you need to read the specific chip from 0x0c8000a1 (ie: c8)
<bryce> RAOF, yes I know
<RAOF> I think it's possible that the difference between 11.10 and Precise is that there wasn't any acceleration for nvc0 class chips in 11.10?
<Sarvatt> thats true, yep
<Sarvatt> was no microcode for it until 3.1 or 3.2
#ubuntu-x 2012-02-02
<tomreyn> hi
<tomreyn> does x-edgers X get security updates which are applied on stable releases?
<tjaalton> it's following upstream crack, so in a sense yes
<tomreyn> i realise the X issue where you hit ctrl-alt-* to kill the screensaver is still present here
<tomreyn> let me see which versions i have
<tjaalton> well edgers doesn't have xkb-data
<tjaalton> i guess
<tomreyn> oh that's xkb-data, okay
<tomreyn> so it's not fixed in stable
<tjaalton> no need to
<tjaalton> since they don't have xserver 1.11
<tjaalton> fixed in precise
<tomreyn> hmmi was thinking everything including 1.10 was affected.
<tjaalton> nope
<tomreyn> okay, so my options to get rid of this issue now are? upgrade (from oneiric) to precise?
<tomreyn> i guess i'm going offtopic now, sorry.
<tjaalton> or backport xkb-data from precise
<tjaalton> if it's your own machine, why do you care anyway? :)
<tomreyn> care about backporting, or about having this security issue?
<tjaalton> the latter
<tomreyn> because i'm not the only one who has physical access to it
<tomreyn> and i like to not have to log out when i leave it
<tjaalton> don't run edgers then
<tjaalton> or backport, or upgrade
<tomreyn> right. thank you for your help. :)
 * apw notes there is a subtle change in the way xmodmap works when you remap keys, you need to specify the keysym at least twice to ensure shif-<key> stil produces something
<apw> (in precise)
<tjaalton> sigh, this scroll jumping is annoying
<Daviey> apw: funny you say that, one of my key combinations stopped working - which confused the hell out of me :)
<tjaalton> ok, so llvmpipe is still not that useful :)
<tjaalton> at least unity isn't
<tjaalton> runs, but all sorts of glitches
<shadeslayer> I'm curious, but has anyone had X crash repeatedly when trying to play videos with VLC?
<jcristau> on fglrx?
<tjaalton> works just fine on intel
<tseliot> shadeslayer: if you're referring to fglrx (as jcristau asked) then it's a known bug
<shadeslayer> tseliot: yes, on fglrx
<shadeslayer> could I get a bug number?
<tseliot> shadeslayer: bug #921384
<ubot4> Launchpad bug 921384 in fglrx-installer (Ubuntu) "[MASTER] Xorg crashes when trying to play a video with XV under xserver 1.11 (affects: 8) (dups: 1) (heat: 62)" [High,Triaged] https://launchpad.net/bugs/921384
<shadeslayer> I reported bug 925501
<ubot4> Launchpad bug 925501 in xorg (Ubuntu) "X crashes while playing videos (dup-of: 921384)" [Undecided,New] https://launchpad.net/bugs/925501
<shadeslayer> marked it as a dupe
<shadeslayer> tseliot: what's the cause though?
<shadeslayer> I have to reboot to OS X to watch videos these days :( 
<tseliot> shadeslayer: it's a bug in the driver. I don't know what the actual problem is since the driver code il closed
<Sarvatt> shadeslayer: switch to -vo gl in mplayer to work around it
<shadeslayer> oh okay
<shadeslayer> Sarvatt: uhhh .. 
<shadeslayer> Sarvatt: I'm not familiar with X
<shadeslayer> oh, use mplayer instead of vlc?
<tseliot> right, it's just xv that doesn't work
<Sarvatt> nothing to do with X, what video player are you using?
<Sarvatt> vlc? one sec, let me look at the menu layout
<shadeslayer> yes
<Sarvatt> tools -> preferences -> video -> video output
<shadeslayer> One sec, I'll have to reboot
<shadeslayer> :)
<Sarvatt> try glx or X11
<jcristau> or, get rid of fglrx :)
<tjaalton> heh, QtSDK installer settings window seems to be infinitely large, it's OOM killed within seconds of opening it..
<tjaalton> oh, and seems that the browser went too
<tjaalton> thanks
<shadeslayer> well ... no crash
<shadeslayer> no video output as well
<shadeslayer> boom
<shadeslayer> vlc crashed
<Sarvatt> i've heard using smplayer or whatever mplayer frontend you want and switching the video output driver to gl works fine if you want to try that
<shadeslayer> Sarvatt: I'll remove fglrx
<Sarvatt> good call :)
<shadeslayer> what's the free alternative for fglrx?
<tjaalton> -ati
<shadeslayer> awesome
<tjaalton> just deactivate the driver, -ati is the default anyway
<shadeslayer> tjaalton: I don't have enough space for / ... so removing it to gain a wee bit of space
<tjaalton> -ati is installed already..
<shadeslayer> out of 62 GB's 50 GB's are already used ... ;)
<shadeslayer> okay
<tjaalton> so yes do remove fgrlx if you don't use it
<tjaalton> and reboot
<shadeslayer> righto
<shadeslayer> arf
<shadeslayer> just one small problem
<shadeslayer> wrong resolution
<shadeslayer> 1152x864 .. my panel does 1440x900 natively
<shadeslayer> And the maximum I can choose is 1152x864 : http://wstaw.org/m/2012/02/02/plasma-desktopjL2325.png
<shadeslayer> a couple of desktop effects are disabled as well :(
<tjaalton> so you're not using -ati then
<tjaalton> some fglrx remnants left
<tjaalton> check Xorg.0.log
<shadeslayer> okay, I think it's using vesa
<tjaalton> how did you remove fglrx
<tjaalton> ?
<shadeslayer> http://paste.kde.org/198656
<shadeslayer> tjaalton: sudo apt-get remove fglrx-updates
<tjaalton> check jockey
<shadeslayer> looking
<shadeslayer> Nope, both are not activated
<tjaalton> tseliot: ^
<Sarvatt> shadeslayer: remove nomodeset from your kernel command line :)
<tjaalton> ahah
<tjaalton> yeah i've no browser to check the logs..
 * shadeslayer doesn't remember why he put in nomodeset
<shadeslayer> okay, brb reboot
<tjaalton> because someone on some forum told it was the greatest idea ever?
<tseliot> shadeslayer: maybe you should also remove your /etc/X11/xorg.conf
<tjaalton> shouldn't the uninstaller do that?
<tjaalton> or does jockey handle it
<tseliot> tjaalton: the uninstaller? Let me check jockey...
<Sarvatt> yeah jockey does the xorg.conf handling
<tjaalton> so removing it the apt-get way doesn't work..
<Sarvatt> not sure that fglrx even installs an xorg.conf anymore, its not needed
<tjaalton> it doesn't, but amdcccle does
<tjaalton> if you touch the configs
<tjaalton> at least when configuring dualhead
<tjaalton> unless amdcccle crashes, of course
<tjaalton> which, according to the numerous bugreports is what happens
<tseliot> Sarvatt: right, that's my point. It shouldn't create a xorg.conf
<tjaalton> anyway, if jockey has a 'disable driver foo' commandline option, postrm should call that
<tseliot> tjaalton: yes, it was definitely amdcccle
<shadeslayer> :D :D
<shadeslayer> tseliot: don't have that
<shadeslayer> everything works
<shadeslayer> tseliot: as for the forum thing ... hmm .. possible
<shadeslayer> thanks a ton :)
<tseliot> shadeslayer: amdcccle is Amd's catalyst panel
<shadeslayer> videos work too \o/
<tseliot> or whatever is called
<tseliot> tjaalton: that would work only if the driver was enabled in Jockey
<shadeslayer> don't have amdccle
<shadeslayer> I think fglrx removed that
<tjaalton> tseliot: then the postinst should call jockey ;)
<tjaalton> if you apt-get install fgrlx
<tjaalton> things should work the same, no matter which way you install the driver
<tseliot> tjaalton: what if Jockey installs fglrx which in turn calls jockey? ;)
<shadeslayer> okay, now everything is heating up like crazy
<shadeslayer> fan is on full throttle
<tjaalton> tseliot: good point! need to think about it
<tjaalton> shadeslayer: which distro version is this?
<shadeslayer> Precise
<tjaalton> ok
<tjaalton> so no thermal control for you then
<shadeslayer> tjaalton: oh why?
<tjaalton> no support
<shadeslayer> heh :)
<tseliot> tjaalton: fglrx could call a script which removes any reference to fglrx in xorg.conf when the package is removed
<shadeslayer> I thought it was a problem with the driver
<tjaalton> tseliot: yes, jockey?
<tseliot> tjaalton: but if I managed to get my fallback system in X to work properly we wouldn't need any of this
<tjaalton> tseliot: split that functionality from jockey so that it can be called externally
<tjaalton> tseliot: what's that?
<tjaalton> maybe I've heard about it
<shadeslayer> I just spun up my fans to the max, cooled everything down, lets see if it happens again
<tseliot> tjaalton: I'm trying to get to a point where, if X finds a driver in xorg.conf which is either not available (e.g. there's no fglrx driver) or if there's no supported graphics card for that driver, it falls back to a different driver using autoconfiguration
<tjaalton> tseliot: ok good, but that could confuse the user and/or bug triager ;)
<ricotz> Sarvatt, tjaalton, the mesa package in https://launchpad.net/~canonical-x/+archive/x-staging/+packages has the same problem
<jcristau> ignoring stuff that's explicitly configured sounds kinda bad
<ricotz> tjaalton, him drisearchdirs=/usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri
<tseliot> tjaalton: the alternative is letting X fail
<ricotz> tjaalton, i mean, hi
<tjaalton> "same problem"
<tjaalton> ?
<tjaalton> but yes, Sarvatt told me about it
<ricotz> tjaalton, alright ;)
<Sarvatt> ricotz: yeah i'm fixing it up in the ubuntu branch now
<ricotz> good
<Sarvatt> ..and pushed
<Sarvatt> pushed xserver too
<FernandoMiguel> evening <3
<Sarvatt> archives open, mesa 8.0 tonight? :)
<tjaalton> and libxcb
<tjaalton> go for it
<tjaalton> hmm
<FernandoMiguel> fear!
<tjaalton> I'll sync libxcb
<Sarvatt> need http://kernel.ubuntu.com/~sarvatt/wayland/ for mesa (is in git)
<tjaalton> bryceh: -qxl is ready for syncing when syncpackage thinks so :)
<tjaalton> ie. not yet
<bryceh> tjaalton, already uploaded it
<tjaalton> uh, ok
<Sarvatt> ok got video-vmware all working now, took some cherry-picks
<Sarvatt> uploaded it to canonical-x/x-staging
<Sarvatt> pushed it to git too
<tjaalton> oh, how messy the upstream versioning is..
<tjaalton> no wait
<tjaalton> Sarvatt: check the version
<tjaalton> 11.0.99.901 << 11.99.901
<Sarvatt> thats right
<tjaalton> so now we can't push vmware there anymore..
<tjaalton> you mean upstream bumped the version?
<Sarvatt> yeah
<Sarvatt> 11.0.99.901 was the 11.1.0 release rc
<Sarvatt> with no XA support
<tjaalton> hah
<tjaalton> ok then
<tjaalton> so 23:41 < tjaalton> oh, how messy the upstream versioning is..
<Sarvatt> scared me
<Sarvatt> i'm doing 3 things at once, darn S3 bug
<Sarvatt> so totally could have flubbed it :)
<tjaalton> hehe
<bdmurray> bryceh: have you seen bug 507062?
<ubot4> Launchpad bug 507062 in libx11 (Ubuntu Oneiric) (and 4 other projects) "synaptic assert failure: synaptic: ../../src/xcb_io.c:385: _XAllocID: Assertion `ret != inval_id' failed. (affects: 592) (dups: 352) (heat: 3588)" [Medium,Triaged] https://launchpad.net/bugs/507062
<bryceh> bdmurray, yes
<tjaalton> bdmurray: there's new libxcb in precise synced today, see if it still happens with it
<bdmurray> I'm not experiencing it just ran across the report again
<bryceh> tjaalton, do you know for certain there is a fix for this bug?  it's been rather long standing
<bdmurray> the upstream bug watch for that bug has a link to another upstream bug with a patch of sorts
<tjaalton> there's another one too gathering dupes
<bryceh> bdmurray, 507062 just times out for me so I can't really look at it
<bdmurray> +text ;-)
<bdmurray> https://bugs.freedesktop.org/show_bug.cgi?id=27552
<bdmurray> that's the upstream one
<ubot4> Freedesktop bug 27552 in Lib/Xlib "Lots of processes crash in XCreatePixmap() with _XAllocID: Assertion `ret != inval_id' failed" [Normal,New: ]
<bdmurray> which then points to https://bugs.freedesktop.org/show_bug.cgi?id=23690
<ubot4> Freedesktop bug 23690 in Lib/Xlib "Return value from xcb_generate_id() not checked" [Normal,New: ]
<bryceh> thanks
<bdmurray> Would it make sense to prevent reporting them in apport?
<bdmurray> there is a bug pattern but its not working for one reason or another
<bryceh> bdmurray, I think there's likely little value in having more bug reports auto-filed about it
<bryceh> bdmurray, so yeah a bug pattern may make sense here
<bryceh> tjaalton, did you find that the new libxcb includes 0001-_XAllocID-don-t-assert-when-running-out-of-IDs-23690.patch ?
<jcristau> _XAllocID sounds like an xlib thing, not libxcb
<bryceh> true
<bryceh> ajax's comments seem to indicate the patch may not be a proper fix
<bryceh> bdmurray, are you reproducing the problem or just triaging through bugs?
<bdmurray> bryceh: just triaging
<tjaalton> bryceh: no, but it's the first release in well over a year, and should contain some thread related fixes
<bryceh> mm
<bryceh> ok, then I say we should just leave the bug as is for now, wait until the new bits are fully deployed, and then later we can check back and see if it's fixed
<bryceh> tjaalton, if you remember what the other bug # is maybe put a request to test after things have landed
<bryceh> bdmurray, if you're able to make changes to 507062 via email or some such, can you close out the bug report and tell users to file new bug reports if they reproduce it in Precise?
<tjaalton> bryceh: you touched it recently :)
<tjaalton> bug 905686
<ubot4> Launchpad bug 905686 in nautilus (Ubuntu) (and 2 other projects) "nautilus assert failure: nautilus: ../../src/xcb_io.c:528: _XAllocID: Assertion `ret != inval_id' failed. (affects: 37) (dups: 34) (heat: 321)" [Medium,Triaged] https://launchpad.net/bugs/905686
<bryceh> tjaalton, I'm sure I touch all the bugs recently ;-)  but yeah I remember this one
<tjaalton> unlike me, only recently started looking at the precise bugs..
<bdmurray> Its too bad the retracer removes dependencies.txt
<bryceh> tjaalton, btw as you go through old bugs, if there are ones that have been verified as still affecting precise, tag them 'precise'.  Then later as fixes turn up, someone can track getting the fix into the LTS.
<tjaalton> bryceh: yep, sure thing
<Sarvatt> so wayland, then mesa, then xserver-xorg-video-vmware are ready to go. best not to copy from canonical-x this time since mesa will have to go through NEW and vmware is built against that I guess?
<Sarvatt> tjaalton: absolutely sure we shouldn't squash all the post 0ubuntu1 changes into 0ubuntu1?
<Sarvatt> (mesa)
<Sarvatt> got all 3 packages here http://kernel.ubuntu.com/~sarvatt/packages/
<Sarvatt> fixed up the mesa source.changes to include everything since 7.11-1
#ubuntu-x 2012-02-03
<cnd> RAOF, bryceh: going forward, how do we want to update our xserver tree with upstream changes from stable 1.11 and 1.12 stable releases
<cnd> do we want to continually merge in the latest patches, or only when new releases are made
<cnd> ie, only once 1.11.4 is released do we merge in everything since 1.11.3
<RAOF> Either is reasonable at this point.  If there are important patches they should be pulled in, or wait until the release and merge it in.
<cnd> ok
<bryceh> it would make troubleshooting somewhat easier if we pull in only the official point releases, and specific patches to fix specific bugs in between
<cnd> that's my thinking too
<RAOF> I don't think there's any particular reason to aggressively track the release branches.
<cnd> yeah
<bryceh> it's easy enough to cherrypick fixes we know we need as we learn about them
<cnd> bryceh, RAOF: any issues if I add this patch in to our server: ead968a4300c0adeff89b9886e888b6d284c75cc
<cnd> sadly, I can't give you a link to the git diff because git.fd.o is down
<cnd> the usefulness for us is that with the patch xorg-gtest can be run as non-root
<RAOF> cnd: Absolutely.
<cnd> righteo
<bryceh> cnd, yep fine by me, assuming it causes no known issues
<cnd> none that I'm aware of :)
<bryceh> tjaalton, for bug #921941, should -mtrack be included in -input-all ?
<ubot4> Launchpad bug 921941 in xf86-input-mtrack (Ubuntu) "No way for user to know that mtrack module is needed on upgrade to latest xorg with Apple trackpad (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/921941
<Sarvatt> bryceh: no way
<Sarvatt> synaptics works fine
<bryceh> Sarvatt, apparently not
<Sarvatt> mtrack just provides some more features but its in no way needed
<Sarvatt> bryceh: i'm using it on the same system he posted the bug on
<Sarvatt> mtrack doesn't build in precise right now
<Sarvatt> oh weird, it did build, what the heck?
<Sarvatt> it just has a few extra features like multitouch gestures but its not even maintained on freedesktop and very rarely gets updates, really dont think its appropriate for input-all
<Sarvatt> bryceh: what happened was he had mtrack in an xorg.conf
<Sarvatt> and was trying to use it
<Sarvatt> thats what it looks like to me
<Sarvatt> all the macbook air setup guides recommend using it
<bryceh> alright
<Sarvatt> bryceh: I guess mtrack needs adding to the apport hooks?
<RAOF> Huh.  You live and learn.
<Sarvatt> i responded on the bug and pinged him in #ubuntu-devel
<bryceh> yeah
<bryceh> oh heh, was just drafting up a reply myself
<cnd> Sarvatt, bryceh: I think the only real feature people want out of mtrack is the click-and-drag support
<cnd> I hope to get to that still in synaptics before feature freeze
<bryceh> cnd, awesome
<cnd> the rest of mtrack is handled better by gestures on the client side of X
<cnd> and I agree, it definitely shouldn't be in -input-all
<tjaalton> morning
<tjaalton> Sarvatt: well, we should've used -0~ubuntuN with mesa ;)
<tjaalton> a goot guideline for the staging repo in general, I guess
<tjaalton> good even
<tjaalton> Sarvatt: oh well, just squash it I guess. we'll have rc3 soon anyway
<tjaalton> not a big deal since the releases aren't tagged
<Sarvatt> tjaalton: ya mind doing that? its past midnight here, barely awake
<tjaalton> sure
<tjaalton> didn't upload -vmware either?
<tjaalton> it'll just sit in depwait until mesa is done
<tjaalton> now that it build-depends on libxatracker
 * Sarvatt can't upload anything but did ask
<tjaalton> haha, of course
<tjaalton> so wayland first
<Sarvatt> got packages up here http://kernel.ubuntu.com/~sarvatt/packages/ if it's any easier
<tjaalton> ok sure
<tjaalton> ah wayland release is in git too
<Sarvatt> i do believe its time to look into getting upload privileges.. 118 uploads should be enough
<tjaalton> please
<tjaalton> and I should file the DD application..
<tjaalton> got the needed signatures at the sprint
<tjaalton> wayland uploaded
<Sarvatt> heck its more than 118, launchpad only lists 1 upload per package per release and i do multiples usually
<Sarvatt> like the last 2 libdrm's to precise count as one on launchpad
<Sarvatt> thanks for the help tjaalton
<tjaalton> hmm so mesa, I'll just squash it?
<tjaalton> yw
<Sarvatt> i think that's the right thing to do but would be ok to do it either way :)
<tjaalton> oh well, you'll get one upload more if I pull yours :)
<tjaalton> you don't have xserver there?
<Sarvatt> oh heck
<tjaalton> hmm mesa source.changes doesn't have 8.0~rc2-1 entries
<tjaalton> oh sure does
<tjaalton> push git too
<Sarvatt> sheesh making that mistake too much this past week, pushed
<tjaalton> :)
<Sarvatt> looks like chase has something else queued for xserver
<Sarvatt> should i get that ubuntu9 ready or wait?
<tjaalton> you mean 10?
<Sarvatt> yeah he's got a 10 in UNRELEASED state
<tjaalton> I see it as 11 :)
<Sarvatt> oh yeah
<Sarvatt> sheesh
<Sarvatt> ping noise woke me up, sorry i'm half here :)
<tjaalton> does xserver build-dep on the new mesa without the search path?
<Sarvatt> http://kernel.ubuntu.com/~sarvatt/packages/xserver/
<tjaalton> or break if it builds against the older one
<Sarvatt> they're doing some test rebuild, its probably worth uploading xserver without a drisearchpath in dri.pc dependency before mesadependency before mesa
<tjaalton> ..ok so xserver before mesa.. got it
<tjaalton> well mesa uploaded already though
<tjaalton> vmware too
<tjaalton> all done, thanks for preparing them :)
<tjaalton> ah, breakfast/wakeup time ->
 * apw is seeing alll new shiney visual corruption on alt-tab in precise.  anyone seen that?
<apw> https://launchpadlibrarian.net/91781478/BROKEN2.png
<apw> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/925936
<ubot4> Launchpad bug 925936 in xorg (Ubuntu) (and 2 other projects) "screen corruption on alt-tab in unity (affects: 1) (heat: 6)" [Undecided,New]
<tjaalton> apw: apt-cache policy libgl1-mesa-dri
<apw> libgl1-mesa-dri:
<apw>   Installed: 7.11-0ubuntu4
<apw>   Candidate: 7.11-0ubuntu4
<tjaalton> ok, so not 8.0~rc2 yet
<tjaalton> what does "all new" mean? :)
<tjaalton> what has changed?
<apw> oneiric -> precise
<apw> so in theory i have A2 on here
<tjaalton> ok
<tjaalton> i've no such issues with sandybridge
<tjaalton> I'll upgrade my x61 (i965)
<apw> as there is  X pending i could update just X, seems it wants to deinstall most of my machine otherwise ... sigh
<tjaalton> huh?
<tjaalton> there should be no such issues
<apw> The following packages will be REMOVED
<tjaalton> how did you upgrade?
<apw>   gstreamer0.10-plugins-good:i386 gstreamer0.10-x:i386 gtk2-engines:i386
<apw>   gtk2-engines-murrine:i386 gtk2-engines-oxygen:i386 gtk2-engines-pixbuf:i386
<apw> its going to remove ... alll of my i386 things, i am told archive skew due to the rebuild test
<tjaalton> ok
<apw> the upgrade i did yesterday was an update-manager -d update, and worked fine
<apw> its today thats the problem :/
<tjaalton> ah ok
 * apw goes for an update, and will re-test
<tjaalton> there is a new mesa available too, so test with that too
<apw> tjaalton, ok thanks
<apw> The following packages have been kept back:
<apw>   evolution-common evolution-indicator evolution-plugins libgl1-mesa-dri
<apw>   libgl1-mesa-dri:i386 libgl1-mesa-glx libgl1-mesa-glx:i386 libglapi-mesa
<apw>   libglapi-mesa:i386
<apw> tjaalton, bugger, the skew is holding back the mesa update
<tjaalton> ok..
<apw> tjaalton, ok ... by hook and by crook i got it upgraded, and the issue is still there
<tjaalton> apw: hum, ok
<tjaalton> try booting an older kernel.. trying to rule out variables
<tjaalton> since the dri driver was the same as on oneiric
<apw> bah the upgrade has removed my older kernels
<tjaalton> :)
<tjaalton> hmm, shouldn't it leave the last of the old series?
<tjaalton> newest abi
<tjaalton> i recall it doing that here
<apw> it has left 3.0.0-5 and -9
<apw> oh i wonder if its ordering textually when it makes the list
<apw> hense i have -9
<tjaalton> hah
<apw> tjaalton, ok same with the latest O kernel too
<tjaalton> apw: ok, thanks
<tjaalton> mind testing alpha1 livecd too.. just to get another testing point
<tjaalton> it didn't have the new X yet
<apw> tjaalton, that'll have to go on my todo list
<tjaalton> or unity
<tjaalton> sure
<tjaalton> no rush
<apw> tjaalton, where can i find the alpha1 image btw, so i can start it downloading
<tjaalton> cdimages.u.c
<tjaalton> or -s
<tjaalton> hmm, not there
<apw> tjaalton, hrm ... so i don't see an old image, not sure if we keep them now i think abuot it
<tjaalton> ok..
<apw> tjaalton, ok this is only happening on my external monitor, not on the internal lcd in the same X session
<tjaalton> I need to rejig my cobbler setup to support precise in order to test it on my X61
<tjaalton> apw: aha! now that's something then :)
<tjaalton> so it didn't do it on oneiric?
<tjaalton> I'll blame unity
<apw> its pretty obvious when it happens, and i don't recall seeing it
<apw> but i wouldn't like to say it wasn't there
<tjaalton> it's as easy a target as they get
<apw> :)
<tjaalton> at least there was the 4->5 bump in unity
<apw> iterestingly it also dammages windows in front of the scrolling window
<apw> tjaalton, and the fuzzed through stuff through the popup is in the right place, just the bits outside the popup are out of line
<tjaalton> yep
<apw> and its any scrolling in any sized panel which trips it, not necessary for it to be anywhere specific on the screen
<apw> very odd indeed.
<tjaalton> I'll try it on the sandybridge machine..
<tjaalton> seems to work fine on it
<tjaalton> now I need to install the older one to see what happens there..
<tjaalton> apw: looks like there's a new unity pushed to precise, just in time for the weekend..
<seb128> tjaalton, well, it was tested in a ppa for the week and got quite some tester sending back feedback through checkbox, should be fine
<jcristau> famous last words
<jcristau> ;)
<tjaalton> seb128: yeah, i bet it's better than during oneiric ;)
<seb128> what could possibly go wrong? ;-)
<tjaalton> just to give apw something to test again, since the bug might be unity related and possible fixed in this new version
<apw> tjaalton, 'yay'
<seb128> you can use ppa:unity-team/staging if you want to try it
<seb128> it's going to take an hour or two for the archive version to build
<tjaalton> yeah, forgot about that
<Prf_Jakob> Hmm looks like mesa-utils is broken in precise.
<Prf_Jakob> I need my glxgears.
<Prf_Jakob> for benchmakring :)
<tjaalton> broken how?
<Prf_Jakob> Can't find installation source, only referred to by other packages.
<tjaalton> enable universe
<Prf_Jakob> ah ok
<Prf_Jakob> Okay... seems that for some reason Unity and ubuntu-desktop gets removed if I try to dist-upgrade to get the new 8.0 mesa...
<apw> Prf_Jakob, yep there is a unity upload in the archive, and only half compiled
<Prf_Jakob> apw: Ah, so I just need to wait and it will sort itself out?
<apw> Prf_Jakob, heres hopng
<Prf_Jakob> heh
<tjaalton> if you apt-get install libxatracker1 manually, apt-get upgrade should pull the new mesa bits (and -vmware)
<tjaalton> without removing anything
<Prf_Jakob> hmm, after killing X, it just seems to continously crash and restart the X server.
<Prf_Jakob> (just running of the Live CD).
<tjaalton> with -vmware?
<tjaalton> ok
<tjaalton> which driver?
<Prf_Jakob> I'll install it properely.
<Prf_Jakob> -vmware
<Prf_Jakob> Ah, hmm, well this is awkward, I can't install it since the default screen is to small....
<tjaalton> 800x600?
<Prf_Jakob> yupp
<tjaalton> isn't that your driver failing? :)
<Prf_Jakob> Its the default, 1024x768 is to big.
<tjaalton> can't you change it then?
<tjaalton> from the settings
<Prf_Jakob> Don't think so.
<tjaalton> how is 10x7 too big.. cirrus for kvm uses that
<Prf_Jakob> 13" and small macs that will make the UI to big.
<Prf_Jakob> smaller*
<tjaalton> then don't use the live-session installer, but start it directly
<tjaalton> should work that way I guess
<Prf_Jakob> Can't set that setting in Fusion.
<Prf_Jakob> tjaalton: this is a problem for small netbooks as well
<jcristau> people run vmware on small netbooks?
<Prf_Jakob> No, but the installer not working
<Prf_Jakob> As per 869239
<Prf_Jakob> bug 869239
<ubot4> Launchpad bug 869239 in ubiquity (Ubuntu Precise) (and 1 other project) "webcam screen should be resized for netbooks (Eee PC, 10") (affects: 11) (dups: 3) (heat: 62)" [High,Fix released] https://launchpad.net/bugs/869239
<Prf_Jakob> There we go
<Prf_Jakob> Hmm fixed...
<tjaalton> webcam?
<tjaalton> well as I said, don't run it from the live session?
<tjaalton> but boot directly to the installer
<Prf_Jakob> I started the live session, changed the resolution and then started the installer.
<tjaalton> so you _could_ do that..
<Prf_Jakob> Right, but just picking install now fails.
<tjaalton> so you did that before?
<Prf_Jakob> Yes
<Prf_Jakob> Changing the minimum default size for the new driver is a kernel patch.
<Prf_Jakob> tjaalton, Sarvatt: Any way I can see which git hash a package was built from?
<Prf_Jakob> You might have picked up a old version of -vmware.
<Prf_Jakob> Gtg, flying to FOSDEM.
<Sarvatt> Prf_Jakob: it's the11.99.901 tarball + 8ff19c2b2 vmwgfx: Avoid including a library header and use pixman for type conversion
<cnd> jcristau, we are looking at creating a package for xorg-gtest
<cnd> initially just ubuntu-only because of deadlines, but there's no reason it can't be packaged in debian and then we sync from there eventually
<cnd> how can we get an xorg-gtest packaging repo on git.debian.org?
<tjaalton> cnd: it's created with /git/pkg-xorg/setup-repository on alioth. first check the path where it should go
<tjaalton> the hierarchy follows upstream
<cnd> tjaalton, ahh, thanks
<tjaalton> maybe ping debian-x@ too
<Sarvatt> ppa's just aren't working anymore with the publishing/build time skew between arches, really going to have to change my workflow for xorg-edgers..
<Sarvatt> RAOF: how hard is it to copy from x-staging to the archive?
<Sarvatt> its a really good idea to build mesa updates in there first from now on with the skew between i386 and amd64 builds, libegl1-mesa-dev is broken in the current one and needs a libxcb-glx0-dev dependency
<tjaalton> who's using libegl1-mesa-dev?
<Sarvatt> wayland-demos, mesa-demos, i'm sure plenty of arm stuff like clutter
<tjaalton> ok then
<Sarvatt> (clutter uses egl instead of gl on armel/armhf)
<FernandoMiguel> evening
<tjaalton> i think RAOF is done for the day though ;)
<tjaalton> so either let those be broken for now and cumulate more stuff in mesa git until monday (if something comes up)
<tjaalton> or push it now to precise
<Sarvatt> oh I was just shooting a question at him, was curious how hard it was for him to do that for X before
<Sarvatt> like if it needs hand holding from other people to do or if it's possible to just copy it himself
<Sarvatt> Steve Langasek (vorlon) wrote on 2011-12-20:	 #7
<Sarvatt> (Priority: OMG there's a game with "meat" in the name and it doesn't work on Ubuntu, must fix)
<Sarvatt> Changed in mesa (Ubuntu):
<Sarvatt> status:	 Confirmed â Triaged
<Sarvatt> importance:	 Undecided â Medium
<Sarvatt> ha
<FernandoMiguel> LLOL
<FernandoMiguel> the importance of the correct motivation
<tjaalton> hehe
<Sarvatt> so yeah we'll need to get plymouth fixed or revert a few commits off libdrm next update
<Sarvatt> since it only builds libdrm-intel1 on amd64 and i386 now
<tjaalton> you uploaded mesa 0u5 to staging?
<Sarvatt> oh no should i?
<Sarvatt> i dont know what screws you up
<tjaalton> nah just noticed that the changelog is finalized
<tjaalton> er, "released"
<Sarvatt> wall was unclear if you wanted to upload that as it was, or wait and amass some more fixes monday
<tjaalton> yeah but now someone else could bump it to u6 :)
<Sarvatt> like what happened with xserver? lol
<tjaalton> that
<Sarvatt> its just you and me touching that branch, we can just use dch -a :P
<Sarvatt> RAOF, bryceh: heads up if you commit anything to the ubuntu mesa branch, ubuntu6 wasn't released
<tjaalton> ok, works for me then :)
<Sarvatt> i will try to get the PPU stuff sorted by next week
<tjaalton> I'd like to drop the extra osmesa flavors
<Sarvatt> yeah that'd be freaking awesome
<tjaalton> no-one else builds them
<tjaalton> checked fedora, opensuse, gentoo, arch
<Sarvatt> that tends to be the most fragile part of the build too
<Sarvatt> noone builds them so people dont notice they broke it in git master
<tjaalton> I tested it in september or so, cut the build time maybe by 40%
<bryceh> Sarvatt, nothing on my todo for mesa
<tjaalton> btw, jeremyhu is asking for a commit to natty :)
<tjaalton> (mesa)
<tjaalton> bug 853667
<ubot4> Launchpad bug 853667 in mesa (Ubuntu) "ATI Radeon HD 3850 is completely unusable with default configuration due to frequent lockups (affects: 1) (heat: 4)" [Undecided,New] https://launchpad.net/bugs/853667
<tjaalton> problem is that he's unable to test an sru for it, if it was made
<Sarvatt> tjaalton: I hate replying to bugs like this.. "Yeah we suck, our stable update criteria won't allow us to update to new stable version updates even though you guys try to maintain stable branches so distros can update it safely."
<Sarvatt> what else can we say, it's the truth. it's the same deal with xserver that he maintains the stable branches for.. our stable update criteria where every patch has to be verified even if it's an obvious fix that went through the criteria and testing for the upstream stable branch
<tjaalton> yeah it sucks
<broder> that's not the case for microrelease exceptions, though
<tjaalton> we really should ask for those, for mesa & xserver
<Sarvatt> it requires an extensive test suite
<tjaalton> problem is stat the mesa pointreleases aren't that 'micro'
<Sarvatt> there's piglit which mesa stable is run against, but not run at build time and not packaged
<tjaalton> *that
<Sarvatt> yeah they're borderline as many changes as in the kernel
<Sarvatt> only it's nowhere near as strick as kernel stable is
<broder> i don't think the criteria specfically require an extensive automated test suite
<Sarvatt> refactoring to allow a fix to apply cleanly is allowed
<broder> though it having one would certainly satisfy the criteria
<Sarvatt> strict rather
<Sarvatt> upstream has a sufficiently high level of regression testing for their stable releases
<Sarvatt> regression tests are enabled in the package's build
<broder> yes, but that does not necessarily imply "extensive regression tests are enabled in the package's build"
<Sarvatt> hmm might have misinterpreted it a but, but piglit (the mesa test suite) isn't part of mesa
<Sarvatt> bryceh: is ia32-libs version parsing still in apport? that should go too
<Sarvatt> for xorg bugs
<bryceh> yeah I've not stripped it out yet
<Prf_Jakob> Sarvatt: for some reason it was stuck on 11.0.99.901, its upgrading now.
<Prf_Jakob> *fingers-crossed*
<Sarvatt> oh that makes a bit of sense, 11.99.901 was waiting until mesa 8.0 went through the new package queue for libxatracker so might not have made the livecd yesterday
<Prf_Jakob> OpenGL renderer string: Gallium 0.4 on SVGA3D; build : RELEASE;
<Prf_Jakob> Whieeee
<Prf_Jakob> And Unity is smooth when running glxgears, good all the important bits are in place.
<Sarvatt> Prf_Jakob: so it's working? truth be told I don't have the hdd space to test it and have been too busy with ivybridge drama
<Prf_Jakob> Sarvatt: Yupp
<Prf_Jakob> works just fine
<Sarvatt> AWESOME!
<Prf_Jakob> yeah!
<Sarvatt> so tomorrow's livecd will work, awesome
<Sarvatt> broder: I believe you were asking about vmware 3D passthrough?
<Sarvatt> broder: it's all in precise now, tomorrow's livecd will work out of the box
<Sarvatt> Amaranth: you too ^^ :)
<Prf_Jakob> Virtual highfive, or vFive in marketing term.
<Amaranth> Sarvatt: yay
<Amaranth> Hopefully gles unity works with it :P
<Prf_Jakob> a dist-upgrade should work as well now
<Prf_Jakob> gles?
<Prf_Jakob> Amaranth: is that whats in there now?
<Sarvatt> Prf_Jakob: nah he's working on gles compiz for linaro, its not in ubuntu yet
<Prf_Jakob> ah
<Sarvatt> Amaranth: is gles compiz going to make 12.04?
<Amaranth> *shrug*
<Sarvatt> cedarview kinda depends on it being there :)
<Amaranth> I'm not really involved anymore
<Sarvatt> making gl work? no sorry we only care about gles in meego
<Sarvatt> oh ok
<Prf_Jakob> Sarvatt: cedarview is PVR right?
<Sarvatt> yup
<Prf_Jakob> *shudder*
<Amaranth> Sarvatt: The plan was to always only have it built with gles on ARM though
<Sarvatt> so same deal as clutter
<Sarvatt> and cedarview is fooked because its x86
<Amaranth> Time for lpia? :)
<Sarvatt> lol
<Sarvatt> thats basically the only option
<Prf_Jakob> So this sucks because nVidia and fglrx doesn't support GLES?
<Prf_Jakob> or you could have just used gles?
<Amaranth> Prf_Jakob: And mesa doesn't support the extension needed to make GLES compiz efficient
<Amaranth> NV_post_sub_buffer
<Sarvatt> Prf_Jakob: clutter and I guess compiz need to pick between gles or gl at compile time so it cant be done in the archive on x86/amd64, on arm we can just compile clutter with gles only support by default because noone will care
<Prf_Jakob> Amaranth: which would be?
<Prf_Jakob> Amaranth: Oh, the mesa copy region extension but for egl.
<Prf_Jakob> Amaranth: that shouldn't be hard to fix.
<Amaranth> Prf_Jakob: Yeah, I wouldn't expect it to be
<Amaranth> It already supports NOK_copy_sub_buffer or whatever its called
<Amaranth> Which is the same thing with a different calling convention iirc
<Prf_Jakob> Ok, I'll put that on my todo.
<Prf_Jakob> Amaranth: http://lists.freedesktop.org/archives/mesa-commit/2011-December/034733.html <-- seems somebody beat me to it :)
<Amaranth> KDE guy, guess the kwin folks came to the same conclusion
<Prf_Jakob> Amaranth: should be in 8.0
<Amaranth> Cool
<Prf_Jakob> You guys needs to package eglinfo up :)
<Amaranth> Isn't it es2_info?
<Prf_Jakob> right you are
<Prf_Jakob> Yupp its there
<Prf_Jakob> Oh, es2gears oth does not throttle correctly.
<Prf_Jakob> Good second window dragging dealy.
<bryceh> nvidia-settings  precise  285.05.09-0ubuntu1
<bryceh> why isn't that at 290?
<Prf_Jakob> delay*
<Prf_Jakob> time to sleep
#ubuntu-x 2012-02-04
<Sarvatt> Prf_Jakob: see ya man, thanks again for checking it!
<Sarvatt> and you know, making it work upstream so we could pull it in
 * Sarvatt should have gotten the 256GB MBA
<Sarvatt> oh well ivb refresh!
<Sarvatt> xorg-pkg-tools directory I do xorg-edgers packaging from is 19.4GB, sheesh
<Sarvatt> 64GB is not enough, hate to wipe the OSX install because thats the only way to do firmware updates
<broder> Sarvatt: <3
<broder> i'll try it out next week
<tjaalton> Sarvatt: get a desktop/server already, ssh into it
<tjaalton> do magic
<Sarvatt> have tons, RDP sucks
<tjaalton> rdp?
<Sarvatt> vmware
<Sarvatt> shares the display over rdp?
<Sarvatt> what were you referring to?
<tjaalton> why do you need that? you do all the stuff on terminals anyway :)
<tjaalton> i mean you have everything on your tiny laptop :)
<Sarvatt> tjaalton: /var/log/xorg.0.log wont tell me if minecraft doesnt work, thats all i care about :P
<Sarvatt> bah SNA
<Sarvatt> half that last sentence was invisible
<Sarvatt> so glad we arent shipping it :)
<Sarvatt> tjaalton: no school this morning, why are you awake this early? :)
<Sarvatt> should that be why am i awake this late? probably..
<Sarvatt> need to run it on real hardware to see if it works though, display corruption in unity wasny visible in any logs remotely last i tried
<Sarvatt> wasnt too
<Sarvatt> it started up fine but all kinds of corruption
<Sarvatt> (mesa 7.11 svga drivers with xorg state tracker)
<tjaalton> Sarvatt: yeah weird, 7h of sleep was apparently enough
<tjaalton> wonder when the drive-by bug triagers stop using -mouse/-keyboard as a target
<Sarvatt> ha, really?
<tjaalton> yep
<tjaalton> well, they have 23 bugs in total
<Sarvatt> i've been noticing the same thing with nvidia-graphics-drivers-180 from kubuntu bugs for years too
<Sarvatt> keyboard related bug, must be xf86-input-keyboard!
<Sarvatt> whoops its a kernel platform driver mishandling a hotkey bug
<tjaalton> oh we still have -elographics too
<Sarvatt> oh yeah and the package isnt in the archive anymore
<Sarvatt> speaking of which
<Sarvatt> i accidentally resurrected keyboard or mouse last release
<tjaalton> -mouse is though, forgot it's used by -vmmouse
<Sarvatt> sync request after it was purged from the archive
<tjaalton> hah
<Sarvatt> yah was keyboard, obviously wasnt mouse
<tjaalton> syncing -void
<Sarvatt> i filed bugs for syncing xtrace and glide yesterday
<tjaalton> just ping here
<tjaalton> :)
<Sarvatt> rendition fakesync, and xterm were the ones i remember
<Sarvatt> that still needed syncing
<Sarvatt>  /merging
<tjaalton> also if you do file bugs, mark them on http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/versions-current.html
<Sarvatt> well i didnt because motu has been seriously on top of it
<Sarvatt> and both were in universe
<Sarvatt> it doesnt last more than a few hours before going through
<Sarvatt> oh
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-glide/+bug/926284
<ubot4> Launchpad bug 926284 in xserver-xorg-video-glide (Ubuntu) "Sync xserver-xorg-video-glide 1.2.0-1 (universe) from Debian testing (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> xtrace went through but not the driver
<tjaalton> done
<tjaalton> synced radeontool, xrestop too
<tjaalton> i really like that overview of package versions..
<Sarvatt> versions-current.html?
<Sarvatt> yeah it freaking rocks, was just thinking that earlier when i was doing a requestsync run
<tjaalton> Prf_Jakob: yeah I told you to install libxatracker1 by hand and then run upgrade ;)
<tjaalton> Sarvatt: you mean motu handles xterm?
<Sarvatt> tjaalton: nawh i didnt merge xterm yet
<Sarvatt> i only did xtrace and glide
<tjaalton> i think we have a silly diff there, it's maintained by upstream on debian..
<Sarvatt> was just saying renditon needs a fakesync and xterm needs a merge
<tjaalton> yeah doing the fakesync now
<Sarvatt> xterm was something silly last i looked, like showing the ubuntu logo
<tjaalton> rendition fakesynced
<tjaalton> so that leaves xkb-data, xorg and xterm merges to finish and we'd be "synced" with debian
<tjaalton> oh and xserver too
<tjaalton> enough of a morning workout, bf time ;)
<tjaalton> wtf? we'll be getting firefox 11 in precise?
<tjaalton> thought 10 was chosen because it's LTM
<tjaalton> hmm -ati git isn't uptodate
<Prf_Jakob> tjaalton: I did, that didn't seem to help the other time around.
<tjaalton> Prf_Jakob: ok.. didn't notice that then
<Prf_Jakob> tjaalton: anyways Unity package landed and it all works now :)
<tjaalton> Prf_Jakob: nice :)
<bjsnider> i don't understand why, if canonical hired the compiz guy, the project is almost deceased
<Sarvatt> awesome, it does indeed just work http://paste.ubuntu.com/829188/
<Sarvatt> getting the unity panel to unhide in a virtual machine window is proving "fun" though
<tjaalton> heh, because of the treshold?
#ubuntu-x 2012-02-05
<Sarvatt> bjsnider: planning on doing a requestsync -d experimental i965-va-driver and requestsync -d experimental libva before feature freeze or does it need ubuntu changes?
<bjsnider> unless somebody has taken the i965 package and finished it, it's not ready
<Sarvatt> its all released in experimental
<bjsnider> it is?
<Sarvatt> wont get synced automatically
<bjsnider> news to me
<Sarvatt> yea
<bjsnider> i'll take a look at it at some point
<bjsnider> what's the version number?
<Sarvatt> http://packages.debian.org/changelogs/pool/main/i/intel-vaapi-driver/intel-vaapi-driver_1.0.15-1/changelog
<bjsnider> ok, that work was done without my knowledge, so it's probably syncable. it's not the barebones thing i sent them anymore
<bjsnider> looks like it's relatively mature
<bjsnider> i just gave it to siretart and he asked if anyone wanted to work on it and that's the last i heard of it
<Sarvatt> do ya want to do the sync so your name is tied to it for later upload rights purposes or anything?
<Sarvatt> thats why i was asking
<Sarvatt> just has to go in before the 16th
<Sarvatt> requestsync -d experimental i965-va-driver && requestsync -d experimental libva, attach test build logs from pbuilder to the bugs it files, its super easy
<bjsnider> test builds in precise?
<Sarvatt> yeah not using precise? sudo pbuilder create --distribution precise then sudo pbuilder --build foo.dsc
<bjsnider> precise isn't very precise at this point
<Sarvatt> of course all the effort so it shows up under https://launchpad.net/~brandonsnider/+related-software might be for naught now since its not archive admins doing the processing, most people forget to leave your attribution when they sponsor it now :P
<RAOF> Sarvatt: Thanks for looking at that - I was thinking of pulling that across.
<bjsnider> Sarvatt, i've got one more i was looking at, how can i check if it's part of the plan or not already?
<Sarvatt> sec, pizzas here
<bjsnider> there should be a "planned features" wiki like fedora's
<bjsnider> but not on the ubuntu wiki site because that's constantly borked
<RAOF> By and large the blueprints targeted to a release *should* be the âplanned featuresâ
<Sarvatt> bjsnider: one more what? lots of things are planned like that but the decisions done in the teams, like we picked X versions back in november
<bjsnider> another package i would like to have updated, but i don't know if it's already planned
<RAOF> What package?
<Sarvatt> yeah totally depends on the package so need to know that :)
<RAOF> bjsnider: I think generally you should assume that if there's not already a bug about it, and it's not super-core (mesa, xorg-server), then there's probably no-one doing anything with it right now :)
<bjsnider> you mean nobody cares about my little package?
<RAOF> bjsnider: I don't know - what little package are you talking about? :)
<RAOF> Also, âcaringâ â  âabout to update itâ âº
<bjsnider> gnome-mplayer/gmtk/gecko-mediaplayer
<Sarvatt> thats fully up to date
<Sarvatt> 1.0.5-1 in debian unstable, 1.0.5-1 in precise
<bjsnider> coolio
#ubuntu-x 2013-01-28
<mlankhorst> hm why do we still build the xserver udebs on ubuntu, do we actually use them anywhere?
<jcristau> no
<tjaalton> mlankhorst: do they bother you :)
<mlankhorst> tjaalton: only in the sense it takes unnecessary build time..
<tjaalton> well, d-i does build the gtk version too which uses them
<tjaalton> http://archive.ubuntu.com/ubuntu/dists/raring/main/installer-amd64/current/images/netboot/gtk/ etc
<mlankhorst> aw :(
<tjaalton> the official iso's don't use them
<mlankhorst> so that's a yes then, ah well
<tjaalton> how many seconds does it take building them?-)
<mlankhorst> not on my main system, but waiting on arm builders in ppa's for example
<tjaalton> ah
<mlankhorst> hm looks like we could just pull some patches to make reverse optimus work on xserver 1.13
<mlankhorst> eg intel driving output on nouveau or radeon
<tjaalton> so my t420s could use displayport (owned by nvidia)?
<tjaalton> hmm no, that's normal optimus?-)
<mlankhorst> nah 'normal' optimus would let you switch to the nvidia card for rendering the internal display if you plug something in
<tjaalton> of course..
<mlankhorst> but yeah looks like we need to pull some patches from fedora xserver for that
<mlankhorst> airlied also updated the autobind patch for it
<tjaalton> I think we'd want some commits from the latest -modesetting to fix some race bugs..
<tjaalton> also for quantal/precise
<tjaalton> just that it's hard to verify they actually fix a race
<mlankhorst> yeah :(
<mlankhorst> sru's are so annoying for x, mostly because a lot of the upstream development on those drivers is just bugfixes. You kind of want all of them even if not directly affected by them.
<mlankhorst> mm i did get the hdmi output to show up on the eee
<mlankhorst> actually using it caused x to crash, I suspect I have to grab the f18 patches :/
<mlankhorst> hm still crashes
<seb128> does xorg default to mirror or span for multimonitor configs?
<bryce> seb128, it mirrors by default but that doesn't matter, since gnome-randr sets its own defaults
<seb128> bryce, g-s-d's xrandr default is "don't do anything, let xorg handle it", which is what should happen at least in the greeter and for new users
<seb128> then g-s-d write a config and overwrite that once you use the xrandr panel in system settings
<bryce> seb128, hmm, I thought it did override things
<bryce> seb128, anyway if it isn't, then it should be coming up as mirrored by default.
<seb128> bryce, that was changed some cycle ago, http://git.gnome.org/browse/gnome-settings-daemon/commit/data/org.gnome.settings-daemon.plugins.xrandr.gschema.xml.in.in?id=75e052127eeb022d83b7a744b110d8bde5b7280c
<bryce> seb128, aha that explains it
<seb128> bryce, the key description states "'do-nothing' will use the default Xorg behaviour (extend the desktop in recent versions)"
<seb128> is that wrong/do we patch Xorg?
<Sarvatt> seb128: thats only true in fedora as far as I can see.. lovely
<Sarvatt> aka http://pkgs.fedoraproject.org/cgit/xorg-x11-server.git/tree/xserver-1.6.99-right-of.patch
<bryce> although I do note there's been a lot of change of this code in current git recently 
<bryce> seb128, so, testing this on precise with HW.  when I hotplug a new monitor (no monitor.xml present), with gnome running the external monitor shows up to the right of my lvds.
<bryce> seb128, when I start up a raw X session with no gnome running, then do the same, the monitor does not turn on by default when hotplugged, and when I do turn it on, it's mirrored.
<bryce> Sarvatt, does this match what you're seeing?
<bryce> seb128, did you file a bug report for jason?
<Sarvatt> bryce: hotplug under gnome, extended, bare xinit I get mirrored, and gnome is mirrored after killing that X and restarting lightdm
<bryce> Sarvatt, ok, same as me
<seb128> bryce, not yet, I was trying to figure out if there is a bug and what component is to blame for it first
<seb128> bryce, Sarvatt: seems like a g-s-d issue then?
<bryce> seb128, yep
<seb128> bryce, thanks
<bryce> seb128, see the 'Handling of hotplug' section on https://live.gnome.org/RandR
<seb128> bryce, ok, I guess we need to backport http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=32f7a938fca072e14bad1928b492e29ba0e3090c
<seb128> "Despite the name, the "default-monitors-setup" key is only used at boot time. After hot-plug of an external monitor, the "xinerama" setup is always used."
<seb128> bryce, thanks for the help tracking it down ;-)
<bryce> seb128, I think that does the opposite of what's wanted
<bryce> maybe, let me look closer
<seb128> + case GSD_XRANDR_BOOT_BEHAVIOUR_DO_NOTHING:
<seb128> + config = make_xinerama_setup (manager, priv->rw_screen); 
<seb128> is weird
<seb128> I think it's based on the fact that upstream assumes xinerama is the default xorg behaviour
<bryce> yeah
<seb128> which is likely because upstream is using fedora, and they are patching their xserver...
<bryce> seb128, hum, yes that could be
<seb128> I will comment on that bug and check with them
<bryce> so yeah I think that patch might end up doing the "right" thing accidentally, but I think it might end up just forcing all multi-head to mirrored, which isn't quite what we want
<seb128> I think otherwise the patch makes change if the make_xinerama_setup in that case is changed to make_mirror_setup instead
<seb128> well, that's the default behaviour
<seb128> if you use the panel you end up with a monitors.xml config and that's used
 * bryce nods
<bryce> seb128, ok so with this patch it looks like the CONF_KEY_DEFAULT_MONITORS_SETUP key would let us control what our policy is, separate from fedora, yes?
<bryce> seb128, well, aside from that here's my thought:
<seb128> bryce, yes, that's a gsettings key, we can change the default in our override (where we set the theme, wallpaper, etc)
<bryce> in make_xinerama_setup() it iterates through the outputs, and lays them out one to the right of the next
<bryce> we could have that code check the physical dimensions of the screen, and if it is 0mm x 0mm, don't increment x in that case.
<bryce> hrm, although that will  overlay rather than clone, that's not quite right either
<bryce> seb128, anyway, my thinking is that there needs to be some logic somewhere that detects if the output is a projector, and in that case clone, but in all other cases extend
<seb128> bryce, do you see that logic to be an xorg thing or a GNOME thing?
<seb128> doing it at the server level would make it work for all desktops, but I guess the xserver is not really the place to make such decisions on behaviours?
<tjaalton> don't think there's any reliable way to detect projectors..
<bryce> seb128, well, to my knowledge, it's not something we're going to be correct 100% of the time.  (There isn't an EDID property that says "I'm a projector".)  So it feels like something that should be on the client end, so it can be configured by the user when it's wrong
<seb128> ok
<tjaalton> well, what's worse is seemingly random behaviour
<seb128> well, I will backport a tweaked version of the gsd fix as a first fix
<seb128> we can try to be smarter then, though I'm not sure either how to guess that a projector is in use
<jcristau> hrm
<jcristau> why would you want to clone for a projector?
<tjaalton> so you can see the presentation from your laptop screen, so no need to strain your neck trying to see the big screen :)
<tjaalton> I guess that's why..
<bryce> jcristau, it's in the specification to do it that way
<jcristau> "the specification"?
<bryce> "Connecting to a Projector or TV
<bryce> When connecting to a projector or TV (heuristic evaluation of the EDID can determine with reasonable certainty whether the display is a projector or TV), the default behaviour is to mirror displays, and presentation mode is checked by default"
<bryce> https://docs.google.com/a/canonical.com/document/d/1aHvJ-iIw-59bXTYBmIhQqEx0za2h9jpFE_RhZ2VOvJc/edit?authkey=CJO5wPkH&hl=en_GB
<tjaalton> restricted
<jcristau> that's not a rationale..
<tjaalton> maybe the presentation app should clone it's window :)
<jcristau> usually when using a projector i want to have notes or something on the laptop, not a clone.  maybe it's just me...
<bryce> tjaalton, what if the user is presenting things using several apps?
<tjaalton> bryce: he can tick 'mirror' :)
<bryce> jcristau, it's just you. ;-)
<tjaalton> actually what jcristau said it's how powerpoint/impress works
<tjaalton> or one mode of it
<bryce> tjaalton, that's not what they're asking for though
<tjaalton> probably misused by 95% of it's users :)
<tjaalton> they?
<bryce> TPTB
<bryce> Chris Kenyon & co., etc.
<tjaalton> so they didn't get proper feedback :)
<bryce> tjaalton, lack of understanding has never stopped a manager from making a decision ;-)
<JanC> tjaalton: LibO has a presentation mode like that too
<tjaalton> JanC: yep, that's what I meant by 'impress' :)
<JanC> I was reading a bit too fast and only saw the first  âº
<JanC> but I remember people were begging for it in Impress for a long time, so I assume it's something that people really want and should work  âº
<tjaalton> bryce: :)
<JanC> of course, when doing presentations using Evince, maybe clone is better
<JanC> and don't call it "mirror", the last thing you want is a *mirrored* image :p
<tjaalton> right :)
<JanC> it's like that funny feature of Intel's drivers where you can turn somebody's screen upside down with a shortcut  :p
<JanC> in Windows
<bryce> tjaalton, think it's worthwhile to look at displaylink on the nexus7 again?  we're still basically screwed with too-old kernel and too-new X.org right?  Have you had any other ideas?
<bjsnider> displaylink? is that like displayport?
<tjaalton> bryce: right, not worth it imo
<tjaalton> bjsnider: no, graphics over usb
<tjaalton> erm
<tjaalton> the adapter is behind usb, the display connector can be whatever
<bryce> tjaalton, yeah sounds good
#ubuntu-x 2013-01-29
<tjaalton> anyone know where the piglit packaging is, and if it's actually in the archive?
<ricotz> tjaalton, xorg-edgers branch
<tjaalton> I'm not after a ppa :)
<tjaalton> I thought it was uploaded to quantal, but can't find it even from raring
<ricotz> tjaalton, i said branch not ppa ;)
<tjaalton> branch where?
<tjaalton> don't tell me bzr..
<ricotz> it isnt in the archive afaics, https://code.launchpad.net/~xorg-edgers/piglit/debian-packaging
<ricotz> but first waffle needs to get into the archive though
<tjaalton> yeah found the same
<tjaalton> oh well
<ricotz> tjaalton, https://code.launchpad.net/~xorg-edgers/+archive/piglit/+sourcepub/2814972/+listing-archive-extra
<tjaalton> danvet was asking
<tjaalton> bad sarvatt, why u no git :)
<ricotz> whole launchpad is bzr, not his fault ;)
<tjaalton> well no-one stopping from adding it to git.d.o
<mlankhorst> hm
<mlankhorst> seems airlied's reverse optimus patches work
<tjaalton> mlankhorst: how did you test?
<mlankhorst> tjaalton: well the hdmi port on my eee is not visible from i915
<mlankhorst> so I just plugged something in for that
<tjaalton> cool
<tjaalton> the eee is hybrid?
<mlankhorst> yes
<mlankhorst> it was my original test machine for this kind of thing :-)
#ubuntu-x 2013-01-30
<mlankhorst> morning
<mlankhorst> hm, shall I push the reverse prime changes?
<tjaalton> yes
<tjaalton> note that I've added some changes to the current branch
<mlankhorst> yeah noticed
<mlankhorst> I didn't bother adding numbers to the patches, I feel like it's useless to do so now :)
<tjaalton> yep
<tjaalton> huh, fresh 12.10 installation doesn't have jockey installed?
<tjaalton> oh it's under software sources now
<tjaalton> oh and enabling the blob should yell loud and clear that the machine needs to be rebooted, logout will end in misery..
<tjaalton> looks like reboot isn't much better, I get no unity with hd5450 & fglrx
<tjaalton> so much for testing s3 :)
<tjaalton> didn't build the module..
<mlankhorst> oops, I pushed the xorg-server change out under your name.
<tjaalton> oh, heh
<mlankhorst> oh silly xxv-ati.git, one commit 'Fixes rotation with glamor', next commit another fix '[...] Otherwise rotation won't work when glamor support isn't built in.'
<tjaalton> hehe
<tjaalton> mlankhorst: so what do I need to do to test the reverse optimus patches? should it just work when I plug a monitor, or does it need some xrandr tricks?
<mlankhorst> well ati one is still lacking, was hoping i could do a point release first and then just apply the patch on top
<tjaalton> i have intel/nouveau
<mlankhorst> oh sure, just update both
<mlankhorst> and check xrandr -q
<tjaalton> nice..
<tjaalton> will do in a bit
<mlankhorst> I'm fighting nouveau interrupts atm :/
<mlankhorst> btw you might get some conflicts with the symbolic name, like having 2 LVDS1 panels or something
<tjaalton> so 3.5.0-18 has three commits to radeon, none of which have any way of affecting s3 resume on my card :/
<tjaalton> ok
<mlankhorst> tjaalton: didn't fglrx suspend break too? what if it's not a radeon commit that broke it
<tjaalton> mlankhorst: well fglrx is broken on 12.10 regardless
<tjaalton> tried the newer version too
<mlankhorst> ah :-(
<tjaalton> with the stock & updates kernels, all broken so that it won't survive too many cycles :)
<tjaalton> this is a different issue after all
<mlankhorst> so lts-quantal is broken because quantal is broken? to the panic mobile! :O
<tjaalton> well
<tjaalton> I couldn't reproduce the radeon issue on quantal..
<tjaalton> so wondering wth might cause it
<mlankhorst> wasn't there a upstream bug that was related?
<tjaalton> yes
<tjaalton> oh well, just have to bisect -17..-18
<mlankhorst> ah k, I'm going to push a new radeon release upstream, then to raring in a bit
<mlankhorst> pushed :)
<bryce> tjaalton, for bug #1068994 someone suggested disabling MT as a work around.  Is that feasible?  Wanna try it?
<ubottu> bug 1068994 in ubuntu-nexus7 "button1 gets stuck after a while" [Critical,Confirmed] https://launchpad.net/bugs/1068994
<tjaalton> bryce: I already asked, there's no way to do that other than building a server/driver without MT support
<mlankhorst> tbh we should diagnose the root cause
<tjaalton> orly? :)
<mlankhorst> I always wanted to dive into the input stack, down the rabbit hole!
<tjaalton> seriously doubt that, but ymmv :)
<mlankhorst> Sarcasm selftest complete!
<mlankhorst> https://bugs.freedesktop.org/show_bug.cgi?id=56557 ?
<ubottu> Freedesktop bug 56557 in Server/Input/Core "Pointer emulation on root window is broken" [Normal,Assigned]
<mlankhorst> maybe worth testing the series listed at the end
<tjaalton> https://bugs.freedesktop.org/show_bug.cgi?id=56578
<ubottu> Freedesktop bug 56578 in Server/Input/Core "race condition with active/passive grabs when opening menus with touch" [Normal,New]
<tjaalton> it's not that one
<tjaalton> already tried those
<bryce> is there any debugging options that can be flipped on?
<mlankhorst> seems to be in the bug report
<mlankhorst> probably just enable the standard spam
<bryce> m
<bryce> so... any other ideas?
<ogra_> bryce, i'm still not convinced it is X 
<mlankhorst> what else, synaptics?
<ogra_> if it happens to me, i can still interact with apps ... just not with desktop elements
<tjaalton> it's using evdve
<tjaalton> evdev
<mlankhorst> oh evdev, still
<tjaalton> ogra_: those use Xi1
<tjaalton> ogra_: search for an app that uses proper Xi2-based multitouch, and keep it running to see if you still can get to it when input gets stuck
<ogra_> tjaalton, all compiz bits hang ... but i can still use the ubuntu key + number in onboard to switch to i.e. firefox and can tap on links
<ogra_> onboard apparently never dies (i have the floating button enabled, that also always works to bring it up)
<ogra_> so i can navigate my way though the desktop with it to notice that i can even play aisle riot while the rest of the desktop is unresponsive
<ogra_> but i can not move any windows around nor get any clicks through to launcher or panel
<ogra_> you guys are indeed the experts but to me it looks more like a compiz issue (when X input dies i would expect that to affect everything)
<bryce> ogra_, intriguing, yeah may not be X
<bryce> (certainly wouldn't be the first time an "X bug" turned out to just be compiz's fault...)
<bryce> ogra_, is it unreproducible with non-compiz WM's?
<ogra_> yes, it wasnt reproducable with lubuntu 
<ogra_> i havent tried non unity setups in a while though
<bryce> ogra_, I recall we'd gotten gnome-shell up on n7; if it's unreproducible there too then I think we can shift focus to compiz
<ogra_> i think desrt got it running 
<ogra_> i never managed, there is some GL check that didnt work and only got me into fallback when i tried, he had the full shell up
<ogra_> tjaalton, what woudl such an app be ?
<ogra_> (any pointers ?)
<tjaalton> well, whot never blamed it on compiz so we just concluded that it's hitting some bug that the other vm's don't
<tjaalton> :)
<tjaalton> ogra_: good question..
<tjaalton> maybe there are some demo apps?
<ogra_> compiz ?
<ogra_> :)
<bryce> there's that finger drawing toy app, that's fully MT and Xi2
 * ogra_ googles "finger drawing toy app" and fails :P
<bryce> bah :-)
<bryce> ts_test
<bryce> http://ofb.net/~rafi/ts_test.tgz
<tjaalton> that's old
<tjaalton> doubt it does xi2
<bryce> yeah dunno
<Sarvatt> git://people.freedesktop.org/~whot/multitouch
<tjaalton> too obvious :)
#ubuntu-x 2013-01-31
<ricotz> RAOF, hi :)
<RAOF> ricotz: Yo!
<ricotz> RAOF, how are you?
<RAOF> ricotz: Pretty good.
<ricotz> RAOF, good, news about Australia arent that good in the last time
<RAOF> Eh, it's just fires and floods.
<ricotz> RAOF, could you take a look into updating colord? https://launchpad.net/~ricotz/+archive/staging/+sourcepub/2955146/+listing-archive-extra
<tjaalton> RAOF: hey, what happened to piglit getting in the archive? was it dropped?
<RAOF> ricotz: I happen to be doing just that now :)
<ricotz> RAOF, oh, nice
<RAOF> tjaalton: Weren't you the one who was going to do that?
<tjaalton> was I? :)
<tjaalton> sheesh
<ricotz> heh
<tjaalton> ok so the first step is to put the packaging somewhere
<ricotz> is waffle added already
<RAOF> tjaalton: I'm pretty sure I wasn't going to be doing piglit. apitrace just made it through AA review, though :)
<tjaalton> oh I must've mixed it with apitrace
<tjaalton> right-o, it was Sarvatt who packaged it for qa
<tjaalton> piglit that is
<tjaalton> ok I'll talk with him how to proceed
<mlankhorst> hmz
<ricotz> MCR1, hi, i hope 12.100~beta3 works alright?
<MCR1> ricotz: Yep, it does. Thanx a lot. Fast as always ;)
<MCR1> (I mean your work, not the driver ;))
<MCR1> ricotz: Although I doubt that one fix of this release was Linux related ;)
<MCR1> *even one fix
<ricotz> yeah, since there are no dedicated changelogs it is hard to say
<ricotz> mlankhorst, hi, did someone had a look at refreshing mesa packaging for the 9.1 branch yet?
<mlankhorst> I think tjaalton did slightly
<ricotz> i got scared away through the buildsys changes which made some patches really diverged
<ricotz> (otherwise there would have been an update in xedgers)
<mlankhorst> I'm building X on nexus7 atm for testing the input bugs
<ricotz> mlankhorst, as a side note, not sure if it is worth to take a snapshot of llvm-3.3 to make it possible to build the r600 gallium driver
<mlankhorst> oh right 
<mlankhorst> that's where I stopped on :P
<ricotz> mlankhorst, https://launchpad.net/~ricotz/+archive/unstable/+sourcepub/2935469/+listing-archive-extra
<tjaalton> that won't happen
<tjaalton> aiui
<ricotz> understandable, could be an option of edgers though
<ricotz> so the only option is to drop the radeonsi driver
<tjaalton> yes
<ricotz> which was done in edgers too
<ricotz> tjaalton, do you finished the packaging update by any chance?
<mlankhorst> can't we just make a llvm-mesa package?
<ricotz> mlankhorst, if so we can use a snapshot too
<ricotz> 3.3 is whole different namespace and doesnt interfere with files of 3.2 or less
<mlankhorst> actually it would need some better name than that
<mlankhorst> something i could copy to precise when the time comes
<tjaalton> mlankhorst: it's possible, talk with doko :)
<ricotz> llvm-3.3 it is
<tjaalton> ricotz: didn't touch it since two weeks ago
<ricotz> they are coinstallable, no need to rename things here
<ricotz> tjaalton, ok, did it build at this time?
<mlankhorst> ok as long as mesa builds with llvm-3.3, it would be fine by me
<tjaalton> ricotz: seems so
<ricotz> tjaalton, can you push it to debian git?
<tjaalton> ricotz: yes, later
<mlankhorst> tjaalton: hm, with http://cgit.freedesktop.org/~whot/xorg-integration-tests/ do you think we could apply for a MRE for xorg-server?
<tjaalton> mlankhorst: yes, that's the plan
<mlankhorst> ok we'll need to have some ppa with the updated packages though
<tjaalton> yup
<mlankhorst> I was testing with that actually
<tjaalton> I haven't looked at xit yet, how is it used?
<mlankhorst> the thing seems to be that xorg-gtest will fail to install due to running some tests of its own in the build step
<mlankhorst> needs to be run as real root
<mlankhorst> and needs /dev/uinput too
<mlankhorst> CONFIG_INPUT_MISC and CONFIG_INPUT_UINPUT with the uinput module loaded..
<tjaalton> ah, crap
<mlankhorst> [ RUN      ] XServer.IOErrorException
<mlankhorst> XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":133"
<mlankhorst>       after 7 requests (7 known processed) with 0 events remaining.
<mlankhorst> FAIL: xserver-test
<mlankhorst> o.O
<tjaalton> looks like stephen webb filed an ITP for xorg-gtest yesterday
<tjaalton> in debian
<mlankhorst> it restores the error handler for some reason in RegisterXIOErrorHandler
<mlankhorst> wtf
<mlankhorst> how can it be that old_handler be != _XDefaultIOError
<mlankhorst> some linking thing?
<mlankhorst> hm must be
<jcristau> tjaalton: is that somebody you know?
 * jcristau doesn't want to end up with two competing packagings for this thing
<tjaalton> jcristau: what now?-)
<tjaalton> lost me there
<jcristau> stephen webb
<jcristau> re: xorg-gtest
<tjaalton> ah
<mlankhorst> jcristau: I'm using the debian packaging
 * jcristau is confused
<mlankhorst> git+ssh://git.debian.org/git/pkg-xorg/lib/xorg-gtest.git
<tjaalton> oh
<tjaalton> bregmata is a canonical employee
<jcristau> mlankhorst: that looks way out of date
<mlankhorst> yes :/
<jcristau> raring seems to have a 0.7.0 version
<mlankhorst> hm but no guarantee it's packaged anywhere though, I'll check
<tjaalton> hmm, maybe I should ping him that it's taken care of already?
<tjaalton> I didn't know it existed under pkg-xorg
<tjaalton> jcristau: would piglit make sense under pkg-xorg?
<jcristau> dunno
<mlankhorst> hm shall I just import xorg-gtest into git again then?
<tjaalton> it's kinda special, always out of date
<jcristau> what's the use case for a piglit package?
<mlankhorst> having the same measuring rod
<tjaalton> right :)
<tjaalton> but having the packaging somewhere is useful
<tjaalton> erm
<tjaalton> probably would be fine if I ran piglit first to see what it is :)
<tjaalton> as a distro package it probably doesn't make sense
<mlankhorst> just a bunch of tests, surprisingly it didn't even lock up on nouveau for me
<tjaalton> i most likely did run it during last cycle
<mlankhorst> I guess I'll just update the xorg-gtest branch from ubuntu to debian-experimental branch in git
<mlankhorst> finally got xorg-integration-tests to build
<mlankhorst> doesn't pass all tests, though :)
<tjaalton> mlankhorst: the llvm-config hack in mesa doesn't seem to work with 9.1, or I'm missing some detail
<tjaalton> anyway, I'll push the experimental packaging now..
<mlankhorst> tjaalton: hm would have to check
<mlankhorst> tjaalton: what version of autoconf?
<mlankhorst> looks like the official way to fake it would be to make a temporary symlink in some temp/bin/llvm-config and then just pass it as --with-llvm-prefix=whatever/temp :/
<mlankhorst> or we could just patch configure.ac again I suppose
<mlankhorst> btw I'm getting this on precise
<mlankhorst> checking for llvm-config... (cached) llvm-config-3.2
<mlankhorst> ../../configure: line 23315: llvm-config-3.2: command not found
<mlankhorst> so guessing you need to fixup the build-deps
<mlankhorst> afk a bit, food
<tjaalton> getting the same, it should be right..
<tjaalton> heh, build-dep on llvm-3.1-dev
<mlankhorst> ;P
<tjaalton> still fails though
<tjaalton> checking for "/usr/lib/llvm-3.2/lib/libLLVM-3.2.so"... no
<tjaalton> checking for "/usr/lib/llvm-3.2/lib/libLLVMTarget.so"... no
<mlankhorst> ugh seems weird
<mlankhorst> llvm-config-3.2 --libdir ?
<tjaalton> i'm building with sbuild
 * mlankhorst should set up git-pbuilder at one point
<mlankhorst>         NOTE: Mesa is attempting to use llvm shared libraries because you have
<mlankhorst>         passed one of the following options to configure:
<mlankhorst>                 --with-llvm-shared-libs
<mlankhorst>                 --enable-opencl
<mlankhorst> looks like /usr/lib/llvm-3.2/lib/libLLVM-3.2.so does not exist, but /usr/lib/llvm-3.2/lib/libLLVM-3.2.so.2 does..
<mlankhorst> maybe a packaging error?
<bjsnider> .so should be in the -dev package
<mlankhorst> yeah but libLLVM-3.2.so should probably not be in /usr/lib/llvm-3.2/lib/, but /usr/lib/$(arch)
<bjsnider> i'm rusty on the rules, hold on a sec
<bjsnider> the headers go in /usr/include but the .so goes alongside the actual shared lib
<mlankhorst> yeah
<bjsnider> so i suppose the -dev has a problem if it isn't installing the .so
<mlankhorst> it's installing it, but something is installing libLLVM-3.2.so.1 twice..
<bjsnider> dpkg -S will tell you what is isntalling a particular file
<mlankhorst> tjaalton: I'll try to get upstream to accept a patch to test for -lLLVM-3.2 first before it tests the location
<mlankhorst> libllvm3.2:amd64: /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1
<mlankhorst> llvm-3.2-dev: /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so                                                                                                                                                     
<mlankhorst> llvm-3.2-dev: /usr/lib/llvm-3.2/lib/libLLVM-3.2.so.1  
<mlankhorst> weee
<mlankhorst> looks like a bug in the packaging
<mlankhorst> I'll leave it for tomorrow :/
<bjsnider> pretty easy fix in that -dev package though
<tjaalton> bryce: is it possible for apport to not report false gpu hangs, at least for released versions?
<tjaalton> bug 1073626
<ubottu> bug 1073626 in xserver-xorg-video-intel (Ubuntu) "Constant "false gpu hang" system alerts" [Undecided,Confirmed] https://launchpad.net/bugs/1073626
<bryce> tjaalton, well we can just shut it off entirely for quantal.  
<bryce> we probably don't care about gpu hangs on quantal anyway
<bryce> tjaalton, I can take care of that
<mlankhorst> we sort of do, due to backport stack\
<bryce> tjaalton, for false gpu hangs in development releases, well I don't think we have a sure fire way to distinguish between false gpu lockups and real ones.
<bryce> tjaalton, is there a packaging way we could have the udev rule only be applied for !stable releases?
<jcristau> an udev rule that does wget http://archive.ubuntu.com/ubuntu/dists/ and looks if there's a newer version? :)
<bryce> jcristau, :-P
<mlankhorst> dont we already have something like development release in the motd?
<tjaalton> that's what i was thinking
<tjaalton> bryce: where does the 'false' part come from?
<bryce> tjaalton, a dialog pops up and asks the user if they experienced a display lockup recently.  If they say 'no', it adds False.
<bryce> it mostly works but there's about 10-20% false falses
<bryce> you know, I could do something as stupid as just take the release YY.MM and compare it to the current date, and then exit the apport hook if it looks released
<bryce>  
<bryce> tjaalton, mlankhorst:  but this all begs the question - what do we want to do with the gpu lockup bug reports?
<mlankhorst> it's annoying though
<bryce> we can't grok them.  In the past I just forwarded them upstream, but invariably they just got set to incomplete with a random selection from ["Need steps to repro", "Test on newer kernel", "This patch should do it, trust me."], then +3 months and close as unanswered.  Then next cycle all the same GPU lockup bugs error #'s start coming in again...
<mlankhorst> yeah :/
<mlankhorst> it's been ok fixing some nouveau bugs myself though but the remaining ones.. also hard to get accepted since there aren't always specific launchpad bugs for it (was it this hangbug or that hangbug..)
<bryce> tjaalton, mlankhorst maybe one of you would have better luck working with upstream on forwarding the lockup bugs?
<bryce> unfortunately people who use the apport hook to report gpu lockups assume that it collects 100% of required info to fix the bug, so rarely say anything, and never provide steps to reproduce
<mlankhorst> sort of trying to play upstream for nouveau myself, but without steps to reproduce :/
<bryce> but people reporting reproducible hangs tend to not know to collect the i915 error file and stuff, so require a lot of handholding to get a proper report
<bryce> mlankhorst, yeah you've done a good job tackling the nouveau bugs.
<bryce> mlankhorst, do you mostly use the reported info, or work with the reporter to get more info, or work just on issues you can repro locally?
<mlankhorst> mostly reproducible ones, and sometimes just cherry picking stuff from mesa git that looks important
<bryce> hmm, I wonder about having the apport hook locally log lockups, and only prompt to file a bug on the 10th visit
<bryce> then, we may have a situation more likely to have reproduction steps...
<mlankhorst> well the problem with apport is it immediately gets into your face
<mlankhorst> which steals focus and is annoying
<bryce> not much I can do about that :-)
<bryce> (well, aside from just disabling it entirely)
<mlankhorst> yeah needs to be rethought :/
<bryce> essentially it was --> thus begat whoopsie
<bryce> however it pretty much has that same flaw
<Sarvatt> just showing the crash indicator and not showing the popups unless you click it would be nice
<mlankhorst> indeed..
<mlankhorst> or just not endless windows popping up, but something more organized
<mlankhorst> probably both
<tjaalton> bryce: i've worked with ickle more during the past few weeks to sort out any issues with sna in particular
<tjaalton> not via b.fd.o but irc
<tjaalton> helps that he's subscribed to -intel bugs
<mlankhorst> \o/
<bryce> Sarvatt, explain?
<Sarvatt> like if you get a crash, you just get the icon up top telling you, and clicking that brings up all the crashes in order like it does now
<bryce> tjaalton, cool.  Would you mind working with him on our gpu lockup bugs as well?
<bryce> tjaalton, at least for the rest of this cycle.  we can re-evaluate again next cycle if we still are seeing lots.
<bryce> Sarvatt, ah.  I don't think I can fix that though.
<tjaalton> sure, some are well known already
<Sarvatt> ah yeah wasn't talking about intel, just apport/whoopsie in general
<bryce> Sarvatt, ah gotcha
<bryce> well, I have been looking into how to condense the X hook dialogs, since I know people aren't really looking at them anyway
<mlankhorst> ideally apport would be able to work without user interaction at all..
<Sarvatt> sudo apt-get install ubuntu-desktop^
<Sarvatt> The following NEW packages will be installed:
<Sarvatt>   apport apport-gtk unity-lens-shopping whoopsie
<Sarvatt> every machine i have :P
<mlankhorst> indeed..
<mlankhorst> apport panicking over a WARN_ON in kernel I added myself for testing ._.
<bryce> mlankhorst, well, my thinking is this - MOST of the time we do need to interact with the user to get more info, but we can either do it *before* the bug is filed or *after*.  The latter requires manpower to do bug triage and ask questions, the former annoys the user with dialogs...
<mlankhorst> yes, but we should bug the user only once, instead of repeatedly with newly popping up windows
<bryce> yeah
<mlankhorst> and definitely apport should shut up if the same thing happens a second time :/
<mlankhorst> no need to remind me every reboot a WARN_ON happened
<bryce> heh
<bryce> well, with X bugs, what I really want is just to get the damn bugs fixed!  If the apport hook never has to fire off, then it doesn't matter how annoying it is.  ;-)
<mlankhorst> I do care about stability, but if we never needed those hooks why would we add them? best make them as least annoying and intrusive as possible..
<Azelphur> bryce: That machine with the 7770 we was talking about the other day, I spent another few hours with it today and figured out what was wrong, the ATI drivers refuse to build against the current kernel in Ubuntu 12.10, I booted it up on 3.5 (17) and was able to install the official drivers from amd.com from the debs produced by --buildpkg and then everything worked.
<tjaalton> Azelphur: you probably don't have the headers installed, known bug in 12.10
<tjaalton> install linux-generic and it should pull them
<Azelphur> I think I had the headers installed, I found a forum post saying that they apparently don't build against 3.7, which is why I downgraded
<Azelphur> next time I have access to that box I'll try it :)
<tjaalton> 3.7 isn't "the current kernel" of 12.10
<Azelphur> ah yea, I also upgraded it to xorg-edgers (in an attempt to solve the issues)
<Azelphur> so perhaps it's the missing headers package that caused all the issues,t hen :)
<bryce> Azelphur, :-)
<bryce> yeah all the ppas we have can sometimes cause as much trouble as worth ;-)
<Azelphur> well the ppa wasn't the cause, seems like the missing headers was always the cause
<Azelphur> I tried to do it the normal way first, the weird stuff only came as attempts to problem resolve
<Sarvatt> 3.7 is the default kernel in xorg-edgers for 12.10 yeah :( but there's a fglrx in the ppa that builds against it
<Sarvatt> it's just called fglrx, not fglrx-updates though
<Azelphur> yea, I'm blaming the missing headers thing for all my issues :P
#ubuntu-x 2013-02-01
<mlankhorst> morning
<tjaalton> mlankhorst: did you see mrcooper's comment about the llvm issue?
<tjaalton> https://bugs.freedesktop.org/show_bug.cgi?id=59967
<ubottu> Freedesktop bug 59967 in Mesa core "[regression] configure: error: Could not find llvm shared libraries" [Normal,Reopened]
<mlankhorst> yeah, not sure what to think
<tjaalton> common/native_wayland_drm_bufmgr_helper.c:11:41: fatal error: wayland-drm-server-protocol.h: No such file or directory
<tjaalton> although it's built before the egl state-tracker
<tjaalton> hrm, same thing without parallel
<tjaalton> looks like it was missing the path from cppflags after all..
<tjaalton> nope..
<mlankhorst> maybe need another newer wayland?
<tjaalton> no, the header is generated during build
<mlankhorst> :/
<tjaalton> bryce: lsb_release -d shows "development release" if base-files hasn't been bumped for the release, so maybe use that as an indicator if the system is running a released version or not :)
<tjaalton> ah, realized why the header isn't found..
<tjaalton> it doesn't support out-of-tree builds..
<tjaalton> top_srcdir is wrong
<tjaalton> should use top_builddir
<mlankhorst> again?
<tjaalton> yeah, dejavu all again :)
<tjaalton> so, after dropping --with-shared-llvm-libs and fixing that include it builds fine
<mlankhorst> erm you kind of want --with-shared-llvm-libs though, reduces on image size
<tjaalton> $libdir/gallium-pipe/pipe_{r600,nouveau,swrast,vmwgfx,r300}.so
<tjaalton> sure, but wanted to see what else needs fixing
<mlankhorst> ah np
<tjaalton> what those pipe files are?
<mlankhorst> they're gallium pieces split up
<mlankhorst> so for example vdpau_nouveau and dri_nouveau would both use pipe_nouveau.so
<tjaalton> ok, so in the dri package
<mlankhorst> you get a cookie if you enable vdpau btw
<tjaalton> does it work?
<mlankhorst> well it no longer crashes on mplayer -vo vdpau
<mlankhorst> so it's better than using xv probably
<tjaalton> ok
<tjaalton> one thing at a time :)
 * mlankhorst is trying the input merge request from hutterer on panda
<tjaalton> ugh, libxatracker gensymbols seems to dump all the llvm symbols there too?
<tjaalton> + LLVMInt64TypeInContext@Base 9.1~git20130129.ff515c4e-1
<tjaalton> + _ZN4llvm10SSAUpdaterC2EPNS_15SmallVectorImplIPNS_7PHINodeEEE@Base 9.1~git20130129.ff515c4e-1
<tjaalton> just to show a few examples
<tjaalton> meaning it's linked wrong?
<mlankhorst> linked statically..
<tjaalton> hm right, no llvm shared libs :)
<mlankhorst> gah
<mlankhorst> my nexus7 reboots reliably on the xorg-server dh_install step :(
<mlankhorst> nfs over wireless
<tjaalton> huh
<mlankhorst> tried to get a build running with xorg-server
<tjaalton> OOM killer behaving?
<mlankhorst> it just reboots, don't think it's the oom killer
<mlankhorst> hm, maybe update evdev? I was running xorg-integration-tests, and noticed it complaining about evdev
<mlankhorst> and I'm off to fosdem, bb :)
<njin> bryce, hallo bug1112871 , reproduced in the new kernel 3.8.0-3
<njin> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1112871
<ubottu> Ubuntu bug 1112871 in xserver-xorg-video-intel (Ubuntu) "[clarkdale] False GPU lockup IPEHR: 0x02000000" [Undecided,New]
<njin> also in kern.log: [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
<tjaalton> njin: can you reproduce it?
<njin> tjaalton, no now totem strangely works
<bryce> njin, hi thanks
<njin> thanks you guys
<bryce> njin, yeah I think steps to repro are needed before this can go anywhere
<bryce> dah, he left
 * bryce updates bug
<tjaalton> there are several mediaplaer-related bugs after the sna swith, dunno if they are dupes
<tjaalton> some just crash the server though
<tjaalton> well, not several but some
#ubuntu-x 2013-02-02
<Dandel> I noticed a small problem with attempting to resume piglit tests using the installed package.
#ubuntu-x 2014-01-29
<Sarvatt> jcristau: all the nvidia drivers in sid except 96.xx work with it, but yeah fglrx is at least a month behind
<Sarvatt> not sure how the blobs work in debian though, in ubuntu someone has to add the new abi and reupload them but the drivers actually do work
<jcristau> Sarvatt: all drivers in sid look like they already have xorg-video-abi-15 in their list of alternative dependencies (except 96xx)
<jcristau> but 96xx already doesn't support 1.14
<jcristau> s/all/& nvidia/
<jcristau> Prf_Jakob: is there a plan for a vmware ddx release some time soon?
<Prf_Jakob> jcristau: there is a plan yes
<Prf_Jakob> jcristau: just need QE to sign off.
<jcristau> ok, thanks
<alkisg> Hi, is vesafb.ko missing in Trusty? Should udev-fallback-graphics get updated to `modprobe uvesa`?
<alkisg> $ grep vesa /etc/init/udev-fallback-graphics.conf 
<alkisg>         modprobe -q -b vesafb
<alkisg> $ ls /lib/modules/*/kernel/drivers/video/*vesa*
<alkisg>  /lib/modules/3.13.0-5-generic/kernel/drivers/video/uvesafb.ko
<alkisg> Ah, and v86d is not installed either... from its description and the output of `dmesg`, I'm guessing it's needed...
<alkisg> Anyway, I think that the fallback graphics logic has been broken since 12.04
<mlankhorst> uvesa is not meant to be used
<alkisg> In the 10.04 days, when the "appropriate driver" failed to initialize xorg, a switch to xvesa happened, and a dialog was displayed about starting a session with fallback graphics etc
<alkisg> This doesn't work in 12.04, 14.04 etc, xorg just restarts continuously...
<tjaalton> it never used vesafb
<mlankhorst> indeed
<alkisg> Then I don't know what that "udev-fallback-graphics.conf" does, but the symptoms that I see are still there, i.e. no fallback graphics probably since we started using KMS.
<alkisg> And someone should remove that udev-fallback-graphics service since vesafb isn't being shipped, it's just producing annoying messages in syslog...
<tjaalton> on what hw??
<tjaalton> -?
<tjaalton> if kms is used but it doesn't work, there's no way to fallback to anything aiui
<alkisg> Aaah ok that might be the reason then
<alkisg> I've had reports from many schools here, I don't remember the graphics cards but I can note them down when needed, I think I remember some older sis ones...
<tjaalton> they don't have kms
<alkisg> Then maybe there's no fallback graphics logic anymore :)
<tjaalton> sure is
<tjaalton> if the xserver crashes
<tjaalton> it'll get loaded with a fallback conf
<alkisg> Hmm maybe we somehow accidentaly block that in LTSP, I haven't seen it since 10.04
<tjaalton> i mean if the xserver crashes when starting with default (no) conf
<alkisg> In LTSP by default we don't use a xorg.conf. But we don't use lightdm etc either, we have our own DM called ldm, and X is launched by that
<alkisg> We have about 500 schools here, I haven't seen the fallback graphics triggered in years...
<alkisg> Do you happen to remember offhand what upstart job starts the fallback graphics?
<alkisg> Or is that xorg?
<tjaalton> failsafe-x.conf
<alkisg> Thank you, reading...
<tjaalton> i'd say it's a good thing you never saw it..
<alkisg> I did see black screens that we had to work around with XSERVER=vesa though :)
<alkisg> Lots of them
<tjaalton> crappy sis driver then
<tjaalton> it can't detect if you get no output
<alkisg> It's not only sis... we have a lot of old cards, a lot of xorg crashes etc
<tjaalton> or crappy drivers in general
<alkisg> The bad thing is that they worked fine up until 10.04, and they started having serious issues since 12.04
<alkisg> And they're very very slow in gtk too *now*, maybe because of the switch to cairo instead of gdk...
<alkisg> Like, needing 0.5 sec to draw one menu item in gnome-panel...
<tjaalton> no exa support then
<alkisg> 10 times slower than 10.04, at least
<tjaalton> which 12.04?
<alkisg> I've seen that with sis and older nvidia cards (pre-geforce), I haven't yet pinpointed it exactly
<alkisg> We use gnome-fallback with metacity
<tjaalton> .{1,2,3}
<alkisg> 3
<alkisg> QAh
<alkisg> Ah
<alkisg> I've tried with 3.2 kernel and xorg, and with the raring one
<tjaalton> .3 has the raring stack
<alkisg> sis crashes xorg with the saucy one
<tjaalton> and kernel
<alkisg> *raring
<alkisg> But the issue was there in both of the kernels/xorg combinations...
<tjaalton> so it was already 1.13 that dropped exa
<tjaalton> err
<tjaalton> not exa
<tjaalton> the other one
<alkisg> uxa?
<tjaalton> no
<alkisg> OK I got what you mean, I also don't remember it :)
<alkisg> I tried gtkperf and I saw very big variations in some of its tests
<alkisg> Like, two PCs having similar times everywhere, but in 2 tests, the first pc would need 50 seconds and the other one 5 seconds...
<alkisg> *xaa
<tjaalton> yup
<alkisg> And I thought it was because of some functions using software instead of hw acceleration, in some drivers...
<alkisg> (and those software implementations being very bad... :-/)
<tjaalton> probably that too
<tjaalton> in other parts
<alkisg> Would it be possible to run a very old xorg in a recent ubuntu?
<alkisg> E.g. 1.7.6 from Lucid, to Trusty?
<alkisg> start on stopped lightdm EXIT_STATUS=[!0] or stopped gdm EXIT_STATUS=[!0]
<alkisg> ...that's why it never gets triggered in LTSP, since we're using LDM...
<alkisg> I'll check if we can emit a "stopped lightdm" signal even if we don't have lightdm installed...
<tjaalton> hehe
<tjaalton> it might be possible to forward-port, yes
<tjaalton> and rebuild the drivers
<alkisg> brb, my i915 hangs every now and then in trusty... :-/
<tjaalton> that's progres..
<tjaalton> +s
<bryceh_> Sarvatt, done any displayport troubleshooting recently?  does this Xorg.0.log jog any ideas?
<bryceh_> http://paste.ubuntu.com/6840625/
<bryceh_> user has a usb-to-hdmi adapter to run an external monitor
<bryceh_> adapter is http://www.amazon.com/Sabrent-1920x1080-1600x1200-DisplayLink-USB-HDMI/dp/B005UKG4KU/ref=cm_cr_pr_product_top
<bryceh_> er s/displayport/displaylink/ 
<bryceh_> it seems the kernel driver is not exposing the EDID from the monitor
<bryceh_> dmesg & xrandr:  http://paste.ubuntu.com/6840629/  http://paste.ubuntu.com/6840630/
<bryceh_> the monitor lights up with VESA modes okay
<bryceh_> we tried guessing a modeline to force it to 1920x1080, and it seems to work, but screen stays black
<bryceh_> <guym> DVI-1-0 connected 1920x1080+1920+0 (0xfa) normal (normal left inverted right x axis y axis) 0mm x 0mm
<bryceh_> <guym>         Identifier: 0xf3
<bryceh_> <guym>         Timestamp:  1331890
<bryceh_> <guym>         Subpixel:   unknown
<bryceh_> <guym>         Gamma:      1.0:1.0:1.0
<bryceh_> <guym>         Brightness: 1.0
<bryceh_> <guym>         Clones:
<bryceh_> <guym>         CRTC:       4
<bryceh_> <guym>         CRTCs:      4
<bryceh_> <guym>         Transform:  1.000000 0.000000 0.000000
<bryceh_> I also had him try connecting to other CRTCs but he just gets errors for anything other than 4
<RAOF> bryceh_: Can you get the kernel to fake a 1920x1080 EDID for it?
<RAOF> That would be something like drm_kms_helper.edid_firmware=DVI-1-0:edid/1920x1080.bin
<bryceh_> RAOF, I can give that a try, but shouldn't a forced modeline work around that?
<bryceh_> I'm going to have him connect the monitor to a known good setup to collect the correct edid and modeline
<RAOF> bryceh_: Depends; My LCD display with broken EDID hardware doesn't get detected as *connected* unless I force an edid.
<RAOF> So a modeline doesn't help for my display, but faking an edid does.
<bryceh_> hmm, ok
<bryceh_> one other weird thing is that he assures me this setup had been working up until recently, without need for modeline forcing
#ubuntu-x 2015-01-26
<mlankhorst> Sarvatt: sure hah
#ubuntu-x 2015-01-27
<hyperair> gar. monitor hotplugging is broken with compiz on xorg-edgers with i915 on an ivb
<Sarvatt> new regression?
<Sarvatt> i just updated -intel for the first time in a month yesterday
<hyperair> not sure, i just switched to xorg-edgers just the other day after i upgraded my kernel
<hyperair> 3.17.x was having issues with tf2
<hyperair> it lagged like hell
<hyperair> 3.16 was gold, but that was with trusty's stack, not utopic
 * Sarvatt updates it again, craploads of commits
<hyperair> also i'm getting the hpet hangs with 3.18
<hyperair> that odd one where the kernel locks up and doesn't respond to any sysrq key but alt+sysrq+b
<hyperair> and it seems that running any sort of 3d activity reliably causes the issue to appear
<Sarvatt> still on your gen4 intel?
<hyperair> ivb
<hyperair> yeah
<Sarvatt> oh ivb nevermind, hmm
<hyperair> er gen3
<Sarvatt> thought you had a gm45 for some reason
<hyperair> heh
<Sarvatt> was gonna say i just saw a fix for hangs on that on 3.18+ recently
<hyperair> oh you did?
<hyperair> Sarvatt: where's the fix?
<hyperair> is it after 3.18.2?
<Sarvatt> just for old gpus, not ivb, i'm on ivb and not seeing any problems
<hyperair> aw damn.
<hyperair> have you tried any heavy 3d activity recently?
<hyperair> and which kernel are you running?
<Sarvatt> 3.13 with 3.19-rc6 drm in a dkms
<hyperair> bah
<hyperair> that's an old kernel
<hyperair> doesn't count
<[4-tea-2]> Greetings, using the xorg-edgers PPA on a system with a GTX980, I've been seeing major performance issues for the past few days. Not complaining, just wondering if anybody else can confirm whether it's caused by xorg-edgers?
<Sarvatt> [4-tea-2]: the blobs were updated 10 days ago or so, that should be all thats affecting you. might want to try another series of them
<Sarvatt> 340 instead of 346 or the reverse
<[4-tea-2]> Sarvatt: thanks for the advice, I'll try that
<Sarvatt> err, 340 doesn't even support the 980 :(
<[4-tea-2]> I wasn't aware the 980 is too new. :\
#ubuntu-x 2015-01-30
<Noskcaj> How long till wayland/weston 1.6.1 will be in ubuntu? Saves me some work with the libinput transition if it's soon
<tjaalton> asking the wrong question :) it's synced from debian so should preferably go there first
<tjaalton> ah they got pushed to experimental, so needs a manual sync
<Noskcaj> tjaalton, if a patch is added in ubuntu for weston, should it be quilt or directly applied?
<Noskcaj> http://cgit.freedesktop.org/wayland/weston/commit/?id=c54f23d8df4e758f097d127df4d44d7a00059cef in this case
<tjaalton> Noskcaj: I prefer quilt
<Noskcaj> ok, there are patches by debian already directly applied though
<tjaalton> i've synced them though, is this not in 1.6.1?
<Noskcaj> 1.6.91
<tjaalton> ok
<tjaalton> well, assuming it'll get synced anyway in the future guess I don't mind how it's applied
<tjaalton> newer libinput is in debian NEW btw
<tjaalton> i also assume debian will get the new versions once libinput 0.9 is in
<tjaalton> 1.6.9x that is
#ubuntu-x 2016-02-03
<tjaalton> let's get rid of a few input drivers..
#ubuntu-x 2016-02-04
<furkan> tjaalton: any suggestion on how i can debug my keyboard issue?
<furkan> it is a regression, so any packages that i could downgrade?
<furkan> i tried the kernel and that wasn't it, i'm not sure what else i should try
<furkan> i was going to try unity-settings-daemon but couldn't find out how to get an old package
<tjaalton> furkan: launchpad has them
<tjaalton> or the archive
<mamarley> ricotz: I uploaded new versions of the 340 and 352 drivers that contain tseliot1's bugfix for https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-352/+bug/1540896 (along with the new EGL stuff) to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.
<ubottu> Launchpad bug 1540896 in nvidia-graphics-drivers-352-updates (Ubuntu Trusty) "Always load all the nvidia modules" [Undecided,In progress]
<mamarley> (And this time, I compressed all my changes into a single changelog entry and used the "+" in the version number where applicable.)
<tseliot1> mamarley: well done, I was about to ping you to tell you about that :)
<ricotz> mamarley, I see
<ricotz> tseliot1, I am wondering why this is not officially uploaded to xenial?
<tseliot1> ricotz: what do you mean?
<ricotz> the EGL related fixes
<tseliot1> ricotz: they are in my local 361 branch. I was hoping to upload those changes together with the new driver
<ricotz> so why is there still a delta
<tseliot1> ricotz, mamarley: I can backport and upload this, if it can make things easier for you guys:  http://paste.ubuntu.com/14877693/
<tseliot1> otherwise it will land directly with the 361 series
<mamarley> tseliot1: Backport it to the previous drivers versions in Xenial?
<tseliot1> mamarley: 352
<mamarley> (Also, do you have the other change that adds the alternative installation commands for EGL stuff?)
<mamarley> tseliot1: Yes, it probably would make it easier on us so we wouldn't be maintaining different code.  We wouldn't have to re-upload if you uploaded the same version we had already uploaded.
<tseliot1> mamarley: yes, this one http://paste.ubuntu.com/14877750/
<tseliot1> ok, I can do that
<mamarley> tseliot1: The changes in *.in in that patch are specific to the 361 series.
<tseliot1> mamarley: yes, I would have to separate the library stuff, as I did for the udev rule when I backported that to 352
<mamarley> OK.  Also, you may have already noticed, but those symlink changes in 361 only happened for i386 and amd64, which causes the armhf driver to FTBFS.
<tseliot1> mamarley: I haven't uploaded that yet, so, no, I hadn't noticed. Do you already have a patch for that, or shall I write one?
<mamarley> tseliot1: I didn't know of a clean way to fix it, so I didn't do anything to it yet.
<tseliot1> mamarley: ok, I think I dealt with something similar in the past
<ricotz> tseliot1, you mean waving an angry fist to nvidia for not keeping the installation layout in sync ;)
<tseliot1> ricotz: :D
<tseliot1> I can do that :P
<ricotz> heh
#ubuntu-x 2016-02-05
<tseliot> mamarley, ricotz: I've just uploaded 352 and 352-updates in xenial. The diff should be zero now (I hope)
<ricotz> tseliot, thanks!
<tseliot> :)
#ubuntu-x 2017-01-30
<ricotz> mamarley, hmm, I see, while zesty will get 4.10 a patch or a new nvidia release will be needed at some point
<mamarley> It seems to be working properly for me so far.  I don't think most x86 systems use CPU hotplugging, but in any case I don't have the skills or equipment necessary to fix or test the CPU hotplugging support in the driver.
<ricotz> ok
<mamarley> I also made a patch for 340, but it too doesn't have proper CPU hotplugging support.
#ubuntu-x 2017-02-02
<ricotz_> mamarley, hi, is your 4.10 patch any different from https://gist.github.com/tpruzina/c8b06270dc08adb6054df449bebfe7e3 ?
<mamarley> ricotz_: It is the same as that one, except the file paths are different.
<mamarley> My 340 patch is also based on that one with a bunch of extra stuff that I did myself.
<ricotz_> ok, so no difference ;)
<mamarley> Yep.  I figured why waste time doing it myself if I could just use what someone else already did?  It is open-source after all.
<ricotz_> with 4.10-rc6 it seems safe to give this a try on this machine
<ricotz_> yeah, that is fine with referencing it properly
<mamarley> Yeah, 378 is running fine for me on two boxes and 340 on one box, both with 4.10-rc6.
<ricotz_> good
#ubuntu-x 2018-01-29
<soee> mamarley: new driver ?
<soee> 390.25 that is
<tjaalton> always impatient?
<ricotz> (literally not even 30 mins ago)
<mamarley> soee: Sure, I will package it.
<mamarley> tjaalton: It's really OK, if he tells me when the new driver is released, I don't have to constantly poll to see when it is released.
 * mamarley is a software crack addict too, which is how he got to be on the GPU driver team in the first place.
<ricotz> haha
<tjaalton> fair enough
<mamarley> soee: ricotz: 390.25 is up in the normal staging PPA.
<ricotz> mamarley, nice, thanks
#ubuntu-x 2018-01-30
<soee> mamarley: thanks :)
#ubuntu-x 2019-01-30
<soee_> mamarley: what was your ppa with latest drivers builds?
<mamarley> soee_: ppa:mamarley/staging, but 318.30 isn't there quite yet. :(
<soee_> mamarley: ok than im waiting :) Any problems with this version (to package)?
<mamarley> I also wouldn't recommend leaving that one enabled, because sometimes I upload completely untested stuff there that might break your system.
<soee> mamarley: https://i.imgur.com/QXKnj27.png :)
#ubuntu-x 2019-02-02
<mamarley> ricotz: 318.30 is in the normal spot.  Somewhat surprisingly, this release adds support for Linux 5.0-rc without any patches.
<mamarley> I also have patches for 340, 396, and 315, but I haven't packaged those yet.
