#ubuntu-x 2007-04-02
<ubotu> New bug: #99961 in xrdb (main) "[apport]  xrdb crashed with SIGFPE" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99961
<ubotu> New bug: #69322 in linux-source-2.6.17 (main) "Touchpad freezes on Acer Aspire 1500, making X unusable. (dup-of: 34501)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/69322
<ubotu> New bug: #100036 in xserver-xorg-video-savage (main) "Mouse cursor craeates artifacts" [Undecided,Unconfirmed]  https://launchpad.net/bugs/100036
<ubotu> New bug: #40617 in linux-restricted-modules-2.6.15 (restricted) "After installing nvidia-glx text mode terminal became unavailable" [Medium,Unconfirmed]  https://launchpad.net/bugs/40617
<ubotu> New bug: #96099 in linux-restricted-modules-2.6.20 (restricted) "linux-image-2.6.20-13 is available but linux-restricted-modules-2.6.20-13 is not available" [Undecided,Fix released]  https://launchpad.net/bugs/96099
<ubotu> New bug: #18608 in xserver-xorg-input-acecad (universe) "Ace Cad graphics tablets not supported" [Medium,Rejected]  https://launchpad.net/bugs/18608
<tepsipakki> Mithrandir: about wacom-tools et al.. I've packaged upstream 0.7.7-7 which is reported to work/compile with 2.6.20 (the stable release 0.7.6-4 didn't)
<tepsipakki> hotplug doesn't work, but it hasn't worked before either
<tepsipakki> bug 69163
<tepsipakki> bug #69163
<tepsipakki> bah
<tepsipakki> ubotu is busy
<tepsipakki> oh, and the current version we have (0.7.2) doesn't work either (the driver does not load), but the reason is most likely that the previous (ancient) build didn't use SSP-capable gcc, so building with -fno-stack-protector should make it work too
<tepsipakki> https://bugs.launchpad.net/ubuntu/+source/wacom-tools/+bug/69163
<tepsipakki> I went through the diff.gz and it had only autoreconf- and po-stuff in it
<Mithrandir> can you get it tested?
<tepsipakki> there are three people who have tested it
<tepsipakki> so far
<tepsipakki> actually, hotplugging a tablet on current feisty apparently freezes the machine, according to one report
<tepsipakki> but I'll wait for more testers
<Mithrandir> ouch
<Mithrandir> they've tested 0.7.7?
<tepsipakki> yes
<tepsipakki> there is one bug in the wacom-kernel-source.postinst, but easy to fix
<tepsipakki> and harmless as it is
<tepsipakki> +pretty
<Mithrandir> ok
<Mithrandir> please get it uploaded then
<tepsipakki> thank you
<tepsipakki> I'll also change the device path to a more working one (/dev/wacom -> /dev/input/wacom), sanctioned by mjg59
<tepsipakki> then usb-tablets work out-of-the-box, not forgetting the serial ones. Compatibility symlink is used in /dev/wacom
<tepsipakki> by a udev-rule
<Mithrandir> can you also get the new libx11-6 sans xcb in?
<Mithrandir> ok, sweet
<tepsipakki> sure, soon
<Mithrandir> can you try to get it done today?
<tepsipakki> yes, hence "soon" :)
<Mithrandir> "soon" can mean lots of things; thanks a lot. :-)
<tepsipakki> heh, should've said "ASAP" :P
<seb128> I'll do it now
<tepsipakki> libx11?
<seb128> tepsipakki: usually location?
<tepsipakki> seb128: I can upload nowadays :)
<seb128> tepsipakki: you can upload, or you need sponsor?
<seb128> ah, alright
<seb128> rock on ;)
<tepsipakki> I can upload it in a minute, having a conversation with the unichrome (VIA) maintainer
<tepsipakki> after that is done it's time for some uploads
<crimsun> tepsipakki: how do you feel about an xserver-xorg-video-i810-modesetting sync from experimental?
<tepsipakki> crimsun: I've packaged -intel 1.9.93, does that suffice?-)
<crimsun> tepsipakki: meaning it'll go into feisty? if so, sure!
<tepsipakki> would you like to try?
<crimsun> yep, I'm happy to test
<tepsipakki> +it
<tepsipakki> there's i386 deb at http://users.tkk.fi/~tjaalton/dpkg
<tepsipakki> one regression is that after a logout it blanks the screen, but a restart seems to fix that
<tepsipakki> maybe it changed the output port
<tepsipakki> that is basically the experimental version plus our changes
<tepsipakki> libx11 uploaded
<crimsun> tepsipakki: right, symptom confirmed here
<crimsun> it's still a massive step forward in terms of stability and features over the current feisty -i810-modesetting
<tepsipakki> ok, maybe we should just upload that one, and track upstream the following few weeks.. Mithrandir?
<tepsipakki> the current -modesetting is crap, I know
<Mithrandir> tepsipakki: we are releasing in about 2.5 weeks.
<tepsipakki> s/few weeks/next week/ :P
<tepsipakki> the current -modesetting is a git-checkout from october
<Mithrandir> it's universe, ask motu-uvf. :-P
<Mithrandir> but probably, yes.
<tepsipakki> oh, right.. didn't think of that
<kylem> +1
<seb128> tepsipakki: could you have a look at http://lists.freedesktop.org/archives/xorg/2007-March/022423.html ?
<seb128> tepsipakki: that would make some GNOME guy really happy ;)
<tepsipakki> seb128: what does it do in practice?-)
<seb128> tepsipakki: not sure, desrt (a GNOME guy) is working on real composite,etc and he said that would be really nice if we can get that change
<seb128> brb, rebooting to try something
<tepsipakki> kylem: it seems that the wacom kernel module is included with our kernel sources
<tepsipakki> it seems to be v1.46.. I'll check what the new wacom-tools has
<tepsipakki> oh
<tepsipakki> it's upstream :)
<tepsipakki> included in vanilla
<tepsipakki> same version as in wacom-tools
<tepsipakki> maybe I'll add a disclaimer to the package description as with ndiswrapper
<tepsipakki> seb128: that patch you mentioned isn't committed upstream yet
<seb128> avr 02 16:20:15 <desrt> keith refactored and posted a new version of the patch
<seb128> avr 02 16:20:32 <desrt> the new one is the one that's going into xorg 1.3 and won't work with feisty's xserver
<seb128> avr 02 16:20:44 <desrt> there are some missing constants in headerfiles or something
<seb128> tepsipakki: I'll have a look later on it
<tepsipakki> ok, thanks
<seb128> np
<ubotu> New bug: #99761 in xorg (main) "Server X crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99761
<ubotu> New bug: #22537 in wacom-tools (main) "xsetwacom can't set parameters" [Medium,Needs info]  https://launchpad.net/bugs/22537
<ubotu> New bug: #84991 in linux-restricted-modules-2.6.20 "Resume from suspend fails with FGLRX" [Undecided,Confirmed]  https://launchpad.net/bugs/84991
<ubotu> New bug: #101984 in linux-restricted-modules-2.6.20 (restricted) "firegl_public.c: Ubuntu modification uses obsolete __syscall_return " [Undecided,Unconfirmed]  https://launchpad.net/bugs/101984
<ubotu> New bug: #30766 in linux-restricted-modules-2.6.17 (restricted) "[acx111]  default firmware not working for acx d-link dwl-g650+" [Medium,Fix committed]  https://launchpad.net/bugs/30766
<ubotu> New bug: #45162 in linux-restricted-modules-2.6.15 (restricted) "Wrong acx111 PCI default firmware for DWL-G520+" [High,Fix released]  https://launchpad.net/bugs/45162
<ubotu> New bug: #102018 in xorg (main) "[Needs-packaging]  lbxproxy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102018
<ubotu> New bug: #102032 in xorg-server (main) "X server crashes with autologin and screensaver when GLX is enabled" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102032
<ubotu> New bug: #102103 in xorg-server (main) "dual monitor mouse cursor type "sticking" between monitors" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102103
<ubotu> New bug: #102115 in xserver-xorg-video-unichrome (universe) "[UVFe]  new upstream snapshot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102115
#ubuntu-x 2007-04-03
<ubotu> New bug: #86440 in linux-restricted-modules-2.6.20 (restricted) "Current nvidia driver in feisty restricts screen resolution" [Undecided,Needs info]  https://launchpad.net/bugs/86440
<ubotu> New bug: #102144 in xserver-xorg-video-i810 (main) "intel 950 graphics media accelerator - wrong resolution" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102144
<ubotu> New bug: #102170 in xrandr (main) "[apport]  xrandr crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102170
<ubotu> New bug: #102205 in xorg-server (main) "Xorg crashed - one of many" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102205
<tepsipakki> kylem: I assigned bug 99251 to the kernel team
<ubotu> Malone bug 99251 in linux-source-2.6.20 "S3 3D support broken in Feisty" [Undecided,Confirmed]  https://launchpad.net/bugs/99251
<tepsipakki> something in the drm-code has broken it, apparently
<tepsipakki> it used to work not too long ago
<Mithrandir> tepsipakki: any ideas about bug #99288?
<ubotu> Malone bug 99288 in xserver-xorg-video-ati "Screen corruption on Radeon Mobility M7 LW [Radeon Mobility 7500] " [High,Unconfirmed]  https://launchpad.net/bugs/99288
<tepsipakki> oh, that one... no ideas yet, sorry
<tepsipakki> there's a new upstream prerelease, I'll go through the commits in that one to see if there are interesting patches merged
<tepsipakki> I could make a package for Matt to test if the new one fixes something, and then search for the fix
<Mithrandir> thanks.
<Mithrandir> if you could, that'd be wonderful
<Mithrandir> I guess I could test with that radeon 7500 I have lying about here.
<tepsipakki> http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=shortlog;h=ati-6.6.191
<tepsipakki> the shortlog is quite hefty :)
<tepsipakki> I made a new x-x-v-unichrome last night, and filed a UVFe (it's in universe)
<Mithrandir> coolie
<tepsipakki> bbl ->
<ubotu> New bug: #49834 in xorg (restricted) "Writing to the gtk textview buffer crashes xorg" [Undecided,Rejected]  https://launchpad.net/bugs/49834
<tepsipakki> ok, xserver-xorg-video-ati_6.6.191-1ubuntu1 available at http://users.tkk.fi/~tjaalton/dpkg
<Mithrandir> ask mdz to test it?
<tepsipakki> yes
<tepsipakki> I'll test it myself first :)
<tepsipakki> the new ati works for me
<tepsipakki> intel uploaded
<tepsipakki> I'll be back in 6h ->
<ubotu> New bug: #102130 in xorg (main) "liveCD fails to boot (xorg crash)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102130
<ubotu> New bug: #102147 in xorg (main) "intel 950 graphics media accelerator - wrong resolution" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102147
<ubotu> New bug: #102295 in xrandr (main) "[apport]  xrandr crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102295
<ubotu> New bug: #87643 in linux-restricted-modules-2.6.20 (restricted) "fglrx in linux-restricted-modules-2.6.20-8-generic updated to version > 8.28.8 doesn't support old video cards (dup-of: 85907)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87643
<ubotu> New bug: #83145 in linux-restricted-modules-2.6.20 (restricted) "Older ATI Radeons not supported from fglrx driver above 8.28.8" [Undecided,Rejected]  https://launchpad.net/bugs/83145
<ubotu> New bug: #85426 in evince (main) "Feisty's Evince's hotkeys borked (with Finnish locale) (dup-of: 23244)" [Low,Rejected]  https://launchpad.net/bugs/85426
<ubotu> New bug: #86300 in evince (main) "evince zoom shortcut key problems (dup-of: 23244)" [Low,Rejected]  https://launchpad.net/bugs/86300
<ubotu> New bug: #86541 in evince (main) "can't search for strings containing dash in evince (dup-of: 23244)" [Low,Rejected]  https://launchpad.net/bugs/86541
<ubotu> New bug: #88554 in linux-restricted-modules-2.6.20 (restricted) "Prism54 module disable usb ports when i plug my usb wireless card" [Undecided,Confirmed]  https://launchpad.net/bugs/88554
<ubotu> New bug: #94148 in linux-restricted-modules-2.6.20 (restricted) "atheros wifi card drop connection and low signal" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94148
<ubotu> New bug: #99249 in linux-restricted-modules-2.6.20 (restricted) "[feisty beta]  totem-xine faults when playing music files with graphic effects activated" [Medium,Unconfirmed]  https://launchpad.net/bugs/99249
<ubotu> New bug: #102500 in xorg (main) "resolution ati only 1024x768x60" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102500
<tepsipakki> hm, maybe xrdb needs a rebuild against xorg-7.2
<tepsipakki> a security update to libx11..
<ubotu> New bug: #101922 in xserver-xorg-video-intel (universe) "[UVFe]  a new version of the driver" [Medium,Fix released]  https://launchpad.net/bugs/101922
<crimsun> thanks for 1.9.94!
<tepsipakki> heh, it's still in NEW
<tepsipakki> and it's .93
<crimsun> just read the commits run across debian-x (I'm backlogged due to spam)
<tepsipakki> oh..
<tepsipakki> I'll do .94 then
<tepsipakki> didn't notice they already did .94 :)
<tepsipakki> ok, .94 uploaded
<ubotu> New bug: #102558 in Ubuntu "Turning on touchpad opens KHelpCenter (dup-of: 91056)" [Undecided,Confirmed]  https://launchpad.net/bugs/102558
#ubuntu-x 2007-04-04
<ubotu> New bug: #102625 in mesa (main) "[apport]  glxinfo crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102625
<ubotu> New bug: #102462 in xorg (main) "fatal server error while booting from live cd" [Undecided,Needs info]  https://launchpad.net/bugs/102462
<ubotu> New bug: #95580 in linux-restricted-modules-2.6.20 (restricted) "[apport]  glxinfo crashed with SIGSEGV on x-server login (dup-of: 96663)" [Medium,Confirmed]  https://launchpad.net/bugs/95580
<ubotu> New bug: #95979 in xorg (main) "Error in xorg.conf 1440x900 resolution" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95979
<ubotu> New bug: #102618 in compiz (main) "[apport]  compiz.real crashed with SIGSEGV in viaGetLock() (dup-of: 90850)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102618
<ubotu> New bug: #102683 in xorg (main) "xorg won't start on nvida 6600 card due to nv driver not supporting 6600's" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102683
<ubotu> New bug: #102685 in Ubuntu "HP dv6000 series touchpad lock button spawns "KDE Help Center - Start Page" on unlock (dup-of: 91056)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102685
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #33413 in xorg (main) "X11 crash when mouse is pointed to /dev/ttyS0" [Medium,Needs info]  https://launchpad.net/bugs/33413
<ubotu> New bug: #102735 in linux-restricted-modules-2.6.20 (restricted) "[apport]  compiz.real crashed with SIGSEGV in _nv000044gl()" [Medium,Unconfirmed]  https://launchpad.net/bugs/102735
<ubotu> New bug: #102757 in linux-restricted-modules-2.6.20 (restricted) "wlan led changes between on and blinking when wlan is disabled" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102757
<tepsipakki> x-x-v-intel is sitting in NEW
<tepsipakki> hey seb128 
<seb128> hi tepsipakki
<seb128> tepsipakki: thanks for the ati fix ;)
<tepsipakki> yep, it wasn't that hard to find, when you have #xorg-devel ;)
<seb128> :)
<tepsipakki> shouldn't bug 61746 warrant a SRU?
<ubotu> Malone bug 61746 in xorg-server "Xorg exits when it receives an ACPI button/lid event" [High,Confirmed]  https://launchpad.net/bugs/61746
<tepsipakki> causes loss of user data
<tepsipakki> subscribed ubuntu-sru to that bug
<ubotu> New bug: #102875 in libx11 (main) "Opera no more function today 4april (dup-of: 102851)" [Undecided,Confirmed]  https://launchpad.net/bugs/102875
<ubotu> New bug: #102925 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx upgrade to 1.0-9755 uncompatible with GeForce4 MX 440 on feisty (dup-of: 96430)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102925
<ubotu> New bug: #92835 in linux-restricted-modules-2.6.20 (restricted) "Suspend/Hibernate doesn't work with nvidia-glx." [Undecided,Confirmed]  https://launchpad.net/bugs/92835
<ubotu> New bug: #102119 in xorg (main) "Xserver dosn't start at boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102119
<ubotu> New bug: #103050 in linux-restricted-modules-2.6.20 (restricted) "Xorg fails to start requesting libwfb when using packaged NVIDIA drivers" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103050
<ubotu> New bug: #102329 in restricted-manager "Nvidia restricted driver disappeared from restricted-manager (dup-of: 93209)" [Undecided,Needs info]  https://launchpad.net/bugs/102329
<ubotu> New bug: #103035 in xorg (main) "ATI driver sets rez to 1024x768, if I change xorg to 1280 it forces 95hz refresh" [Undecided,Needs info]  https://launchpad.net/bugs/103035
<ubotu> New bug: #102903 in xorg (main) "Monitor MD6155AJ not recognized" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102903
<ubotu> New bug: #98999 in xorg (main) "[Edgy]  - hangs, windows become unresponsive" [Undecided,Needs info]  https://launchpad.net/bugs/98999
<ubotu> New bug: #102396 in xorg (main) "screen not updated for playing videos when composite is enabled" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102396
<ubotu> New bug: #96298 in xorg (main) "[feisty]  gnome does not recognise twinview anymore" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96298
#ubuntu-x 2007-04-05
<ubotu> New bug: #62163 in control-center "variables from the session are not defined" [High,Confirmed]  https://launchpad.net/bugs/62163
<ubotu> New bug: #96473 in linux-restricted-modules-2.6.20 (main) "nvidia-glx with Geforce go 7200: after 5/6 windows opens: window content is black!" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96473
<ubotu> New bug: #103099 in xorg (main) "[feasty beta]  X.org doesn't work in "Desktop" CD" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103099
<ubotu> New bug: #103090 in compiz (main) "[apport]  compiz.real crashed with SIGSEGV in savageGetLock() (dup-of: 81889)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103090
<ubotu> New bug: #96037 in xorg (main) "Custom screen resolution 1280x768" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96037
<ubotu> New bug: #101860 in linux-source-2.6.20 (main) "Kernel driver bug with a prism54 usb key (dup-of: 88554)" [Undecided,Confirmed]  https://launchpad.net/bugs/101860
<ubotu> New bug: #102768 in xorg (main) "nvidia + xorg + 7.04 no X !" [Undecided,Needs info]  https://launchpad.net/bugs/102768
<ubotu> New bug: #103118 in linux-restricted-modules-2.6.20 (restricted) "Nvidia kernel module not receiving interrupts  from graphics device" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103118
<ubotu> New bug: #102672 in xorg (main) "ThinkPad T20 LCD 1024x768 resolution not supported" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102672
<ubotu> New bug: #97031 in gstreamer0.10 (main) "Wrong colors in video-files with gstreamer on ATI (dup-of: 73102)" [Medium,Unconfirmed]  https://launchpad.net/bugs/97031
<ubotu> New bug: #95548 in xorg (main) "Feisty Beta doesn't correctly configure monitor" [Undecided,Needs info]  https://launchpad.net/bugs/95548
<ubotu> New bug: #94739 in linux-restricted-modules-2.6.20 (restricted) "Frequent lockups when NV 3d enabled" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94739
<ubotu> New bug: #103190 in xorg (main) "Xorg needs 20 % cpu power" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103190
<tepsipakki> bah, the patch for the radeon UYVY overlay bug doesn't apply without applying a set of other patches
<tepsipakki> practically making radeon_video.c the same as in head
<ubotu> New bug: #51032 in xorg (main) "Dapper doesn't use the right settings for monitor Philips 109P4" [Undecided,Rejected]  https://launchpad.net/bugs/51032
<ubotu> New bug: #103281 in mesa (main) "[apport]  glxinfo crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103281
<ubotu> New bug: #103289 in xkeyboard-config (main) "New Georgian keyboard layouts and enhancements" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103289
<ubotu> New bug: #51026 in xorg (main) "Beginning of lines truncated in virtual terminal" [Undecided,Needs info]  https://launchpad.net/bugs/51026
<ubotu> New bug: #103013 in xorg (main) "LiveCD fails to configure X.org correctly under image ratios different of 4:3" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103013
<ubotu> New bug: #103223 in xorg (main) "X doesn't load in Feisty (nVidia FX5500 PCI)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103223
<ubotu> New bug: #34298 in xserver-xorg-video-nv (main) "1600x1200 resolution not offered though hardware supports it" [Low,Needs info]  https://launchpad.net/bugs/34298
<ubotu> New bug: #38055 in xserver-xorg-video-nv (main) "Low resolution with Geforce MX cards" [Medium,Needs info]  https://launchpad.net/bugs/38055
<ubotu> New bug: #45797 in xserver-xorg-video-nv (main) "Graphics corrupt and freeze on boot" [Medium,Needs info]  https://launchpad.net/bugs/45797
<ubotu> New bug: #55586 in xserver-xorg-video-nv (main) "NVidia 7600GT + default nv driver always crashes video players on AMD64, binary driver works fine" [Undecided,Needs info]  https://launchpad.net/bugs/55586
<ubotu> New bug: #45651 in xserver-xorg-video-nv (main) "nVidia GeForce 2 MX400 does not work with the nv driver" [Medium,Rejected]  https://launchpad.net/bugs/45651
<ubotu> New bug: #17786 in xserver-xorg-video-nv (main) "nv driver can't use dpms on GeForce FX Go 5200" [Medium,Rejected]  https://launchpad.net/bugs/17786
<ubotu> New bug: #101958 in mesa (main) "[apport]  soffice.bin crashed with SIGILL" [Undecided,Unconfirmed]  https://launchpad.net/bugs/101958
<ubotu> New bug: #102207 in linux-restricted-modules-2.6.20 (restricted) "Desktop Effects fails. Reports composite extenson not available." [Undecided,Rejected]  https://launchpad.net/bugs/102207
<ubotu> New bug: #102587 in restricted-manager (main) "restricted-manager reports "Your hardware does not need any restricted drivers." (dup-of: 93209)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102587
<ubotu> New bug: #50858 in xserver-xorg-input-synaptics (main) "Erratic behavior of tapping" [Undecided,Fix committed]  https://launchpad.net/bugs/50858
<ubotu> New bug: #91292 in linux-restricted-modules-2.6.20 (restricted) "Resolutions lost on upgrade from Edgy to Feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91292
<ubotu> New bug: #102988 in mesa (main) "[apport]  glxgears crashed with SIGSEGV in __ctype_b_loc()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102988
<ubotu> New bug: #102894 in xorg (main) "No graphical shutdown screen and 'Inappropriate ioctl for device' error on shutdown in Feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102894
<ubotu> New bug: #102858 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV in _dl_tls_get_addr_soft()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102858
<ubotu> New bug: #99122 in linux-restricted-modules-2.6.20 (restricted) "nvidia.ko not found" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99122
<ubotu> New bug: #3198 in mesa (main) "[radeon, savage]  Starwars screensaver locks X" [Medium,Confirmed]  https://launchpad.net/bugs/3198
<ubotu> New bug: #85800 in debconf (main) "debconf error on upgrade install [feisty]  (dup-of: 68267)" [Undecided,Confirmed]  https://launchpad.net/bugs/85800
<ubotu> New bug: #99291 in restricted-manager "fails to detect nVidia GeForce Go 6100 (dup-of: 93209)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99291
<ubotu> New bug: #99371 in restricted-manager (main) "non-free driver manager install the wrong driver (dup-of: 93209)" [Undecided,Needs info]  https://launchpad.net/bugs/99371
<ubotu> New bug: #102737 in compiz (main) "[apport]  compiz.real crashed with SIGSEGV in savageGetLock() (dup-of: 81889)" [Medium,Unconfirmed]  https://launchpad.net/bugs/102737
<ubotu> New bug: #103344 in earth3d (universe) "[apport]  earth3d crashed with SIGSEGV in viaGetLock() (dup-of: 90850)" [Medium,Rejected]  https://launchpad.net/bugs/103344
<ubotu> New bug: #37225 in xkeyboard-config (main) "asus multimedia hotkeys not handled" [Medium,Confirmed]  https://launchpad.net/bugs/37225
<ubotu> New bug: #103300 in compiz (main) "compiz causes white, glitchy desktop (dup-of: 91850)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103300
<ubotu> New bug: #103321 in xorg (main) "Kubuntu/Feisty Beta - Live cd stops hangs during boot" [Undecided,Needs info]  https://launchpad.net/bugs/103321
<ubotu> New bug: #103400 in linux-restricted-modules-2.6.20 (restricted) "compiz freezes x server after screensaver kicks in" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103400
<ubotu> New bug: #66281 in xserver-xorg-video-intel (universe) "compiz very slow on i945 (edgy)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/66281
<ubotu> New bug: #69309 in xserver-xorg-video-intel (universe) "only one video mode available (1440x900)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/69309
<ubotu> New bug: #103431 in linux-restricted-modules-2.6.20 (restricted) "bcm43xx fails to initialize properly during boot process, causing a long boot pause" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103431
<ubotu> New bug: #103382 in xorg (main) "The 1680x1050 is not supported (only 1400x1050)" [Undecided,Needs info]  https://launchpad.net/bugs/103382
<ubotu> New bug: #103500 in xkeyboard-config (main) "[can-not-install]  file overwrite error" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103500
#ubuntu-x 2007-04-06
<ubotu> New bug: #103562 in linux-restricted-modules-2.6.20 (restricted) "slow boot on last update" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103562
<ubotu> New bug: #103566 in restricted-manager (main) "Restricted manager shows Ti4600 as legacy card (dup-of: 96430)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103566
<ubotu> New bug: #103008 in xorg (main) "X crashes on any graphical acceleration" [Undecided,Needs info]  https://launchpad.net/bugs/103008
<ubotu> New bug: #103605 in xorg (main) "PCI video card not addressed correctly for X" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103605
<ubotu> New bug: #103545 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx doesn't work with GF 8800 in Feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103545
<ubotu> New bug: #103671 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103671
<ubotu> New bug: #103675 in linux-restricted-modules-2.6.20 (restricted) "nvidia on feistyfawn requires -386 kernel" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103675
<ubotu> New bug: #103603 in xorg (main) "X server at 100% CPU" [Undecided,Needs info]  https://launchpad.net/bugs/103603
<ubotu> New bug: #16686 in xorg (main) "regression: radeon DRI and SMP is bad" [Medium,Needs info]  https://launchpad.net/bugs/16686
<ubotu> New bug: #103813 in linux-restricted-modules-2.6.20 (restricted) "AIGLX with fglrx fails to initialize DRI (undefined symbol)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103813
<ubotu> New bug: #103816 in xorg (main) "xvmc extension missing?" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103816
<ubotu> New bug: #49358 in xkeyboard-config "the layout ca(multix) is broken" [Low,Confirmed]  https://launchpad.net/bugs/49358
<ubotu> New bug: #28852 in xorg (main) "Dapper 3: Screen resolution not "stable"" [Medium,Needs info]  https://launchpad.net/bugs/28852
<ubotu> New bug: #29399 in xorg (main) "change of screen resolution does not work" [Medium,Confirmed]  https://launchpad.net/bugs/29399
<ubotu> New bug: #48289 in xorg (main) "Gnome desktop screen is offset to the right by 1/2 Icon" [Medium,Needs info]  https://launchpad.net/bugs/48289
<ubotu> New bug: #103839 in xserver-xorg-video-trident (main) "totem crashes entire machine, leaves black screen with garbage." [Undecided,Unconfirmed]  https://launchpad.net/bugs/103839
<ubotu> New bug: #34527 in xorg (main) "Philips 105MB monitor improperly detected" [Low,Needs info]  https://launchpad.net/bugs/34527
<ubotu> New bug: #103862 in linux-restricted-modules-2.6.20 (restricted) "OpenOffice and F-Spot don't launch if installed xorg-driver-fglrx" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103862
<ubotu> New bug: #103897 in linux-restricted-modules-2.6.20 (restricted) "No appropriate and up-to-date drivers for GeForce 3-4" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103897
<ubotu> New bug: #103902 in xserver-xorg-input-evdev (main) "X crashes when using evdev: undefined symbol xf86OSRingBell" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103902
#ubuntu-x 2007-04-07
<ubotu> New bug: #87775 in linux-restricted-modules-2.6.20 (restricted) "[feisty]  modprobe vmdesched fails with unknown symbol" [Undecided,Confirmed]  https://launchpad.net/bugs/87775
<ubotu> New bug: #103806 in xorg (main) "It is impossible to install ATI drivers, and to activate desktop effects in 7,04 on my iMac Core Duo" [Undecided,Confirmed]  https://launchpad.net/bugs/103806
<ubotu> New bug: #103945 in xorg (main) "desktop cd fails to start gdm with hp nc6400 (widescreen, ati-based laptop)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103945
<ubotu> New bug: #103971 in xorg-server (main) "xorg: cvt not packaged." [Undecided,Unconfirmed]  https://launchpad.net/bugs/103971
<ubotu> New bug: #103884 in xorg (main) "Weird Colors on Nividia second DVI" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103884
<ubotu> New bug: #96195 in Ubuntu "touchpad cursor  "jumps" (dup-of: 34501)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96195
<ubotu> New bug: #96596 in linux-source-2.6.20 (main) "'psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1' (dup-of: 34501)" [Undecided,Confirmed]  https://launchpad.net/bugs/96596
<ubotu> New bug: #96240 in linux-restricted-modules-2.6.20 (restricted) "blank screen when coming back from suspend" [Undecided,Confirmed]  https://launchpad.net/bugs/96240
<ubotu> New bug: #95926 in linux-restricted-modules-2.6.20 (restricted) "Desktop effects freeze when switching user" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95926
<ubotu> New bug: #50217 in xhost (main) "xhost: does not work" [Undecided,Confirmed]  https://launchpad.net/bugs/50217
<ubotu> New bug: #104168 in xorg-server (main) "Segfault at logout in libramdac.so(xf86SetCursor+0x10a)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104168
<ubotu> New bug: #104180 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV in memcpy()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104180
<ubotu> New bug: #104188 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV in memcpy()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104188
<ubotu> New bug: #18605 in xorg-driver-synaptics (main) "Touchpad doesn't tap-to-click anymore after suspend" [Medium,Confirmed]  https://launchpad.net/bugs/18605
<ubotu> New bug: #104213 in xorg (main) "X server ignores screen resolutions in xorg.conf" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104213
<ubotu> New bug: #104036 in xserver-xorg-input-keyboard (main) "`~ keyboard keys misbehave in xorg" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104036
#ubuntu-x 2007-04-08
<ubotu> New bug: #104286 in linux-restricted-modules-2.6.20 (restricted) "[nvidia]  no xvideo on primary head" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104286
<ubotu> New bug: #104292 in xorg-server (main) "crazy mouse pointer in last update to xserver-xorg-core_1%3a1.0.2-0ubuntu10.6_i386" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104292
<ubotu> New bug: #55648 in xorg "LCD panel won't stay powered off (dup-of: 71368)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/55648
<ubotu> New bug: #104360 in compiz (main) "When using compiz on ATI Radeon 9600 videocard, contents of all windows is not visible and desktop cube is not working.  (dup-of: 89189)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104360
<ubotu> New bug: #104416 in xorg (main) "Computer reboots when running Secon Life" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104416
<ubotu> New bug: #104424 in linux-restricted-modules-2.6.20 (restricted) "Must upgrade fglrx for beryl/compiz/desktop effects/etc." [Undecided,Unconfirmed]  https://launchpad.net/bugs/104424
<ubotu> New bug: #53228 in xserver-xorg-video-ati (main) "Reproduceble X crash" [Undecided,Needs info]  https://launchpad.net/bugs/53228
<ubotu> New bug: #92532 in xserver-xorg-video-v4l (main) "xserver-xorg-video-v4l - Genius VideoCam Express V2 messed up in Kubuntu Feisty Herd5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92532
<ubotu> New bug: #52144 in xorg (main) "Command: "X -configure" " [Undecided,Needs info]  https://launchpad.net/bugs/52144
<ubotu> New bug: #104481 in xorg (main) "Xorg server up to 95% of CPU" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104481
<ubotu> New bug: #104491 in xorg-server (main) "I can not use my monitor's native resolution" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104491
<ubotu> New bug: #104540 in xserver-xorg-video-i810 (main) "Dapper LTSP:glxinfo "direct rendering: No" for i810" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104540
#ubuntu-x 2008-03-31
<ubotu> New bug: #209495 in xserver-xorg-input-evdev (main) "evdev crashes x server with Microsoft Comfort Optical Mouse 3000" [Undecided,New] https://launchpad.net/bugs/209495
<ubotu> New bug: #194848 in xorg-server (main) "hardy alpha 5 closes session after choose keyboard" [Undecided,Confirmed] https://launchpad.net/bugs/194848
<ubotu> New bug: #209528 in xrandr "External monitor on with panel off causes screen distortion" [Undecided,New] https://launchpad.net/bugs/209528
<bryce> heya
<tjaalton> howdy
<ubotu> New bug: #207765 in ubiquity (main) "Install crashes on partitioning screen when brazilian portuguese language is selected during boot (dup-of: 184651)" [Undecided,New] https://launchpad.net/bugs/207765
<ubotu> New bug: #208347 in ubiquity (main) "Installer crashes if cd language is pt-br (dup-of: 184651)" [Undecided,New] https://launchpad.net/bugs/208347
<ubotu> New bug: #188431 in ubiquity (main) "Brazialin Installation Crash (dup-of: 184651)" [Undecided,Confirmed] https://launchpad.net/bugs/188431
<tjaalton> bryce: fixing bug 184651 might fix bug 205979 as well
<ubotu> Launchpad bug 184651 in xorg-server "Crash when starting gnome-settings-daemon" [High,In progress] https://launchpad.net/bugs/184651
<ubotu> Launchpad bug 205979 in xorg-server "xserver crash on exit in CloseDownDevices and SrvXkbFreeGeomRows" [Unknown,Confirmed] https://launchpad.net/bugs/205979
<tjaalton> I've got it on my git tree
<tjaalton> the latest upload fixed the issue where keys got stuck
<tjaalton> so maybe seb128 is happy now :)
<bryce> yeah I'll take a deeper look tomorrow.  Also got some various patches and stuff I need to test and get uploaded
<tjaalton> what i'd like to get fixed is the problem where the server falls back to 800x600 resolution, because it's using the default ranges (hsync 31.50-37.90, vrefresh 50-70)
<tjaalton> there are some modesetting patches upstream
<ubotu> New bug: #209568 in xserver-xorg-video-ati (main) "hard lock up with R430 X800 XL PCIe" [Undecided,New] https://launchpad.net/bugs/209568
<ubotu> New bug: #208343 in openarena "Openarena doesn't render the graphics properly (dup-of: 199823)" [Undecided,New] https://launchpad.net/bugs/208343
<ubotu> New bug: #208961 in mesa (main) "Update manager fails - From Gutsy to Hardy Beta" [High,New] https://launchpad.net/bugs/208961
<ubotu> New bug: #27293 in xkeyboard-config (main) "Problems with Default Language and Keyboard Settings" [Medium,Incomplete] https://launchpad.net/bugs/27293
<Ng> tjaalton: did you build 2.6.24-13 yourself, or is my mirror just stale?
<soren> Ng: 2.6.24-13 seems to be in the archive.
<Ng> hmm
 * Ng shrugs, I'll check back in a bit and see if apt cares about it yet :)
<tjaalton> Ng: a.u.c has it, but there are no lum/lrm packages yet, so no wifi etc :)
<Ng> ah, that'll be why apt doesn't care yet :)
<tjaalton> yes, you need to hand-pick it
<Ng> right now I need lum ;)
<tjaalton> hehe
<soren> http://people.ubuntu.com/~ubuntu-archive/madison.cgi?package=linux-image-2.6.24-13-generic&a=&c=&s=
<mvo> tjaalton: do you have a idea about bug #208961 ? the libgl1-mesa-glx failure?
<ubotu> Launchpad bug 208961 in mesa "Update manager fails - From Gutsy to Hardy Beta" [High,New] https://launchpad.net/bugs/208961
<tjaalton> mvo: hum, not really.. why would it fail even if that file was not there
<tjaalton> or does it unpack libGL.so first and tries to link it to libGL.so.1 which is not yet unpacked?
<mvo> tjaalton: that is possible, I have not looked closely yet, but it sounds pausible
<tjaalton> the logs didn't have anything about nvidia/fglrx so that's not it :)
<tjaalton> well, nvidia-kernel-common but everyone has it
<jcristau> could be a diversion gone mad
<jcristau> they tend to be made of fail
<tjaalton> yep..
 * mvo wished there would be a declarative way for diversions (instead of putting them in the maintainer scripts)
<tjaalton> mvo: maybe check if the user has had nvidia/fglrx installed at some point
<mvo> tjaalton: my personal favorite solution would be that the maintainer script would be robust enough to not fail but if needed I can try to add magic to update-manager 
<tjaalton> mvo: I think they are better now
<tjaalton> oh you mean mesa?
<mvo> yeah
<jcristau> mvo: dpkg is failing to unpack the package afaics, nothing the maint scripts can do
<tjaalton> mesa maint scripts only do ldconfig
<tjaalton> at least the one for libgl1-mesa-glx
<tjaalton> ones
<mvo> jcristau, tjaalton: right, my bad. I haven't looked close enough
<tjaalton> but the nvidia/fglrx scripts should be better now, but not something that can be fixed for released versions I think
<mvo> tjaalton, bryce: do you have any idea what might cause bug #208878 ?
<tjaalton> mvo: could be the nvidia driver playing tricks
<bryce> mvo, I've added some speculation and questions
<bryce> mvo, currently there's not enough detail in the report to really do much troubleshooting, aside from maybe browsing l-r-m for similar reports
<dennda> Hey. Are there any issues known related to Intel X3100 graphics cards and external screens? (Especially if you want to rotate the external screen)
<bryce> denna, yeah see bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/
<bryce> rotation causes lockups on some intel cards
<bryce> we need someone to do some backtraces and such to narrow in on where the problem is.
 * dennda volunteers
<dennda> Just not right now, but I would be more than happy to help fix the outstanding issues (I have, as I said, a X3100)
<dennda> bryce: just tell me what I need to do
<bryce> ok, the procedure is documented at https://wiki.ubuntu.com/DebuggingXorg; I can give more advice when you are ready to work on it
<bryce> bbiab
<dennda> Ok. That's likely to be tomorrow or the day after tomorrow
<dennda> I hope there's still enough time to get those things into hardy :)
<bryce> excellent
<bryce> even if not, the crash-on-rotate bug is important enough we can push to get it SRU'd post-release
#ubuntu-x 2008-04-01
<ubotu> New bug: #209693 in ubuntu "windows have a "red glow" with Compiz enabled (dup-of: 186382)" [Undecided,New] https://launchpad.net/bugs/209693
<ubotu> New bug: #190680 in linux-restricted-modules-2.6.24 (restricted) "openoffice corrupted display" [Undecided,New] https://launchpad.net/bugs/190680
<ubotu> New bug: #209862 in linux-restricted-modules-2.6.24 (restricted) "Compiz stopped working after update" [Undecided,Invalid] https://launchpad.net/bugs/209862
<ubotu> New bug: #209906 in xkeyboard-config (main) "t61 keyboard under Hardy (Fn, Menu, ThinkVantage keys)" [Undecided,Confirmed] https://launchpad.net/bugs/209906
<ubotu> New bug: #209945 in xorg (main) "X does not start on a Novatech 8375X" [Undecided,New] https://launchpad.net/bugs/209945
<ubotu> New bug: #209949 in xorg (main) "SHMConfig not enabled even when enabled in xorg.conf" [Undecided,New] https://launchpad.net/bugs/209949
<ubotu> New bug: #209853 in xserver-xorg-video-ati (main) "gnome-display-properties: ATI Radeon 1650, Rotate Left/Right shuts off Display" [Undecided,New] https://launchpad.net/bugs/209853
<ubotu> New bug: #209911 in wacom-tools (main) "[Hardy] Switching from one screen to another doesn't work any more" [Undecided,New] https://launchpad.net/bugs/209911
<ubotu> New bug: #209840 in wacom-tools (main) "[Hardy] It's only possible to draw dots" [Undecided,Invalid] https://launchpad.net/bugs/209840
<ubotu> New bug: #209866 in xorg (main) "X server fails on dual-head nVidia 7600" [Undecided,New] https://launchpad.net/bugs/209866
<ubotu> New bug: #209812 in linux-restricted-modules-2.6.24 (restricted) "Freezes after installation nVidia driver" [Undecided,New] https://launchpad.net/bugs/209812
<ubotu> New bug: #210176 in xresprobe (main) "[hardy] xresprobe is missing" [Undecided,Won't fix] https://launchpad.net/bugs/210176
<ubotu> New bug: #193333 in xorg-server "Kopete crashes X specially if compiz is running" [Undecided,Confirmed] https://launchpad.net/bugs/193333
<ubotu> New bug: #181386 in xorg (main) "LiveCD monitor resolution too high" [Undecided,Confirmed] https://launchpad.net/bugs/181386
<ubotu> New bug: #204081 in linux-restricted-modules-2.6.24 (restricted) "atieventsd crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/204081
<ubotu> New bug: #210156 in ubuntu "Keyboard layout changes (dup-of: 206008)" [Undecided,New] https://launchpad.net/bugs/210156
<pochu> hi folks, X just crashes here (Intel X3100 on a desktop). this is the output of tail -30 /var/log/Xorg.0.log.old, is there something I can do to debug this? http://pastebin.com/f318cd497
<pochu> hmm, could be 190418. I had just opened totem, but it was totem-gstreamer (and not totem-xine) and it was to play an ogg video, and not a dvd
<pochu> bug 190418
<ubotu> Launchpad bug 190418 in xserver-xorg-video-intel "[965GM]  Server crash when starting totem-xine to play a DVD" [High,Confirmed] https://launchpad.net/bugs/190418
<ubotu> New bug: #205079 in linux-restricted-modules-2.6.24 (main) "kubuntu Hardy Heron could not install libc6" [High,New] https://launchpad.net/bugs/205079
<ubotu> New bug: #192367 in python-support (main) "package python-sepolgen 1.0.11-0ubuntu1 failed to install/upgrade: Unterprozess post-installation script gab den Fehlerwert 1 zurÃ¼ck (dup-of: 208961)" [Medium,Invalid] https://launchpad.net/bugs/192367
<ubotu> New bug: #192375 in python-support (main) "update-python-modules crashed with OSError in getsize() (dup-of: 208961)" [Medium,Invalid] https://launchpad.net/bugs/192375
<ubotu> New bug: #189270 in python-support (main) "update-python-modules crashed with IOError in post_change_stuff() (dup-of: 208961)" [Undecided,New] https://launchpad.net/bugs/189270
<ubotu> New bug: #193632 in python-support (main) "update-python-modules crashed with IOError in post_change_stuff() (dup-of: 208961)" [Undecided,New] https://launchpad.net/bugs/193632
<ubotu> New bug: #196142 in python-support (main) "update-python-modules crashed with IOError in post_change_stuff() (dup-of: 208961)" [Undecided,New] https://launchpad.net/bugs/196142
<ubotu> New bug: #196767 in python-support (main) "update-python-modules crashed with IOError in post_change_stuff() (dup-of: 208961)" [Undecided,New] https://launchpad.net/bugs/196767
<ubotu> New bug: #198396 in python-support (main) "update-python-modules crashed with IOError in post_change_stuff() (dup-of: 208961)" [Undecided,New] https://launchpad.net/bugs/198396
<ubotu> New bug: #203640 in python-support (main) "update-python-modules crashed with IOError in post_change_stuff() (dup-of: 208961)" [Undecided,New] https://launchpad.net/bugs/203640
<ubotu> New bug: #204125 in python-support (main) "update-python-modules crashed with IOError in post_change_stuff() (dup-of: 208961)" [Undecided,New] https://launchpad.net/bugs/204125
<ubotu> New bug: #206888 in python-support (main) "update-python-modules crashed with IOError in post_change_stuff() (dup-of: 208961)" [Undecided,New] https://launchpad.net/bugs/206888
<ubotu> New bug: #209596 in brltty (main) "update-python-modules crashed during update (dup-of: 208961)" [Undecided,New] https://launchpad.net/bugs/209596
<ubotu> New bug: #210414 in xserver-xorg-video-ati (main) "[hardy] Extremely slow graphics at rotated 1400x1050" [Undecided,New] https://launchpad.net/bugs/210414
<ubotu> New bug: #210434 in linux-restricted-modules-2.6.24 (restricted) "compiz does not render shadows, regardless of settings" [Undecided,New] https://launchpad.net/bugs/210434
<seb128> hey bryce
<bryce> hey
<seb128> bryce: anything pending on me for the gnome-display-properties update?
<bryce> well, the revert dialog is nearly done but needs more testing before it's ready for upgrade
<bryce> I haven't looked at the new xrandr gui patches from upstream yet
<seb128> ok
<seb128> let me now when the revert dialog is ready for testing, I'll give it a run
<seb128> xrandr 1.2 rotation sucks on my ati card
<bryce> yesterday I tested the dialog exhaustively on 10 different hardware systems
<seb128> ah, how did it go?
<bryce> I haven't posted the results yet, but found a bunch of bugs (no major show stoppers for the dialogs, but a lot of stuff needing fixed in the drivers
<bryce> it looks like the only serious condition is trying to use rotation on -radeon, which causes lockups
<seb128> ok, not too bad then
<bryce> I wonder if we could even just disable xrandr rotation on -radeon, like with -nv
<bryce> of course, then no one would get to make use of my dialog! 
<seb128> well, rotations is not what people are looking at usually
<bryce> resolution changing pretty much works about 90%, with the 10% failures being modest issues, no crashes or lockups just weird looking screens
<bryce> and generally re-applying a different resolution brought things back in those cases
<tjaalton> bryce: hey, I'll probably merge xorg-server when it's uploaded in debian. there are a couple of upstream fixes from the stable branch, and would drop some of the patches we are carrying. also, we probably should check out the modesetting rework that ajax did a month ago
<bryce> tjaalton: are you certain that's safe enough?  It's getting a bit late in the cycle....
<tjaalton> bryce: the merge or the modesetting stuff?
<bryce> modesetting
<tjaalton> no idea, but there are cases where the server fails to get ddc data when it used to work with xresprobe et al
<tjaalton> so that _might_ help there
<bryce> hmm
<jcristau> tjaalton: i don't think it will help with ddc
<jcristau> aiui it just changes the logic to pick a mode after that
<tjaalton> ah.. well even if we leave that out, there are some commits in master/1.5 from the intel guys
<bryce> I guess I'm a bit burnt by how many times upstream moves to new tech, which causes regressions in older configs
<tjaalton> that were also proposed for 1.4.1 but no-one took them
<tjaalton> heh
<bryce> if we had an extra month of testing I'd probably be less concerned
<tjaalton> maybe I need to get a list of bugs where the modesetting fails, they are scattered through all the drivers currently
<bryce> yeah
<tjaalton> gah, late.. night
#ubuntu-x 2008-04-02
<bryce> ok, revert dialog seems to work, although my devel box for some reason borks up when setting to a lower resolution.  Only piece of hw I have that does that though.  Odd.
<bryce> http://people.ubuntu.com/~bryce/Testing/XrandrGui/xrandrgui-04.png
<bryce> tjaalton: I see you've already been active on bug 184651, so probably already know about the patch attached to it, but in case not, I wanted to make mention of it
<ubotu> Launchpad bug 184651 in xorg-server "Crash when starting gnome-settings-daemon" [High,In progress] https://launchpad.net/bugs/184651
<tjaalton> it's fixed upstream, and the patch is in debian too and was on my local tree
<bryce> that bug got mentioned at the distro team meeting as high priority by evand and cjwatson (who are on one of the dupes of that bug )
<bryce> awesome
<tjaalton> shouldn't it have been milestoned then?-)
<bryce> hmm, seems to be milestoned
<tjaalton> ah, right
<tjaalton> duh
<bryce> seb128: http://people.ubuntu.com/~bryce/Testing/XrandrGui/xrandrgui-04.png
<seb128> hey bryce
<seb128> ah, nice!
<bryce> seb128: patches, packages, and debs posted to bug #197673
<ubotu> Launchpad bug 197673 in gnome-control-center "gnome-display-properties should revert change automatically if not acknowledged" [High,In progress] https://launchpad.net/bugs/197673
<seb128> bryce: excellent
<bryce> needs testing next
<bryce> it would be nice to get the gnome-desktop patch uploaded, because it's a dependency for the other two.
<bryce> also, don't forget the three updated patches at http://people.ubuntu.com/~bryce/Testing/XrandrGui/
<bryce> these also need integrated/tested.
<bryce> night.
<seb128> bryce: well, you have upload rights now ;-)
<seb128> bryce: do you want me to test those and upload if that works correctly on my hardy?
<seb128> bryce: 'night
<ubotu> New bug: #210646 in xorg-server "After xorg and gtk updates many programs run extremely slow" [Undecided,New] https://launchpad.net/bugs/210646
<ubotu> New bug: #210652 in linux-restricted-modules-2.6.24 (restricted) "[Hardy] ltmodem driver missing" [Undecided,New] https://launchpad.net/bugs/210652
<ubotu> New bug: #210660 in compiz (main) "compiz.real crashed with SIGSEGV when attempting to switch users (dup-of: 160264)" [Undecided,New] https://launchpad.net/bugs/210660
<ubotu> New bug: #210390 in xserver-xorg-video-radeonhd (universe) "unable to rotate screen using gnome-display-properties" [Wishlist,Confirmed] https://launchpad.net/bugs/210390
<dennda> bryce: I am sorry for not being very responsive. I am still a bit busy but I hope we can start working on debugging tomorrow
<ubotu> New bug: #210740 in xserver-xorg-video-intel (main) "gnome-display-properties: resolution change does not do anything for internal notebook display" [Undecided,New] https://launchpad.net/bugs/210740
<ubotu> New bug: #210780 in xserver-xorg-video-intel (main) "X slower after upgrade to 4GB RAM" [Undecided,New] https://launchpad.net/bugs/210780
<ubotu> New bug: #208428 in ubiquity (main) "Ubuntu does not install (dup-of: 184651)" [Undecided,New] https://launchpad.net/bugs/208428
<ubotu> New bug: #210830 in xdm (universe) "[hardy] XDM: huge font size" [Undecided,New] https://launchpad.net/bugs/210830
<bryce> seb128_: with the three updated patches, what needs to happen is to replace the corresponding patches in the three packages, and then update all the other patches as needed since some of the code changes may cause minor breakage.
<seb128_> bryce: ok
<bryce> dennda: ok no prob, yeah I know how it goes re:busy.  
<seb128_> bryce: could you try to remove debug g_print calls in those patches? I would like to not have .xsession-errors flooded with non issues in hardy
<bryce> seb128_: by "the three updated patches" I mean the redhat patches I posted at http://people.ubuntu.com/~bryce/Testing/XrandrGui/, not the revert dialog patches
<seb128_> ok
<seb128_> let's go by steps and get the revert changes in first
<bryce> the revert dialog patches aren't ready for upload yet - in addition to the g_print() calls there's at least one situation I know of that will cause it to not work right
<seb128_> ok
<seb128_> also I commented on the bug, I just had a quick look to the gnome-desktop one
<bryce> well, if you can work on the new redhat patches, I can continue work on the revert dialog to get that done in the meantime, and then help in with what remains for the redhat patches
<seb128_> you like file in the return false cases
<seb128_> s/like/leak
<seb128_> in what order do you want to do things?
<seb128_> update to current redhat versions first
<seb128_> and then do the undo?
<bryce> I think the revert dialog should get uploaded first; it's almost done.  I expect once the new redhat stuff is packaged we'll need to test it a day or so
<seb128__> re
<seb128__> sorry sucking dsl line today
<seb128__> <seb128_> ok
<seb128__>  btw you need to rebase your gnome-desktop changes on the current hardy version
<seb128__>  the upload was only a shlibs update
<seb128__>  so no conflict there, just the changelog and the .shlibs which changed
<seb128__> bryce: ^ dunno if you got that before the disconnect
<bryce> oh ok, I'd checked the base before I started but it must have been updated in the meantime
<seb128__> yes, I did update yesterday to fix a bug
<ubotu> New bug: #210861 in xserver-xorg-video-intel (main) "X server crashes when compiz is enabled and I try to use -vo xv in MPlayer" [Undecided,New] https://launchpad.net/bugs/210861
<dennda> bryce: In which language is the new gnome-display-properties written?
<dennda> I can't seem to find the source
<dennda> (I am experiencing quite a few bugs and I'd love to help fixing all of them)
<seb128> dennda: C
<seb128> dennda: apt-get source gnome-control-center
<dennda> gna
<dennda> don't know C yet, unfortunately
<dennda> was hoping it was python
<bryce> most of the meat of the code is actually in gnome-desktop
<bryce> dennda: well if you care to learn C, I'm available to answer questions
<dennda> bryce: I do, but that'll be some point in the future. Many things to do at the moment
<dennda> but thanks
<dennda> Hm are there patches for X3100 still in the queue? (Video has some bugs with compiz enabled)
<bryce> phoronix test suite released (GPLv3)
<tormod> hi there! I find it alarming how many GL screensavers are crashing nowadays, see https://bugs.edge.launchpad.net/ubuntu/+source/xscreensaver/ Of course most of them are nvidia and fglrx...
<tjaalton> hey, I've witnessed matrixview hanging my coworkers desktop :)
<tjaalton> on nvidia
<bryce> yeah I've just triaged all the -fglrx bugs, and it seems there are a lot of DRI/DRM/GLX type of issues
<bryce> from the limited amount I've dug into them, I wonder if a kernel module is missing or something
<bryce> I cut the number of -fglrx bugs in l-r-m by half :-)
<tormod> wouldn't a missing module just disable DRI and actually avoid the crashes?
<bryce> well you'd think so
<bryce> I'm not really sure though - like I said I didn't dig into any of the bugs very far
<bryce> tormod: btw ati has been bugging me for our "top 5 bugs", so if you have some to suggest, I can pass them up the chain
<tormod> (wildly guessing) could it be a compiler issue, some new defaults, broken optimizations etc?
<bryce> I'm guessing they'll just say it's not their problem (kernel issue) or some such, but maybe then we'd have more info
<bryce> an ABI issue would be more likely I'd guess
<tormod> ati? as in Alex and Dave?
<bryce> I don't really know enough about how the fglrx<->kernel integration is set up to say
<tormod> or AMD?
<bryce> ah, I mean the ATI engineers inside AMD who develop fglrx
<tormod> hard to pick the "top 5" since no reports have a useful backtrace
<tormod> they could have a look at my xscreensaver link above
<bryce> yeah that's my thought too
<jcristau> of course they don't have a useful backtrace, it's proprietary crap
<bryce> jcristau: well sometimes the surrounding X calls have some clues
<bryce> but unfortunately most of the auto-gathered ones in launchpad don't even have that, so they're even more useless than usual ;-)
<Ng> tjaalton: do you ever see a green console before/after suspend?
<tjaalton> Ng: I've seen that yes
<Ng> it started happening on mine a couple of days ago and has done on every subsequent suspend/resume (I've not rebooted yet)
<tjaalton> I'll check again after -13 is usable
<bryce> tormod: heh, can you see all the private crash bugs in xscreensaver?
<bryce> you're not kidding about there being a ton of crash bugs
<tormod> bryce: no, ah don't tell me I just see the top of the iceberg
<Ng> tjaalton: don't spose there's anything I can do while it's like this, is there? I really need to reboot to get an unoopsed kernel so I can get some debugging info for another bug ;/
<Ng> tjaalton: s/do/do to debug this/, that is
<bryce> tormod: there's another 9 marked private.  I'll unprivate them
<tjaalton> Ng: I'm not sure.. maybe -13 is better since there were some changes related to drm
<bryce> there we go
<tormod> there are also some r300 and radeon crashes. Is apport working better than before?
<bryce> I'd talked with pitti about it a couple weeks ago; apparently it had broken and stopped doing it's work correctly, but he kicked it and said it should work properly now
<tormod> bryce: that might explain why these crashes started to flood a few days ago
<tormod> btw why is "cdrom" listed in NonfreeKernelModules?
<Ng> tjaalton: ok
<bryce> tormod: heh I noticed that too.  nfi
<bryce> maybe this has to do with it?  http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg32430.html
<ubotu> New bug: #209414 in ubuntu "Atheros 5007 reported incorrectly as "Atheros Communications, Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01) " on Amilo 1718li Laptop in Hardy Heron Beta (dup-of: 182489)" [Undecided,New] https://launchpad.net/bugs/209414
<bryce> oooh, that could explain the performance bugs we got too
<ubotu> New bug: #210749 in xorg (main) "Openoffice spreadsheet crashes x" [Undecided,New] https://launchpad.net/bugs/210749
<tormod> amd64 seems to be overrepresented.
<bryce> interesting
<bryce> I've noticed a surprising number of amd64 bugs in general
<tormod> This gives a good overview: https://bugs.edge.launchpad.net/ubuntu/+source/xscreensaver/?field.searchtext=crashed+with&orderby=title
<bryce> are you able to reproduce the problem?  I'd be interested to hear if setting Option "AIGLX" "off"  has any effect
<bryce> it's weird, when I search on "[fglrx]" in xscreensaver, only 3 bugs come up
<tormod> bryce: search and sort in LP has been broken for ages
<bryce> bleah
<tormod> you have to make the URL yourself, like I did above.
<bryce> ahh
<bryce> 12 bugs - https://bugs.edge.launchpad.net/ubuntu/+source/xscreensaver/?field.searchtext=fglrx&orderby=title
<ubotu> New bug: #211043 in linux-restricted-modules-2.6.24 (restricted) "could not find module b43" [Undecided,New] https://launchpad.net/bugs/211043
<bryce> hrmph, these backtraces are less than useful.  All I can tell is it has something to do with GL in fglrx
<bryce> and you're right; amd64 is overrepresented
<tormod> yes there are also some [r300 amd64] crashes
<bryce> hm, bug 179042 maybe?
<ubotu> Launchpad bug 179042 in linux-restricted-modules-2.6.24 "[fglrx] fglrx, compiz and opengl conflict" [Medium,Triaged] https://launchpad.net/bugs/179042
<tormod> anyone here having that combination?
<bryce> here's another, that got put into l-r-m already - 181121
<bryce> probably all those xscreensaver bugs could be duped onto that one
<tormod> bug #181121
<ubotu> Launchpad bug 181121 in linux-restricted-modules-2.6.24 "[fglrx] glplanet crashed with SIGSEGV" [Undecided,Incomplete] https://launchpad.net/bugs/181121
<tormod> what do you mean it got put into l-r-m?
<tormod> oh I got it
<tormod> do you have a bughelper script to do mass-reassigning?
<bryce> sorry, that was a GL game not a screensaver, but it looks like the same issue
<bryce> no, but bdmurray does
<tormod> glplanet is also a screensaver
<tjaalton> tormod: no I mean that according to the changelog the driver manager doesn't recommend installing fglrx anymore, if the user is running r300 or whatever the fglrx supports but also has good support in -ati&mesa
<bryce> ahhh
<bryce> ok even better.  I assumed it was some sort of game
<tormod> tjaalton: re what?
<tjaalton> tormod: re: "what do you mean it got put into l-r-m?" (or was that not for me :)
<tormod> bryce 181121 is a poor dup, since it should already have been closed for no response.
<tormod> tjaalton: not for you :)
<tjaalton> tormod: awww :)
<bryce> tormod: ahh, but it's reported by bdmurray who is the Canonical Bugmeister
<tormod> bryce: right! So if he doesn't follow up, who will? :)
<bryce> precisely
<bryce> also I subbed ted gould who maintains xscreensaver; he should also be eyeballing this one
<tormod> would you like to have 181121 assigned to you? otherwise I close it.
<bryce> I'd already asked brian about this bug this morning, but said he could look at it when he has time (I think he has bug hug day events going on presently)
<tormod> ok here you are.
<bryce> tormod, I gather fglrx just gained AIGLX support in the latest version.  Maybe it's buggy?
<bryce> I've encouraged a bunch of the -fglrx bug reporters to test turning it off.
<tormod> would make a lot of sense. when did the latest fglrx get in?
<tormod> off-topic: is the data I submit thru hwtest available on LP?
<bryce> afaik the data is not available :-/
<bryce> last fglrx update was January I think
<tjaalton> no, early March
<tjaalton> Tue 11th
<bryce> hmm, my l-r-m checkout must be old
<bryce> oh I see what I did.  duh
<tjaalton> I'm about to upload a new one
<tormod> early March, then apport came back and crash bugs started to flood? could make sense.
<tormod> what about all the nvidia bugs?
<ubotu> New bug: #211066 in linux-restricted-modules-2.6.24 (restricted) "Cannot upgrade linux-restricted-modules-generic" [Undecided,Confirmed] https://launchpad.net/bugs/211066
<tjaalton> here we go, the first bug about no lrm available for -14
<Ng> tjaalton: brightness works for me in -14 \o/
<Ng> although gdm is being very very strange
<Ng> I had to comment out GtkTheme=Human in gdm.conf to get the greeter to not consume a whole core in a gtkrc loading loop
<ubotu> New bug: #211074 in linux (main) "[hardy] no nvidia module FATAL with linux-image-2.6.24-14-generic (dup-of: 211066)" [Undecided,Incomplete] https://launchpad.net/bugs/211074
<ubotu> New bug: #211076 in linux-meta (main) "Hardy, linux-restricted-modules broken (dup-of: 211066)" [Undecided,New] https://launchpad.net/bugs/211076
<bryce> I do have to say that the fglrx bug reporters are surprisingly responsive compared with the -intel reporters
<bryce> but maybe that's just because the reports are all much more recent
<ubotu> New bug: #210905 in mumble (main) "not push-to-talk - xevie problem" [Undecided,Confirmed] https://launchpad.net/bugs/210905
<ubotu> New bug: #211089 in ubuntu "kernel update left Ubuntu without restricted drivers (dup-of: 211066)" [Undecided,New] https://launchpad.net/bugs/211089
<tjaalton> Ng: yeah brightness works, tried it with -13
#ubuntu-x 2008-04-03
<Ng> tjaalton: of course now that means that g-p-m or something is blinding me by making it brighter on idle ;)
<Ng> and I can't reboot anymore. this hardy install isfalling to pieces and I have no idea how all this new fangled stuff fits together :)
<tjaalton> Ng: ah, so the brightness goes up when you leave it alone?
<Ng> yes
<tjaalton> I noticed that the dimming works, but then when you resume it dims to the lowest value :P
<Ng> argh, and then up even more when I type agan
<Ng> bryce: how come the brightness sliders disappeared from power preferences?
<Ng> there seems to be absolutely no way of setting a default brightness now
<bryce> no idea
<tjaalton> Ng: it's tedg's territory :)
<Ng> sorry, yes good point
<tjaalton> lrm uploaded.. I bet there's going to be a new nvidia soon, since the windows version was updated on Tuesday
<tjaalton> and because lrm got updated
<tjaalton> obviously :)
<tjaalton> lrm took a couple of hours too much.. night!
<bryce> yeah, I didn't plan on spending so much time on lrm either
<ubotu> New bug: #211098 in xorg (main) "[hardy] Screen resolution only 640x480" [Undecided,New] https://launchpad.net/bugs/211098
<bryce> uploading my first package as a core-dev (finally)... the changes for displayconfig-gtk in the menus
<bryce> \o/ Accepted
<bryce> man, uploading directly to main is a thrill.  How have I been missing this!?!
<ubotu> New bug: #211080 in update-manager (main) "dist-upgrade 7.10 to 8.04 beta failed (dup-of: 211066)" [Undecided,Incomplete] https://launchpad.net/bugs/211080
<ubotu> New bug: #211134 in update-manager (main) "[Hardy] update-manager could not update (dup-of: 211066)" [Undecided,New] https://launchpad.net/bugs/211134
<ubotu> New bug: #211158 in linux-restricted-modules-2.6.24 (restricted) "nvidia restricted driver cannot be enableed" [Undecided,New] https://launchpad.net/bugs/211158
<ubotu> New bug: #208951 in linux-restricted-modules-2.6.24 (restricted) "frontend crash on tv view" [Undecided,New] https://launchpad.net/bugs/208951
<ubotu> New bug: #208859 in linux-restricted-modules-2.6.24 (restricted) "mythfrontend.real crashed with SIGSEGV in memset()" [Undecided,New] https://launchpad.net/bugs/208859
<tjaalton> bryce: feel the powah!
<bryce> ;-)
<tjaalton> Ng: does the suspend hotkey work for you?
<Ng> tjaalton: I don't ever use it. let's find out!
<Ng> tjaalton: yep, Fn+F4
<tjaalton> works?
<tjaalton> doesn't generate any keyevent here, don't know when it broke
<tjaalton> Ng: ^^
<Ng> tjaalton: hmm, odd
<Ng> [Thu Apr  3 09:58:16 2008] received event "ibm/hotkey HKEY 00000080 00001004"
<Ng> [Thu Apr  3 09:58:16 2008] executing action "/etc/acpi/sleepbtn.sh"
<tjaalton> removing from dock still hangs the machine, duh
<Ng> ouch
<tjaalton> Ng: what does 'lsmod|grep thinkpad_acpi' say?
<Ng> thinkpad_acpi          51836  0 
<Ng> nvram                   9992  1 thinkpad_acpi
<tjaalton> same
<Ng> I did notice that there's nothing in modprobe.d setting options for thinkpad_acpi anymore, which seemed a bit odd
<Ng> I'm sure we used to set hotkey masks, experimental and fan_control
<tjaalton> so frustrating.. no idea where to look
<Ng> yeah, backups of my old laptop show /etc/modprobe.d/thinkpad_acpi.modprobe
<Ng> my current install just has /etc/modprobe.d/thinkpad_acpi.modprobe.dpkg-bak
<Ng> which I would assume modprobe is ignoring
<tjaalton> hmm, it was dropped from acpi-support. what does it contain?
<Ng> options thinkpad_acpi hotkey=enable,0xffff8f experimental=1
<Ng> that's from my old backup
<Ng> the dpkg-bak one on my new laptop also has fan_control=1
<Ng> I'm not sure if I changed either :/
<tjaalton> I don't see why it was obsolete
<tjaalton> well, adding it doesn't fix the problem
<Ng> boo
<tjaalton> ah, from dmesg "standard ACPI backlight interface available, not loading native one..."
<tjaalton> bzzt!
<tjaalton> oops
<tjaalton> wrong issue :)
<Ng> yeah ;)
<tjaalton> I'm too tired..
<tjaalton> all the other hotkeys work but not suspend
<tjaalton> wrong, radio button, video switch and "the one next to it" don't work either
<Ng> F8?
<tjaalton> hibernate does, but I never use it
<tjaalton> yep
<Ng> that's toggling trackpads/nipples afair
<tjaalton> oh
<Ng> I have no idea if we're even supposed to support that. I don't think I've ever pressed it and my trackpad is disabled in the bios anyway because they are evil and wrong ;)
<tjaalton> heh
<ubotu> New bug: #211230 in xorg (main) "X-Server crashes when pressing a key" [Undecided,New] https://launchpad.net/bugs/211230
<ubotu> New bug: #211240 in linux-restricted-modules-2.6.24 (restricted) "Xen doesn't work with proprietary ATI drivers" [Undecided,New] https://launchpad.net/bugs/211240
<ubotu> New bug: #211250 in linux-restricted-modules-2.6.24 (restricted) "external display not detected properly" [Undecided,New] https://launchpad.net/bugs/211250
<ubotu> New bug: #43625 in linux-restricted-modules-2.6.15 "Restarting Xorg after suspend causes system to hang." [Medium,New] https://launchpad.net/bugs/43625
<ubotu> New bug: #210244 in xulrunner-1.9 (main) "Momentary Black Screen around context menu  (dup-of: 182038)" [Undecided,New] https://launchpad.net/bugs/210244
<ubotu> New bug: #207597 in firefox-3.0 (main) "picture scales not propperly to fit screen (dup-of: 182038)" [Undecided,New] https://launchpad.net/bugs/207597
<ubotu> New bug: #209953 in firefox-3.0 (main) "Large image is corrupted when zoomed out (dup-of: 182038)" [Undecided,New] https://launchpad.net/bugs/209953
<ubotu> New bug: #195836 in firefox-3.0 (main) "netvibes.com rendering broken in last firefox 3 update (dup-of: 186186)" [Undecided,Invalid] https://launchpad.net/bugs/195836
<ubotu> New bug: #197378 in firefox-3.0 (main) "web page displayed wrong (dup-of: 182038)" [Undecided,Invalid] https://launchpad.net/bugs/197378
<Ng> tjaalton: interesting catch on the wifi leds bug ;)
<tjaalton> Ng: yep..
<ubotu> New bug: #202748 in firefox-3.0 (main) "firefox sometimes shift content in webpages (dup-of: 186186)" [Undecided,Invalid] https://launchpad.net/bugs/202748
<ubotu> New bug: #211356 in xorg (main) "x crashes 5 minutes into session" [Undecided,New] https://launchpad.net/bugs/211356
<ubotu> New bug: #211362 in xorg (main) "kubuntu hardy doesn't recognize the Intel Graphics Media Accelerator 3100" [Undecided,New] https://launchpad.net/bugs/211362
<ubotu> New bug: #211365 in linux-restricted-modules-2.6.24 (restricted) "System forgets display setup" [Undecided,New] https://launchpad.net/bugs/211365
<Q-FUNK> howdy!
<Q-FUNK> -geode is in NEW at debian.  do we have any way to sync it from there?
<ubotu> New bug: #211385 in xserver-xorg-video-amd (main) "please sync xserver-xorg-video-geode (main) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/211385
<bryce> tjaalton: I dunno - what do you think of the XAANoOffscreenPixmaps change?
<ubotu> New bug: #205520 in compiz (main) "Title Bar of Current Window Turns Pink or Invisible (dup-of: 186382)" [Undecided,New] https://launchpad.net/bugs/205520
<ubotu> New bug: #211424 in linux-restricted-modules-2.6.24 (restricted) "[hardy] mythfrontend crash in glxMakeCurrentReadSGI()" [Undecided,New] https://launchpad.net/bugs/211424
<tjaalton> bryce: I don't think it's a good idea
<tjaalton> but I can't remember why
<bryce> it doesn't feel good to me either, but don't have a good argument (yet)
<bryce> I mean, even the greedy patch - which has been *widely* approved as an improvement, is having strange side effects (I think)
<bryce> if this were a month or two ago, I'd have no problem flipping it on
<tjaalton> well, there's a reason ajax wrote the patch for fedora :)
<ubotu> New bug: #210717 in xorg (main) "Cannot set Screen resolution" [Undecided,New] https://launchpad.net/bugs/210717
<bryce> some day I need to make a triaging run through mesa...  so many bugs, so little time...
<bryce> rebooting, brb
<ubotu> New bug: #211285 in xorg (main) "i855GM: blank screen after resume from suspend to ram, on Hardy" [Undecided,Incomplete] https://launchpad.net/bugs/211285
#ubuntu-x 2008-04-04
<ubotu> New bug: #211586 in linux-restricted-modules-2.6.24 (restricted) "fglrx halts on Radeon HD 3850" [Undecided,New] https://launchpad.net/bugs/211586
<ubotu> New bug: #211610 in linux-restricted-modules-2.6.24 (restricted) "[fglrx] fglrx freezes randomly" [Undecided,New] https://launchpad.net/bugs/211610
<pwnguin> which team looks after gdm?
<tjaalton> pwnguin: desktop-
<bryce> heya pwnguin
<pwnguin> hey
 * pwnguin enjoys breaking more things
<ubotu> New bug: #211689 in xorg (main) "segmentation fault in xorg 7.3" [Undecided,New] https://launchpad.net/bugs/211689
<ubotu> New bug: #205234 in linux-meta (main) "[Hardy] Atheros AR5418 chipset not supported (dup-of: 122703)" [Undecided,New] https://launchpad.net/bugs/205234
<ubotu> New bug: #211457 in linux-restricted-modules-2.6.24 (restricted) "ATI card glitchy in Hardy Heron Beta" [Undecided,Incomplete] https://launchpad.net/bugs/211457
<dennda> bryce: Hopefully we can get a bit productive today :)
<ubotu> New bug: #211785 in pixman (main) "Please sponsor pixman 0.10.0-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/211785
<ubotu> New bug: #211787 in xorg (main) "Monitor not correctly detected anymore" [Undecided,New] https://launchpad.net/bugs/211787
<ubotu> New bug: #205328 in ubuntu "[Hardy] strange opengl behaviour (dup-of: 199823)" [Undecided,New] https://launchpad.net/bugs/205328
<ubotu> New bug: #211875 in ubuntu "keyboard layout (dup-of: 205314)" [Undecided,New] https://launchpad.net/bugs/211875
<ubotu> New bug: #211927 in linux-restricted-modules-2.6.24 (restricted) "Very low refresh rate/fps and problems with 3d windows enabled" [Undecided,New] https://launchpad.net/bugs/211927
<bryce> hah, just saw this in redhat's newest xrandr gui code:
<bryce> +     * Firefox apparently believes what X tells it. It is a foolish
<bryce> +     * application.
<ubotu> New bug: #211948 in linux-restricted-modules-2.6.24 (restricted) "Laptop screen brightness will no longer adjust" [Undecided,New] https://launchpad.net/bugs/211948
<ubotu> New bug: #156730 in nvidia-settings "nvidia-settings package cannot be installed along with nvidia-glx-legacy" [Undecided,Invalid] https://launchpad.net/bugs/156730
<ubotu> New bug: #205695 in xkeyboard-config (main) "french dvorak layout outdated" [Undecided,New] https://launchpad.net/bugs/205695
<ubotu> New bug: #211957 in xorg (main) "No way to type # on Mac keyboards." [Undecided,New] https://launchpad.net/bugs/211957
<ubotu> New bug: #208357 in xscreensaver (main) "[fglrx] queens crashed with SIGSEGV (dup-of: 181121)" [Medium,Incomplete] https://launchpad.net/bugs/208357
<ubotu> New bug: #210195 in xscreensaver (main) "ripples crashed with SIGSEGV in xcb_poll_for_event() (dup-of: 181121)" [Undecided,New] https://launchpad.net/bugs/210195
<ubotu> New bug: #210593 in xscreensaver (main) "ripples crashed with SIGSEGV in xcb_poll_for_event() (dup-of: 181121)" [Undecided,New] https://launchpad.net/bugs/210593
<ubotu> New bug: #210671 in xscreensaver (main) "[fglrx amd64] looking at different screen savers and crashed (dup-of: 181121)" [Medium,Incomplete] https://launchpad.net/bugs/210671
<ubotu> New bug: #210721 in xscreensaver (main) "ripples crashed with SIGSEGV in xcb_poll_for_event() (dup-of: 181121)" [Undecided,New] https://launchpad.net/bugs/210721
<ubotu> New bug: #180897 in xscreensaver (main) "[fglrx] glmatrix crashed with SIGSEGV (dup-of: 181121)" [Medium,Incomplete] https://launchpad.net/bugs/180897
<ubotu> New bug: #202658 in xscreensaver (main) "[fglrx amd64] glmatrix crashed with SIGSEGV in g_module_symbol() (dup-of: 181121)" [Medium,New] https://launchpad.net/bugs/202658
<ubotu> New bug: #203873 in xscreensaver (main) "[fglrx] engine crashed with SIGSEGV (dup-of: 181121)" [Medium,Incomplete] https://launchpad.net/bugs/203873
<ubotu> New bug: #205565 in xscreensaver (main) "[fglrx] circuit crashed with SIGSEGV (dup-of: 181121)" [Medium,Incomplete] https://launchpad.net/bugs/205565
<ubotu> New bug: #207069 in xscreensaver (main) "[fglrx amd64] ripples crashed with SIGSEGV in xcb_poll_for_event() (dup-of: 181121)" [Medium,New] https://launchpad.net/bugs/207069
<bryce> sorry... went on a duping spree there ;-)
<ubotu> New bug: #178997 in xscreensaver (main) "[fglrx] antinspect crashed with SIGSEGV (dup-of: 181121)" [Medium,Incomplete] https://launchpad.net/bugs/178997
<ubotu> New bug: #179002 in xscreensaver (main) "[fglrx] glplanet crashed with SIGSEGV (dup-of: 181121)" [Medium,Incomplete] https://launchpad.net/bugs/179002
<jcristau> bryce: 207069 doesn't seem to be GL-related?
<bryce> ok
<jcristau> any particular reason for forking pixman instead of syncing it? (lp#211785)
<tjaalton> jcristau: I advised to sync it..
<tjaalton> seeing you uploaded it a while earlier
<jcristau> ok
<jcristau> i had it ready in git for a while, just didn't get around to uploading
<bryce> I posted the -intel quirks I've been gathering up to xorg - https://bugs.freedesktop.org/show_bug.cgi?id=15353
<ubotu> Freedesktop bug 15353 in Driver/intel "Quirks for -intel from Ubuntu/Dell" [Normal,New] 
<bryce> jcristau: the above patch applies against xorg git
<jcristau> right i've seen that on xorg-team :)
<tjaalton> hmh, so our nvidia-glx-new is busted somehow.. using the installer there are no pink shadows with compiz etc
<tjaalton> need to test it myself now
<bryce> I have a packaging question...
<bryce> I've got three packages which somewhat interdepend on each other - gnome-desktop, gnome-settings-daemon, and gnome-control-center
<bryce> the latter two link to the first.  g-c-c relies on g-s-d to make changes
<bryce> most of the logic is in gnome-desktop, so most of my code changes are there
<seb128> jcristau: the reason is that is was updated for ubuntu first without knowing how long it would take for debian
<bryce> I've made a change to gnome-desktop to add a new capability, that gnome-control-center now uses
<bryce> no changes are needed in gnome-settings-daemon; it just needs to be rebuilt against the newer gnome-desktop
<bryce> is the correct approach to change the build-depends for gnome-settings daemon?
<bryce> or do I just need to bump it as a -XbuildY?
<seb128> tjaalton: we will likely sponsor the contributor update first because he put work on it and we will sync later
<tjaalton> seb128: hmm, ok
<tjaalton> the five minutes of fame :)
<seb128> tjaalton: you don't want to discourage them contributing ;-)
<jcristau> seb128: well as i said the package was ready 5 days ago
<seb128> jcristau: well, not everybody is tracking all the dcsv around
<jcristau> but ok, just bad luck
<seb128> right
<seb128> no big deal, just a bit extra work for this contributor
<jcristau> yup
<seb128> bryce: why does it need to be rebuild if no change are required, there is no static lib used there, a rebuild should make no difference?
<bryce> seb128: gnome-settings-daemon has a build-depends against libgnome-desktop-dev.  Doesn't it statically link against it?
<jcristau> that would be broken
<bryce> ??
<bryce> so you're saying it dynamically links and things will automatically update, and I don't need to worry about doing anything to gnome-settings-daemon
<jcristau> gnome-settings-daemon depends on libgnome-desktop-2
<bryce> in the gnome-settings-daemon control file is "Build-Depends: ... libgnome-desktop-dev (>= 1:2.21.92-0ubuntu2), ..."
<jcristau> bryce: well yeah, if you want to link with a lib you need to have the .so around at linking time
<jcristau> and that's in the -dev package
<seb128> bryce: right, ldd binary will tell you what libs it's using
<seb128> bryce: we don't use libs statically that would increase usage and force to update every copy to fix issues
<bryce> ok great
<tjaalton> damnit, no build log from the nvidia-installer
<jcristau> seb128: re:211785, i'm not too sure about the symbols file in there. some enums changed between 0.9.6 and 0.10.0, so i think the version should be bumped for functions which use those
<jcristau> (these things make me somewhat nervous)
<seb128> jcristau: are you saying they broke ABI?
<jcristau> no. i'm saying they added stuff to the pixman_format_code_t enum.
<seb128> ah
<jcristau> so if an app uses the new ones, it should get a versioned dependency on libpixman-1-0 (>= 0.10.0)
<seb128> right, the shlibs should be bumped
<jcristau> the shlibs should be bumped anyway because of the new functions
<seb128> right, thanks for pointing it
<jcristau> and afaict fta did that
<jcristau> but i'm talking about the debian/libpixman-1-0.symbols file
<jcristau> (shlibs is ignored by dpkg-shlibdeps if there's a symbols file)
<seb128> ok, thanks for the comments, I told him about the issue
<jcristau> thanks
<seb128> I have not played with the new symbols thing yet so I didn't know
<seb128> I think I'll just upload his version briefly so it's listed on -changes and sync on debian ;-)
<seb128> so everything should be already, he'll get credit for his work and we will be in sync again
<jcristau> sounds good :)
#ubuntu-x 2008-04-05
<bryce> heh, someone is happy with the patch posted to #206287
<bryce> tjaalton: that patch fixes mesa's libgl1-mesa-glx, not sure if that's the same that you were looking at earlier
<tjaalton> bryce: ah that one, nice to see it fixed
<tjaalton> ..upstream
<bryce> yup
<jcristau> the actual fix is http://cgit.freedesktop.org/mesa/mesa/diff/?h=mesa_7_0_branch&id=1e83d70b6d07c7d3c61ee0ddf0de9420c167175d
<jcristau> i mean, the one that was committed upstream
<bryce> heh, I love 1 char fixes
<tjaalton> yawn.. bedtime, night!
<ubotu> New bug: #212018 in xorg (main) "X selects wrong modeline for LG Flatron L222WS" [Undecided,New] https://launchpad.net/bugs/212018
<ubotu> New bug: #211954 in xorg (main) "Incomplete desktop in GNOME (hardy) after boot" [Undecided,New] https://launchpad.net/bugs/211954
<ubotu> New bug: #212073 in xorg (main) "Touchscreen stops functioning correctly in Xorg if the device is removed/reinserted" [Undecided,New] https://launchpad.net/bugs/212073
<ubotu> New bug: #212079 in xorg-server (main) "Xorg crashed with SIGSEGV in FlushClient()" [Medium,New] https://launchpad.net/bugs/212079
<ubotu> New bug: #212108 in xserver-xorg-input-mouse (main) "man page out of date" [Undecided,New] https://launchpad.net/bugs/212108
<ubotu> New bug: #139391 in linux-restricted-modules-2.6.22 "[gutsy] ath_pci not running well w/ 11g" [Undecided,New] https://launchpad.net/bugs/139391
<bryce> just got the number of -intel bugs down to 100.
<dennda> ping bryce 
<bryce> yep (about to go to bed tho)
<dennda> oh
<dennda> where do you live?
<bryce> oregon
<bryce> ok bedtime.  ttyl
<dennda> ok
<dennda> good night
<dennda> bryce: I just got an intel-driver-update
<dennda> I cannot adjust my displays brightness since
<dennda> ok now it works magically
<dennda> I need to investigate that further
<tjaalton> fixed by the new kernel
<dennda> hm?
 * dennda boots once again
<dennda> gnome had some startup problems, maybe that was the cause
<ubotu> New bug: #212163 in xserver-xorg-video-intel (main) "Need a Pipe-A quirk for Subsystem: Sony Corporation Unknown device [104d:81e6]" [Undecided,New] https://launchpad.net/bugs/212163
<dennda> hm no
<dennda> same effect
<dennda> my brightness-adjustment-applet for the panel shows this read exclamation mark and I can't adjust the brightness
<dennda> (the gnome-systray-things are not loaded. power-manager and network-manager don't show up. I started nm-applet by hand.)
<dennda> last session they came up at some point and since then, adjusting the brightness worked
<dennda> ah
<dennda> q.e.d.
<dennda> happened again
<dennda> odd
<Q-FUNK> tjaalton: did I pick the right LP user to add you to the sync request for -geode ?
<tjaalton> Q-FUNK: don't know.. which bug #?
<Q-FUNK> tjaalton: bug #211385
<ubotu> Launchpad bug 211385 in xserver-xorg-video-amd "please sync xserver-xorg-video-geode (main) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/211385
<tjaalton> Q-FUNK: replied
<Q-FUNK> thanks!
<Q-FUNK> the main difficulty, though, is that this is currently sitting in NEW at Debian
<tjaalton> nothing special tehre
<tjaalton> there
<Q-FUNK> ture, but it delays importing on time for hardy
<Q-FUNK> true
<tjaalton> packages can be synced from NEW afaik
<Q-FUNK> ah, in that case, we're in business :)
<ubotu> New bug: #212206 in xserver-xorg-video-intel (main) "[Hardy] digital output driver (SDVO) sets wrong resolution on GM965" [Undecided,New] https://launchpad.net/bugs/212206
<ubotu> New bug: #212341 in xorg (main) "Many graphics glitches while using the screensaver settings dialog with desktop effects enabled." [Undecided,Incomplete] https://launchpad.net/bugs/212341
<dennda> bryce: tell me when you got up
<bryce> I'm up
<dennda> ah cool
<dennda> hilighting me is always a good idea
<dennda> bryce: what was that link again?
<bryce> not sure
<dennda> got it
<dennda> bryce: so you want me to enable those stacktraces and then rotate my external screen and do some stuff until it crashes?
<bryce> yup
<bryce> (pardon I don't recall the bug number - been looking at a lot of bugs lately)
<dennda> ok
<dennda> will come up with them tomorrow or so
<dennda> how do you prefer to get them? email? paste? bugreport?
<bryce> bug report
<dennda> ok
<bryce> upload as attachments (not inline)
<ubotu> New bug: #212510 in xserver-xorg-video-ati (main) "[gutsy] [hardy]No signal with Samsung SyncMaster 750s" [Undecided,New] https://launchpad.net/bugs/212510
#ubuntu-x 2008-04-06
<ubotu> New bug: #212602 in xserver-xorg-input-keyboard (main) ""keyboard" driver no longer availible in hardy" [Undecided,New] https://launchpad.net/bugs/212602
<bryce> hmm, isn't -keyboard deprecated?  that bug probably could be closed as won'tfix
<bryce> hmm, maybe not; looks like ajax put out a new version a couple weeks ago
<bryce> ah, yes it is - http://gitweb.freedesktop.org/?p=xorg/driver/xf86-input-keyboard.git;a=commitdiff;h=ec247cd91cf147a8d1e79b0746680b049269798f;hp=278c7d8f44ba7393a95ab1a4a557d6f385044022
<ubotu> New bug: #212637 in xorg (main) "S-Video/TV-out displays blank screen" [Undecided,New] https://launchpad.net/bugs/212637
<ubotu> New bug: #212647 in xorg (main) "Install Session Bug" [Undecided,New] https://launchpad.net/bugs/212647
<ubotu> New bug: #212648 in xorg (main) "a visit to http://www.themareks.com/xf/ in firefox hardy causes X to restart" [Undecided,New] https://launchpad.net/bugs/212648
<ubotu> New bug: #212672 in xorg (main) "couldn't upgrade to hardy from dapper" [Undecided,New] https://launchpad.net/bugs/212672
<ubotu> New bug: #212753 in xrandr "Evtouch and stick mouse should also be rotated when changing screen rotation" [Undecided,New] https://launchpad.net/bugs/212753
<ubotu> New bug: #212749 in xorg-server (main) "gdmflexiserver --xnest does not start" [Low,Invalid] https://launchpad.net/bugs/212749
<ubotu> New bug: #212799 in xserver-xorg-video-intel (main) "[hardy] Compositing + Xv causes SIGSEGV in memcpy()" [Undecided,New] https://launchpad.net/bugs/212799
<ubotu> New bug: #212869 in mesa (main) "package libgl1-mesa-dri does not install correctly during upgrade to 8.04 beta" [Undecided,New] https://launchpad.net/bugs/212869
<ubotu> New bug: #212897 in xorg (main) "[hardy][xorg] soft lockup, CPU0 stuck for 11s!" [Undecided,New] https://launchpad.net/bugs/212897
<ubotu> New bug: #208570 in xserver-xorg-driver-vesa (universe) "strange graphics bug, window looks squished, wrong colors" [Undecided,New] https://launchpad.net/bugs/208570
<ubotu> New bug: #18945 in xorg (main) "xorg crashes after screen resolution is changed" [Medium,Invalid] https://launchpad.net/bugs/18945
<ubotu> New bug: #212963 in xorg (main) "t60p multi-head oddity" [Undecided,New] https://launchpad.net/bugs/212963
<ubotu> New bug: #212978 in xorg (main) "package xserver-xorg 1:7.3+10ubuntu7 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/212978
#ubuntu-x 2009-03-30
<TimU> Scratch that.  Starting fresh from "apt-get source ..." and running debuild seems to be working.  I must have horked it somehow while trying to enable debugging.
<hyperair> does anybody here have experience with ati cards and backlight setting?
<RAOF> bryce: I think the libdrm changes are ready for upload.  I've added the LP foo to the changelog, pushed to git again.
<tjaalton> RAOF: ok, I can take care of it
<RAOF> Thanks.
<tjaalton> superm1: 529d1d720 made it in 7.4
<superm1> tjaalton, spectacular.  i sent an email to that ML and when i got turned away to that vmware guy's email. so sounds like he made it happen :)
<tjaalton> superm1: your email got through to the list today :)
<tjaalton> building mesa 7.4 now, and if it's ok I'll upload it to my ppa
<tjaalton> and file a FFe for it
<tjaalton> ok, mesa is building now https://edge.launchpad.net/~tjaalton/+archive/ppa
<bryce> tjaalton: let me know the bug id for the FFe so I can help push it through
<sbeattie> bryce: low-priority, but do you know what's up with bug 351076? They all provide xserver-xorg-video-2.1 which xserver-xorg-core lists as a conflict; are they incompatible and should be removed, or is there some other fix/update that needs to happen?
<ubottu> Launchpad bug 351076 in xserver-xorg-input-void "Package xserver-xorg-input-aiptek does not install (Januty beta)" [Undecided,New] https://launchpad.net/bugs/351076
<tjaalton> sbeattie: there are a few input drivers that won't build against xserver 1.6. on my list of things to fix..
<tjaalton> bryce: it doesn't exist yet :)
<bryce> tjaalton: ok.
<bryce> actually I think I ran across a "please upgrade to mesa 7.4" bug we could probably reuse
<tjaalton> yeah
<bryce> sbeattie: what timo said :-)  I can confirm I was able to reproduce the problem.  
<tjaalton> i was hoping to just sync them from debian, but it might take a week or two until 1.6 is in unstable
<tjaalton> only a handful of drivers are updated against it in experimental
<tjaalton> there are maybe six drivers to fix
<sbeattie> okay, I just wanted to make sure you guys were on top of it; I dislike having uninstallable packages in the archive.
<tjaalton> the archive rebuild was a great reminder ;)
<Ng> this is so weird, the guy who sites next to me just upgraded to jaunty, he also has a 965 and his is smooth as in Intrepid. I downgraded from xorg-edgers to jaunty packages and mine is back to being highly affected by CPU. our Xorg.0.logs are very similar
<Ng> could something like mtrr be at fault I wonder?
 * Ng never been entirely sure how to check the sanity of mtrrs
<bryce> tjaalton: hmm, a week or two might cut things a bit close; what needs done to update them specifically?  Just packaging stuff or does it need code changes as well?
<jcristau> tjaalton: if you can prep them in git i could upload to experimental probably.
<jcristau> no time to do it myself this week though
<tjaalton> bryce: new upstream versions, likely
<tjaalton> jcristau: ok, I'll have a look tomorrow
<bryce> tjaalton: do you happen to know how .pot files get added to xkeyboard-config?  (bug 349341)
<ubottu> Launchpad bug 349341 in xkeyboard-config "launchpad xkeyboard-config .pot is obsolete: 1.4 whereas binary is 1.5" [Undecided,Confirmed] https://launchpad.net/bugs/349341
<bryce> tjaalton: it seems once in the past there was a .pot file included, but the packaging doesn't seem to produce it 
<Ng> UXA doesn't seem to help either, which is interesting
<Ng> the only thing that seems to help is flipping up to the edgers packages, but that brings occasional X hangs, and more frequent segfaults on resume
<tjaalton> bryce: don't remember off-hand, but + can check once I get home
<bryce> ok thanks
<tjaalton> Ng: now is a good chance to try mesa  7.4 from my ppa ;)
<Ng> tjaalton: sure, I'll downgrade to jaunty -intel stuff again
<Ng> tjaalton: in your personal ppa?
<tjaalton> Ng: yep
<Ng> ok, installed, rebootin'
<Ng> tjaalton: well it doesn't seem to have improved things, but it hasn't made them any worse :)
<tjaalton> Ng: eexcellent :)
<Ng> is the new mesa so we can sneak in a newer -intel? ;)
<tjaalton> a cunning plan, you say? :)
<Ng> I have a sticky tail and a "Fox" name badge for such a plan ;)
<bryce> Ng: sort of late in the process to be upping -intel... the mesa update is mainly for bug fixes
<tjaalton> yeah :)
<superm1> tjaalton, at some point were you looking into pulling the patch referred to in  http://www.phoronix.com/scan.php?page=news_item&px=NjYwMw into ubuntu?  it certainly would make the things jockey has to do less necessary and great from a user perspective
<tjaalton> superm1: yes I was
<superm1> tjaalton, what happened with it?
<tjaalton> doesn't work if you have an xorg.conf
<tjaalton> so we'd need to not ship one first
<superm1> but it's still an improvement over the current situation then no?
<jcristau> loading with nv > failing to load because nvidia doesn't work
<jcristau> so no
<superm1> oh it totally fails if no xorg.conf is around
<tjaalton> different codepath
<tjaalton> um
<jcristau> FatalError("no screens found"); -> unhappy user :)
<tjaalton> I mean, it doesn't work if there _is_ an xorg.conf
<superm1> so is the failure coming from extra checks going on in the NV driver or in X libraries?  
<tjaalton> I'm not sure what jcristau meant, but yes there are issues :)
<jcristau> it's something like that: if (no xorg.conf) { make a list of possible drivers; for each one, if its preinit works, break, happiness, if not try the next one } else { find the first candidate; if its preinit fails, fatalerror }
<superm1> so why the logic to fail if the first candidate doesn't work when there is an xorg.conf?  is there a good reason for that?
<jcristau> (there's no good reason for it to work like that, but nobody's fixed it, so..)
<tjaalton> ah, right :)
<superm1> ah
<tjaalton> anyway, a couple of episodes of "my name is earl" now.. ->
<superm1> tjaalton, b4 you run, do you have the commit handy? i'd like to play around with it a bit when i get some time
<jcristau> superm1: 66fb2530
<superm1> thanks jcristau 
<jcristau> np
<Ng> bryce: I figured as much ;(
<bryce> Ng: if you know of specific patches/fixes that should  be backported, I'd be game
<Ng> bryce: I don't suppose there are any magic tools that'll help me build the driver between whatever is in jaunty and current git?
<bryce> sort of a wip but there is scripts in xorg-pkg-tools that does it
<bryce> Ng: but basically apt-get build-dep xserver-xorg-video-intel, grab the git snapshot, autogen.sh, copy over the debian directory, and debuild to get a deb as usual
<bryce> assuming you want to keep everything maintained by the packager; if you don't care, build/install from git should work too, although there may be some ./configure differences
<Ng> bryce: I'll see what I can turn up. I guess a good initial thing would be to just diff the sources, but my guess is there will be a fair number of changes
<bryce> Ng: indeed.  git log and git show can be helpful
<tjaalton> bryce: 'cd po; make xkeyboard-config.pot' would generate the potfile
<bryce> tjaalton: mm, ok, any reason not to make the package do that automatically?
<bryce> Subject: Announcing the Next Ubuntu Hug Day! - April 02 2009
<bryce> This week's HugDay target is *drum roll please* xorg-server and xserver-xorg-video-intel!
<bryce>  * https://wiki.ubuntu.com/UbuntuBugDay/20090402
<tjaalton> bryce: I guess the build has changed
<jcristau> it looks like the pot file is not usually needed for the build, and isn't shipped in the upstream tarball.
<tjaalton> yeah, so I'm not sure how launchpad wants it..
<tjaalton> bryce: that's going to be a busy session ;)
<bryce> hope so
#ubuntu-x 2009-03-31
<pwnguin> how the hell does evdev work?
<pwnguin> im getting pushback from scottk on closing a bug about requiring root prives to use uinput; im wondering if evdev solves anything
<tjaalton> pwnguin: which bug
<tjaalton> bryce: so is the pot file in the binary now or just the source package?
<tjaalton> bryce: xkeyboard-config..
<pwnguin> bug #312957
<ubottu> Launchpad bug 312957 in cwiid "CWiid Version 0.6.00 unable to open uinput " [Undecided,Invalid] https://launchpad.net/bugs/312957
<tjaalton> does it work in jaunty?
<tjaalton> in intrepid evdev grabbed the input devices
<tjaalton> but doesn't do that anymore in jaunty
<pwnguin> it works as well in jaunty as it ever has
<pwnguin> the problem is that the program uses uinput
<pwnguin> which is a security black hole
<tjaalton> ok
<tjaalton> well, I don't know about that :)
<pwnguin> the conclusion ive come to is to just use sudo and be done with it
<pwnguin> user beware
<tjaalton> well, the package could use policykit to use the plugdev group for the device
<tjaalton> erm
<tjaalton> no policykit needed there
<tjaalton> PK adds the group for the active user
<pwnguin> when i spoke with scott remnant a year or longer ago
<tjaalton> or something like that
<pwnguin> This implies to me that any user could insert input events to your X server, and thus click on any part of the screen, etc.
<pwnguin> These permissions are definitely inappropriate.
<tjaalton> heh, ok then
<pwnguin> im not about to overrule the udev maintainer ;)
<tjaalton> so the driver is faulty
<pwnguin> there's no way from here to there
<pwnguin> im wondering if evdev works substantially differently
<tjaalton> doesn't use uinput
<tjaalton> anyway, afk->
<pwnguin> the uinput.h does say it's substantially copied from evdev
<pwnguin> so they cant be all that different in practice ;)
<pwnguin> g'nite or whatnot
<tjaalton> night
<bryce> tjaalton: just the source package
<tjaalton> ok
<bryce> I trust that's sufficient for rosetta
<tjaalton> probably is
<bryce> fwiw, it wasn't as simple as just running make <foo>.pot; it seems this part of the makefile has bit rotted some
 * bryce -> bed
<Ampelbein> tjaalton: hi. could you have a look at bug #352335, please?
<ubottu> Launchpad bug 352335 in xserver-xorg-input-acecad "FTBFS due to xserver-1.6" [High,Confirmed] https://launchpad.net/bugs/352335
<Ampelbein> I added a patch and would like you to check if it's ok.
<tjaalton> Ampelbein: the patch itself does, but it's a lot of changes for just a simple patch
<tjaalton> I'll update them in debian so we can sync them
<tjaalton> there are six input drivers that FTBFS, minus aiptek
<Ampelbein> tjaalton: i had a little chat with bryce yesterday about using or not using quilt
<Ampelbein> i've done the change for aiptek using quilt and he said it was ok.
<tjaalton> sure
<jcristau> Ampelbein: the fix should be as simple as updating to the new upstream
<tjaalton> all those drivers got a new version because of xserver 1.6
<Ampelbein> so do we wait until debian has the changes and sync?
<tjaalton> it's the least effort (for you anyway ;)
<Ampelbein> ok, just thought it would be helping.
<tjaalton> np, it was just delayed on my part
<tjaalton> heh, I already had the git repos cloned
<PolitikerNEU> ah - maybe you can help me here: Is there a kernel including the openchrome-driver so VIA-chips work out of the box?
<laanan> hello, i have a problem getting 3D acceleration with my Intel 945 gfx in Jaunty. i've asked in #ubuntu+1 and was directed here
<tjaalton> PolitikerNEU: there is xserver-xorg-video-openchrome in jaunty, isn't it enough?
<tjaalton> laanan: /var/log/Xorg.0.log plese
<tjaalton> pleAse
<laanan> ok, just a sec
<laanan> tjaalton, (the Driver "intel" was added by me, no change from the default of nothing): http://pastebin.com/m6f83c26b
<tjaalton> laanan: that's xorg.conf
<laanan> tjaalton, oh sorry
<laanan> tjaalton, http://pastebin.com/m29001fee
<tjaalton> laanan: dri is used, so what doesn't work?
<laanan> if it helps, i seemed to have the same problem with a fresh install of 8.10, and changing `Driver "vesa"` to `Driver "intel"` in xorg.conf fixed it. the problem is all 3D accel. apps seem software rendered
<laanan> that is, it's more than just sluggish, frame rates are around 1-2hz for most gl screensavers and games
<tjaalton> what does 'glxinfo| grep direct' say?
<laanan> it says `direct rendering: Yes`, but it said that in 8.10 too and obviously it wasn't (again, adding Driver "intel" fixed it in 8.10)
<tjaalton> adding that shouldn't do anything
<laanan> ok
<jcristau> just pastebin 'LIBGL_DEBUG=verbose glxinfo'
<PolitikerNEU> tjaalton: At least in 8.10 (was openchrome there?) it was not enough - has the situation changed in 9.04?
<tjaalton> PolitikerNEU: try the beta livecd
<PolitikerNEU> tjaalton: I will - the problem it is not my laptop
<laanan> tjaalton, http://pastebin.com/m1b3276ca
<jcristau> so it's accelerated alright
<tjaalton> yep
<laanan> the advice i got for 8.10 did fix the problem, and from what i remember glxinfo was pretty much the same before and after the xorg.conf change
<jcristau> it's not clear to me what the problem is.  you said you wanted 3d accel, you've got that already.
<tjaalton> laanan: gnome or kde?
<laanan> gnome
<tjaalton> try with a new user or purge your compiz configuration
<tjaalton> a livecd would do as well
<laanan> well, for example, glxgears gives me around 300fps now, it was the same with 8.10 before the change. after the change glxgears in 8.10 runs at over 5 times the speed
<tjaalton> glxgears is not a benchmark
<jcristau> pick another example
<laanan> it's just an indicator, the skyrocket screensaver gets around 1-2hz, GtkRadiant is almost unusable as well
<laanan> tjaalton, could you explain purging my clmpiz configuration ?
<tjaalton> laanan: probably in too many places I don't know.. just create a new user and try there
<tjaalton> or try without the effects (ie. with metacity)
<laanan> ok, well i have None checked in Appearance/Visual Effects.. i will try to create a new user
<tjaalton> you need to log out and log back in as that user, quick switch to it basically means you got no DRI
<tjaalton> in that session
<laanan> ok
<laanan> hmm, no change. this problem is not a large issue for me, as 8.10 works fine for the most part. i just wanted to try Jaunty since it seems there was a bug fixed in Mesa affecting one of my apps
<laanan> thank you for the help though, i appreciate it
<tjaalton> you could try the mesa packages at https://edge.launchpad.net/~tjaalton/+archive/ppa
<laanan> i can use those with Intrepid ?
<tjaalton> no
<laanan> oh, well from what i gather the bug was unrelated to this current issue
<laanan> (and i am a Linux newbie, so i'm a little over my head here anyway :))
<tjaalton> try a livecd, it should work there
<tjaalton> if not, then it's a bug
<laanan> that's what i tried first (the daily build), same problem
<tjaalton> ok
<laanan> it was explained to me that my previous 8.10 install was using the generic vesa driver, and was slow even tho direct rendering was enabled. i figured it was the same situation here but apparently not
<tjaalton> vesa doesn't support dri
<laanan> yeah, that was the reason was everything crawled there
<laanan> for me, apparently i need `Driver "intel"` in 8.10 for everything to work as it should.. are you saying that (if everything is goes well) i don't need that in 9.04 ?
<tjaalton> you shoudn't need that in 8.10 either
<tjaalton> just remove the line
<laanan> ok, i will try that the next time i am in 8.10. (but the problem still remains with or without that line in 9.04)
<laanan> anyway, if i have time and can get it sorted out, i will come back and let you know. thanks again
<tjaalton> np
<Ng> hmmmm
<Ng> tjaalton: interesting data point, I just booted a live CD... compiz stuff seems fine :/
<Ng> so something about my setup which has no appreciable xorg.conf, or .drirc or interesting compiz settings, is very much worse
<tjaalton> Ng: there you go, upgrades ftl :)
<Ng> this could also explain why the 965 belonging to the guy next to me is nowhere near as badly affected as mine
<Ng> tjaalton: well, I'm not sure it's 100% conclusive, there will be a lot more happening on my install than a live CD
<Ng> but I am now very tempted to do a full re-install ;)
<tjaalton> heh
<Ng> aha! a more comparable test from the live CD still shows the same juddering
 * Ng feels vindicated and re-assured ;)
<BUGabundo> bryce: ping
<BUGabundo> how are we with support for intel 8x5 for jaunty?
<bryce> BUGabundo: piss poor at the moment
<bryce> BUGabundo: do you have feedback on it?  I asked on the list for input from any 8xx owners but no one responded
<BUGabundo> thanks bryce
<BUGabundo> i changed xorg to use DRI false
<BUGabundo> and i can use this test PC
<BUGabundo> i have a bunch of then to install until saturday
<bryce> BUGabundo: what chipset?
<BUGabundo> bryce: 865
<BUGabundo> i comment on the bug
<BUGabundo> do u need any further testing?
<BUGabundo> i guess i could give u reverse ssh to it or something
<bryce> I'm going to limit 304871 to just 845 graphics
<bryce> which I think is fixed now
<bryce> 865 will need a separate bug report
<BUGabundo> ok
<bryce> 317457 maybe
<BUGabundo> is it opened yet?
<bryce> BUGabundo: have you filed one for this issue?  If so I'd prefer making that the master since you're more active
<BUGabundo> i did not
<bryce> otherwise I guess we can use 317457
<bryce> ok
<BUGabundo> thats why i came here 1st
<BUGabundo> ok, i'm subed to it now
<bryce> 328528 is UXA lockup on 865
<bryce> I've not decided if that's a dupe, I think it may be a separate issue.  You have that one too?
<BUGabundo> let ne see
<BUGabundo> bryce: i didnt mess much on this xorg
<BUGabundo> just added dri
<BUGabundo> bryce: is there any thing i can do to make this card run compiz?
<bryce> BUGabundo: can you try the Legacy3D "false" option mentioned in the bug report?
<bryce> BUGabundo: did you already try option "AccelMethod" "UXA"?
<BUGabundo> no i did not
<BUGabundo> let me see if i can do it
<BUGabundo> ok now where do i need to add that stuff?
<jcristau> device section of xorg.conf
<BUGabundo> but keep dri false?
<jcristau> not if you want compiz
<BUGabundo> oh
<bryce> you can try them both together if you want but disabling dri sort of cancels out uxa
<BUGabundo> so i add legacy3d and uxa
<BUGabundo> is this ok? http://paste.ubuntu.com/141679/
<bryce> BUGabundo: can you also try each of those two options separately?
<bryce> I'd like to know if Legacy3D will solve your issue without also having to go to UXA
<BUGabundo> sure
<BUGabundo> i'll just make dinner wait a bit more
<bryce> no prob
<BUGabundo> killing X now
<BUGabundo> with both i can login
<BUGabundo> commenting 3d
<BUGabundo> spoke too soon
<BUGabundo> system froze
<BUGabundo> bryce: having both seems like a bad choice on 865
<bryce> :-/
<bryce> yeah not many good reports of UXA on 965
<bryce> er 965
<bryce> dah
<bryce> 888865
<bryce> BUGabundo: try with only Legacy3d
<BUGabundo> rebooted
<bryce> I don't expect that will work, but if it does we're golden since I have a patch for that already
<BUGabundo> and repeated the same thing
<bryce> ok so, the only thing that has worked has been disabling DRI?
<bryce> (which disables compiz)
<BUGabundo> bryce: now testing with only 3d
<yow|x2> i dont use compiz, id be happy to test BUGabundo 
<BUGabundo> after that i can try wit only uxa
<bryce> yow|x2: what chipset do you have?
<yow|x2> intel ich7
<BUGabundo> bah
<BUGabundo> critical bug... Delete will not send to trash
<yow|x2> 945gm / 945gms for video
<bryce> yow|x2: we're only looking at 8xx for this, but thanks.
<BUGabundo> bryce: just 3d i have a black background
<BUGabundo> see top and bottom bars
<BUGabundo> mouse moves
<yow|x2> ack. gotta figure out why im getting freezing so much
<BUGabundo> bryce: want me to test just UXA now?
<BUGabundo> cant even jump to TTY
<bryce> BUGabundo: if you'd like; we already decided we're not going to do UXA, and I'm pretty sure it won't work for you
<BUGabundo> alt+sysqr+K just showed blue screen
<BUGabundo> then black
<bryce> yeah that's because the kernel kills X but doesn't know how to reset the graphics card to a sane state
<bryce> probably have to reboot
<BUGabundo> bryce: FAIL
<BUGabundo> UXA wont work on this system
<BUGabundo> just DRI
<BUGabundo> any more combos u need me to test?
<bryce> nope, that should do it
<bryce> ok, I'll go with the disable DRI patch for 865 then
<bryce> shame to lose compiz and 3D on that chipset, but better that it not freeze up
<BUGabundo> so no compoiz?
<BUGabundo> ohh my students wont be able to play with it!
<bryce> BUGabundo: there was one reporter that said he resolved it on 865 by booting a 2.6.27 kernel
<bryce> so you could try that, if you just want to be able to show it off
<bryce> er wait that reporter was on 855
<bryce> still, booting an earlier kernel might be worth trying if you have one handy
<BUGabundo> bryce: no change. this is a daily jaunty image
<bryce> hrm, too bad
<bryce> tjaalton, superm1: either of you know if anyone is going to up us to the latest -nvidia?  Or should we be skipping it?
<superm1> bryce, from the looks of it, it's bug fixes, but i'm not positive
<bryce> I've seen several positive reports around it, and judging from the rate of new bugs against nvidia-180 so far, we could use bug fixes there
<superm1> bryce, yeah especially KDE plasma fixes
<bryce> good god, xorg is up to 35 bugs after just a couple weeks
#ubuntu-x 2009-04-01
<stgraber> bryce: do you know of cases where glxinfo is extremely slow ?
<stgraber> like a few mins to run
<bryce> stgraber: glxinfo?  hmm
<bryce> in general glx can be slow to run if software rendering is enabled, but even there glxinfo should be quick
<stgraber> yeah, it's making the session open time to go up to a few minutes because compiz is calling glxinfo a few times
<bryce> no, this is not a bug I've run across so far
<bryce> did you find any bugs about it in LP?
<superm1> that sounds like something that might happen with a half installed -fglrx?
<stgraber> that's on an Intel classmate, I believe you're familiar with the hardware ? (a few person at Canonical got one at UDS-Boston)
<superm1> oh nvm
<stgraber> that's with 100% intel hardware :)
<bryce> stgraber: no I've not touched the classmate myself
<stgraber> hmm, I guess I just found the issue, not sure if it's a bug actually.
<stgraber> glxinfo doesn't work if the current vt isn't X
<stgraber> so having X start in background, glxinfo doesn't work until I switch to vt7
 * stgraber notices that the classmate doesn't have a pause/sysrq key ...
<tjaalton> bryce: don't know if tseliot is working on it
<tjaalton> but we're an "all-nvidia" shop :( so I'd be interested in seeing a new bugfix release..
<tjaalton> (we = HUT)
<bryce_> tjaalton: ok, well it's been quite a while since I did a -nvidia release.  I'd be game to give it a go, though.
<tjaalton> bryce_: yeah, I'm willing to try as well
<tjaalton> got a 8600GT to try it on
<tjaalton> but first the couple of input drivers..
<tjaalton> bryce_: acecad, aiptek, fpit are now in experimental, elographics, penmount, void pushed to git and waiting for an upload
<bryce_> excellent
<tjaalton> uploaded mesa with the texture bump to my ppa 
<tjaalton> +size
<bryce_> nice
 * bryce swats a couple more -intel bugs
<tormod> bryce: re your ML post, I think "taking on tasks" scares everybody to silence :)
<bryce> it's ok, if no one volunteers I have a fallback plan for 8xx.  It's just pretty nasty.  Want to give 8xx users a chance to help grind grain before I start taking the bread away from them.  ;-)
<tormod> tjaalton: maybe you can consider 324854 (uxa) for your mesa ppa
<tjaalton> tormod: seems a bit invasive
<tjaalton> and since uxa is not used by default..
<tjaalton> what's the commit-id?
<tjaalton> nevermind, got it
<tormod> ok. if it only would touch uxa code it wouldn't be so bad, but I am not able to judge from the patch
<Ng> tormod: thanks for doing the xorg-edgers PPA, it's very handy :)
<tormod> Ng: you're welcome :) hope I will get some co-uploaders some time
<Ng> tormod: do you happen to know offhand how huge the difference is between -intel 2.6.3 and 2.6.99/git?
<tjaalton> tormod: well, looks like it should affect only DRI2, which means EXA users are safe
<Ng> tormod: I promised bryce I'd see if I could figure out what's changed between jaunty's package and yours that makes my 965 much nicer, but if it's going to be thousands of lines of diff then I'm probably going to fail ;)
<tormod> Ng: git diff would tell you, but yes, it is quite a lot of code
<tjaalton> git bisect is your friend
<tormod> yes that should actually be efficient here
 * Ng should read up about that
<mifritscher> hi
<Ng> ohhhh, nice, bisect does the middle-point searching thing
 * Ng wonders if it'll be happy to go backwards though. the kernel.org docs are mostly about "current is broken, current-20 worked, find where it broke", where I need to work out where's it's fixed between 2.6.3 and 2.6.99
<tjaalton> sure will
<Ng> win :)
<Ng> so with my fresh checkout of git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel how would I figure out which commit corresponds to 2.6.3?
<Ng> aha, there's a tag
<bryce> ok, 18hrs of bug work is enough for one day.  cya tomorrow.
<bryce> %-P
<tjaalton> heh :)
<mifritscher> hi
<Ng> so 2.6.3 seems to be about 3 months ago
<Ng> which works out to 8k5 lines of diff ;)
<mifritscher> yust tested the 2.6.99 on  https://launchpad.net/~xorg-edgers with a g965
<mifritscher> all works well, but the 3dmark01
<mifritscher> still stable, but extrme, simialiar aartefacts on all tests (old objects which got moved are still there)
<mifritscher> Im running9.04
<Ng> mifritscher: out of interest, is the jaunty intel driver working ok for you?
<mifritscher> yes
<mifritscher> but the 2.6.3 has a funny dependencie on pae
<mifritscher> uxa runs only without pae, exa DOES need pea *G*
<mifritscher> (with 4 GB ram)
<mifritscher> didn't try that with 2.6.99 again, I've running it without pae + uxa
<Ng> I only have 2GB of RAM, I'm just trying to work out why 3d stuff is a bit slow for me, but not for everyone :)
<Ng> (works fine with the edgers PPA, but like you I see some artifacts, and I've had a couple of X hangs)
<mifritscher> hmm, 3dmark01 gave me 1280 points on 2.6.3 and 1484 points on 2.6.99
<mifritscher> on VIsta I got 3783
<mifritscher> trac gets ca. 20 fps (and no artefacts)
<mifritscher> trying 2003 *G*
<Ng> is 3dmark available freely for linux? it might help my case if I can produce objective numbers rather than subjective workspace-flipping tests
<mifritscher> killed X right after starting the program (not the acutal test)
<Ng> would we expect 2.6.3 to work with a snapshot of libdrm? I just realised that both of those will have been replaced by the edgers PPA so the fix I need could be in either. I know it can't be mesa because I tried tjaalton's 2.4 packages and there was no change
<mifritscher> backtrace: http://rafb.net/p/i3S8KQ46.html
<mifritscher> now it starts, but it is missind DXT1 and DXT3 texture compression
<mifritscher> (as with the old driver)
<tormod> Ng: newer libdrm should be fine for intel 2.6.3
<mifritscher> tormod, you are one of the maintainers of https://launchpad.net/~xorg-edgers/+archive/ppa, right?
<tormod> mifritscher: de facto the only one
<mifritscher> is the artefacts problem already known or do you need more details?
<mifritscher> ah ;)
<tormod> you have to check upstream. that's the point of this PPA :)
<mifritscher> #intel-gfx is sort of dead :-/
<tormod> it's the time of day
<tormod> check the bug tracker as well
<mifritscher> didn't found anything
<mifritscher> ( http://bugs.freedesktop.org/buglist.cgi?quicksearch=Drivers%2FDRI%2Fi965 )
<mifritscher> and for the pae I found only http://bugs.freedesktop.org/show_bug.cgi?id=17993
<ubottu> Freedesktop bug 17993 in Driver/intel "[GEM] kernel with PAE panics when starting X" [Normal,Assigned]
<mifritscher> but for me it is the other way around: I actually need pae to use exa ;-)
<mifritscher> (for uxa, I must not use pae)
<BUGabundo> bryce ping
<BUGabundo> what about intel 815? is there a master bug for it?
<jcristau> the i815 driver hasn't changed in years afaik
<thiebaude> i hope someone might help me, i cant log into gnome, but only fluxbox
<thiebaude> i have the i815
<hyperair> thiebaude: wrong channel
<BUGabundo> hyperair: actually I asked him to come here
<hyperair> eh?
<thiebaude> BUGabundo sent me over here
<BUGabundo> with all this intel probs on 8x5
<hyperair> well yeah but fluxbox works
<hyperair> obviously X starts
<jcristau> BUGabundo: 810 is completely separate
<thiebaude> i thought i had the bug 304871
<ubottu> Launchpad bug 304871 in xserver-xorg-video-intel "[i845G] Fatal server error: Couldn't bind memory for BO front buffer (Jaunty)" [High,Fix released] https://launchpad.net/bugs/304871
<thiebaude> its halfway fixed
<BUGabundo> thiebaude: can you try to logout and select Safe Gnome Session?
<jcristau> thiebaude: if your chip is a 810/815, then that bug is irrelevant
<thiebaude> ok thanks again BUGabundo
 * BUGabundo goes back to +1
<thiebaude> see you
<BUGabundo> guys sorry for the noise
<BUGabundo> but thiebaude is reproducing the bug
<BUGabundo> of X freezing a few secs after login
<BUGabundo> with a 815... it looks pretty much like all other 8x5
<BUGabundo> what can he do to debug it?
<jcristau> BUGabundo: i already told you, 815 is not like all other 8xx...
<BUGabundo> but symptoms are very much the same
<BUGabundo> on gnome , at least
<thiebaude> i can only get into fluxbox
<mnemo> will mesa 7.4 be included in time for the testday tomorrow?
<Ng> bryce: how much will I be mocked if I suggest rolling jaunty back to Intrepid's intel driver? :D
<Ng> is such a thing even possible?
<Ng> I fully appreciate that my view of the driver is very small and I may be missing wider issues, but I've yet to encounter anyone with an improved experience, but I am encountering lots of regressed ones
<Ng> where "lots" is an unquantified value
<Ng> so I just thought I'd throw the idea out there
<jcristau> you'd probably have to revert the kernel, too...
<Ng> jcristau: as in, patches we've applied to the kernel? or does intel's 2.4.x simply not work on a 2.6.28 kernel?
<Ng> (I really wish they wouldn't have release numbers that are so confusingly similar to kernel ones ;)
<jcristau> as in, "it worked better in intrepid" is not only related to the intel ddx, that's only one component
<jcristau> so 2.4.x with 2.6.28 might work, but it might not work better than what you have right now, and it is probably not as tested
<jcristau> so i'm just saying it's hard to know beforehand what will work best :)
<Ng> ok, these are good points :)
<Ng> I have the impression that we are somewhat stuck between a rock and a hard place until we are fully in the land of UXA and KMS!
<Ng> which can only really be Intel's fault, imho
<jcristau> i get the feeling we're between a rock and a hard place until we are until the next rock and the next hard place :/
<jcristau> s/until/between/2
<Ng> heh
<Ng> surely after we're all using DRI2 and UXA and KMS there's no more big architecture stuff and Intel will actually fix bugs? :)
<Ng> they seem to have been bug fixing a lot recenlt
<bryce> Ng: well, back when we were on XAA and Intel was pushing EXA I remember thinking, "Once we're fully in the land of EXA, Intel will fix all their bugs, and it will be all milk and honey after that."
<bryce> so I disoptimistically have to agree with jcristau
<bryce> Ng: also even if reverting to the Intrepid driver were feasible, it would also result in losing some hardware support for newer hardware
<Ng> bryce: you're filling me with confidence here, man ;)
<Ng> bryce: if you're on -platform you will shortly get a horrific braindump from me of what I'm seeing and trying to do about it. It's a mess of information which I apologise for, I just wanted to braindump everything I have about it in the hopes that something good can come from it!
<bryce> I unsubbed from platform when I moved to the desktop team
<bryce> so you might cc ubuntu-x@ if you think it's worth me reading
<Ng> ah right, so everyone on platform won't care. go me ;)
<Ng> sent to -x :)
<bryce> ok, bating breath and waiting
<Ng> I really should subscribe to -x
<bryce> yep
<Ng> hah, especially since that mailman reply was not "lala wait for moderation", but "go away" ;)
 * Ng subscribes and resends
<bryce> heh
<tjaalton> Ng: the mesa version on my ppa is 7.4 ;)
<tjaalton> not 4.3
<mnemo> bryce, tjaalton: what is the mesa 7.4 ETA right now? also, I heard a rumor that EXA perf might be fixed by some patch that disables GEM, have you heard that as well?
<Ng> tjaalton: doh, I fail ;)
<LLStarks> ...
<bryce> mnemo: tjaalton has put 7.4 in his ppa.  I think he is awaiting sufficient tester feedback before putting it in
<LLStarks> bryce.
<LLStarks> i
<LLStarks> i'm having trouble with my intel git compiles
<LLStarks> i have all the deps and followed directions, but x breaks.
<albert23> mnemo: switching of gem plus an additional patch on -intel indeed fixed performance with I945 for me.
<albert23> mnemo: debdiff http://paste.ubuntu.com/142337/
<albert23> patch 203 was accepted upstream 2 days ago
<bryce> LLStarks: sympathies
<LLStarks> any advice?
<bryce> albert23: bug# ?
<albert23> bryce: freedesktop bug 20797
<ubottu> Freedesktop bug 20797 in Driver/intel "[i945] Performance regression in 2.6.3 from 2.6.1 with non-gem kernel" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=20797
<bryce> LLStarks: I recommend nuking from orbit, it's the only way to be sure
<LLStarks> ...wut?
<bryce> albert23: thanks
<albert23> bryce: performance on 945 is 303011
<bryce> LLStarks: oh you mean advice on your build issue?  you didn't show any details so I can't give any advice.  I do advocate nuking from orbit as a general solution to random build problems though.  It helps.
<LLStarks> there's no problem with the actual build.
<LLStarks> i just can't get the binaries to start x.
<bryce> albert23: thanks for the performance bug; is there also a corresponding launchpad bug (so I can set up subscriptions and such)
<bryce> LLStarks: you can't find the binaries?
<albert23> bryce: no, I didn't consider it an Ubuntu bug, as jaunty does have gem
<albert23> that patch only helps if you switch of gem
<LLStarks> no. they just won't start x when i restart.
<LLStarks> they are pathed to /usr
<bryce> LLStarks: try http://wiki.ubuntu.com/X/Troubleshooting/.
<bryce> albert23: give that we're not using uxa, I wonder if it hurts anything to turn off gem as well
<albert23> bryce: see the debdiff. UXA still works :-)
<bryce> hmm, I thought gem was a prerequisite for UXA
<albert23> bryce if (pI830->accel == ACCEL_EXA is the trick
<albert23> see the pastebin
<LLStarks> does the debdiff work with the 2.6.99 ppa packages?
<LLStarks> also, does the patch negate the need for anholt's pending a17 fix?
<albert23> bryce: my concern would be that the fake bufmgr code hasn't been tested in jaunty
 * bryce nods
<albert23> LLStarks: the debdiff has two parts. 1 switch of gem, 2 the TILE_NONE fix
<albert23> LLStarks: the a17 fix should fix gem, so you don't need the first part anymore
<LLStarks> i see.
<LLStarks> so the patch right now is just a stop gap?
<albert23> for me it is
<albert23> and I am really not sure if it would be good for jaunty, given where we are in the release cycle
<LLStarks> i severely doubt a performance patch would be denied a freeze exemption
<albert23> LLStarks: btw, latest intel from git needs libdrm 2.4.6 and kernel 2.6.29
<LLStarks> i knew  about 2.4.6
<albert23> I needed a patch to build with kernel headers from 2.6.28 and it still only runs on 2.6.29 kernel
<LLStarks> but not the kernel
<LLStarks> i do have a few mainline and self-built 2.6.29 kernels.
<LLStarks> i don't think i got intel to work with those either.
<LLStarks> hi.
<LLStarks> i just uploaded some photos for my lvds bug: freedesktop bug 20951
<ubottu> Freedesktop bug 20951 in Driver/intel "[945GM] Fullscreen graphical corruption on LVDS" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=20951
<LLStarks> hopefully they are helpful
#ubuntu-x 2009-04-02
<Ng> soo
<bryce> oso
<Ng> my performance issue has to do with EXA, not particular versions. 2.6.3 and the git snapshot both show it when set to EXA. Setting either to UXA pretty much completely eliminates the slowdowns
<Ng> which doesn't really help us, I suspect
<Ng> I sure wish I'd thought to check it wasn't that before I bisected 3 months of the git tree ;)
<Ng> on the upside, I know now how to bisect and I also know that checkinstall does a good job of building a IDON'TCAREJUSTMAKEITWORK package for such testing :)
<Ng> I think I've missed Sciri at this point, but I've left him a message to flip over to UXA to see if his 950 speed problems are the same, and I'll check Matt's X61 tomorrow if he's in the office
<Ng> but having used UXA myself for a few days I don't think it's really in a usable state yet. I'd rather they were slow than crashy
<Ng> (and I'll do a followup to platform and -x about this)
<bryce> Sciri?
<Ng> Sean (OEM sysadmin in Lexington)
<bryce> Ng: ok, sounds like you've arrived at the same general conclusion as the rest of us
<Ng> heh, I do like to be fashionably late to the party ;)
<bryce> :-)
<Ng> do we know when Intel are likely to next cut a release?
<bryce> I think 2.7 should be here any day now, not sure of the exact schedule but I think it's this month
<Ng> perhaps we could do a semi-official PPA of that for affected souls?
<Ng> and by "we" I mean "someone who can do a good job of that, so not me" ;)
<bryce> that said; we've been burned by poor qa troubles with 2.5.0 and 2.6.0 so while I trust cworth will do a great job, experience so far suggests waiting for the .1
<bryce> Ng: ah, did you check the xorg edgers ppa?
<bryce> fairly sure tormod has bleeding edge -intel in there
<Ng> yep, that's what I used initially to try out UXA, and mistakenly latched onto the idea that it was the newer code that was saving me, rather than just UXA
<bryce> ahh
<bryce> ok that starts to make more sense, and seems consistent with most of the data we've gotten so far
<Ng> for my part I'd rather have everything lovely in the future, so regardless of the results I see from Matt/Sean I'm going to stick with git and see if I can catch the hang bug(s) I had with from tormod's, so at least we can be damn sure we can use UXA for karmic
<Ng> err, "I had with UXA/git"
<bryce> good man
<Ng> my desktop is sufficiently stateless that I can weather the crashes, and the slowness drives me crazier than they do
<bryce> also make sure as you file bugs, to ensure they're also forwarded upstream
 * Ng nods
<bryce> I've been deliberately not doing this with UXA bugs, to stay focused on jaunty issues, and because I know it'll take a lot of back and forth troubleshooting which I don't want to be the bottleneck for
<bryce> but getting the bugs upstream is the best chance we have to make all this better in karmic
<Ng> I had an idea on the bus home that maybe we could encourage/sponsor a compiz plugin for stress testing desktop operations. development releases could have a special extra GDM session that fires up a bunch of apps and just goes at a load of windowing operations as fast as possible and measures the results, as well as potentially pushing it into crashing without the reproduction steps being "uhh, I
<Ng> just kinda use my computer for a few days"
<LordMetroid> S-video support is there any way to make it automatic?
<LordMetroid> Cause xrandr denies me usage
<bryce> Ng: yeah we need that sort of stress tool to help make bugs more easily reproduced
<bryce> LordMetroid: see the config page in the Ubuntu-X wiki
<LordMetroid> I did
<LordMetroid> it didn't work
<pwnguin> heh. i think larabel just volunteered to be the xorg release managemener
<bryce> pwnguin: ?
<bryce> ah, in the he-who-complains vein
<pwnguin> yea
<bryce> hmm at least the ubuntu 9.04 beta vs. fedora 11 comparison turned out in our favor
<bryce> although I notice he didn't include gl performance comparisons
<Ng> bryce: that's interesting, I would have guessed they'd be similar or f11 slightly ahead through having newer bits
<seb128> Ng: what is f11 using?
<Ng> seb128: afair they're using a newer kernel for KMS
<mnemo> they also have mesa 7.5-devel and intel ddx 2.6.99
<mifritscher> hi
<mifritscher> the 20090326 version of https://launchpad.net/~xorg-edgers/+archive/ppa worked for me, but not the current
<mifritscher> (uxa mode crashes somewhere in UXA_polygon_something)
<mifritscher> (sorry, xorg already killed the log)
<mifritscher> on 4 gb ram without pae, which workd on the 0326 version
<mifritscher> +g965
<mifritscher> xaa+exa with pae still works, but crashes/hangs with 3dmark2001
<mifritscher> a8and has the same artifacts as in uxa with the 26 driver)
<mnemo> mifritscher: please open a bug on bugs.freedesktop.org and mention the info you just gave
<mnemo> output of "uname -a", "lspci -nn | grep VGA", "dmesg" is also useful
<mnemo> plus xorg.log, xorg.conf and ~/.xsession-errors
<Ng> tjaalton: in case your mesa goes into jaunty, https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/324854 may want to be looked at (I've not checked the code, but with your mesa I see the symptoms, and didn't with tormod's 7.3+git which has that stuff cherrypicked)
<ubottu> Launchpad bug 324854 in xserver-xorg-video-intel "DRI2: (UXA) white transparency artifacts with compiz [patch]" [Undecided,Invalid]
<tjaalton> Ng: yeah, there's another bug open already
<tjaalton> uh no
<tjaalton> this is the one
<Ng> I just figured I'd mention it :)
<tjaalton> hmm so I didn't push it
<tjaalton> the patch is on my repo
<tjaalton> I've been on a "sick" leave the past two days, tending the kids
<tjaalton> so haven't given much thought about how to actually get this in jaunty
<Ng> :/
<Ng> hope everyone is recovering :)
<tjaalton> the noise level is getting higher, so I'd say so
<Ng> hehe
<tjaalton> forgot :)
<tormod> Ng: the 7.3+git from xorg-edgers should be pretty much the same as 7.4
<tormod> but timo's 7.4 has some Ubuntu patches
<tormod> did you also check with the different libdrm2's btw?
<Ng> I did all of my testing last night with the -edgers drm
<Ng> EXA => fail in all cases, UXA => win in all cases (where "fail" means "slow, but works" and "win" means "fast, but may render badly or hang or segfault on resume" ;)
<tormod> Ng, I was thinking about the symptoms you mentioned 15:28
<tormod> oh sorry that was my own PPA, not xorg-edgers that you mentioned
<tormod> or maybe not
<Ng> tormod: I had tjaalton's mesa installed and an edgers ddx, and I was seeing the split-second white rendering
<Ng> tormod: just flipped over to your mesa and indeed that is fixed
<tormod> Ng: flipped to xorg-edgers mesa? or downgraded to my ppa mesa which I mention in that bug report?
<Ng> tormod: flipped to edgers mesa
 * Ng all edgers atm, although not the very very latest ddx because I need to work and don't want to potentially hit the problem mifritscher was having earlier
<tormod> did mifritscher report it upstream? has anyone confirmed it?
<Ng> it was suggested that he report it upstream, don't know if he did yet
<Ng> I'll certainly upgrade to the new snapshot tonight
<tormod> I got confused because I forgot that I cherrypicked 661775aa in both ppas...
<Ng> his problem may be related to having 4GB and no PAE, but I'm not sure
<seb128> hi tormod
<seb128> tormod: do you need any other information about this intel crasher?
<tormod> hi seb128, I don't think I get further myself
<tormod> either the devs recognize something or someone needs to debug hands-on
<tormod> since it is so reproducible, some gdb watchpoints might work
<tormod> but I do not know how many unrefs there are on a VT switch to keep track off
<tormod> maybe valgrind could help?
<seb128> I tried to valgrind the xorg server without luck
<tormod> xorg is allergic to debugging
<tormod> one could set up some gdb stuff to log every unref with some info
<seb128> what variable should be watched?
<jcristau> there's a libdrm patch to help with valgrind
<jcristau> it's been posted recently on intel-gfx@
<tormod> seb128: yeah you only know that afterwards :)
<seb128> jcristau: well I got issue with valgrind complaining about setuid too
<seb128> jcristau: do you know how to workaround that?
<seb128> I manage by some way but they I had nothing in the xorg log out of the X command and argument
<seb128> no error, etc
<seb128> it seems valgrind exit or something
<tormod> a gdb "breakpoint command list" could be used at the unref function
<tormod> I'd suggest at first just to count the number of calls to see if it's worthwhile, if it's only a few then log the caller and object address on each call, to see which two callers want to free the same object address
<seb128> right
<seb128> I will do that
<tormod> but in many cases the right developer will recognize his mistake when he sees such a symptom, and fix it faster than any debugger in-from-the-cold can do
<seb128> let's see, the bug seems to have enough informations but nobody is picking it up yet
<tormod> seb128: if you're successful with gdb, please send me the gdb session, so I can learn how you do it
<seb128> ok will do
<jcristau> seb128: run valgrind on /usr/bin/Xorg instead of the wrapper, i guess
<seb128> jcristau: that's what I did, I renamed Xorg to Xorg.binary and create an Xorg wrapper calling valgrind
<tseliot> federico1: did you have a look at the final version of my patch? http://bugzilla.gnome.org/show_bug.cgi?id=568160
<ubottu> Gnome bug 568160 in libgnome-desktop "Gnome Settings daemon causes high CPU usage with an expensive call" [Major,Unconfirmed]
<federico1> tseliot: oops, no - thanks for the reminder
<tseliot> federico1: np
<federico1> let me see if I can finish something in gnome-panel really quickly and I'll get to it
<tseliot> bryce or bryce_: can you upload the new nvidia driver, please? The source is in comment 5 of this bug report (which is assigned to you): https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/348852
<ubottu> Launchpad bug 348852 in nvidia-graphics-drivers-180 "nvidia driver 180.44 is available" [High,Triaged]
<bryce> tseliot: will do
<tseliot> bryce: thanks a lot :-)
<bryce> tseliot: uploaded
<tseliot> bryce: thanks a lot
<bryce> tseliot: also requested all -180 bug reporters do a retest
<tseliot> bryce: good idea :-)
<tseliot> just to be sure
<tormod> seb128: are you gdbugging? :) actually which line of gen4_render_state_cleanup explodes?
<seb128> no I'm not and I don't have the computer with the intel card with me now
<seb128> did you read the bug comments?
<seb128> I've wrotten what free leads to crash there
<seb128> and bryce copied the corresponding code
<seb128> I will put a break on the free call tomorrow
<seb128> and get a bt for each call
<tormod> seb128: yes I saw it was line 1727, just want to make sure it is the same line number in my code
<seb128> I wrote in a comment what line is the crash one
<seb128> let me open the bug
<seb128> "the crash is on "free(block);" in free_block()"
<seb128> intel_bufmgr_fake.c:473
<seb128> in the current jaunty source
<tormod> seb128: is the calling line in gen4_render_state_cleanup I wonder about
<tormod> this? -> drm_intel_bo_unreference(render_state->sf_state_bo); 
<seb128>     drm_intel_bo_unreference(render_state->sf_state_bo);
<seb128> yes
<tormod> thanks. it would mean the preceding drm_intel_bo_unreference(render_state->vs_state_bo); was fine
<seb128> could be that both calls lead to free the same thing?
<bryce> I contacted Intel about this bug.  I will follow up today.  They said it sounded like something that could be an easy fix.
<seb128> bryce: thanks, I get it every time on my d630 so let me know if you need any debug informations
<seb128> I didn't manage to run the xserver under valgrind yet
<bryce> ok great
<seb128> but otherwise I should be able to get infos ;-)
<seb128> bryce: should I open an another bug about the UXA crash?
<seb128> that one is on guest session opening
<seb128> I mentioned it in the bug because I've been asked to try UXA but that's rather a different issue
<bryce> seb128: yes, although I think there is already one open on it with UXA
<seb128> ok, I will not bother with that one now then
<bryce> if it appears to be different at all, file a new bug (we can always dupe later)
<seb128> I will check for dups and open it directly on freedesktop if there is no similar bug there
<seb128> or do you prefer having it in launchpad too?
<bryce> I do prefer having it in launchpad for tracking purposes
<tormod> seb128: about valgrind and your setuid issues, can't you just run the second "/usr/bin/Xorg :20" as root?
<bryce> with UXA bugs I'm appending "(UXA bug)" to the subjects so we can easily get a list of all open UXA bugs
<seb128> bryce: ok
<tormod> you can reproduce with two barebones X servers right?
<seb128> I did manage to run xserver under valgrind
<bryce> this will be useful in helping make the determination on when UXA is ready to go, and/or prioritize attention to those bugs when we get near to switching
<tormod> ok
<seb128> but I got nothing else that the command and arguments in the log
<seb128> ie no error printed there when it crash
<tormod> bryce, just so that you know, I'll be off and mostly far away from internet the next 12 days or so, in case you see people pinging in bug reports etc
 * tormod goes to the mountains
<bryce> tormod: ok thanks for letting me know.  Have fun, and hope the internet withdrawl symptoms aren't too severe ;-)
<tormod> I'll try to cope with launchpad abstinence
<tormod> cool we have jbarnes on #ubuntu-bugs
<bryce> yeah I'd invited him earlier.  I was hoping we'd be seeing more triaging activity on #ubuntu-bugs, but at least the hug day page is slowly getting filled in
 * Ng tests latest edgers -intel :)
<tormod> Ng: curious if you get the fbFill seen on phoronix forum (UXA)
<tormod> *crash
<Ng> tormod: yup
<Ng> the guy this morning seemed to be seeing something else
<Ng> [13:17] < mifritscher> (uxa mode crashes somewhere in UXA_polygon_something)
<tormod> on phoronix it was uxa_check_poly_fill_rect which sounds like a close relative
<tormod> you get the same backtrace as http://phoronix.com/forums/showpost.php?p=69074&postcount=132 ?
<Ng> 5: /usr/lib/xorg/modules/drivers//intel_drv.so(uxa_check_poly_fill_rect+0xd5) [0xb782a985]
<Ng> tormod: looks the same
<Ng> tormod: I don't see a fdo bug :/
<Ng> forums are such epic fail ;)
<bryce> heh
<Ng> http://pastebin.com/f742caee4 is my log
<tormod> you have all these people posting tons on the forum but never touched a bug tracker :(
<Ng> just gonna quickly ask in #intel-gfx before filing a bug
<Ng> (maybe they're in the middle of something atm and expect it to be broken)
<tormod> Ng: I just asked jbarnes on #ubuntu-bugs
<Ng> ah
<Ng> hrm, not on there
<tormod> <jbarnes> tormod: ah looks like one of the PAT bugs
<tormod>  tormod: try booting with 'nopat'
<Ng> okidoki, re-installing it and rebooting :)
<jbarnes> Ng: I didn't see your whole log... I assume you're on a fairly recent kernel
<tormod> jbarnes: we're talking 2.6.28 here (Jaunty). maybe not recent for intel :)
<tormod> but doesn't 2.6.28 have GEM?
<jbarnes> 2.6.28 should have gem
<Ng> jbarnes: http://pastebin.com/f742caee4 is without nopat, http://pastebin.com/f4e93c41e is with nopat (whole cmdline was root=/dev/mapper/kodachi-root ro elevator=noop quiet splash nopat)
<jbarnes> but it doesn't have the master bits...
<jbarnes> ah I just posted a fix for this to intel-gfx
<jbarnes> "fix offset in begin_gtt_access case"
<jbarnes> care to test for me? :)
<Ng> absolutely :)
<Ng> tormod: hrm, is the -edgers drm actually 2.4.6?
<jbarnes> tormod, Ng: so there are bleeding edge builds of libdrm & xf86-video-intel for ubuntu out there already?
<jbarnes> I've been wanting that for some of my machines here
<Ng> jbarnes: tormod has been doing a PPA with periodic snapshots, deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu jaunty main
<jbarnes> nice, I've been meaning to set up daily builds of git master but haven't had a chance yet
<Ng> jbarnes: your patch seems to work :)
<jbarnes> Ng: great
<tormod> Ng: I added the commit that warranted 2.4.6 to the 2.4.5+ package, and deps for it in -intel
<Ng> tormod: ah good, I was just a bit confused when I tried to test jbarnes's patch against -intel git and it whined my drm was too old, but your package (which currently matches git afaict) built fine :)
<tormod> jbarnes: I have scripts that build xorg pieces pretty much automatically. well, the -intel stuff always needs some hand-tweaking ;)
<jbarnes> tormod: due to bleeding edge dependencies I guess
<tormod> Ng: I commented on the libdrm deps (although not so clear) in the changelog
<tormod> if you look at the PPA, everything is in the changelog, my manual tweaks are marked with "+"
<tormod> https://edge.launchpad.net/~xorg-edgers/+archive/ppa is a better link than the above
<tormod> jbarnes: yes the kernel/kms/libdrm stuff...
<Ng> tormod: I did read the changelogs, but i didn't absorb that. would it be worth bumping the package version to 2.4.6?
<tormod> they haven't even released 2.4.6 properly :)
<Ng> oh right :)
<tormod> I thought I had a reason for just cherry-picking that commit and not just get git-head...
 * tormod googles his mind
<tormod> laziness I think, would have to all the manual steps again (or merge in master again)
<tormod> Ng (and jbarnes), are you interested in auto-xorg-git and uploading to the ppa, I could add you to the team
<jbarnes> tormod: are there docs on how to create a repo?  I know nearly nothing about making debs so I don't think I need upload privs yet :)
<tormod> s/laziness/time constraints/
<Ng> tormod: I'd definitely like to get my hands on the script. checkinstall does ok for -intel, but would clearly fail for drm :)
<tormod> the script does everything: auto-xorg-git -g -D -H ../xorg-pkg-tools/hooks intel
<Ng> outstanding :)
<tormod> see https://edge.launchpad.net/~xorg-edgers there are even README files :)
<Ng> it might be interesting to have daily builds going in
<tormod> automation would be awesome, see the "ppa-update" script that I use for the packages which do not need any tweaking
<Ng> I've been meaning to track down a daily PPA builder for my own stuff. I know jcastro was talking about one at the last UDS, and jkakar has such a thing
<tormod> if there's a tweak I need semi-permanently, I add it to the "hooks"
#ubuntu-x 2009-04-03
 * Ng looks at http://blog.launchpad.net/ppa/introducing-autoppa
<tormod> I just tried to make a new libdrm package, but now the r6xx-r7xx branch does not merge nicely with master ;(
<tormod> which it should since it itself merged in master a few days ago... forgot to pull
<Ng> hmm, autoppa is kinda bzr-centric
<Ng> tormod: wow, auto-xorg-git is pretty impressive :)
<tormod> ok uploaded 2.4.6~
<tormod> thanks! credits go to Bryce as well
<Ng> tormod: I'm wondering about an option which notices the git tree in the working directory is already up to date and immediately bails - that way it'd only build/upload if there are actually new changes
<tormod> it has that option :)
<tormod> the ppa-update uses it
 * Ng sighs, sorry, I swear I did look through the options!
<Ng> tormod: so, I'm happy to do some uploading of -intel, subject to some sanity checking of what I'm doing :)
<Ng> I guess we'd need separate LP accounts for bots that were auto-uploading though
<Ng> I certainly can't leave any GPG keys associated with my main account unlocked anywhere
<tormod> Ng: cool. apply for team membership. yes you'd need some autobuilder keys
<tormod> the rule is kind of to make as few manual changes as possible
<Ng> just uploaded a test run to my own PPA
<tormod> url?
<Ng> https://edge.launchpad.net/~cmsj/+archive/ppa
<Ng> I don't think the upload has been scanned yet
<Ng> or it has and the rejection mail hasn't hit me yet :)
<Ng> cool, accepted. that was the result of "./auto-xorg-git -n -g -D -H hooks -w /tmp/xorg-pkg-tools/ intel"
<tormod> the drm-snapshot 2.4.6 is done. notice I used -t "~" because 2.4.6 is not released
 * Ng nods
<tormod> if the debian patch in -intel (pci id stuff) is not needed, no manual tweaks should be necessary atm
<tormod> I am fixing up the drm-snapshot hooks also, except merging in r6xx-r7xx the rest is automatic
<tormod> Ng: pushed the hooks cleanup to bazaar/lp
<tormod> jbarnes: is there a txt file archive of intel-gfx ML somewhere, for snatching that patch without html?
<tormod> never mind, saving as text in Firefox did not screw up as much as I thought
<tormod> uploaded a new -intel with said patch. I guess on the edge means to stay ahead of git master :)
<tormod> jcristau: I don't know what the 2.6.28 kernel in Debian does, but I had to revert http://git.debian.org/?p=pkg-xorg/lib/drm-snapshot.git;a=commitdiff;h=c32452f1fe831fe95a197883ab6f6617cd78afb1 to build -intel in Jaunty
<LLStarks> quick question. does kms require uxa?
<bryce> Here's the final chart of X bugs from last quarter - http://people.ubuntu.com/~bryce/totals-proprietary-2009-Q1.svg
<sbeattie> bryce: dumb question, but what is this 'Xlib:  extension "Generic Event Extension" missing on display ":0.0".' warning I'm seeing from jaunty clients?
<bryce> dunno, haven't seen that one before
<tjaalton> GE is part of XI2
<tjaalton> AIUI
<bryce> ah
<bryce> why would that be showing up with clients?
<tjaalton> beats me
<bryce> fwiw, I've noticed we've got a lot of weird warnings strewn about...  in fact I was just looking at the one on bug 353049
<ubottu> Launchpad bug 353049 in xserver-xorg-video-intel "*ERROR* Unknown parameter 6" [Low,Invalid] https://launchpad.net/bugs/353049
<bryce> where possible I'd like to suppress these sorts of messages to avoid confusion; lacking that, I'd like to get them documented at https://wiki.ubuntu.com/X/Glossary so we can point people to them 
<mnemo> on every single boot I get this warning:
<mnemo> [   24.182667] [drm:i915_setparam] *ERROR* unknown parameter 4
<mnemo> i havnt had time to file that bug yet
<bryce> mnemo: don't bother - see the link I just posted
<mnemo> aah it covers both 4 an 6
<mnemo> good
<bryce> tjaalton: just got a reject mail on vmmouse
<tjaalton> bryce: heh, yeah it was my mistake
<bryce> okie
<tjaalton> re-uploaded the current version
<tjaalton> but then I actually applied the patch and signed & uploaded then new version
<tjaalton> so it should be ok now
<tjaalton> hmm, should sync requests be assigned to the release team now?
<tjaalton> since these are new upstream versions (FFe)
<bryce> I assume it's still just the ubuntu-archive team
<bryce> in any case, it's essentially the same group of guys anyway ;-)
<tjaalton> heh, right
<RAOF> Hey all.  Is there something blocking the libdrm with fixed libdrm-nouveau1.symbols file?
<tjaalton> RAOF: no, I've just forgot to upload it
<bryce> I can take care of it
<bryce> sorry RAOF, it's been on my todo list, I was just trying to get an xserver update out first
<bryce> (...which I just now uploaded!)
<RAOF> That's fine.  It's not as if it totally breaks nouveau or anything.
<RAOF> Hurray for xserver updates!
<RAOF> Anyone testing nouveau should be savvy enough to ask about manually installing libdrm-nouveau1, anyway :)(
<bryce> ah just minor stuff... I've been raking through X packages looking for patches people posted, and putting them in
<bryce> so this has some xvfb-run script fixes, and a man page for Xephyr
<RAOF> Let's see if there's anything interesting I should be pulling for nouveau at the same time as the rebuild...
<bryce> tjaalton: btw speaking of extra patches, I saw there's a mesa patch from tormod on bug 324854 you might look at
<ubottu> Launchpad bug 324854 in xserver-xorg-video-intel "DRI2: (UXA) white transparency artifacts with compiz [patch]" [Undecided,Invalid] https://launchpad.net/bugs/324854
<tjaalton> bryce: yes, it's on my repo but not yet uploaded
<RAOF> Looks like the Fedora nouveau testing day produced a couple of fixed bugs.  Yay!
<bryce> RAOF: do you know how they organize that?
<RAOF> bryce: No, not really.  There's a wiki page detailing test-cases, with a link to a rawhide ISO, but I'm not sure who writes the page, how people get notified, etc.
<bryce> yeah, I've seen that page, very curious
<mnemo> mozilla has an awesome way of organizing test days... they have a web app which helps you go through manual steps
<mnemo> look at it here: https://litmus.mozilla.org/
<mnemo> so basically you log in and say what build you have, then you follow instructions and enter results
<mnemo> you can see which testcases havn't been checked in a long time using what browser versions
<bryce> interesting
<bryce> I've wondered if we ought to do more organized test day type stuff for X
<mnemo> I think it would be a great idea because there is so many OS/hardware/software configs etc
<bryce> well, I think it is driven more by an ability to follow through on test results
<bryce> (which is why I was curious how fedora had organized their test day)
<mnemo> I agree, right now it feels like we have a shortage of bugs, heh... even upstream bug tracker seems flooded with pretty high quality bugs... i have 3-4 crash bugs at least with repro steps that isn't being fixed
<mnemo> maybe we should start some effort to clone eric anholt instead?
<bryce> heh, I've had eric close plenty of my bugs but not fix them (so far) ;-)
<bryce> mnemo: I've had some luck in diving in and helping fix bugs on -ati this release.  With -intel though the code seems to be getting more and more complex so it's rather intimidating to work on
<bryce> RAOF: libdrm uploaded btw
<mnemo> bryce: cool
<RAOF> bryce: Thanks.
<RAOF> I'll wait till it's built everywhere, then do some DDX testing.
<tjaalton> six sync requests filed for the input drivers
<bryce> xorg uploaded - fixes dexconf for kvm users
<tjaalton> does dexconf run?-)
<bryce> tjaalton: :-P  of course I checked ;-)
<tjaalton> :)
<tjaalton> I actually meant that "is it run on install"
<tjaalton> seems that it isn't at least on our preseeded installations
<bryce> hmm
<tjaalton> but I haven't noticed since the xorg.conf's are distributed otherwise
<tjaalton> hmm wait
<tjaalton> got the ideapad again, so I can check
<tjaalton> it's empty
<tjaalton> funny that no-one has complained
<bryce> empty as in 0 bytes?
<tjaalton> yes
<Unggnu> hi
<bryce> hi Unggnu
<bryce> tjaalton: that sounds undesired
<bryce> hm
<Unggnu> I am not sure if it works in Intrepid too but Apport seems to generate very good backtraces and other usefull information if X crashes in Jaunty. Maybe we should change the Backtracing Wiki to prefer enabling Apport.
<bryce> weird, I've not seen bug reports with xorg.conf's attached that were 0 bytes
<bryce> (would apport exclude them?)
<Unggnu> Things like http://launchpadlibrarian.net/24144277/Disassembly.txt and you don't need to install dbg packages or use ssh/gdb
<bryce> Unggnu: certainly feel free to improve the Backporting page.  My thought there was that if apport works and catches the crash, the user really wouldn't need docs - if it doesn't catch it, then they're probably in a situation where they have to do it manually anyway
<Unggnu> But I don't know how stable the process is.
<Unggnu> You have a point :)
<Unggnu> But nearly all of the intel reports in the top ten doesn't have backtrace and apport is disabled if a stable version is used
<Unggnu> One of the problem is that you need ssh/a second computer. No problem for a pc geek of course but ... :)
<bryce> yes true
<bryce> Unggnu: if you have ideas on how we can tell users how to enable apport (post-release) to get backtraces, please do update the top of the page with that info
<bryce> I agree the current process is a bit techie for most people
<bryce> honestly that Backporting page probably needs a good bit of copyediting to clean it up
<Unggnu> The wiki is fine for me is just a lot of work
<methril|work> morning
<mnemo> hi
<methril|work> i''ve a xcrash in Jauntyy beta
<mnemo> right
<methril|work> hi mnemo!
<mnemo> =) =)
<mnemo> bryce might know if your bug is a known issue, thats why I wanted you to describe the bug here
<methril|work> well, every start of Xs give me that backtrace (at the end of Xorg.0.log)
 * methril|work nods
<Unggnu> methril|work: Did apport said something?
<mnemo> this is the backtrace methril|work is seeing:   http://pastebin.com/m21463627
<mnemo> RhdAssertFailed() in radeon driver
<Unggnu> Why radeonhd?
<bryce> hmm
<bryce> crash in -radeonhd, needs the radeonhd debug symbols
<bryce> looks like a failed assertion
<methril|work> hw: 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc M56P [Radeon Mobility X1600] [1002:71c5]
<mnemo> methril|work: please install the package xserver-xorg-video-radeonhd-dbg
<methril|work> ok
<bryce> X1600... is that an r6xx? I forget
<methril|work> r5xx IIRC
<bryce> mm
<bryce> methril|work: did you try the -ati video driver?  it should work ok for r5xx cards
<Unggnu> I would use the radeon-Driver if it works
<Unggnu> yes
<Unggnu> Jaunty radeon driver even works with r7xx
<bryce> :-)
<methril|work> i don't remember why i choose radeonhd, if you suggest others, i could change
<bryce> hmm, there's 100 calls to RhdAssertFailed in the -radeonhd codebase, so hard to guess where it's failing beyond that
<Unggnu> radeonhd isn't the default driver. It has to be installed manually afaik
<bryce> there's a handy chart comparing them on different chips here:  http://www.x.org/wiki/RadeonProgram
<methril|work> nice!! thank you
<Unggnu> We should really start a petition to get the radeonhd and radeon devs working together
<bryce> Unggnu: that's already in progress.  By now I think -ati has absorbed most of what's cool of -radeonhd
 * methril|work nods about devs working together
<Unggnu> Oh, I hope so
<bryce> since both are opensource it's fairly easy for -ati to eat -radeonhd code ;-)
<methril|work> hehehe
<bryce> really, it's only 6xx/7xx that still make some sense to pick radeonhd, and even there like unggnu says the difference is going away
<mnemo> bryce: actually the xorg.log says which assert is failing, look above the backtrace.. i missed that at first ;o
<Unggnu> No, it doesn't. Radeonhd has no real XV support for 7xx but radeon has
<Unggnu> That's why I don't understand the whole separation thing
<mnemo> ../../src/rhd_mc.c:417: RHDMCSetup: Assertion 'RHDMCIdle(rhdPtr, 1)' failed.
<RAOF> There were some philosophical differences that got expressed in code.
<RAOF> But I think those actually got resolved (in favour of the -radeon approach).
<Unggnu> radeon works great except of the missing Powerplay but it isn't their fault
<bryce> mnemo: aha good point
<mnemo> here is the code in the driver at the assert:
<mnemo> http://pastebin.com/m2259f52a
<bryce> Unggnu: oh I assumed radeonhd had Xv support.  IN that case, yeah no reason to use it over -ati
<Unggnu> I didn't got it to work here.
<Unggnu> Xv with radeonhd even in Jaunty.
<bryce> mnemo: hmm, not sure what that code does
<mnemo> me neither
<bryce> mnemo: but this is certainly well enough triaged to send the bug upstream if you'd like
<Unggnu> Everyone can do what they want but many resources are blown in the wind which is a shame imho. I would at first try if ati/radeon works.
<mnemo> yup
<bryce> Unggnu: me too
<methril|work> i'm going to try with radeon
<Unggnu> bryce according to pitti using "sudo force_start=1 /etc/init.d/apport start" in a stable Ubuntu version should do the job. After a crash a dump should be created and the user should get a message after a restart
<bryce> Unggnu: interesting, that'd be useful to have in the backtracing page
<methril|work> (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
<methril|work> what does that mens?
<Unggnu> methril|work: you need a restart I guess
<Unggnu> because of the kernel module
<methril|work> :(
<mnemo> methril|work: going with -ati is probably the best thing for you, but it would also be useful if you filed a bug report about the radeonhd bug here: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/radeonhd
<methril|work> could i force the kernel module down and up?
<methril|work> ok
<Unggnu> methril|work: Probably
<methril|work> id' like to help a litle bit more
<Unggnu> methril|work: maybe also remove radeonhd first, I am not sure
<Unggnu> If you use current -intel you become an addicted restarter ;)
<Unggnu> And removing fglrx module is also not easily possible according to my experience
<methril|work> i see some related bug with radeon and fglrx
<methril|work> in the launchpad
<Unggnu> FGLRX crashes a lot at least with R770
<Unggnu> methril|work: Does removing/adding module work?
<methril|work> not yet
<methril|work> i'm going to install the dbg driver
<methril|work> (firewall problem at work)
<methril|work> it could be that the Kernel Modesettings are wrong?
<Unggnu> Kernel modesetting?
<Unggnu> This isn't a feature from Jaunty afaik?
<methril|work> ok, then forget it (next kernel release 2.6.29)
<RAOF> That's for intel; ATI is slated for 2.6.30 IIRC
<jcristau> no it's not
<jcristau> more probably .31
<Unggnu> :)
<Unggnu> Some news site said that Fedora has kms for intel, radeon and the open source nvidia driver
<bryce> phoronix
<Unggnu> yeah
<RAOF> Indeed; they pull in the drm modules from the relevent git branches.
<mnemo> http://www.phoronix.com/scan.php?page=news_item&px=NzEwMA
<mnemo> "Enabled by default on Fedora 11 will be Intel kernel mode-setting (along with the ATI kernel mode-setting that can already be found in Fedora 10)."
<Unggnu> They will have fun in combination with ext4 :-D
<methril|work> :)
<bryce> night
<mnemo> nn
<Unggnu> night bryce
<methril|work> night
<RAOF> I could concievably pull in the modesetting branch for nouveau-kernel-source; I don't think that's a wonderful idea, though.
<Unggnu> I guess there will be enough problems if kms comes with Ubuntu 9.10
<RAOF> Not if fedora runs into them first! :)
<Unggnu> Of course it would me more stable than now but ...
<methril|work> i'd like to test it :)
<Unggnu> methril|work: use a Live CD :)
<Unggnu> Intel driver makes so many problems lately that I think stability is more important than fancy features
<RAOF> methril|work: Fedora livecds should give you that fun.
<methril|work> well, i like ubuntu :)
<methril|work> i was checking all the xorg drivers, no one is working radeon, radeonhd neither ati
<methril|work> i've both, debug and not debug
<methril|work> i've this in the gdm log: /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/extensions//libdri.so: undefined symbol: atiddxAbiDixLookupPrivate
<jcristau> fglrx fail.
<methril|work> it's possible that before that fail i', not able to switch to a Terminal?
<tjaalton> everything is possible with fglrx
<tjaalton> mesa 7.4 uploaded
<mnemo> methril|work: if you want to try KMS on ubuntu... first install 2.6.29 mainline kernel (google for "ubuntu mainline kernel") and then subscribe to the xorg-edgers PPA and then read some docs on KMS to figure out what params you need to pass at boot or whatever
<mnemo> tjaalton: ah, great work.. thanks a lot
<methril|work> mnemo: i know, i read about it. Thank you :)
<Unggnu> methril|work: Could you check a daily LIve CD of Jaunty?
<methril|work> i could, where it's?
<Unggnu> methril|work: http://cdimages.ubuntu.com/daily-live/
<Unggnu> tjaalton: indeed :)
<Unggnu> methril|work: If you change the driver you really should restart if it has DRI support.
<methril|work> i see
<methril|work> i'm restarting aggain and again :D
<methril|work> looks like crappy windows
<Unggnu> methril|work: At least with the Live CD you could check if the radeon works at all
<methril|work> (it's a joke)
<Unggnu> for you
<tjaalton> well, fglrx is loaded/installed, so no wonder that DRI is not working..
<methril|work> it's working because i restarted at the MacOS partiton and works
<methril|work> if you didn't put fglrx qhy it has to load?
<tjaalton> you have it on the xorg.conf?
<methril|work> not now
<tjaalton> so.. -ati works now?
<Unggnu> methril|work: I guess the module is loaded before X start so it is module configuration issue.
<tjaalton> I don't know how fglrx works, but the nvidia module is loaded by the driver when X starts
<jcristau> the problem was xorg's /usr/lib/xorg/modules/extensions//libdri.so was replaced by fglrx..
<tjaalton> heh
<Unggnu> oh
<tjaalton> ok so dpkg --purge xorg-driver-fglrx
<methril|work> was what i was going to do now tjaalton :)
<tjaalton> should've been the first thing to check ;)
<tjaalton> lunch ->
<methril|work> fglrx did the trick
<methril|work> i'm going to check the other drivers
<methril|work> thank you
<tormod> we introduced an apport hook for -ati to detect fglrx loaded...
<methril|work> could be good to post a bug in launchpad? or put some comments?
<tormod> we should put more warnings in the fglrx package description that it fscks up for other drivers, but I think I already have filed a bug on this
<methril|work> i see a bug in launchpad
<tormod> bug #?
<methril|work> #346803Ã§
<tormod> bug 346803
<ubottu> Launchpad bug 346803 in fglrx-installer "Radeon XPRESS 200M 5955 not recognized by aticonfig:No supported adapters detected (dup-of: 284408)" [Undecided,New] https://launchpad.net/bugs/346803
<ubottu> Launchpad bug 284408 in update-manager "r3xx Hardware does not work with fglrx [EPR#257839]" [Medium,Fix released] https://launchpad.net/bugs/284408
<methril|work> also
<methril|work> bug 313027
<ubottu> Launchpad bug 313027 in fglrx-installer "MASTER: fglrx does not support xserver 1.6" [High,Fix released] https://launchpad.net/bugs/313027
<Brandie> y hello thare
<BUGabundo> hey everyone
<Brandie> =D
<BUGabundo> need a X guru here to help out Brandie!
<BUGabundo> s/he is having trouble on jaunty with an ati card
<Brandie> Why didnt I just buy a nvidia? D=
<BUGabundo> eheh
<Brandie> I love my ubuntu ;_; <3
<BUGabundo> Brandie: calm down a notch! 
<BUGabundo> this is a (more) serious #
<Brandie> sorry.
<BUGabundo> bryce ping
<BUGabundo> Brandie: seems everyone is busy
<BUGabundo> hand in here a bit longer, ok?
<Brandie> mmm alright
<Brandie> So, Why does ubuntu seem to have alot of problems with ati cards?
<BUGabundo> abi bump
<Brandie> http://img8.imageshack.us/img8/2776/dscf2478.jpg I get that when i try to boot into 9.04 :\
<BUGabundo> Brandie: you can and should start by opening a bug on LP
<BUGabundo> that way you can get help from more devs
<Brandie> D=
<Brandie> I think I remember the fix.
<BUGabundo> $ apport-cli -fp xserver-xorg
<Brandie> I just need the name of the propietari ati driver, so I can remove it
<Brandie> If i remember, I remeoved that, then reinstalled it in the os. and it worked.
<BUGabundo> that would work.. .XFIX should have fixed that too
<Brandie> mmm, It didnt last time. I cant remember the name os the package the official ati drivers install...
<Brandie> luckily i can still boot into 8.10
<BUGabundo> ehe
<Brandie> or... maybe i cant... It's giving me the same error not
<Brandie> *now
<BUGabundo> oops
<Brandie> fglrx
<BUGabundo> bye go to go. guud lucj
<Brandie> what?...
<jbarnes> bryce: gee thanks, I was running out of high prio bugs :p
<bryce> jbarnes: no prob, I suddenly find myself with plenty of extras
<_MMA_> So I'm running Jaunty. (Intel 855 I believe) tried to connect a external monitor to the laptop not I have a corrupted screen with a cursor that looks fine. Disconnected monitor. Rebooted several times. No dice.
<_MMA_> Any help?
#ubuntu-x 2009-04-04
<bryce> https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
<bryce_> heya cwillu
<cwillu> poke poek
<bryce_> cwillu: with -intel bug triaging, the name of the game for us is getting bugs upstreamed to Intel
<bryce_> we fix _some_ bugs in Ubuntu but the vast bulk are fixed upstream, and we cherrypick the patches into Ubuntu
<bryce_> of course, hardly anyone reports bugs to us in a form that we can upstream, so it usually takes some work on our part to massage them into shape, getting the requisite info, etc.
<bryce_> cwillu: the page to bookmark is http://intellinuxgraphics.org/how_to_report_bug.html
<cwillu> got it
<bryce_> I've been developing some automated scripts that help in gathering or requesting the info, but some reporters really need human help
 * cwillu is composing notes in the background, please keep the info dump going :)
<bryce_> ah ok :-)
<bryce_> what else...
<bryce_> you may want to join the ubuntu-x@ mailing list as well; quite low traffic but I try to announce stuff there and we sometimes have useful discussions
<bryce_> https://lists.ubuntu.com/mailman/listinfo/Ubuntu-x
<cwillu> if I start adding tags to bugs in a private namespace, are they likely to remain there, at least for a week or so?
<bryce_> we also have a team set up in launchpad - https://edge.launchpad.net/~ubuntu-x-swat
<bryce_> private namespace?
<cwillu> (cwillu-foo, cwillu-bar)
<bryce_> ahh, yeah feel free to add tags
<cwillu> mainly so I don't trip on other stuff by accident
<cwillu> I was planning on opening umbrella bugs per-chipset, linked to newly opened bugs for each unique symptom that I can see.  
<bryce_> btw, if you join the ubuntu-x-swat list, one important caveat is that it subscribes you to the bug mail - roughly 100 mails per day
<bryce_> so if you do that make sure you have procmail or something to filter those out.  I'd be happy to share my procmail rules if you use it
<cwillu> I think a good portion of the deluge comes from people posting to the first bug they find with a similar symptom, so "intel video hangs" gets all the traffic even if it's an 810 bug
<bryce_> being a member of the team enables you to set states Triaged and Wontfix, set priorities, etc.
<cwillu> bryce, I'm addicted to gmail :p
<bryce_> hehe
<bryce_> indeed, you're absolutely right.  "driver performance regression" would be another good subjectline if you wanted to cause a me-too storm ;-)
<bryce_> I try to always update bug titles when I see ones that just describe a generic symptom
<bryce_> it helps head off confirmation hell
<bryce_> regarding tagging of chipsets, one thing I've been doing is prepending bug titles with chipset names, [i845], etc.
<cwillu> yep, that was my inspiration actually :)
<bryce_> I think people used to use tags for the same purpose, but an advantage to the subject lines is that it helps mitigate me-too'ing
<cwillu> Umbrella bug per chipset, and then nice fresh bugs with the chipset in the title, a list of similar but different bugs in the summary, exhortations to verify the chipset and simple instructions to do so
<bryce_> as well, even mroe importantly, it's the format upstream likes to have when we upstream the bugs
<cwillu> basically, a couple hundred words of boilerplate, to make it easy on the lazy bug reporters
<bryce_> sounds interesting
<cwillu> is that counterproductive re: upstreaming those bugs?  (I'm imaging that the boiler plate can be stripped easily enough)
<bryce_> dunno, I'd need to see it in action.  Willing to give anything a shot that helps us get more organized
<cwillu> I guess if I get a start on this over the weekend, I probably won't be tripping over too much concurrent activity on launchpad
<cwillu> I'll avoid marking any of the old bugs as duplicates until it's clear if it's a win or not
<cwillu> (are duplicated bugs hidden from searching-by-tag by default as well?)
<bryce_> yes
<cwillu> this would also be one of those days I regret not having my wiki up and running
<cwillu> my schemes -> http://pastebin.com/f5600578c
<bryce_> nice
<cwillu> is there any need to drill down to the particular revision, or is the general chipset enough?
<bryce_> when you go through bugs you'll note the format I've been trying to use, basically separating standard sections via [lspci], [testcase], etc.
<cwillu> yep
<cwillu> god I hope they get that ext4 mess sorted out quick
<bryce_> especially when upstreaming bugs I like to have the top of the bug report be a very brief [problem] statement, no more than 1-3 sentences, so people can quickly skim it
<cwillu> okay
<cwillu> Time for bed now, I should be getting started in ~10 hours or so
<cwillu> Thanks for the info :)
<bryce_> regarding the particular revision...  in the subjectline I tend to keep it just to the family, but in the [lspci] section it is good to be more specific
<cwillu> okay
<bryce_> sure, cya later :-)
<cwillu> don't know if you want to mention anything on the mailing list, I probably won't be bothering to subscribe to it until I'm thoroughly sick of sifting through launchpad sometime tomorrow :p
<bryce_> ok, I'll wait 'til you make introductions
<tjaalton> bryce_: looks like the glxinfo crashers all had nvidia in NonfreeKernelModules, so -> nvidia-glx-180 :)
<bryce_> aha
<tjaalton> moving them right now
<bryce_> tjaalton: odd, I was just looking at nvidia bug replies
<tjaalton> also, there are a couple of intel regressions, suggesting that the most recent version doesn't work for everyone
<tjaalton> filed against xorg
<bryce_> looks like a handful of people followed through on my request to test + close -180 bugs.  Was hoping to see more, but at least it's something
 * bryce_ looks
<tjaalton> these were filed against mesa
<bryce_> which bug #'s?
<bryce_> none of the new bugs in xorg look due to today's updates...
<tjaalton> 354735
<tjaalton> ok that was the only one I guess
<bryce_> ok
<bryce_> nx6110 sounds familiar...
<bryce_> hmm, well if he truly has narrowed it to 2:2.6.3-0ubuntu4 or ubuntu3, the only change in those that looks reasonably questionable is 118_drop_legacy3d.patch
<bryce_> ./debian/changelog:  * 25_quirks_nx6110.patch:
<tjaalton> hmm bug 354889 looks related
<ubottu> Launchpad bug 354889 in xorg "[jaunty] i845 xorg crashes upon playing video" [Undecided,New] https://launchpad.net/bugs/354889
<tjaalton> found a dupe for steve's bug
<bryce_> how related?
<tjaalton> same error message
<bryce_> I've run across a bunch of "crash on playing video" bugs.  We need to report those upstream
<tjaalton> http://dl.getdropbox.com/u/256410/IMG_0479.JPG
<tjaalton> duped them already
<bryce_> hehe
<bryce_> man, that bit of code to put the error into the dialog has turned out way more useful than I'd anticipated :-)
<tjaalton> heh
<Alexia_Death> bryce: that was a truly inspired idea.
<bryce_> grep ftw
 * Alexia_Death hates having to do that manually when something fails
<Alexia_Death> Now, if crash log would not get overwritten if you log in again for random crashes...
<bryce_> Alexia_Death: it should not get overwritten
<bryce_> Alexia_Death: I made sure the failsafe log gets written to Xorg.failsafe.log instead
<Alexia_Death> failsafe yes
<bryce_> Alexia_Death: also the Xorg.0.log.old should still contain the prior crash
<Alexia_Death> but say my X crashes but theres no need or failsafe
<Alexia_Death> X can start normally
<bryce_> right
<Alexia_Death> greeter loads just fine and I log in
<bryce_> crash should still be in the Xorg.0.log.old
<Alexia_Death> After I log in the crash log is gone.
<Alexia_Death> no. its gone.
<bryce_> are you sure?
<Alexia_Death> the greeter log is in the .old
<bryce_> it's been there for me...
<bryce_> hm
<Alexia_Death> I havent needed it in  the past few months but before that when tablet still crashed X I needed to keep a console session to coppy the log before it was lost
<Alexia_Death> its a sort of thing you only need when things go wrong  with X configured right...
<bryce_> Alexia_Death: ok, well 274870 covers this situation
<Alexia_Death> ?
<bryce_> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503251 - forwarded to debian, but no response so far afaik
<ubottu> Debian bug 503251 in xorg-server "xorg-server: Xorg should keep more rotated logs" [Wishlist,Open]
<tjaalton> Alexia_Death: the wacom hotplug patches are now upstream :)
<tjaalton> in 0.8.3-2
<bryce_> (and I'm open to alternate ideas || patches)
<tjaalton> and builtin serial devices should work OOTB
<Alexia_Death> tjaalton: Indeed:D
<Alexia_Death> bryce: yes, that covers it:)
<Alexia_Death> tjaalton: how was that done?
<Alexia_Death> My daemon has serial devices description file. I use an usb Serial tablet
<Alexia_Death> laterz
<tjaalton> Alexia_Death: with a hal callout program that feeds the parameters to the xserver/driver
<Alexia_Death> tjaalton: sounds sensible:)
<tjaalton> "usb serial tablet"
<tjaalton> how's that possible :)
<Alexia_Death> usb->serail adapter+ serial tablet:)
<tjaalton> ah
<tjaalton> how the hll is lp karma counted these days? yesterday or the day before mine was around 16k and now it's over 50k..
<RAOF> Hm.  We may need to pull in a patch to update libdrm-nouveau.  Let's see...
<bryce_> tjaalton: I heard there was some inflation in translation karma
<tjaalton> i wonder if there's a "my sister runs ubuntu" team..
<tjaalton> bryce_: haven't done those ;)
<tjaalton> oh, soyuz
<tjaalton> 35k from there
<bryce_> tjaalton: btw, cwillu suggested some of these random unexplained lockups might be due to the ext4 fallout
<bryce_> (bug #330824)
<ubottu> Launchpad bug 330824 in linux "Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28" [Medium,In progress] https://launchpad.net/bugs/330824
<tjaalton> oh?
<RAOF> Ow.  Everyone's favourite not-quite-stable filesystem!
<tjaalton> I'll switch to btrfs once karmic opens ;)
<tjaalton> who cares if it can't handle full disks
<tjaalton> disks are cheap
<bryce_> I wonder if there's any way we can easily determine what filesystem they have installed?
<sbeattie> installed or mounted? cat /proc/mounts will tell you what fs types are mounted
<tjaalton> the problem is (reliably) determining where $HOME is
<tjaalton> under / or /home or linked somewhere
<bryce_> I'll add /proc/mounts to our apport
<sbeattie> ooh, mount -t ext4 will tell you if any of the fielsystems are ext4.
<sbeattie> hrm, what does stat -f /path say on an ext4 system? 
 * sbeattie wiped all his test ext4 partitions after getting bit by data loss.
<bryce_>     try:
<bryce_>         script = subprocess.Popen(['mount', '-t', 'ext4'], stdout=subprocess.PIPE)
<bryce_>         matches = script.communicate()[0]
<bryce_>         if (matches):
<bryce_>             report['ext4'] = matches
<bryce_>     except OSError:
<bryce_>         pass
<bryce_> look good?
<tjaalton> sbeattie: Type: ext2/ext3
<sbeattie> ah, bummer. time to file a bug on stat
<tjaalton> yeah
<tjaalton> jcristau: should the rgb.txt-file be revived? there seem to be a number of client apps that still want it
<tjaalton> some of them proprietary
<bryce_> committed
<bryce_> I ought to write an automatic script to reply to bugs with "randomly" in the subject ;-)
<RAOF> Hm.  I think we should pull in the recent changes to libdrm/nouveau.  Does anyone have any particular comments or questions about this?
<bryce_> RAOF, yes what are the recent changes?  Are they feature additions or bug fixes?  How well tested are the changes?  Are there specific bugs in launchpad that they are likely to resolve?
<RAOF> So, it's difficult to say whether the changes are bugfix or new features.  There are things which certainly are bugfixes.  Fixing a memory leak, cleaning up typos.
<bryce_> given that we're a week away from release, how comfortable are you with that uncertainty?
<bryce_> (fwiw, I am struggling with -intel fixes that are *definitely* bug fixes, yet apparently cause regressions... aargh!)
 * wgrant makes it 2.5 weeks, not 1.
<RAOF> I'm not entirely sure; this depends on precisely what xserver-xorg-video-nouveau is doing in Jaunty.  If it's predominantly for testing, then I'd be uncomfortable with not shipping the changes; their lack definitely generates an error in the driver, but I'm not sure whether anything actually _hits_ that path.
<bryce_> wgrant: well, post April 9th we shouldn't be making any changes
<wgrant> bryce_: That's true.
 * bryce_ s/release/end of development/
<bryce_> wtf is up with wiki.ubuntu.com tonight?
<wgrant> It's not very up.
<bryce_> indeed
<RAOF> Well, actually, I am sure that something hits that path; mesa.  DRI is definitely broken because we don't have the changes in libdrm-nouveau, but that's really neither here nor there.  I'm not sure whether anything _else_ hits it.
<bryce_> RAOF: personally I consider it predominantly for testing, and will back you up 100% on that.
<bryce_> RAOF: but ultimately it's up to you -- if the changes cause regressions you'll want to have a plan on if, and how to deal with them.  
<RAOF> Worst case we can simply disable the patch.  That'll take things back to their current, apparently working fine, state.
 * bryce_ nods
<bryce_> make sure to solicit testing feedback in that case
<bryce_> disabling patches pre-release is not too difficult, but post release can require a lot of annoying paperwork
<RAOF> Right.
<bryce_> fwiw, I'm really happy with -nouveau's state in jaunty, it is exceeding where I'd expected of it to be development-wise
<bryce_> similarly with -ati.  I think our open source story on both nvidia and ati hardware is notable
<RAOF> It's very nice that 2D is quite drama-free.
<bryce_> Intel, however, is not meeting what I had anticipated in jaunty.
<bryce_> but still there's time
<RAOF> Intel has been somewhat of a problem child this release, hasn't it.
<RAOF> Although that might also be due to lack of testing; we've only had... 6 bugs reported against the nouveau stack in total?
<bryce_> could be
<bryce_> certainly no shortage of bug reports against nvidia -180
<bryce_> RAOF: I'd put a "we're not accepting bug reports against -nouveau" statement in the bug tracker for -nouvea at the start of jaunty
<bryce_> that may be cutting down on bug reports a bit.  I should probably pull that out (assuming you're interested in bug reports)
<RAOF> I'm moderately interested, but the bugs will be less and less interesting the older Jaunty's snapshot gets.
<RAOF> I know that Jaunty's nouveau package has so far resulted in at least one bug being filed upstream and fixed, though.  So that's good :)
<bryce_> ok
<bryce_> my plan has been to pull that out once karmic opens, which is just a few weeks, so unless you're anxious for bug reports I'll stick to that plan
<RAOF> I think that's a fine plan.
<bryce_> ok kewl.  let me know if there's any specialized info beyond the norm you'd like included in nouveau bug reports
<bryce_> most people don't read directions, but for those who do, we can tell them what to include
<RAOF> Xorg.0.log, as always.  Also, and slightly more difficultly, dmesg with the drm module loaded with 'debug=1'.
<bryce_> interesting; how do you load the drm module with debug=1 ?
<RAOF> "modprobe drm debug=1"
<RAOF> But you obviously have to do that outside of X, and preferably you want to do that before nouveau.ko has been loaded at all.
<bryce_> right, hm
<RAOF> So I tend to start in recovery mode, drop to a root terminal, modprobe, then continue the boot sequence.
<bryce_> usually by the time they've gotten to the directions, they've already got their bug.  I'll need to think on where best to put that direction.
<RAOF> That's obviously only useful if you can easily reproduce the bug; running with debug=1 results in everything being a bit slower, and dmesg being big :)
<bryce_> are there disadvantages to running with debug=1 ? 
<bryce_> oh okay
<bryce_> maybe we need a 'how to debug nouveau' wiki page with this on it
<RAOF> That's a fine idea.
 * bryce_ switching machines...
<bryce> mm
<bryce> ^%$ broken wiki
<bryce> ok, well, some day we should make a troubleshooting page for nouveau.  ;-)
<RAOF> Once the wiki is up!
<RAOF> OK.  libdrm is pushed to git.  I'll craft a call for testing.
<tjaalton> bryce: a random stock reply for such bugs?-)
<bryce> tjaalton: couldn't hurt
<bryce> heya albert23
<albert23> hi bryce
<bryce> albert23: what's new
<bryce> +?
<albert23> bryce: not much yet. Weekend has started and going to do some performance testing on Kubuntu
<albert23> That's a bit slow on 965
<bryce> yes
<bryce> everything is slow on all intel chipsets
<bryce> (my fault I think)
<jcristau> tjaalton: yes, possibly (re: rgb.txt)
<albert23> bryce: actually, Gnome is doing fine on the 965
<albert23> and the 945 is fine without gem as well
<albert23> So I guess it's the whole gem newness that's hurting at the moment
<mnemo> albert23: try open a fullscreen firefox window on each side of the cube in gnome and then spin the cube
<mnemo> I think it
<mnemo> s about how big the bitmaps are or something
 * bryce waves to jcristau
<mnemo> if I spin the cube with no programs active, it's really fast even in EXA but if I create lots of firefox windows then in becomes very slow.. so maybe kubuntu just uses the intel driver differently and thus runs straight into the perf problems
<albert23> mnemo: indeed, 3 times firefox makes the spin slow
<albert23> but Kubuntu already seems to be slower with just moving windows around
 * bryce <-- passing out
<bryce> night everyone.
<albert23> good night
<mnemo> night
<Kano> hi, was it needed to change the order of the entries in the xorg.conf
<cwillu> oooo, uxa is fast again on the latest kernel on 945
<albert23> bug 349314
<ubottu> Launchpad bug 349314 in linux "[i915] allocate MCHBAR space & enable if necessary" [Low,Fix released] https://launchpad.net/bugs/349314
<albert23> Fixes tiling issues and slowdown on i915 chipsets
<cwillu> got the impression that was supposed to help exa though
<cwillu> albert23, was that supposed to be fixing uxa or exa?  Uxa has good performance again, exa still has noticeably slower rendering on larger windows
<albert23> cwillu: the change is in i915_gem_tiling, and gem is used by both exa and uxa
<cwillu> ineffective on exa then
<albert23> cwillu: with exa, do you still see tiling error messages in X log?
<cwillu> yes
<cwillu> http://pastebin.com/f4b9a0722 is uxa
<cwillu> http://pastebin.com/f779fadfc is exa
<cwillu> Failed to set tiling on front/back/depth buffer under exa
<cwillu> There's also a warning:  (WW) intel(0): DRI2 requires EXA
<cwillu> bah, UXA
<albert23> uxa also fails on the front buffer
<cwillu> yes
<cwillu> uxa is fast for any size of window though
<cwillu> like, night and day difference
<albert23> good, so far it was only fast fro small windows for me
<Kano> cwillu: rejected by kernel usually means that the drm from kernel is wrong, 11.40 is patched
<cwillu> Kano, I'm running 11.40
<Kano> well maybe the fix was only for another chipset
<albert23> Jesse mentions he only tested on i915...
 * albert23 has no luck with the new kernel. GLBlur full-screen and sauerbraten are still slow (amd64)
<cwillu> I've never had blur be fast on a 945
<albert23> It's fast for me with gem disabled
<cwillu> wow, turning it on and off again just put performance through the floor, I'm getting .2 fps now
<mnemo> how can I make an LP bug be open against both python2.6 and mesa? if I select "also affects project" I only see upstream mesa project
<cwillu> even with blur redisabled
<mnemo> its for this bug --> https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/355137
<ubottu> Launchpad bug 355137 in python2.6 "[G45] xserver and/or python2.6 crashed with SIGSEGV" [Undecided,New]
<cwillu> mnemo, also affects distribution
<mnemo> aah ok
<cwillu> bryce, the boilerplate for "we need xorg.0.log and lspci" should probably include a note to remark the bug as confirmed or new
<cwillu> ooo, ubuntu wiki is back up
<bryce_> cwillu: in fact what I've been doing lately, is tag bugs "needs-lspci-vvnn" when asking for those files.  I'm working on a script that automatically reviews bugs with those tags, that have had the files subsequently provided by the original reporter, and then it moves the bug to Confirmed automatically
<bryce_> cwillu: using a script to do it ensures some level of consistency, and simplifies things for the reporter a bit, since they can then just reply via email or whatever
<bryce_> oh btw, I've got a processing script that runs against all bugs in New, and asks the user to attach stuff, etc.
<bryce_> so take care not to put bugs into New state unless they do need to be re-processed by the script.  
<bryce_> I've seen situations where the reporter kept putting the bug back to New, and getting a new automated response, repeat etc.
<cwillu> yep, I've been marking them back to confirmed
<cwillu> the first script re: needs-lspci-vvnn, is that running now?
<cwillu> I've removed that tag from about 5-6 bugs that had the relevant details attached
<bryce> cool
<bryce> I run the scripts manually usually on Mondays
<cwillu> you remember anything about 865's dri being disabled offhand?
<bryce> I like to keep them supervised since I've been known to make coding goofs ;-)
<cwillu> heh
<bryce> yes, in fact it is intentionally disabled
<cwillu> is there a particular api for scripting lauchpad, or are you just making normal http requests?
<bryce> yes, the api is provided by 'launchpadlib'
<cwillu> is there any hope for it being enabled?
<cwillu> thanks, I'll look into that
<bryce> https://help.launchpad.net/API/launchpadlib
<bryce> yes, the original problem was that with DRI enabled, 865 would freeze during boot
<cwillu> 845 et al?
<bryce> we tried a number of different things to get it working but no dice, so ended up disabiling it
<bryce> no, I disabled it only on 865
<cwillu> hmm, xorg claims 845 and 865 have it disables
<cwillu> s/disables/disabled/
<cwillu> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/355258
<ubottu> Launchpad bug 355258 in xserver-xorg-video-intel "[i865] Jaunty: DRI disabled with i865" [Undecided,Confirmed]
<bryce> oh right
<bryce> hmm, I think we don't need to disable it on 845; I could take that bit out of the patch
<bryce> this is bug 304871 btw
<ubottu> Launchpad bug 304871 in xserver-xorg-video-intel "[i845G] Fatal server error: Couldn't bind memory for BO front buffer (Jaunty)" [High,Fix released] https://launchpad.net/bugs/304871
<cwillu> yes, I pulled one guy away from that report back to his on report on 865 on the same issue, marked it as fix released, and got him to file a new bug for the dri issue
<cwillu> 343690 I believe
<bryce> good
<cwillu> http://pastebin.com/ff2e4278 is where I'm at
<cwillu> Internally flagging each bug as either a hang/crash, display corruption/anomaly, or performace
<bryce> nice
<cwillu> I'm just working down the list of incomplete bugs from the bug day page
<cwillu> once I've finished that pass, I'll make umbrella bugs for each class, link them all up, etc
<bryce> yeah I've thought we could fix titles to include keywords (like I did with "(UXA bug)") to make them easier to group
<bryce> excellent
<cwillu> I've just been doing [i865] [UXA], etc
<cwillu> plus tags, but ya
<cwillu> wonder how easy it would be to have seperate 'packages' per chipset to report against
<cwillu> I mean, I know they're all in theory -intel, but...
<bryce> btw, there's some triaging graphs here - http://people.ubuntu.com/~bryce/Plots/
<bryce> click on X, then -intel on the left
 * cwillu looks at the dip in incomplete bugs at 12:00->20:00, and shouts "hey, that was me!" :)
<cwillu> is there a magic syntax to write bug numbers in launchpad description so that they get linked up automatically?  If there is, I haven't tripped over it yet
<bryce> :-)
<bryce> "linked up"?  do you mean duped?
<cwillu> no, just referenced
<bryce> ah, yes if you say "bug NNNNN" it'll autolink them
<bryce> "bug #NNNN" may work too
<cwillu> I knew that.  Except for the last 4 hours
<cwillu> anyways :p
<bryce> I don't think creating separate packages for each chipset would be very feasible, but I've thought it would be nice to create a launchpadlib report that allows ordering and/or filtering by chipset (or tags in general)
<bryce> hehe
<cwillu> If I can get a few machines with 845/855/865 chipsets, would some sort of remote access test farm be useful?
<mnemo> cwillu: I think the most useful resource would be a a server that everyone can PXE boot from into various configs for super easy bisection
<mnemo> it would be like grub booting over network where you can choose like 2.6.28kernel+intel2.6.3+mesa7.4 etc
<mnemo> using such a tool we could easily and conveniently bisect issues
<mnemo> and find the patches we need to cherry pick
<cwillu> kexec would make short work of that
<mnemo> if one has to compile mesa,kernel,libdrm and intel ddx it's soo much work to bisect issues (also many people, like me, is not that good at fixing issues when stuff doesnt compile)
<mnemo> ive not really been able to test upstream versions at all until I found xorg-edgers
<mnemo> but know I've been able to file several good upstream bugs using xorg-edgers + mainline kernel
<mnemo> and easy bisection is probably the _one_ thing I can imagine that could help us quickly backport cherry picks
<mnemo> the idea is basically xorg-edgers but with history and bootable directly from network
<mnemo> that would rock imo, heh
<mnemo> but probably hard to build
 * cwillu ponders
<cwillu> I'd need a power supply that I can power-cycle over the network
<cwillu> and maybe a webcam :p
<mnemo> yeah
<mnemo> also... then it would also be easy for us to ask bug reporters to "hey, go boot this blah blah versions and see when it broke plx"
<mnemo> i mean if its really easy we can get help from more people
<cwillu> but beyond that, it doesn't look completely infeasible
<cwillu> biggest problem would be how to handle access to it
<cwillu> I don't need to be providing an open proxy :p
<cwillu> I'm intruiged :
<cwillu> not intruiged enough to jump on it right now, but that's probably something useful that I can poke at post jaunty release
<mnemo> yeah
 * cwillu idly wonders how you spell intruiged anyway
<cwillu> intrigued
<cwillu> that's it
<bryce> hehe
<bryce> a test farm is a good idea. With X testing, there's a bit of a limitation in that a lot of bugs require you to sit in front of a real physical screen
<bryce> also, for bugs where X locks up, if you're using the machine remotely, how do you restart it?  You'd need some sort of IPC or something
<bryce> but... if we had a good plan, I'd totally be on board with it.
<tjaalton> hmm, people on the bibblelabs forums claim that our nvidia packages are broken because they link libGL.so.1 against the nvidia library, when it should be the mesa version..
<tjaalton> resulting that bibble5 doesn't start
<tjaalton> "works on fedora"
<bryce> mne|afk: in fact I've been working on a bisection page thingee (for just -intel and -ati, not mesa, xserver, etc. yet)
<bryce> I've just had so much regular bug work to do, my progress has been slow.  But it's probably about a man-week from being usable
<bryce> cwillu: fwiw, before I started working at Canonical, in my previous job I set up exactly such a remote, automated test harness, for doing NFS testing, called 'Crucible'
<bryce> http://markmail.org/message/yii6s3okfiyqlx57
<cwillu> biggest sticking point is how do you monitor the video:  I mean, one could just get a good big kvm with a monitor and a webcam, but that's pricy
<bryce> yep
<cwillu> otherwise you're stuck with only really being able to test crashers
<bryce> I was actually fortunate in snapping up a kvm when my previoous company went belly up and auctioned everythign off :-)
<cwillu> intels aren't discrete, so you can't just plop a bunch of them into one machine and select them via pci address or whatever
<cwillu> (thinking out loud)
<bryce> right
<bryce> even with discrete cards, there's often only one slot on the mboard to stick them
<bryce> and having >1 vidcard in a system can sometimes cause other kinds of problems... (something I've been testing actually...)
<cwillu> well, that can be addressed with a good choice of machine to use in the first place
<cwillu> although that still doesn't help with the 'capturing the output' problem
 * bryce nods
<cwillu> I miss my multiseats :)
<cwillu> afk for a bit
<mnemo> "With X testing, there's a bit of a limitation"
<mnemo> thats the reason why I was thinking about PXE network booting
<mnemo> so you get different versions of stuff but you can still only test _your_ hardware
<mnemo> "With X testing, there's a bit of a limitation in that a lot of bugs require you to sit in front of a real physical screen"
<mnemo> even
<mnemo> hmm, now still is pretty aburd actually... http://portableubuntu.sourceforge.net/index.php?section=screenshots
<mnemo> ubuntu for Windows ?
<bryce> mnemo: ahh, gotcha, thought you meant pxe booting within a testing environment
<bryce> er, _remote_ testing environment I mean
<tjaalton> lp is quite responsive today..
 * bryce waves
<tjaalton> filing a FFe for wacom-tools
<tjaalton> howdy
<RAOF> tjaalton: Which LP are you using, and how can I get at it? :)
<tjaalton> RAOF: edge, trying to be sarcastic ;)
<RAOF> Oh.  Dissappointing!  I'd quite like to actually access my bugs, damnit!
<maxb> edge is functional, if slow, which is more than can be said for release right now :-)
<bryce> maxb?
<maxb> main lp.net is completely down
<bryce> ah
<bryce> bugger, wonder what happened.  wiki was down last night too
<tjaalton> seems to work now
<RAOF> Bah!  People should restart their computers more often.
<RAOF> Or at least not report bugs when they're running the 2.6.28-7 kernel but only have the 2.6.28-11 headers installed, and then install nouveau-kernel-source.
<tjaalton> yeah, like my vdr box which has intrepid and 2.6.27-2, and dist-upgrade pulled in -11 which fails to boot :)
<tjaalton> I should upgrade it to jaunty now that I have a keyboard which works on it
<tjaalton> plugging the hd to another machine just to edit menu.lst isn't much fun
#ubuntu-x 2009-04-05
<cwillu> Well, I put out a donation request, and it looks like there's 18 different machines I can have by monday 
<cwillu> ... and all but two are amd
<cwillu> bryce, should I be able to mark bugs as triaged now?
<cwillu> https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/339781 is upstream
<ubottu> Launchpad bug 339781 in xserver-xorg-video-intel "[g45] xv video tearing" [Undecided,Confirmed]
<cwillu> with a patch
<cwillu> (dupe of 339233, but I'd still like to know if I'm missing something :p)
<cwillu> yay, I'm sick of confirming incomplete bugs!  \o/
<cwillu> bryce, http://pastebin.com/f707dff7b
<bryce> cwillu: yes you should be able to set Triaged now; let me know if not
<bryce> cwillu: hey you're in Canada?  where abouts?
<bryce> cwillu: wow you've had a busy day! http://people.ubuntu.com/~brian/complete-graphs/xserver-xorg-video-intel/plots/xserver-xorg-video-intel-week-incomplete.png
<cwillu> bryce, heh, well, the scale exaggerates the slope a little :p
<cwillu> planning on opening the umbrella bugs tomorrow, linking them up and putting the boilerplate on the statuses
<cwillu> which will basically consist of going through all the confirmed bugs listed on the hugday paeg
<cwillu> I'm from saskatoon saskatchewan
<cwillu> re: triaged, I still can't.  I get the feeling that there was some inconsistency introduced, I don't think it's subscribing me to new bugs unless I actually subscribe to them by hand (although it was for a few hours)
<BUGabundo> is bug 355671 known?
<ubottu> Launchpad bug 355671 in xserver-xorg-video-intel "Compiz doesn't start after upgrade xorg-video-intel 2.4.1-1ubuntu10.4" [Undecided,New] https://launchpad.net/bugs/355671
<mnemo> not sure... but I have a vague probably that DRI has been disabled on one of the early intel chipsets as a workaround for SEGV in x.org start
<mnemo> bryce or timo would probably have a better answer
<BUGabundo> for ibex too?
<BUGabundo> or just jaunty?
<BUGabundo> this user is on ibex, I think
<mnemo> oh, in that case I have no idea
<mnemo> im talking about jaunty
<BUGabundo> yeah, that I know
<mnemo> bryce uploaded a new intel driver for intrepid on 30th of march
<mnemo> fixing bug #320893
<ubottu> Launchpad bug 320893 in xserver-xorg-video-intel "[i915GM] Regression in xserver-xorg-video-intel version 2.4.1-1ubuntu10.3" [Critical,Fix released] https://launchpad.net/bugs/320893
<mnemo> according to "aptitude changelog xserver-xorg-video-intel"
<BUGabundo> but that isn't even the card that alfatec has
<mnemo> look at the diff, maybe this bugfix introduced a regression for alfatec's card?
<BUGabundo> maybe
<mnemo> sounds like he just updated one of the patch files in the package though
<mnemo> "Update 104_i830-vbt-timing-hack.patch to final version taken upstream"
<mnemo> etc
<BUGabundo> alfatec: can you pastebin your changelogs?
<BUGabundo> /usr/share/doc/xserver-xorg
<jcristau> ym /u/s/d/xserver-xorg-video-intel/
<BUGabundo> eh... since I don't have intel... don't have that path.. lol
<BUGabundo> alfatec: can you ?
<alfatec> yes, just a minute
<BUGabundo> just open that path with nautilus
<BUGabundo> then open the changelog file, and then paste the content to http://paste.ubuntu.com
<BUGabundo> and give us the link alfatec
<BUGabundo>  !pastebin
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<alfatec> http://paste.ubuntu.com/144967/
<alfatec> is that correct ?
<mnemo> hmm so you dont have the most recent intrepid version
<mnemo> and bryce's upload from 30th march was a fix some an issues that some update caused
<mnemo> i'd say it's worth a shot to install the latest version and see if that works
<BUGabundo> afaik alfatec has every update availble to him on ibex
<BUGabundo> unless he is on an old mirror
<BUGabundo> alfatec: what mirror are you using?
<mnemo> BUGabundo: this is what I see inside "aptitude changelog xserver-xorg-video-intel" for ibex --> http://paste.ubuntu.com/144971/
<alfatec> https://neacm.fe.up.pt/ubuntu
<BUGabundo> that would mean he has at least 4 updates lacking
<BUGabundo> it can't be...
<BUGabundo> alfatec: can you please pastebin your /etc/apt/sources.list
<alfatec> ok
<mnemo> alfatec: also pastebin the output of "dpkg -l | grep intel" please
<alfatec> http://paste.ubuntu.com/144973/
<mnemo> heh, what is "http://ppa.launchpad.net/intel-gfx-testing/ppa/ubuntu jaunty main
<BUGabundo> deb http://ppa.launchpad.net/intel-gfx-testing/ppa/ubuntu jaunty main
<mnemo> " ?
<BUGabundo> jaunty?????
<BUGabundo> mnemo: ehehe
<BUGabundo> alfatec: come on.... you did it again?????
<alfatec> http://paste.ubuntu.com/144974/
<mnemo> we've all been newbies ;)
<BUGabundo> 2:2.4.1-1ubuntu10.4
<BUGabundo> that's not the version you mentioned in the bug
<alfatec> O:-)
<BUGabundo> mnemo: he keeps doing it... did the same mistkare yesterday
 * BUGabundo alfatec needs a good head smack
<mnemo> i have "2:2.4.1-1ubuntu10.4" on my intel+ibex box
<alfatec> sorry
<alfatec> a give my self a head smack
<BUGabundo> fix that, and revert the upgrade
<alfatec> ok 
<BUGabundo> then reboot, and re-run update-manager
<BUGabundo> let us know how it went, so we can close the bug as invalid if that is the cause
<alfatec> i have done that 
<alfatec> i change my sources 
<BUGabundo> does compiz works now?
<alfatec> re run update-manager
<alfatec> nop
<alfatec> not working yet
<alfatec> :
<alfatec> :S
<BUGabundo> what driver version do you have now?
<alfatec> 2:2.5.1
<BUGabundo> now its newer?
<BUGabundo> $ compiz --replace
<BUGabundo> works?
<alfatec> i will try 
<alfatec> hangs at the same place
<jcristau> restarted X after update-manager?
<BUGabundo> yeah that too
 * albert23 thinks (EE) intel(0): Cannot support DRI with frame buffer width > 2048 explains the trouble
<BUGabundo> alfatec: are you using dual monitor?
<alfatec> i have to restart the X
<alfatec> yesterday e try the dual monitor 
<alfatec> could be the reason ?
<BUGabundo> it shouldn't
<BUGabundo> unless you saved it to xorg.conf
<BUGabundo> pastebin that too
<albert23> alfatec: the problem is the virtual setting in xorg.conf
<alfatec> http://paste.ubuntu.com/144990/
<BUGabundo> 		Virtual	2640 800
<BUGabundo> I would run XFIX from recovery console
<BUGabundo> just to be sure
 * cwillu hides
<BUGabundo> hey cwillu
<cwillu> wassup?
<BUGabundo> did you get a reply from bryce?
<BUGabundo> he emailed me the other day, and I told him about your tests
<cwillu> yep, that's why I'm here :)
<BUGabundo> alfatec: ping
<alfatec> i'm here
<BUGabundo> alfatec: did you reconfigured X yet?
<BUGabundo> cwillu: bryce aint here, I think
<alfatec> i have a backup of xorg.conf 
<alfatec> i will replace them 
<BUGabundo> no need
<BUGabundo> just let dpgk make one new
<alfatec> it works :>
<alfatec> yes
<BUGabundo> nice
<alfatec> recovery mode fix x
<BUGabundo> lets close your bug
<alfatec> then compiz --replace
<BUGabundo> it was user action
<alfatec> yep
<alfatec> I am grateful for your help, I am of the first steps, but a great desire to learn. Thanks for the compliments patience
<BUGabundo> you can enable it permenatenly on Appearance
<cwillu-maemo> '''Two bugs can have identical symptoms, and still be unrelated.  Check that you have exactly the same chipset _before_ commenting (lspci -nn |grep -i vga).  An issue that isn't isolated to a particular chip usually can't be upstreamed, and so can't be fixed!'''
<cwillu-maemo> bryce, thoughts on that wording?
<mnemo> "bryce has been idle 17hrs 49mins 35secs"
 * cwillu-maemo pokes him anyway
 * cwillu-maemo pokes anyone else who is interwsh
<cwillu-maemo> stupid touscreen...
 * cwillu-maemo pokes anyone else who is interested too
<mnemo> maybe it should say: run "lspci --n | grep -i vga" in a terminal
<mnemo> -nn
<mnemo> not --n
<mnemo> and what are they going to compare that "lspci -nn" output with?
<mnemo> bugs have chipset specified in different ways
<mnemo> since we don't have a specific "chipset: blah" field
<mnemo> im probably nitpicking though
<cwillu-maemo> the lspci thay's already on the bug report in the cases i care about
<mnemo> aah, you mean its listed as "lspci: blah"
<cwillu-maemo> i'm trying to get them as consistent as possible
<mnemo> thats great
<mnemo> i've seen that on some of them
<cwillu-maemo> most of the lspci's are from bryce, i'm just following his lead
<mnemo> mmkay
<cwillu-maemo> is there a syntax to bold stuff in launchpad descriptions?
<mnemo> not that I know of
 * cwillu-maemo starts hunting for injection attacks ;p
<mnemo> I found a pango injection attack in a filename passed to eye of gnome once
<mnemo> http://bugzilla.gnome.org/show_bug.cgi?id=555940
<ubottu> Gnome bug 555940 in general "eog is vulnerable to pango injection attack :-)" [Minor,Resolved: fixed]
<mnemo> thats when you know you got too much time on your hands ;P
 * cwillu-maemo pokes mnemo with copious free time
#ubuntu-x 2010-04-05
<kklimonda|G1> Sarvatt: i havent tested it recently.
<rye> hello, is anybody here aware where x resolution settings are stored in gnome in Lucid ?
<diverse_izzue> hi all. i have problems with the radeon kms modesetting on lucid when i use external screens ( the image is very jittery, not stable). does anybody else have this problem?
<diverse_izzue> rye, i think in a file called monitors.xml, let me search for it
<rye> diverse_izzue, .config/monitors.xml ?
<diverse_izzue> rye, yes
<rye> diverse_izzue, awesome! thanks!
<diverse_izzue> you found that fast...
<rye> diverse_izzue, my wife has jitterring on external display too
<diverse_izzue> on what ATI chip?
<rye> diverse_izzue, radeon + kms + lucid, VGA connection to the external screen
<diverse_izzue> rye, that's kind of a bummer, the biggest lucid regression for me
<rye>   	M52 [Mobility Radeon X1300]
<rye> pci id 1002:5a34
 * rye reboots to check one tiny thing regarding bug #533135
<ubottu> Launchpad bug 533135 in plymouth "System fails to boot with plymouth installed (nouveau driver with >1 display)" [Medium,Triaged] https://launchpad.net/bugs/533135
<rye> grrr, while searching for resolution of one bug with nouveau/plymouth found another bug with GDM :)
<diverse_izzue> rye, do you know if the jitter bug is reported anywhere?
<rye> diverse_izzue, frankly speaking I have no idea. Her videoboard/LVDS started to malfunction recently (mis-colored pixels appearing here and there) so I attributed that jitter to this, that's why I did not report that and nobody seemed to suffer from this when I asked around
<diverse_izzue> rye, i'm confused since this kms thing, don't know where to report. kernel? radeon? mesa? dri?
<rye> ok, I am out of ideas for #533135, something is wrong with that ioctls...
<Sarvatt> rye: booting with radeon.modeset=0 will fix that for now (also you may want to delete /etc/modprobe.d/radeon-kms.conf)
<kklimonda|G1> Sarvatt: were there any fixes recently that could fix my gamma issue? if so i'll check once i'm back how the day after tomorrow
<kklimonda|G1> back home*
<Sarvatt> kklimonda|G1: seems like a general xserver problem people are having with all different types of video right now - https://bugs.freedesktop.org/show_bug.cgi?id=27382
<ubottu> Freedesktop bug 27382 in Server/general "[RS480] black screen after a few user switches" [Major,New]
<kklimonda|G1> Sarvatt: good to know, i've already reported bug against gnome-screensaver ;)
<kklimonda|G1> Sarvatt: but I can reproduce the problem by just running test-fade from gnome-screensaver tarball and there is no vt switch involved
<Sarvatt> does xgamma -gamma 1.0 bring it back?
<kklimonda|G1> yes
<kklimonda|G1> wait, actually xrandr --putput LVDS-1 --gamma 1:1:1 does bring it back
<kklimonda|G1> haven't tried xgamma for some reason
<Sarvatt> do you just use the one account or do you have any guests running at the same time when it happens?
<Sarvatt> can ya point me at your gnome-screensaver bug?
<kklimonda|G1> Sarvatt: can't really say for sure - i think it was only one account then. i'll get you a bug number and answer this for sure when i'm back home.
<Sarvatt> i cant reproduce it but I haven't tried with guest sessions yet, wanted to step through it in gdb to get a better idea of what was going on
<Sarvatt> chrisccoulson: have you seen anything regarding gnome-screensaver's gamma fade not restoring right?
<chrisccoulson> Sarvatt, i've not. have people been reporting issues then?
<Sarvatt> yeah https://bugs.freedesktop.org/show_bug.cgi?id=27382 kklimonda|G1 was just talking about having the problem before you came in, didn't know if maybe you had seen any bugs about it. xrandr --putput LVDS-1 --gamma 1:1:1 brings it back for kklimonda|G1, and other people in that bug report are saying xgamma -gamma 1.0 brings it back
<ubottu> Freedesktop bug 27382 in Server/general "[RS480] black screen after a few user switches" [Major,New]
<chrisccoulson> Sarvatt - interesting, i've not seen that before
<chrisccoulson> the gamma fade should be restored pretty much as soon as it has faded out
<chrisccoulson> kklimonda|G1, is the issue reproducible for you?
<kklimonda|G1> chrisccoulson: yes but i'm not at home till wednesday
<chrisccoulson> kklimonda|G1, when you get home, it would be interesting to see the output of gnome-screensaver --debug when this happens
<chrisccoulson> and also a log from xtrace
<chrisccoulson> i can help you with the latter if you haven't used xtrace before
<kklimonda|G1> chrisccoulson: nothing worth mentioning in screensaver log afair.
<Sarvatt> ok thats nasty
<chrisccoulson> there could be a clue. but the xtrace log could be interesting
<Sarvatt> looks like i can reproduce it with test-fade in gnome-screensaver
<kklimonda|G1> i've always wanted to learn xtrace :)
<Sarvatt> kklimonda|G1: it's easy, just xtrace -D :5 > ~/whatever.xtrace then DISPLAY=:5 yourapp
<kklimonda|G1> Sarvatt: but the output looks scary :)
<kklimonda|G1> good to know how to use it though - thanks
<Sarvatt> kklimonda|G1: you just had to point me at a bug that got me really interested when I'm super busy getting ready for an interview tomorrow, argh :)
<chrisccoulson> heh
<Sarvatt> looks like test-fade only tests XFree86-VidMode fades though
<chrisccoulson> Sarvatt, it should test either
<chrisccoulson> gs_fade_new will select the appropriate method
<chrisccoulson> i think the check at the start of test-fade.c is bogus ;)
<Sarvatt> oh ok, not too familiar with this code base
<Sarvatt> well it definitely thinks it restored the fade right even though the screen was black after the second and I couldn't get it back up- http://pastebin.com/v0udDN9G
<chrisccoulson> i think xtrace would be useful here :-)
<Sarvatt> chrisccoulson: http://pastebin.com/zwXaMH49
<chrisccoulson> hmmm, so the gamma is not reset at the end then :-/
<kklimonda|G1> i could tell ya that without your fancy xtrace!
<kklimonda|G1> ;)
<bryce_> morning
<kklimonda|G1> good morning bryce
<Sarvatt> wish i had another machine handy so i could step through it in gdb, the second fade always fails to restore 
<kklimonda|G1> Sarvatt: i think that the first one also fails and only because just after it the second fade-out is called gamma is "restored"
<Sarvatt> it doesn't restore fully from the first one I think, the screen starts to ramp up the gamma and starts the second fade before its done it looks like
<chrisccoulson> Sarvatt - ok, i can recreate it with test-fade too
<Sarvatt> http://pastebin.com/s33GktML
<chrisccoulson> Sarvatt - i have 2 machines here, so I can debug that
<Sarvatt> thats what I'm using to recreate it and have it reset it after because i only have one machine at the moment
<chrisccoulson> yeah, i just had to use my second machine to reset it
<Sarvatt> (with xtrace -k -D :5 > ~/Desktop/fade.xtrace in another terminal)
<chrisccoulson> anyway, feel free to open a new screensaver bug and assign to me, and i will look at that one this week
<Sarvatt> okie, kklimonda|G1 did you already have a bug opened or should i open a new one? theres a ton across the random ddx packages with this bug
<kklimonda|G1> Sarvatt: i have opened one only on b.g.o - if you open one on LP i'll link the upstream one when i'm back. android mail client sucks when it comes to searchng mails :/
<Sarvatt> chrisccoulson: can you set a break on xf86CrtcSetModeTransform and print crtc->active and crtc->funcs->gamma_set?
<kklimonda|G1> Sarvatt: and subscribe me to LP one -'m not sure if my backlog is going to keep this conversation for two days :)
<chrisccoulson> Sarvatt - yeah, will look at that in a bit
<Sarvatt> chrisccoulson: sorry to bug you when you're probably busy with other things, this is probably a bug in xserver anyway but you seem to be the one in the know when it comes to gnome-screensaver :D
<Sarvatt> kklimonda|G1: whats your LP username?
<kklimonda|G1> Sarvatt: kklimonda
<Sarvatt> oh easy enough
<cnd> bryce_: I created a magicmouse ppa with a dkms package for lucid for magic mouse support (which is a multitouch device)
<cnd> ppa:chasedouglas/magicmouse
<cnd> I see you and apw are working on an MT ppa as part of xorg-edgers
<cnd> maybe there's some integration we could do between the two
<cnd> any thoughts?
<Sarvatt> chrisccoulson: whats your LP name too so I can subscribe you to it? :D
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/555870
<ubottu> Ubuntu bug 555870 in gnome-screensaver "Gamma values are not being set properly after a second fade out resulting in a black screen" [Undecided,New]
<chrisccoulson> Sarvatt - it's chrisccoulson ;)
<chrisccoulson> but i'm subscribed to all gnome-screensaver bugs anyway
<Sarvatt> oh whoops forgot the extra c
<chrisccoulson> heh
<bryce_> cnd, thanks
<Sarvatt> better xtrace here with the gnome-screensaver debug info mixed in so you can tell where each thing happens - http://launchpadlibrarian.net/43176234/fade.xtrace
<chrisccoulson> Sarvatt - got it :)
<chrisccoulson> it needs a gdk_flush in there
<Sarvatt> woot!
<chrisccoulson> and that makes it work ;)
<chrisccoulson> ok, i'll fix that this week then once i've worked out the appropriate place for it
<Sarvatt> nice, i will try to work up a list of bugs to ask for retesting after you upload the fixed one since there are probably at least 20-30 scattered across the various ddx packages that i've come across
<chrisccoulson> Sarvatt, thanks. i will probably ask kklimonda|G1 to test a PPA build before i upload, as the fix won't make beta 2 now anyway
<bryce_> wow, lotta bug reports in over the weekend
<bryce_> mostly intel it appears
<chrisccoulson> bryce_, busy week for you this week then? ;)
<bryce_> chrisccoulson, nah, taking friday off
<bryce_> chrisccoulson, every week's a busy week, but we're frozen this week so it'll not be as bad as usual
<bryce_> of course, I say that monday morning not knowing what the week has in store ;-)
<chrisccoulson> i've got quite a busy week this week, especially with final freeze being just over a week away ;)
<chrisccoulson> and i didn't work today, so it's a short week for me too
<jwhitley> Hi all.  I need help debugging an odd udev issue.  x11_options.* settings show up via udev, but aren't being picked up by xorg.
<jwhitley> "udevadm info --query=all --name=..." and udev logs show correct settings, but these don't show up via xinput list-props and Xorg logs.  ideas on troubleshooting?  (In Lucid, up-to-date as of ~1 hr ago)
<jwhitley> The context is porting a HAL setup for my trackball over to udev for Lucid.  Following docs at https://wiki.ubuntu.com/X/InputConfiguration and https://wiki.ubuntu.com/X/Config/Input
<bryce_> jwhitley, those are a little outdated now... probably xorg.conf.d snippets are the right way to go for lucid
<jwhitley> Do snippets work in Lucid?  I found those when digging around, but it wasn't clear that those patches to Xorg had landed in Lucid.
<jwhitley> Nevermind; they're listed in the man page quite clearly.  Shuffling off to port config to snippets now; thanks.
<Sarvatt> http://fedoraproject.org/wiki/Input_device_configuration is a good reference until the wiki is updated
<RAOF> Good morning all!
<bryce_> heya RAOF
<bryce_> some times I want to throttle reporters and say, "Launchpad is for bug reports, NOT for free technical support!"
<bryce_> but of course they'd just shrug and go, "Uh, what's the difference?"
<bryce_> it's windy here, maybe a tree will fall on top of me in my office and end my pain :-)
<RAOF> :(
<RAOF> I've had two bug reporters talk about icecream on a (pretty serious) macbook nouveau bug.
<bryce_> heh
<bryce_> "launchpad is a bugtracker, not a FORUM!!!"
<RAOF> Please see ubuntuforums.org for an actual forum!
#ubuntu-x 2010-04-06
<Sarvatt> chrisccoulson: is 05_locking_for_compiz.patch supposed to still be in our gnome-screensaver patch series?
<Sarvatt> chrisccoulson: it was fixed years ago? https://bugzilla.gnome.org/show_bug.cgi?id=488264
<ubottu> Gnome bug 488264 in general "keybord grab problem under compiz" [Normal,Resolved: notgnome]
<chrisccoulson> Sarvatt - yeah, we could probably drop that no
<chrisccoulson> s/no/now
<Sarvatt> i'm not sure 02_keep_unlock_raised.patch is relevant still either
<RAOF> Anyone here have a recentish macbook pro with the dual nvidia-gpus?
<bryce_> RAOF, ask on ubuntu-x@ or ubuntu-devel@
<RAOF> Yeah, I guess so.  Not quite so interactive, though :)
<bryce_> whew almost caught up with -ati triaging... 3 more to go
<Sarvatt> RAOF: pretty sure the generation of the gpu in that is just plain busted with accel in general on nouveau
<RAOF> Sarvatt: Upstream thinks that it's likely an EFI problem, and that loading efifb first would make everything work.
<Sarvatt> theres a dell model without EFI with the same hybrid sli setup that i've seen reports on that they had to use noaccel=1
<Sarvatt> trying to dig up the other bug
<RAOF> Ok.  So we might need to be detecting that and quirking off accel.
<Sarvatt> GT240 needs noaccel quirked too
<bryce_> yay, -ati is caught up
<bryce_> (for now)
<bryce_> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg
<RAOF> Damn you plymouth!  Stop killing boot on nouveau+dual head.
<Sarvatt> oh crap we're closing in on 400 bugs now
<Sarvatt> RAOF: geforce 9500M, thats it
<Sarvatt> hybrid 9400M G + 9200M GS
<RAOF> I suspect that hybrid setups generally might just be failing.
<RAOF> Although sadly not because of vga16fb.  One bug I can't blame on that framebuffer!
<RAOF> Sarvatt: Why do you think GT240 needs to be quirked?  Bug #554818 seems to be cruising along nicely with accel.
<ubottu> Launchpad bug 554818 in xserver-xorg-video-nouveau "VT switch not work with GT240" [Undecided,Confirmed] https://launchpad.net/bugs/554818
<RAOF> Oh, wait.  That's the mobile variant.
<RAOF> (I'm not entirely sure where that bug should go, but I'm pretty sure it's not a nouveau bug)
<Sarvatt> thats a GT216 (aka NVA5) I think, alberto has an actual GT215 (GT240 desktop) NVA3 that doesn't work
<RAOF> We can't quirk NVA3 acceleration off - it doesn't have any.
<RAOF> There isn't a voodoo generator for it (in the Lucid packages - one has *just* been checked in to nouveau git)
<RAOF> Um, why are people surprised that atom processors can't decode high resolution h264 video in realtime?
<bryce_> Sarvatt, RAOF, have either of you applied for MOTU/Core-Dev?
<RAOF> I haven't applied for core-dev (yet).
<bryce_> here's a link to the process for core-dev https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
<bryce_> good idea for both of you to add it to your todo list, you'll probably appreciate having the rights when meerkat hits
<RAOF> *Yes*
<bryce_> and you've both definitely done enough to justify getting in :-)
<Sarvatt> huh, never noticed this - http://cvs.fedoraproject.org/viewvc/F-12/kernel/linux-2.6-x86-64-fbdev-primary.patch?revision=1.1&view=markup
<bryce_> I don't know if in the new scheme of things it's still expected for you to join MOTU first before applying for core-dev, but might want to think about it
<bryce_> Sarvatt, might mention that patch to apw or send it to the kernel list
<ScottK> It's never been required, just normal, but I think only one or two made it to core-dev direct.
<bryce_> ScottK, ok
<bryce_> Sarvatt, RAOF, I assume you're not MOTU yet, so would be good to shoot for that first
<RAOF> bryce_: I've been MOTU for a number of years.  That's why you didn't have me pestering you for -nouveau uploads until it hit main :)
<bryce_> RAOF, aha right
<bryce_> Sarvatt, so you'll want to start by applying for MOTU - basically fill out your wiki page according to the application process, then put yourself on the next DeveloperMembershipBoard meeting, which is every two weeks.  Guessing the next one will be around Tues 13th
<Sarvatt> bryce_: yeah I've been thinking about it a lot but I'm quite a ways away from core-dev and MOTU seems to be up in the air (it's not even listed on the DMB application page you linked anymore). thats why I was asking if there were any plans for a Ubuntu-X package set a few months ago. contributing developer seems no different than member which I already am, I was trying to decide on which packages to apply for PPU for in the future as the next st
<Sarvatt> ep
<bryce_> let me know when you have your wiki pages ready and I'll add my endorsement.  Would be good to get an endorsement from Timo and maybe one or two other developers you've worked with
<bryce_> Sarvatt, yeah I'd recommend going for MOTU next, then work your way up to core-dev
<bryce_> I don't know that we'll ever do anything elaborate with making Ubuntu-X a package set with special permissions
<bryce_> pretty much anyone brave enough to work on X.org is probably not going to have much trouble with the general MOTU process
<ScottK> Sarvatt: MOTU is not up in the air anymore.  It was decided at the last UDS to keep it.
<Sarvatt> ah ok, I will take that step next, thanks for the clarification.
<Sarvatt> the fact that it was dropped off of the developer membership board application wiki page made me think a delegated team or PPU was the next step for me now
<bryce_> guess the wiki docs could be more clear
<bryce_> although looks like someone has been updating them
<RAOF> Sarvatt: Where was that agp-intel bug where drm loaded before agp had loaded agp-intel?
<Sarvatt> RAOF: one sec, i emailed it to the kernel-team list, just gotta dig it up
<RAOF> 'Cause it looks like a regression of bug #430694, probably another casualty of 2.6.33 drm backport.
<ubottu> Launchpad bug 430694 in linux "agpgart-intel not loaded before drm sometimes, causes KMS to fail" [Medium,Fix released] https://launchpad.net/bugs/430694
<Sarvatt> https://bugs.launchpad.net/bugs/542251
<ubottu> Ubuntu bug 542251 in linux "[i915] Initialises before agpgart" [Medium,Triaged]
<Sarvatt> it happens on radeon too in alot of bugs, search ati bugs for software rendering :(
<RAOF> But they can't rely on agp-intel being the right agp module, so...
<tjaalton> airlied said he'd make the agp modules mandatory (non-modules) because of bugs like these
<Sarvatt> yeah agp modules should be built into the kernel so it doesn't happen but i dont think any of the kernel people like that idea
<tjaalton> soon they have no choice
<tjaalton> :)
<tjaalton> and debian does that already afaik
<Sarvatt> yeah thats what jcristau said
<Sarvatt> it's going to add .006 seconds to the boot time though! :D
<tjaalton> oh noes :)
<Sarvatt> oh nice ati 6.13
<Sarvatt> apw: any chance of having agp built into the kernel instead of as modules? we've got a lot of nasty bugs about it because we dont
<Sarvatt> can get you a list if it would help, the two major ones we just linked but there are quite a few radeon ones as well
<ScottK> Not for Lucid there isn't.
<Sarvatt> https://bugs.freedesktop.org/attachment.cgi?id=34687 -- darn it's close, no longer crashing the server ever but quadrapassel is black until i move it so part of the window is off of the screen
<Sarvatt> with compiz enabled it's always black :)
<Sarvatt> hmm, what happened to http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=c5155725948be57010c4a558a1b9c5ddefb864c3
<Sarvatt> looks like that got dropped somewhere along the line as well
<Sarvatt> bryce_: wow that washed out DVI-VGA radeon problem got fixed fast - http://marc.info/?l=dri-devel&m=127052658905865&w=2
<RAOF> What's responsible for ensuring the VTs have login prompts on them?  Is that getty?
<Sarvatt> yeah
<RAOF> Yeah?
<Sarvatt> in response to your question :)
<Sarvatt> we're running out of time to fix this clutter problem, ugh :(
<RAOF> Oh, that it's getty that's responsible for login prompts?  Sweet.
<Sarvatt> i'm having so many problems with clutter 1.2 even outside of the server crashes, i think they really expect people using it to be on xserver 1.8/mesa 7.8
<Sarvatt> our glx 1.4 backport stuff is throwing it off, it works fine without them since it falls back to glx 1.2. it's falling back to glXGetVideoSyncSGI too (which SUCKS on intel) since GLX_SGI_swap_control stopped being advertised for some reason recently
<Sarvatt> ok thats a relief, its just quadrapassel that sucks
<Sarvatt> \o/ https://bugs.freedesktop.org/show_bug.cgi?id=26394#c21 fixes everything I can throw at it except it breaks quadrapassel :D
<ubottu> Freedesktop bug 26394 in Extensions/DRI "Server sometimes crashes when closing OpenGL programs" [Critical,New]
<Sarvatt> RAOF: yeah that mbp_backlight intel ddx patch looks good, surprised it's not in there already since its been in the kernel for a few years
<Sarvatt> i thought it was someone's hacky backlight driver thats not upstream yet so not relevant to upstream but its mbp_nvidia_bl
<Sarvatt> yuck, publication is taking upwards of 5 hours on PPAs now
<ricotz> Sarvatt, do you know the problem at launchpad about this delay?
<bjsnider> ricotz, ask in the #launchpad channel
<Sarvatt> ok clutter apps really are fixed, the black screen in quadrapassel I was seeing was just with xorg-edgers packages
<bjsnider> ricotz, there was a merge last night that supposedly fixed a huge gnome-shell memory leak
<Sarvatt> wish I could figure out why GLX_SGI_swap_control isn't advertised in glx extensions though, GLX_SGI_video_sync is *horribly* slow on intel and makes mutter/gnome-shell and such unusable
<chrisccoulson> Sarvatt, i got one confirmation so far that the gnome-screensaver fix resolves the display not being restored correctly on user switching
<Sarvatt> \o/
<chrisccoulson> so, i will upload that today, but it will sit in the queue until after b-2 now
<ricotz> bjsnider, yes, i saw it
<Sarvatt> this xserver fix is pretty darn urgent
<bjsnider> ricotz, cool
<Sarvatt> any clutter app closing under dri2 is segfaulting the server..
<ricotz> Sarvatt, is this clutter crash happening with edgers-ppa and lucid packages?
<Sarvatt> both
<Sarvatt> well i've got the fix in edgers
<ricotz> ok, this would effect me on nouveau with 2.6.34
<ricotz> Sarvatt, ok, but the release is pending, like in all ppa ;-)
<bjsnider> the error that appears in this log is happening when installing nvidia-current right now: http://pastebin.com/zGe5YtEh
<Sarvatt> bjsnider: no error in that log, i told tseliot about it the other day though.. the GUI is saying it failed but it really didn't and it works fine
<bjsnider> yes i know, but it shouldn't say that it failed when it didn't
<tseliot> bjsnider: can I see the output of "update-alternatives --display gl_conf" and of "ldconfig -p | grep GL" please?
<bjsnider> tseliot, hold on, i'm acting as a middle man here
<tseliot> no hurry
<bjsnider> this happened to me too though, so i can contribute
<bjsnider> in pastebin?
<tseliot> yep
<bjsnider> http://pastebin.com/fZhfm8VW
<bjsnider> that's both commands on my system
<tseliot> bjsnider: that looks good. I'll look into this issue
<bjsnider> tseliot, this is the other guy that had the same issue a couple minutes ago: http://pastebin.com/GQJrDeJz
<tseliot> thanks
<Sarvatt> yeah everything looked fine and it really installed right, just that debug message made it throw up an error or something
<BUGabundo> is there any wiki that lets us follow on the current state of which drivers work for which GPU?
<Sarvatt> like what BUGabundo?
<BUGabundo> Sarvatt: I have no idea which ATI drivers are there, and which cards each support
<BUGabundo> everytime an user asks me, I just say I don't know
<BUGabundo> which I really don't like to do :\
<BUGabundo> also, with so many versions of nvidia blog, nouveua, nouveua 3D, bla bla
<BUGabundo> and with the changes intel has been doing in the last two cycles, releasing cards with poor (none?) support for linux
<Sarvatt> only things with poor support for intel are old 8xx GPU's and GMA500 that isn't really intel
<Sarvatt> fglrx is for R600 and up (aka HD 2xxx series or newer)
<BUGabundo> ok
<BUGabundo> need to put that in some wiki
<BUGabundo> I won't remember it in 15 min time
<tjaalton> heh, so there is a driver for the waltop tablets, called linuxwaltop. seems like a fork of linuxwacom-0.8.4
<tjaalton> so.. I'll diff it and see if it can be pushed to xf86-input-wacom
<Sarvatt> tjaalton: only diff is the removal of the wacom vendor check line in one file afaik and they wont accept it upstream
<tjaalton> Sarvatt: really? reference?
<tjaalton> things might have changed now that ping doesn't own the driver anymore
<Sarvatt> i've read it brought up on the wacom-devel lists tons of times in the past year, dont have any references offhand
<tjaalton> ok, I'll search
<tseliot> tjaalton: is the new mesa in place now? Do you have any further changes to make?
<tjaalton> tseliot: haven't uploaded yet, but it wouldn't make it in beta2 anyway
<tjaalton> that's what I was told last week
<tjaalton> so, post-b2
<tseliot> ok, thanks
<Sarvatt> i think you'd need to patch it in the kernel now though
<tjaalton> Sarvatt: that too, but it used to work with linuxwacom in jaunty
<tjaalton> not fully though
<Sarvatt> didn't it build an external kernel module back then?
<tjaalton> no, stock jaunty
<Sarvatt> http://wiki.archlinux.org/index.php/Wacom#WALTOP_tablet_support_by_the_Wacom_drivers
<tjaalton> in karmic that made the server crash
<tjaalton> or didn't work otherwise, can't remember
<tjaalton> judging by the diff the vendor id seems to be the only change.. sigh
<jcristau> and ping is naking that change?
<Sarvatt> look at the n-trig patches to wacom, i'm sure you can hook it in the same way
<tjaalton> jcristau: yep
<jcristau> sounds stupid
<tjaalton> Sarvatt: yeah it's the same spot
<tjaalton> but the kernel driver needs changes too to make it fully functional
<tjaalton> looks like it's a rebranded graphire
<tjaalton> ah the kernel driver is completely new
<Sarvatt> tjaalton: so what happens when you plug in a waltop tablet now? the stylus should at least work?
<tjaalton> Sarvatt: nothing happens, since wacom.conf includes it :)
<tjaalton> but the driver ignores the id
<tjaalton> evdev would "work"
<tjaalton> I haven't tried patching the current driver yet
<Sarvatt> hmm fedora is matching WALTOP to wacom with no xf86-input-wacom patch
<tjaalton> that's a leftover
<tjaalton> pretty sure about that
<tjaalton> they got it from us in the first place..
<tjaalton> once someone had said that it worked ~a year ago
<Sarvatt> the xf86-input-wacom fdi has waltop too
<Sarvatt> ahh
<tjaalton> oh the upstream one? that's hilarious
<Sarvatt> i figured he removed the check
<Sarvatt> tjaalton: did you make the udev rule make a symlink for your waltop tablet?
<tjaalton> Sarvatt: no
<tjaalton> those symlinks are useless now I think
<tjaalton> aiui they were just for convenience when setting up the device via xorg.conf
<tjaalton> in pre-hal world
<Sarvatt> oh, i couldn't use wacom without a symlink though and thats what tripped me up first trying to convert xf86-input-wacom over, i think the driver expects it
<tjaalton> no-one else uses them anyway
<tjaalton> fedora doesn't ship rules at all
<Sarvatt> weird, wonder what problem I had then, it wouldn't load the kernel module unless I had the /dev/input/wacom symlink
<tjaalton> ah
<tjaalton> well, loading the module made no difference
<Sarvatt> err I meant the X driver sorry, kernel module loaded fine when it was plugged in
<tjaalton> when was this?
<Sarvatt> *right* after the udev support went in, back in january
<Sarvatt> looks like its not needed now though and it does the extra device detection in the driver instead
<tjaalton> you mean udev support in wacom?
<tjaalton> that was late january
<tjaalton> hmm, lots of duplicate stuff in the waltop kernel driver.. this should be forward-ported to the current hid infrastructure
<tjaalton> the wacom driver is less than 300 lines..
<tjaalton> waltop is ~500
<tjaalton> well, closer to 1000 since it's split in three files
<tjaalton> perhaps it could use the wacom driver as well, but it's hard to compare these since wacom is newer.. need to grab an older one
<tjaalton> damnit, was looking at the wrong driver :)
<tjaalton> the 300 lines were for the bluetooth wacom
<tjaalton> ok this makes more sense
<tjaalton> still, lots of renaming
<tjaalton> sounds like a fun project to merge this stuff in the wacom kernel driver.. I'll give it a shot
<tjaalton> meh, maybe the kernel drivers aren't mergable after all
<seb128_> hey
<seb128_> could somebody look at bug #554023?
<ubottu> Launchpad bug 554023 in gdm "gdm fails to start" [Low,New] https://launchpad.net/bugs/554023
<seb128_> the guy says it's started on wednesday
<seb128_> seems rather an xorg than gdm issue
<tjaalton> commented
<seb128_> tjaalton, thanks
<ScottK> bryce_: I upgraded my 865 box and once I manually reinstalled the driver, then it works nicely.  Bug #556629 is the bug for the driver getting removed.
<ubottu> Launchpad bug 556629 in update-manager "Upgrade fails due to no video driver - Intel removed during upgrade" [High,New] https://launchpad.net/bugs/556629
<tjaalton> you had x-x-i-2.4 installed?
<ScottK> Yes, I think so.
<ScottK> It's the only way to make Karmic work with 865
<tjaalton> still weird that it removed -video-all instead of pulling -intel
<ScottK> Yes.  I think mvo should look at that case and special case it.
<tjaalton> or should -intel Replace -intel-2.4?
<ScottK> Pretty much anyone with 865 that's on Karmic will hit it (unless they like 800 X 600)
<ScottK> Does it conflict now?
<ScottK> If it does, that would probably solve it.
<ScottK> I need to run out for $WORK meetings, but wanted to bring it to your attention.
<tjaalton> not intel, but the xserver conflicts with every package providing the old abi
<ScottK> Ah.
<mvo> ScottK: thanks! I have a look now
<ScottK> mvo: Great.
<seb128> re
<seb128> tjaalton, bug #554023 the submitter replied
<ubottu> Launchpad bug 554023 in gdm "gdm fails to start" [Low,New] https://launchpad.net/bugs/554023
<Sarvatt> tjaalton: that xserver-xorg-video-intel-2.4 that guy had in a PPA had a bumped epoch. i really wish ppa-purge was automatically run during upgrades somehow instead of just disabling the sources because i get emails all the time from people upgrading from edgers to a new release with older versions than are in edgers
<bryceh> Sarvatt, makes me wonder if people are using xorg-edgers who shouldn't be
<BUGabundo> \o
<Sarvatt> oh crap
<Sarvatt> bryceh: new MAJOR symptom
<Sarvatt> 965+ intel, gpu hang during boot, x64 arch
<Sarvatt> i saw seb128's bug link there and put two and two together, theres huge IOMMU problems and I didn't realize we had IOMMU enabled because I was looking at the i386 config
<Sarvatt> http://cvs.fedoraproject.org/viewvc/F-12/kernel/linux-2.6-cantiga-iommu-gfx.patch?view=markup -- need badly
<Sarvatt> if we see someone with those symptoms, ask them to boot with intel_iommu=igfx_off
<bryceh> Sarvatt, ok; do we have LP#'s on this?
<Sarvatt> the workaround for broken graphics drivers kernel config option was dropped in 2.6.32, dang I wish I realized we had IOMMU enabled sooner
<Sarvatt> here's a redhat bug - https://bugzilla.redhat.com/show_bug.cgi?id=538163
<bryceh> why'd we enable it?
<ubottu> bugzilla.redhat.com bug 538163 in kernel "Spurious DMAR faults on integrated Intel graphics" [High,Closed: currentrelease]
<Sarvatt> probably did it back in karmic and it was fine back then because it picked a kernel option that made it work right with graphics but that kernel config option was dropped
<Sarvatt> thinkpad x200's are especially hit hard with that
<Sarvatt> RAOF must have a 32 bit ubuntu installed
<tjaalton> Sarvatt: so the bug should be reassigned to kernel?
<Sarvatt> well I looked into it a bit more and we are carrying all of the patches, the people still having it all are using swiotlb (meaning they have intel x64 without virtualization support or disabled) so I'm trying to dig into that more
<Sarvatt> like https://bugzilla.kernel.org/show_bug.cgi?id=14627 except we have that fix
<ubottu> bugzilla.kernel.org bug 14627 in Video(DRI - Intel) "i915: *ERROR* Execbuf while wedged" [Normal,Closed: code_fix]
<tjaalton> well maybe it was a different bug too, since this one just doesn't get the edid from vga1
<RAOF> Sarvatt: My x200s is fine, and running x86-64.  Would disabling VT in the bios and trying to boot be an interesting datapoint for you?
<Sarvatt> RAOF: yeah if you dont mind :D
<kklimonda> chrisccoulson: no luck here with your gnome-screensaver
<RAOF> Looking at that RH bug, it looks like people were having problems when VT-x was *enabled* - I have it enabled.
<chrisccoulson> kklimonda, yeah, one person originally said that it worked and then changed their mind
<chrisccoulson> bugger!
<chrisccoulson> kklimonda, xtrace log would be good then, as it looks like there are 2 issues
<kklimonda> chrisccoulson: http://pastebin.com/UNULvm57 - does it look like a proper xtrace?
<kklimonda> if so I'll attache it to 555870
<chrisccoulson> kklimonda, yeah, that looks ok. that is from gnome-screensaver and not test-fade isn't it?
<kklimonda> chrisccoulson: it's from test-fade. do you want one from gnome-screensaver itself?
<chrisccoulson> kklimonda, probably not. it shows the same issue that i thought i'd fixed yesterday
<chrisccoulson> this is definately with the patch applied isn't it?
<kklimonda> chrisccoulson: yes - I have your package installed and have restarted system (because I've managed to lock it while testing :/)
<kklimonda> chrisccoulson: how can you read anything from xtrace log? it looks like nonsense to me ;)
<chrisccoulson> kklimonda, it just shows all the raw X protocol calls. line 424 shows the issue though (the last CrtcSetGamma call)
<chrisccoulson> there should be another call to reset it back to what it was
<chrisccoulson> ** SetCrtcGamma even
<chrisccoulson> ok, i'm slightly confused now
<chrisccoulson> i can't recreate that issue with my patch :(
<kklimonda> oh, both cores at 100% :/
<kklimonda> and I'm wondering why do I smell something funny
<kklimonda> htop
#ubuntu-x 2010-04-07
<bryceh> RAOF, I'm going through the queue of bugs that have been nominated for lucid and assigning them out to people, so I'm going to assign a few -intel bugs to you
<RAOF> Sounds good to me.
<bryceh> RAOF, but the way we handle these at this stage in the release is that they need *reviewed* more than fixed
<bryceh> look at them and decide if they look doable and worthwhile to fix for lucid - if not, unassign yourself and mark them 'ct-rev'
<bryceh> if they do look important, forward them upstream (or find a patch to fix them)
<RAOF> :)
<bryceh> keep in mind we can also fix some post-release via SRUs
<bryceh> ones that are going to affect people from booting the livecd will be higher priority since sru's won't be of help there
<RAOF> I can track those by milestoning them to lucid-updates, right?
<bryceh> I think so, yes
<bryceh> haha, looks like when there is a nomination proposed for karmic, if no one declined or accepted it, launchpad makes a new nomination proposal for lucid even if no one actually asked for it
<bryceh> this explains why I'm having to decline like 80% of the nominations :-)
<RAOF> :)
<jg> bryceh: I tried installing lucid beta 1 on this dell latitude xt I have, and X doesn't start...  Any chance in beta 2?
<RAOF> What video does the dell have?
<jg> it's a ATI Radeon Xpress 1250, I believe.
<jg> RAOF: worked ok in koala...
<RAOF> Hm.  I'm not aware of any particular problems with that chip.
<RAOF> It's difficult to say anything without logs; Xorg.0.log & dmesg are the favourites.
<jg> RAOF: if I can get to the logs.... 
<RAOF> Always the problem! :)
<jg> particularly with a fresh installation....
<jg> and as I had to start over since the upgrade had gone sour from a dying disk...
<RAOF> :(
<bryceh> jg, new thing for ati this release is we're doing KMS by default
<RAOF> You can always try adding radeon.modeset=0 to the kernel boot line.
<bryceh> jg, so you could try going ... yeah what RAOF said :-)
<jg> bryceh, RAOF: I'll try that in the morning.
<johanbr> isn't Xpress 1250 closely related to Xpress 200M?
<johanbr> you may also want to try "pci=nomsi" as a kernel parameter
<johanbr> see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/509273
<ubottu> Launchpad bug 509273 in linux "[Lucid] Radeon Xpress 200M needs PCI quirk to fix or disable MSI" [High,In progress]
<bryceh> johanbr, yeah you might be right
<Sarvatt> jg: thats a rough one because it has a super rare GPU, i dont think it's working at the moment
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati?field.searchtext=rs600
<Sarvatt> jg: http://bugs.freedesktop.org/show_bug.cgi?id=25408
<ubottu> Freedesktop bug 25408 in DRM/Radeon "Radeon KMS doesn't work for RS600" [Major,Reopened]
<jg> Sarvatt, ubottu: certainly seems the same bug
<jg> Sarvatt, ubottu: should I add a "mee tooo" to the bug?
 * Sarvatt wants a fdo-bug command
<bjsnider> is the latest nvidia-settings package going to be added or is it going to be the one in the archive now?
<superm1> bjsnider, what changed between the two?  new features, or just bug fixes?
<Sarvatt> bjsnider: nvidia-settings 195.36.08 IS 195.36.15
<RAOF> Sarvatt: That IOMMU bug doesn't affect me; either with VT on or VT off.  It's possible that it doesn't affect the x200s BIOS', or that I've got a new (or old) enough BIOS to be unaffected.  Or, it's fixed in 2.6.33, but that doesn't seem right.
<Sarvatt> RAOF: we dont have DMAR enabled
<Sarvatt> i was off
<RAOF> Ah, ok.  Cool, false alarm.
<Sarvatt> programmable EC = I think I found my next laptop :)
<RAOF> EC+
<RAOF> EC?
<Sarvatt> wow, first time i've seen a bios *that* crappy
<Sarvatt> dug up an old dell vostro 200 out of storage and apparently you can't boot syslinux based stuff on it
<RAOF> Ah, intel-agp.  The gift that keeps on racing.
<bryceh> does lp #546871 look like a DMAR bug?
<ubottu> Launchpad bug 546871 in xserver-xorg-video-intel "[i945gm] System freeze induced by Chrome" [Undecided,Confirmed] https://launchpad.net/bugs/546871
<bryceh> maybe not
<RAOF> There doesn't seem to be any DMAR messages in dmesg, and that doesn't seem to be the symptom (which seems to be a freeze soon after starting X)
<bryceh> hmm, well I'm not seeing any LP bugs that match up with the DMAR bug
<bryceh> maybe there's something filed against the kernel
<RAOF> Sarvatt says we don't actually have DMAR enabled.
<bryceh> RAOF, aha
 * bryceh un-gtg's a todo :-)
<RAOF> Damnit, apple.  What have you done to the macbook such that a perfectly acceptable G96 doesn't boot right?
 * bryceh waves to ara
<ara> morning bryceh :)
<ricotz> Sarvatt, hello, you need to trigger a xserver rebuild in order to get it built against the new x11proto packages
<bryceh> Sarvatt, RAOF:  http://www2.bryceharrington.org:8080/X/Graphs/drivers.svg
<hceylan> Hello I am trying the packages from ppa:xorg-edgers I upgraded the packages and installed nouveau-back-ports but I get "KMS not enabled" any ideas
<hceylan> My main objective is to test nouveau+galliÄum3D
<RAOF> hceylan: What Ubuntu version are you using?  I think that xorg-edgers is very much tailored to lucid right now.
<bryceh> good god -intel is a buggy driver
<hceylan> lucid
<Ng> bryceh: it's a shame it's not maintained by the creators of the chipset so they can make it really good ;)
<bryceh> Ng, *sigh*
<RAOF> hceylan: There's all sorts of problems that could be.  Can you pastebin dmesg & Xorg.0.log?
<bryceh> Ng, I spent the past month focusing on -ati and have gotten spoiled
<Ng> bryceh: oh? is their stuff good now?
<bryceh> Ng, well, they seem to be much more sane in how they handle bugs
<hceylan> RAOF: gotta go for a meeting I'll be back later. thx
<bryceh> Ng, btw how's your -intel experience been lately?
<Ng> bryceh: apart from the weird flashing bug going round gm45 people, pretty much solid :)
<bryceh> well that's good
<bryceh> Ng, have a lp# on the flashing bug?
<Ng> bryceh: bug #538648
<ubottu> Launchpad bug 538648 in xserver-xorg-video-intel "[gm45] Irregular sync flashes with compiz on (Lenovo T500)" [Medium,Incomplete] https://launchpad.net/bugs/538648
<bryceh> ok
<Ng> it was happening a lot last night so I rebooted with the i915.powersave=0 suggestion, but I'll need to run it for a few days to be able to say whether it's made any difference. Some days I don't get it at all, some days it happens most minutes
<Ng> but never when I have my second monitor attached at work, otherwise I'd be smashing my laptop against a rock ;)
<bryceh> :-/
<seb128> intel works fine there as long as you don't play with a dock station
<seb128> if you start docking and undocking a laptop things just break
<seb128> displays don't activate when they should, xorg crashes, etc
<Ng> interesting
<Ng> I wonder how docking differs from just plugging in a monitor
<Ng> I hook up a monitor to DisplayPort via a DVI adapter every day and poke Fn-F7 and it's been very reliable
<seb128> well I tend to close the lid while docked
<seb128> suspend and take the laptop
<seb128> and open it later somewhere else
<bryceh> seb128, is it messing up gnome-display-properties, or X in general ?
<seb128> which leads to have the laptop screen still off
<seb128> bryceh, in the scenario I describe I've no active screen
<seb128> so I need to switch vt to get one
<seb128> also user switch when docked = fail
<seb128> it turns off the external screen
<seb128> and I've no way to reactivate it
<seb128> I though for a while that the box was crashing
<seb128> until I opened the lid of the docked laptop to notice the laptop screen works
<Ng> seb128: ah right, I'm quite cautious about doing things while it's suspended, so I unplug everything, poke Fn-F7 and then close the lid :/
<Ng> I'll try suspending first :)
<seb128> fn-n7 doesn't success to activate the external screen again after user switch
<bryceh> good god -intel is a buggy driver
<seb128> I need to restart xorg to have it working again
<bryceh> http://www2.bryceharrington.org:8080/X/Graphs/drivers.svg
<seb128> urg
<seb128> nice drop in the ati count
<bryceh> it's at least going in the right direction
<seb128> right
<seb128> I'm wondering if intel is that buggy
<seb128> or if there is just a lot of bug noise or users running into the same issues there
<tjaalton> yeah it could be the same bugs all over again
<bryceh> maybe
<bryceh> we do pretty good triaging on -intel though...
<tjaalton> true
<bryceh> I could buy that on -nvidia which we largely ignore
<seb128> I'm not so sure what videocard I should look at in my next laptop now
<bryceh> seb128, I recommend not getting a video card
<tjaalton> hehe
<seb128> lol
<tjaalton> headless laptops ftw
<bryceh> seb128, seriously, they make your laptop unstable
<tjaalton> a braille "display" for your thumb
<tjaalton> and then just type away ;)
<seb128> let's get a good old serial vt
<bryceh> 965 seems to be ok
<bryceh> ati 5xx is ok but you can't find those on laptops
<seb128> 965 is what I have now
<seb128> which I'm fairly happy with out of docking issues ;-)
<bryceh> at least with intel they put out fixes fairly routinely, so even if it's broken now, it'll improve next go around
<tjaalton> yeah mine works as well, but I don't use another displays
<bryceh> of course, the go-around after that all bets are off
<tjaalton> -an
<bryceh> ati gets better over time
<tjaalton> my next laptop will be a lenovo again, so it's likely with intel gfx. the desktop will get ati next
<bryceh> ati seems to have performance and corruption issues, but less of the crash/freeze issues
<bryceh> intel is the opposite
<bryceh> nvidia is just mad
<tseliot> heh
<bryceh> at least with -nvidia you're in good company
<bryceh> and if you don't like being in good company you have the option of -nouveau
 * tseliot nods
<bryceh> heya tseliot
<tseliot> hey bryceh
<bryceh> tseliot, btw I've assigned a few bugs to you but don't feel they all need to be solved... just review and decide if they really need attention for lucid; if not, tag them 'ct-rev' and unsub from them.
<bryceh> (and if they're kernel issues, please reassign to 'linux')
<tseliot> bryceh: that's fine. I think I can bug upstream about some of those bugs and fix the issues if they are in the packaging
<bryceh> cool
<bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg
<bryceh> good news is we're continuing our downward trend
<sebner> tseliot: is there still a nvidia update planned? (You know, I once told you that my performance dropped with the driver upload before the last one)
<bryceh> ^ the above graph excludes bugs sent upstream or waiting on users (Incomplete without response).
<tseliot> sebner: only minor packaging fixes will get in, unless Nvidia releases something that fixes other bugs
<sebner> tseliot: grrrrm kthx
<tseliot> sorry but I doesn't depend on me
<sebner> tseliot: heh, sure. I'm definately not angry with you but nvidia ;)
<bryceh> night
<tseliot> good night bryceh
<tjaalton> night bryceh 
<tjaalton> ok, waltop wacom hotplug works, now to merge the kernel driver
<apw> anyone know if it is possible to reneble a DRM output which is forced off in a video=foo:d specifier?  from X as it were?
<tjaalton> xrandr --auto?
<apw> tjaalton, doesn't seem to do anything no
<apw> trying to work out just how to handle the booting with screen closed mess
<apw> and trying out the video= to try and fix it
<tjaalton> hmm ok, maybe xrandr can't help if it's forced off from the cmdline
<tjaalton> which probably means the driver can't see it at all
<apw> tjaalton, its listed as disconnected
<apw> but i don't seem to be able to undo that
<apw> which is a shame
<tjaalton> ah, ok
<bjsnider> tseliot, are you planning on updating nvidia-settings to the latest tarball?
<tseliot> bjsnider: I uploaded a fix so that it can work with legacy drivers (no more issues with the lack of the noscanout property). Do you know if there's anything useful in the new release?
<bjsnider> i don't know that, but i asked because i have it in the ppa, and users who are upgrading are keeping it because i guess apt is choosing it over the lucid package
<bjsnider> i have to add conflicts: screen-resolution-extra (>= 0.13) or whatever to force it out i suppose
<bjsnider> it didn't occur to me that apt would keep karmic packages during a distro upgrade
<bjsnider> it's possible that someone upgrading from hardy to lucid would still have hardy packages afterwards
<bjsnider> !info screen-resolution-extra lucid
<ubottu> screen-resolution-extra (source: screen-resolution-extra): Extension for the GNOME screen resolution applet. In component main, is optional. Version 0.13 (lucid), package size 13 kB, installed size 172 kB
<tseliot> yes, well if the version in your ppa is greater than the one in lucid, that's expected
<jg> bryceh, RAOF: booting the live cd nokms works.
<Sarvatt> seb128: funny enough problems like you describe are usually fixed by bios updates, might be worth looking into
<seb128> Sarvatt, oh, thank you
<Sarvatt> I just looked up pitti's D430 after seeing he was 10 updates behind and they fixed a similar issue on his
<Sarvatt> seb128: what model is it?
<seb128> Sarvatt, the laptop? dell d630
<Sarvatt> seb128: what bios version are at? it's up to A17 now, I bet you're at A00 too :D looks like all the same upgrades from pitti's d430 are also on this d630, hangs on resume, crashing opening and closing the lid too fast, bios A12 updated the video bios too
<Sarvatt> dell site is taking way too long to go through every changelog, i just looked at the latest 5 updates
<seb128> Sarvatt, dunno, how do I know the version?
<Sarvatt> sudo dmidecode -t bios
<seb128> out of looking at the screen on boot
<seb128> I never touched the bios in 3 years
<seb128> so I bet it's outdated :p
<seb128> 	Version: A03
<Sarvatt> i mean i only looked between A12 and A17 versions and I saw a ton of major fixes
<seb128> I need to look at how you update a bios from linux
<seb128> I didn't update bios since I stopped having a dos floppy to do that :p
<Sarvatt> yeah same thing here, i just made a freedos boot usb with unetbootin and put the update on it last time though
<Sarvatt> i think dell has a bunch of ways to update it in linux
<seb128> thanks for the hint
<seb128> I will look into trying that
<Sarvatt> hmm the firmware-addon-dell package it looks like?
<seb128> indeed
<Sarvatt> looks like a pain in the butt to set up, freedos boot usb probably much easier :D
<apw> bryceh, about?
<bryceh> hi apw
<apw> bryceh, any idea how to test this multitouch stuff ?
<bryceh> apw, heh was gonna ask you the same thing
<bryceh> apw, I've got your kernel and my bits on the laptop, and played with gimp a bit
<bryceh> doesn't crash, and the finger touches work now (they didn't before)
<bryceh> but only for moving the cursor, not for clicking.
<bryceh> apw, was hoping the qa team could sketch out a testing process for us
<bryceh> apw, know of any tools which will just print out that it received the MT data?
<apw> bryceh, mine works ok but only single touch
<apw> i am told evtest is the toy, but i can't udnerstand the output
<apw> bryceh, i also thought multitouchd was the magic for testing, but i can't make it work
<bryceh> no, they decided against using multitouchd, so don't waste time with that
<apw> bryceh, any idea where rafi is?  looking to find out if i need newer firmware
<bryceh> apw, haven't seen him on irc for a long while
<bryceh> probably reachable via email though
<bryceh> just tried evtest, but can't seem to get output out of it when touching screen.  Do I need to make something stop grabbing the events?
<bryceh> apw, looks like rafi has a test tool
<apw> bryceh, ok i can use evtest to get multitouch data
<apw> on mine i have three event channels
<bryceh> apw, ok how are you running it?
<apw> the one which calls it Multitouch
<apw> evtest /dev/input/event13
<apw> in my case
<bryceh> when I run xinput list I see two 'N-Trig Touchscreen' entries, id=13 and id=14
<apw> No i have 3
<apw>    name    : "N-Trig Pen"
<apw>    name    : "N-Trig MultiTouch"
<apw>    name    : "N-Trig Touchscreen"
<apw> and its the middle one of those i am using
<bryceh> when I run evtest /dev/input/event13 and 14 from within X, and touch the screen, I see nothing printed out
<apw> this is all with stock kernel now, as the stuff has gone into lucid
<apw> hrm
<apw> running as root yes?
<bryceh> ok I have two Pens, two erasers, and two touchscreens
<apw> hmmm
<bryceh> also a generic mouse and a mac mouse button emulation
<apw> one pen :)
<bryceh> hrm
<apw> you do have a different machine of course
<bryceh> this is with the kernel in the ppa, not stock lucid
<apw> which device id is it?  vendor/product ?
<bryceh> I've got the -19 kernel installed, I could boot over to it
<apw> that would be the one i am testing on 
<bryceh> Dell XT2
<apw> sorry i mean what vendor/product does lsinputs list for the touchscreen ones?
<bryceh> are you running evtest from under X, or from the console?
<apw>    vendor  : 0x1b96
<apw>    product : 0x1
<apw>  
<apw> running sudo evtest ... under an xterm
<bryceh> for event13, vendor/product is 0x111d/0x76b2
<apw> so thats not an n-trig then
<apw> ?
<bryceh> it should be
<apw> hrm ... 0x111d is something else
<bryceh> wait, looks like id's for xinput != id's for lsinput
<bryceh> how fun
<bryyce> here we go
<bryyce> /dev/input/event7
<bryyce>    bustype : BUS_USB
<bryyce>    vendor  : 0x1b96
<bryyce>    product : 0x1
<bryyce>    version : 272
<bryyce>    name    : "N-Trig Touchscreen"
<bryyce>    phys    : "usb-0000:00:1d.1-2/input0"
<bryyce>    uniq    : ""
<bryyce>    bits ev : EV_SYN EV_KEY EV_ABS EV_MSC
<bryyce> that looks better
<apw> thats n-trig at least
<apw> so next why don't you have a multi-touch like i do ... 
<apw> i guess next i'd say get into -19 so we're sure its the same kernel
<apw> but i suspect that won't help at all
<bryceh> ok one sec
<apw> bryceh, ok my 'Touchscreen' event channel does not seem to produce any events
<apw> i only get pen events from pen ovviously, and only get finger events on Multitouch
<bryyce> â¡ Virtual core pointer                    	id=2	[master pointer  (3)]
<bryyce> â   â³ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
<bryyce> â   â³ N-Trig Pen eraser                       	id=11	[slave  pointer  (2)]
<bryyce> â   â³ N-Trig Pen                              	id=12	[slave  pointer  (2)]
<bryyce> â   â³ N-Trig Touchscreen                      	id=13	[slave  pointer  (2)]
<bryyce> â   â³ N-Trig Touchscreen                      	id=14	[slave  pointer  (2)]
<bryyce> â   â³ N-Trig Pen eraser                       	id=15	[slave  pointer  (2)]
<bryyce> â   â³ N-Trig Pen                              	id=16	[slave  pointer  (2)]
<bryyce> â   â³ PS/2 Generic Mouse                      	id=18	[slave  pointer  (2)]
<bryyce> â   â³ Macintosh mouse button emulation        	id=19	[slave  pointer  (2)]
<bryyce> Linux tytherleigh 2.6.32-19-generic #28-Ubuntu SMP Wed Mar 31 17:46:20 UTC 2010 i686 GNU/Linux
<apw> bryyce, what printed that output?
<bryyce> apw, xinput list
<bryyce> dev/input/event7
<bryyce>    bustype : BUS_USB
<bryyce>    vendor  : 0x1b96
<bryyce>    product : 0x1
<bryyce>    version : 272
<bryyce>    name    : "N-Trig Pen"
<bryyce>    phys    : "usb-0000:00:1d.1-2/input0"
<bryyce>    uniq    : ""
<bryyce>    bits ev : EV_SYN EV_KEY EV_ABS EV_MSC
<bryyce> /dev/input/event8
<bryyce>    bustype : BUS_USB
<bryyce>    vendor  : 0x1b96
<bryyce>    product : 0x1
<bryyce>    version : 272
<bryyce>    name    : "N-Trig Touchscreen"
<bryyce>    phys    : "usb-0000:00:1d.1-2/input0"
<bryyce>    uniq    : ""
<bryyce>    bits ev : EV_SYN EV_KEY EV_ABS EV_MSC
<bryyce> +1 pen, +1 touchscreen
<bryyce> still not seeing any multitouch
<apw> bryyce, ok so i have a third one
<bryyce> hrm
<bryyce> bryce@tytherleigh:~$ dmesg | grep -i trig
<bryyce> [    2.720204] ntrig 0003:1B96:0001.0001: input,hiddev96,hidraw1: USB HID v1.10 Device [HID 1b96:0001] on usb-0000:00:1d.1-2/input0
<bryyce> [    2.727766] ntrig 0003:1B96:0001.0002: input,hiddev97,hidraw2: USB HID v1.10 Device [HID 1b96:0001] on usb-0000:00:1d.1-2/input1
<apw> you may have an old firmware
<bryyce> apw, have you updated your firmware?
<apw> bryyce, nope ... i don't know how
<bryyce> heh
<bryceh> apw, I'm sure it's something like, "First just boot into Windows 7, then..."
<apw> bryceh, i've not booted windows on mine if that helps
<apw> but i do think you have to have the latest firmware to get multitouch
<apw> so i wouldn't be supprised if its not up to date in there
<apw> no idea how one changes it of course
<apw> mine is demonstrating two finger tracking, no more than two, and no finger identifiers
<bryceh> ok, ...navigating a maze of twisty dell web pages...
<apw> but hey ... its doing something
<bryceh> ok dunno, but lunchtime.  bbiab
<Sarvatt> sheesh, rediculious how many flickering bugs i've googled the laptop name + flicker and seen its a general issue with the model
<Sarvatt> like http://www.google.com/search?hl=en&safe=off&q=Dell+Inspiron+1545+flicker
<Sarvatt> RAOF: what bios version do you have on your x200s?
<RAOF> Sarvatt: Let me fire it up.
<Sarvatt> 3 bugs now from people with x200s's that need i915.powersave=0
<Sarvatt> one on a T500 too
<Sarvatt> RAOF: is it really an x200s? not an x201s or anything?
<RAOF> Ok.  You seem to have triggered a bug on my x200s - it's not coming out of suspend at all.
<RAOF> Really an x200s.
<RAOF> Says so right under the screen.
<Sarvatt> whats the last 4 digits of the model underneath?
<Sarvatt> like x200s 7401 or something
<RAOF> 7465CTO
<Sarvatt> sheesh they give you bios update cd's and everything
<RAOF> Bios revision 2.8
<RAOF> Well, a BIOS update CD isn't really that useful on an x200
<Sarvatt> sure it is, usb image creator :D
<RAOF> Good point.  Is there a newer bios for me there? :)
<Sarvatt> LOTS
<Sarvatt> with nice fixes :D
<Sarvatt> - Fixed an issue where the computer might hang when the battery was low  - Improved the speed control of cooling fan. - Fixed an issue where VT (Intel virtualization Technology) setting was not changed at the first startup - Fixed an issue where some DVI monitors did not work. - Fixed an issue where 1-3-3-1 beeps might sound at boot or take time to resume normal operation from standby mode. - Fixed an issue that set wrong memory type.
<bryceh> Sarvatt, has the bios update confirmed to fix the problems?
<bryceh> (my experience has been that bios updates *sound* like they will fix whatever issue I have, but hardly ever actually *do*)
<Sarvatt> no i was just asking what he had since he has the same system and doesnt see the problems
<bryceh> ahh
<Sarvatt> not too much else to go on :D
<Sarvatt> RAOF: do you have a dual channel memory setup in that machine? it's a CTO so cant compare
<RAOF> Yeah; I've got two dimms in here.
#ubuntu-x 2010-04-08
<RAOF> I'm trying the reporter's cpuburn trick; still no flicker here.
<Sarvatt> got your backlight maxed? maybe if you dim it all the way?
 * Sarvatt gets flicker at the lowest brightness setting but its a hardware problem
<RAOF> The pcert tag is for... hardware that we want to platform-certify?
<bryceh> kewl: http://homepage.mac.com/arekkusu/bugs/GLInfo.html
<RAOF> That's moderately fun :)
<RAOF> bryceh: I see we've both decided that bug #541492 is a candidate for kms blacklisting at the same time :)
<ubottu> Launchpad bug 541492 in xserver-xorg-video-intel "MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?)" [Unknown,Confirmed] https://launchpad.net/bugs/541492
<bryceh> RAOF, heh
<bryceh> RAOF I already sent i830 off to be blacklisted
<bryceh> RAOF, any other chipsets we should think about blacklisting?
<bryceh> there was an ati card, but it ended up the kernel team got some patches to solve it
<RAOF> I'm still going through the list.  I think we should quirk off acceleration for some nvidia cards, and I've got a patch for that, but we can't quirk off kms for them :)
<RAOF> Oh, while I think of it - do you have any tips for how to decypher fedora's kernel packaging?  I wanted to see if they had any secret sauce for making macbook pros work, but I'm struggling with viewcvs.
<bryceh> link?
<RAOF> http://cvs.fedoraproject.org/viewvc/F-12/kernel/ ?
<bryceh> I don't have particular tricks, usually I just thumb through the patches and cherrypick
<bryceh> mm, slow webpage
<RAOF> Nouveau's a bit difficult for that in Fedora, since they basically take the diff between 2.6.33 and nouveau/linux-2.6 and apply it.
<bryceh> ah, ick
<bryceh> yeah in that case you'll have to go through the nouveau git tree or something
<RAOF> And hope that it's not one of the changes that is in fedora but not the nouveau git tree :/
<bryceh> tjaalton, I've moved the versions page up a level (and discarded the historical data):  http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html
<bjsnider> i830. never heard of that one
<RAOF> Yeah.  It's rare, and that doesnt' help.
<bjsnider> the number suggests it's pretty old i guess
<bjsnider> i wonder how many people are still using it
<bjsnider> and on what type of device
<RAOF> At least some on at least one tablet, and it doesn't drive their lvds because the encoder(?) isn't supported at all.
<bjsnider> don't tablets come with their own operating systems?
<RAOF> Tablet laptops, like the lenovo x300
<RAOF> Man, rev 02 Intel hardware is a rich source of hardware bugs.
<RAOF> Why is drm not even *attempting* to load in bug #552481 ?
<ubottu> Launchpad bug 552481 in xserver-xorg-video-intel "[i845g] Login screen doesn't appear" [High,Incomplete] https://launchpad.net/bugs/552481
<bryceh> RAOF, excluding proprietary drivers, we are at a point where we have fewer bugs in our workqueue than when we started:
<bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg
<RAOF> That's a *nice* looking curve at the end
<Sarvatt> bryceh: did you drop the hunk in drmmode_xf86crtc_resize on purpose in the intel 101-copy-fb.patch
<Sarvatt> ?
<Sarvatt> http://cvs.fedoraproject.org/viewvc/F-12/xorg-x11-drv-intel/copy-fb.patch?revision=1.9&content-type=text/plain&view=co
<Sarvatt> @@ -1373,6 +1382,8 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scr  -- that hunk is missing in ours
<bryceh> Sarvatt, wow that's an old one
<Sarvatt> i'm looking at the newest one relevant to 2.9.1
<bryceh> the formatting of our patch doesn't match what I generally create
<bryceh> nor does it look like an upstream patch
<bryceh> iirc someone gave it to me to include, but I don't remember who.  alberto maybe
<Sarvatt> i figured you applied it by hand and did a manual diff or something, must not have been you :)
<bryceh> mmm, maybe it's one of the ones we got from moblin
<bryceh> no, when I do patches they don't have the line of ======'s there at the top
<bryceh> perhaps the fedora patch is an updated version
<Sarvatt> they always had that hunk and fedora doesn't have any changes in the time frame of that diff
<bryceh> wait, are you sure we're missing that?
<bryceh> the chunk is
<bryceh> +	scrn->canDoBGNoneRoot = TRUE;
<bryceh> +
<bryceh> which we do have in our patch
<Sarvatt> we have +	pScrn->canDoBGNoneRoot = TRUE; in another area
<bryceh> I assume it's fine
<bryceh> RAOF, yeah been busting hump getting bug reports cleared out... a lot I'm just reassigning to the kernel, some I'm terminating with prejudice, others sending upstream
<bryceh> I've gotten -ati and xserver under control
<bryceh> -intel's going in the right direction but needs more attention
<RAOF> It looks like we'll want to kms-blacklist 845 & 855, which should resolve quite a number.
<bryceh> yeah I didn't get to i855 but noticed there's a bunch of bug reports there
<ScottK> I'm testing my 865 machine and I got the video into a mode the won't display.  How can I reset the resolution via ssh?
<RAOF> DISPLAY=:0 xrandr --output $WHATEVER --mode $SOMETHINGSAFE
 * ScottK tries
<bryceh> or sometimes just DISPLAY=:0 xrandr --auto
 * ScottK tries that first
<RAOF> That'll be a good one to squirrel away.
<bryceh> that and 'stty sane' :-)
<RAOF> Hm.  Taking out that cheese has made it clear how hungry I am.  Luncheon!
<bryceh> and Dinner for me!
<ScottK> DISPLAY=:0 xrandr --output VGA1 --mode 2048x1536 FTW!  Thanks bryceh.
<RAOF> Again these people with huge displays driven over VGA /:?
<ScottK> RAOF: That was the default after I upgraded.
<ScottK> I'm not going to leave it that way.
<ScottK> bryceh: Kwin desktop effects at 1400x1050 on 865G!
<ScottK> Definitely better than Karmic.
<Sarvatt> bryceh: *all* of the batchbuffer no space left on device bugs i can find that are happening right after startup have multiple displays and drmmode_xf86crtc_resize is called in that case, i'm not sure if its screwing up there because we are missing that hunk but it seems suspicious
<Sarvatt> (plus I cant find any non ubuntu reports of it happening upstream)
<RAOF> Sarvatt: Hm.  Could this perhaps *also* be related to the âplymouth, nouveau, and more than one screenâ hang we've got?
 * RAOF will be back shortly, after checking this kernel build
<RAOF> Good.  That patch works as expected.
<tjaalton> bryceh: ok thanks, updated my setup here
<Sarvatt> i think theres just something wrong in general with the bgnr stuff with multiple displays, looks like its happening in fedora too and we dont see it on radeon/nouveau because it doesn't work if theres multiple displays :)
<Sarvatt> https://bugzilla.redhat.com/attachment.cgi?id=386700
<Sarvatt> the failed to submit batchbuffer no space error always happens right after a (II) intel(0): Allocate new frame buffer event in Xorg.0.log in both ubuntu and fedora, no reports elsewhere
<Sarvatt> (with multiple monitors)
<RAOF> So, what happens if we don't put plymouth on any secondary monitors?
<Sarvatt> need to hook up another monitor and try to reproduce it so i can mess around in drmmode_xf86crtc_resize to see where its failing
<RAOF> This is the one big failing of the x200s: it's got a stupid, useless VGA output instead of something useful.
<bryceh> Sarvatt, ok on the batchbuffer no  space bug, keep investigating and let me know if you find something definitive; sounds like a promising lead
<bryceh> Sarvatt, might be worth making a ppa with redhat's patch instead of ours for folks to test; I can examine it more closely next week if it proves to make a difference
<Sarvatt> i dont think the nouveau thing is related btw, that seems to be a lockup in TTM when theres multiple monitors and it just waits forever somewhere, and its exacerbated by alot of <=nv40 cards always saying they have a tv connected which fedora forces off by default
<Sarvatt> bryceh: it happens on fedora too
<Sarvatt> just fedora and us
<bryceh> well, that's like 95% of the market between the two ;-)
<RAOF> Do we have any reports of -ati disliking plymouth + dual-head?
<Sarvatt> no because it doesnt copy the fb in dual head
<Sarvatt> only intel does that
<bryceh> RAOF, not that I've seen
<Sarvatt> first place i looked was drmmode_display.c in both radeon and nouveau, they have the copyfb stuff upstream already
<bryceh> Sarvatt, or maybe a ppa with that patch dropped
<Sarvatt> yeah thats what i'm thinking, ask them to test with it dropped at worst case (even though that sucks)
<Sarvatt> its the ones with Failed to submit batchbuffer: No space left on device in the xorg log, or [drm:i915_gem_execbuffer] *ERROR* Failed to pin buffer with a -28 return
<bryceh> we need a Ubuntu Bug Triage drinking game
<RAOF> Everytime vga16fb messes things up you take a shot?
<bryceh> and every mention of bug #1
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<bryceh> or "total show stopper"
<RAOF> No!  âI see this behaviour too, on $TOTALLY_DIFFERENT_HARDWAREâ
<RAOF> s/behaviour/bug/
<Sarvatt> ok going to upload an intel with no 101-copy-fb.patch and ask the 10 or so bugs I see from a quick search to test :) if anything disabling it if theres >1 monitor shouldn't be hard, drmmode_display.c is pretty much duplicated between the 3 drivers and we can just do it how nouveau does (besides the uxa specific stuff)
<RAOF> I'm not sure that doing it how nouveau does it is a wonderful idea; copy it too well and you'll make plymouth hang with >1 monitor :)
<Sarvatt> that happening on NV50+ too?
<RAOF> Yes.
<Sarvatt> i think thats a nouveau specific problem though, seems to be hung looping a gem ioctl and getting stuck in ttm_bo_wait
<Sarvatt> first thing i looked at was http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f0fbe3eb5f65fe5948219f4ceac68f8a665b1fc6 but we have that
<Sarvatt> thats where its getting stuck though
<RAOF> Yeah.  I'm pretty sure that we've got the interesting bugfixes from nouveau/linux-2.6.
<Sarvatt> something tells me its a problem fixed in the api bump :)
<RAOF> I seem to remember having the same problem with xorg-edgers, though.
<bryceh> oh one other thing with >1 head systems
<bryceh> I feel like a dunce for not mentioning it already since it's >exactly< what I've been fiddling with all afternoon
<bryceh> watch for cases that are: a) multihead with total width > 2048; and b) running compiz; and c) older hardware with max texture size = 2048
<bryceh> symptoms include black screen, strange corruption on right side of monitor, freezes, or other random behavior
<bryceh> regression from karmic
<bryceh> see bug #428769
<ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor due to hw limit with textures > 2048" [Unknown,Fix released] https://launchpad.net/bugs/428769
<bryceh> in karmic, there was a wrapper script to compiz that checked the max texture size and refused to run
<bryceh> in lucid, they got rid of the wrapper in favor of doing the checks in the compiz binary, but it seems something is still not quite right
<bryceh> bug #555641 is the X.org side of things, basically that it's a hardware limit and compiz shouldn't run in this case
<ubottu> Launchpad bug 555641 in xorg-server "MASTER: max texture size prevents compiz from running" [Wishlist,Triaged] https://launchpad.net/bugs/555641
<bryceh> see also http://bugs.freedesktop.org/show_bug.cgi?id=27530 where alex confirms as much
<ubottu> Freedesktop bug 27530 in Driver/Radeon "[RV370] Portion of second monitor unusable" [Normal,Resolved: notabug]
<RAOF> bryceh: That's a slightly different bug though, isn't it?  I'm fairly sure multihead with *>* 2048 width works by falling back to metacity (I've seen this confimed in lucid bug reports).
<RAOF> The problem in that bug is with a screen resolution exactly *equal* to the max texture size.
<bryceh> RAOF, it's supposed to do that, but I've run through several bug reports now where it clearly did not happen
<RAOF> Which is significantly less common, I'd hope.
<bryceh> well, see #556631 as another example, where it's >2048
<Sarvatt> yeah its 1 pixel off it seems bryceh, 2047 works 2048 doesn't so theres something odd going on
<Sarvatt> 2048 = compiz starts fine but you get a black screen, 2047 works from the bugs i've read over the past few months
<Sarvatt> 2049 would just fall back to metacity right
<RAOF> Sarvatt: Bug #556631 does seem to be a counter example there.
<ubottu> Launchpad bug 556631 in xserver-xorg-video-ati "Portion of second monitor unusable" [Medium,Triaged] https://launchpad.net/bugs/556631
<RAOF> Albiet an -ati counterexample, rather than an -intel one.
<bryceh> I mean we don't have any compiz logs, so don't know exactly whats going on
<bryceh> the reporter could have mindlessly overridden compiz doing checking (if that's still possible to do) for all we know
<RAOF> Yeah.  I just thought of that.
<bryceh> could be an easy fix in the == 2048 case though:  https://bugs.edge.launchpad.net/ubuntu/lucid/+source/compiz/+bug/428769/comments/17
<ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor due to hw limit with textures > 2048" [Unknown,Fix released]
<RAOF> Right.  A >= rather than > on the compiz check.
<Sarvatt> sheesh, how did i not notice that, i've known about this problem since december :D
<Sarvatt> ah nevermind thats just the fix for == which *should* work, i need sleep
<bryceh> heh, you saying I'm not alone in being a dunce?
<bryceh> anyway, I've set up both bugs to get top priority from the compiz folks so hopefully they'll get it sorted
<bryceh> meanwhile if you guys see more blank screen on boot bugs where they're running compiz on dual head with small max texture sizes, dupe 'em up
<bryceh> heya mvo
<Sarvatt> i was figuring it was one of these other ancient patches in here extending the texture 1 pixel in some direction (like 015_draw_dock_shadows_on_desktop.patch maybe?) but couldn't work it out
<mvo> hey bryceh
<bryceh> mvo, we were just discussing an issue we've seen reported a bunch, that I think may be a compiz regression - https://bugs.edge.launchpad.net/ubuntu/lucid/+source/compiz/+bug/428769
<ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor due to hw limit with textures > 2048" [Unknown,Fix released]
<mvo> bryceh: so compiz is not correctly detecting that it can not work in this environment?
<bryceh> mvo, right
<mvo> bryceh: that is very possible, the code that detects this has changed in lucid
<mvo> bryceh: aha, I see put that in comment #15 already
<mvo> bryceh: I can do a upload with a fix as described in #17
<mvo> bryceh: I don't have the HW to test it though
<mvo> bryceh: this particular error
<mvo> but it does make perfect sense
<mvo> (the fix)
<bryceh> mvo, great
<mvo> if LP lets me that is
<bryceh> heh
<bryceh> mvo, probably will be blocked until freeze is lifted tomorrow
<mvo> bryceh: while I have you here, you set bug #540519 to confirmed and targeted it. do you have more inside into it?
<ubottu> Launchpad bug 540519 in software-center "software-center crashed with SIGSEGV in webkit_web_view_execute_script()" [Undecided,Confirmed] https://launchpad.net/bugs/540519
<mvo> bryceh: it looks like a webkit issue to me
<mvo> bryceh: or do you have a recipe to reproduce?
 * bryceh ponders
<bryceh> I got the crash myself, and this was suggested as the dupe of it
<bryceh> mvo, I think I was trying to look at screenshots of games
<mvo> ok, so just clicking on the "enlarge" screenshot picture?
<mvo> bryceh: I upload your suggested fix now. one thing that is odd is that the reporter claims it works with the jaunty version of X/compiz on the same HW
<bryceh> mvo, I think it might have been on a game where the screenshot didn't show.  I don't really remember the precise situation, eventually software-center locked up and I think I had to kill it, so got the crash report later
 * mvo nods
<Mirv> do other intel lucid users have this recent slowdown bug #555595 ?
<ubottu> Launchpad bug 555595 in linux "Intel graphics performance regression in recent lucid kernel update (was: Firefox Slows Down Compiz)" [Undecided,Confirmed] https://launchpad.net/bugs/555595
<bryceh> Mirv, no
<Mirv> bryceh: amd64 or not? 
<Mirv> it seems the problem was not there in at least -16 which I managed to get now installed. 
<Mirv> the bug reporter and me are using amd64
<bryceh> haha http://article.gmane.org/gmane.linux.kernel/969355
 * BUGa_vacations reads
<BUGa_vacations> thanks bryceh
<BUGa_vacations> I needed that
<BUGa_vacations> MAUAUUAU
<BUGa_vacations> bryceh: look at the date
<bryceh> BUGa_vacations, sure or read the rest of the thread http://thread.gmane.org/gmane.linux.kernel/969355
<tjaalton> bloody hell, waltop/wacom merge works
<apw> bryceh, do i take you reposonses to the radeon PLL thread to mean that you think we need it regardless of its hugeness?
<bryceh> apw, yes-ish.  If anyone has specific concerns about possible regressions though, I'd favor further testing first.  I skimmed through the code briefly and didn't see anything that frightened me
<bryceh> but devil's in the details of course
<apw> bryceh, there are kernels with the patches applied in that bug, so we could get people to test that
<bryceh> apw, my experience has been that Alex is a pretty careful coder, and is good about recommending only patches that are safe
<apw> bryceh, yeah as alwasy, a difficult choice
<apw> thats good to know
<bryceh> (one of the reasons I like working on -ati so much more than -intel)
<apw> bryceh, :) thats something ... 
<apw> its works pretty well on my only ati box the current stuff, but i did see some flickering there ... perhaps i need to test
<bryceh> apw, dunno if you saw them but we've bumped a bunch of pll quirk bugs over to linux the past couple weeks
<bryceh> if you do a search for 'needs_pll_quirk' I think you'll turn them up.  At least half a dozen, maybe more.
<bryceh> my guess/assumption is they'd all be fixable after this patch is in place
<bryceh> apw, <shifting-topics> so with the firmware update on my MT tablet, it looks like I'm going to need to reinstall windows 7 in order to install the firmware.  Urgh.
<bryceh> I'll give it a go next week
<merriam> You know compiz was broken the same way (black screen) in the Karmic release?  -->  <bryceh> in karmic, there was a wrapper script to compiz that checked the max texture size and refused to run
<RAOF> merriam: Which bug is this?  The == 2048 width bug, or a > 2048 dimension bug?
<merriam> ==
#ubuntu-x 2010-04-09
<RAOF> Damnit intel.  Couldn't you be just a *little* more verbose by default?
<bryceh> heh
<RAOF> Failing to provide a framebuffer because you don't think there's any outputs connected sounds like something you'd want to at least mention in passing!
<bryceh> pshaw!
<bryceh> yeah I would like it if X would behave better if booted in a situation with no outputs
<bryceh> however, definitely a corner case
<RAOF> Hooray for having a crazily slow netbook!
<tjaalton> ngh, scrolling an lp bug page is painfully slow
<tjaalton> at least with nvidia..
<KiBi> tjaalton: what'bout that new nouveau thingy? :)
<tjaalton> KiBi: what where?
<KiBi> You were sighing about nvidia. Didn't know whether you were speaking about HW or SW.
<tjaalton> oh, I didn't realize this was on #ubuntu-x :)
<tjaalton> but yeah, nouveau 2d is fast
<tjaalton> too bad I "need" compiz
<tjaalton> tseliot: uploading mesa 7.7.1 now, meanin my adsl is useless the next several minutes..
<tseliot> tjaalton: thanks :-)
<seb128> would bug #534571 be a libxi issue?
<ubottu> Launchpad bug 534571 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in XListInputDevices()" [Medium,New] https://launchpad.net/bugs/534571
<seb128>  XListInputDevices() crashing on vnc servers
<jcristau> does the app check for XI support before calling XListInputDevices?
<jcristau> also what libxi6 version is that?
<tjaalton> 1.3-3 if from lucid
<seb128> jcristau, it does
<seb128>         return XQueryExtension (GDK_DISPLAY (),
<seb128>                                 "XInputExtension",
<seb128> libxi6 2:1.3-2
<seb128> ie it queries for "XInputExtension" before using it
<seb128> there is a duplicate with -3 too
<jcristau> sigh epiphany crashed.
<seb128> I should write a small testcase calling XListInputDevices() and try under vnc
<jcristau> try xinput list
<jcristau> seb128: that particular crash is what -3 fixed.  if you have a backtrace from -3 i'd like to see it.
<seb128> jcristau, http://launchpadlibrarian.net/41069061/Stacktrace.txt is one
<seb128> sorry
<seb128> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/546388
<jcristau> that looks like -2
<jcristau> ok
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/546388)
<seb128> it's exactly the same
<seb128> there is still a chance libxi was loaded though
<seb128> the apport infos report was is installed, not if g-s-d still runs for days with the old version loaded
<jcristau> but it does sound like you're calling XI functions when the server has no XI support
<seb128> if you say it's fixed in -3 I will ask if somebody still get it after session restart and current version
<jcristau> ok, thanks
<seb128> right
<seb128> so the client should look for the capability?
<jcristau> yes
<seb128> isn't what the XQuery call I copied before do though?
<jcristau> it is
<seb128> k, so I'm not sure what is happening
<seb128> could be that the server is buggy and declare doing things it doesn't do
<seb128> I've asked for xinput list logs now
<seb128> if somebody still get the issue I will write a small testcase doing the XQuery and the XListInput calls
<jcristau> afaict only some parts of gsd do the supports_xinput_devices check
<jcristau> nothing on the path to set_tap_to_click
<seb128> jcristau, oh, could be the issue then indeed
<ScottK> tseliot: We've found a really bad bug in kdebase-workspace related to display controls.  Unfortunately they are not well maintained upstream, so I was wondering if you might be able to have a look?  It's Bug #554948.
<ubottu> Launchpad bug 554948 in kdebase-workspace "Display settings change defaults to keep, not revert" [High,Triaged] https://launchpad.net/bugs/554948
 * tseliot has a look
<ScottK> Thanks.
<tseliot> ScottK: so, basically you would like the timer to default to "revert" instead of "keep", right?
<ScottK> tseliot: Yes.  It looks to me like it's trying to do that, but the actual revert fails.  I'm not sure though.
<ScottK> Otherwise you can end up stuck.
<tseliot> ScottK: yes, I think it's supposed to do that but maybe I spotted the error
<tseliot> I'd like to check the KDE api reference first though
<ScottK> tseliot: Excellent.  Thank you.
<tseliot> np
<ripps> hrm... I don't what it is, but today, after the last few updates. Xorg has been giving me some pretty nasty spikes in cpu usage, even when I don't have anything open.
<ripps> after rebooting, it works fine for a while, but then it starts acting up again. Think it could be a memory leak or something?
<ripps> it's even causing pulseaudio to skip a bit now
<ScottK> tseliot: The other thing that may not be clear from the bug is that there is a display configuration kcm and the krandrtray systray application.  They appear to share little or no code, but both manage to exhibit this problem.
<tseliot> ScottK: ok
<tseliot> ScottK: out of curiosity, has the revert dialog ever worked?
<ScottK> tseliot: It worked in KDE3.  I can't say for sure about KDE4.  I know it's broken in KDE 4.3 and 4.4 (all I have to test).
<apw> ROAF ... there are queries on your acceleration patch
<tseliot> ScottK: if the app is the one in randr.cpp which uses ktimerdialog.cpp, I'm afraid there's nothing (i.e. no slot) connected to the revert action, therefore, no matter what you click on, you should always get the same result. KTimerDialog::slotInternalTimeout() simulates a button click but that's all you get, as that signal should trigger some (unimplemented) action instead of just closing the dialog. Unless there's some
<ScottK> tseliot: That's the systemsettings kcm.  The systray app is krandr.cpp, iirc.
<ScottK> Getting one of them to work would be a huge help.
<ScottK> krandrtray doesn't use KTimerDialog
<tseliot> ScottK: I'm not sure if I have the time to code this
<ScottK> tseliot: If you don't, you don't, but it would be a really good thing to get into the LTS ....
<ScottK> tseliot: Maybe if I could find someone to help?
<tseliot> ScottK: sure, someone who is familiar with C++/QT. Do you know which program randroutput.cpp belongs to? As RandROutput::applyProposed to do to our case
<ScottK> tseliot: No.  We're getting to the end of what I could figure out.
<ScottK> tseliot: Please see what you can do and I'll try to hunt up a coding assistant.  That may take a few hours.
<jg> bryceh: sigh...  I can't get beta2 to start X at all...
<jg> I can't get the iso to get to a place I can even try to enter the suggested kernel parameters.
<ripps> I think I figured out what was slowing down Xorg, it was mousetweaks. The moment I disabled secondary click from the mouse properties, Xorg's cpu usage dropped. I guess it must be constantly polling the mouse position or something. Definately needs some optimzation
<ripps> cancel that, Xorg started going up again. It's causing pulseaudio from mpd to stutter. This is weird, it wasn't like this yesterday.
<ripps> I'm sorry if I'm sound annoying, but I honestly want to try and fix this bug, but I'm not sure how to go about it. I've tried using gdb, but it just froze my desktop. Right now, since I've just reboot, I'm not experiencing the high cpu usage yet. But if somebody knows how I can capture it in a log as it happens.
<ripps> There it goes, now it's stuck between 10-50%
<ripps> About a half hour, every time.
<ripps> hmm... restarting gdm seems to help, but it's going to get real annoying real fast if I half to restart xorg every 30 minutes.
<Burgundavia> bryceh, you around for a quick question?
<Sarvatt> wonder why meego is disabling GL_ARB_texture_rectangle on intel, can't find any reference to why they have this patch
#ubuntu-x 2010-04-10
<bjsnider> Sarvatt, are hyrbid graphics laptops supported at all? do they work?
<zombie0> I am having graphics issues on my laptop using a hybrid nvidia g210m and onboard intel.  After a recent update to 10.04 my video has stopped work
<zombie0> *working
<zombie0> After selecting an image in grub it goes to a blank screen and thats as far as I can get
<bjsnider> zombie0, you had working compiz off the livecd?
<zombie0> well I just booted the live cd
<zombie0> let me see
<zombie0> bjsnider yep working compiz with live cd
<zombie0> not using propriatery drivers
<Sarvatt> bjsnider: totally depends on the laptop
<bjsnider> open a terminal and run glxinfo
<bjsnider> Sarvatt, have you got a list or something?
<zombie0> mesa-utils isnt installed and its saying that it isnt available
<bjsnider> Sarvatt, does it depend on his ability to shut one chip off manually int he bios?
<bjsnider> zombie0, have you got a network connection to the web on that laptop?
<zombie0> I am setting a hardline up now
<zombie0> bjsnider: Ok have a connection but should I update/upgrade?  because it still cant find it as of now
<zombie0> let me check if universe is enabled
<zombie0> it wasnt
<zombie0> got it now
<bjsnider> i want to know who the renderer is
<Sarvatt> bjsnider: you have to dig through https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/312756?comments=all :) its really complicated by how its done different between different GPU combinations and different manufacturers (and bios revisions even..) 
<ubottu> Launchpad bug 312756 in xorg-server "support graphics card hot switch" [Wishlist,Triaged]
<zombie0> pastebin.com/mUrqvZNG
<Sarvatt> he's using the intel if compiz works on a livecd
<bjsnider> Sarvatt, didn't dave airlie just write the first code to deal with this?
<bjsnider> Sarvatt, must be, yes
<zombie0> Mobile Intel GM45
<bjsnider> if he could just get it to do that exery time he'd be fine
<zombie0> yea maybe add a xorg.conf entry for that driver instead
<bjsnider> you might have to blacklist nouveau, nv and nvidia too
<zombie0> not really sure how to do that
<bjsnider> but it could still decide to use vesa with the nvidia chip
<Sarvatt> zombie0: did you install the proprietary drivers or something?
<zombie0> I didnt try to but I have a feeling on of the updates attempted to
<bjsnider> Sarvatt, without nvidia-current it selects nouveau
<bjsnider> because he has no glx
<bjsnider> and he doesn't have a manual switch in the bios
<bjsnider> the fact that the hardware is sending power to the nvidia chip is the problem. the kernel sees it and watns to use it
<bjsnider> maybe the laptop only uses the intel chip if you're booting off the cd instead of the hard drive
<zombie0> so would it be worth trying to blacklist those other types of drivers?
<zombie0> well I can now get regular video on boot by using driver "intel" with xorg.conf
<zombie0> but no glx
<zombie0> uninstalled nvidia-current and nouveau and now its picking up the intel glx
<zombie0> all good, reboots with glx enabled
<zombie0> bjsnider and Sarvatt:  thanks alot for the help guys!  really needed it.  Have a great night and a beer on me :)
<Sarvatt> ahh sorry, went afk there but it did sound like that was the problem, jockey probably saw the device and offered it when its not the graphics device in use
<bjsnider> where's my beer?
<bjsnider> what happens when the hardware decides to switch to nvidia?
<RAOF> bjsnider: Then we ask him to test 2.6.34, where VGA switcheroo is implemented.
<bjsnider> RAOF, that's the airlie code?
<RAOF> bjsnider: Yeah.  ACPI methods to switch graphics cards.
<bjsnider> i'm not sure xorg/mesa is prepared for that
<johanbr> last I heard, it required restarting X
<ripps> hmm.... I think my Xorg became very slow after a save-file dialog in my browser. Perhaps that's what's causing the Xorg high cpu usage. Is there a program associated with open-save dialog windows?
<Sarvatt> ripps: gtk+
<Sarvatt> ripps: are you using chromium by any chance? :D
<ripps> Sarvatt: sorry, I was away from computer. Yes, I'm using chromium
<ripps> But the Xorg cpu usage persists even after I've closed chromium
<Sarvatt> hmm, our cairo pad patch is slightly different than what other distros are using - http://cvs.fedoraproject.org/viewvc/devel/cairo/cairo-1.8.6-repeat-modes.patch?view=markup
<Sarvatt> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/cairo/lucid/annotate/head:/debian/patches/06_Xlib-Xcb-Hand-off-EXTEND_PAD-to-XRender.patch
<Sarvatt> wooo, mass X lib update
 * hyperair wonders whether the nvidia binary drivers are working in lucid yet
<tjaalton> just fine
<RAOF> Have been working for some time.
<RAOF> Sarvatt: Hm, yeah.  We should probably grab that change for Maverick.  It looks like it will expose some untested driver paths if we grab it now.  Also, firefox is now bundlezilla, so won't benefit.
<Sarvatt> RAOF: any ideas on what to do about nouveau in edgers? i'd like to drop lbm since i cant keep it updated and make it require a 2.6.34 kernel somehow
<Sarvatt> wish I could copy the mainline kernels directly into the PPA :D
<johanbr> actually, why not?
<Sarvatt> why not what?
<johanbr> put the mainline kernels into the PPA
<Sarvatt> because they are built with external scripts i cant do in a ppa I believe? i haven't had time to work this out
<Sarvatt> i dont know how to bump the abi properly for a PPA kernel
<johanbr> oh
<Sarvatt> i dont use it and have a lot of other things taking up my time, and nouveau in edgers is stagnating because i havent been able to update it in almost a month (outside of mesa) because we can't update lbm-nouveau due to the backlight changes in 2.6.34 that upstream rebased onto
<johanbr> well, maybe the easiest thing is just to wait until the first lucid+1 kernel is released
<Sarvatt> it already is, i could copy it in there
<Sarvatt> but it'd be a lot more useful to be able to merge upstream nouveau into it
<johanbr> oh, I didn't realize it was already out...
<Sarvatt> oh man, so many compiz fixes upstream since our version :(
<Sarvatt> bryceh: driconf options would be good to have added to mesa bug reports
<Sarvatt> hmm doesn't look like fglrx is getting removed properly upgrading from hardy-lucid on the cards that fglrx no longer supports
<Sarvatt> maybe it'd be a good idea to just completely remove fglrx on upgrade and people can install it manually again after
<johanbr> wouldn't that break some setups?
<johanbr> say you specify fglrx in xorg.conf, and then fglrx is removed
<tjaalton> update-manager could take care of that. the same thing happens with nvidia aiui
#ubuntu-x 2010-04-11
<Sarvatt> looks like i'm not alone getting insane memory usage with intel 2.11
<ripps> I know the moment I say this I'm going to Jinx it, but since installed kernel 2.6.33 from the kernel-ppa I havent' had any Xorg cpu hogging.
<Sarvatt> tjaalton: have you seen http://cgit.freedesktop.org/~whot/xf86-input-wacom/log/?h=waltop ?
<Sarvatt> ripps: did you also update ati to 6.13 at the same time? :D
<ripps> Sarvatt: no, I rebooted and tried that before installing 2.6.33
<ripps> So, no the ati update didn't fix it
<Sarvatt> still had it with 6.13 and the lucid kernel then?
<ripps> Sarvatt: yes
<ripps> whoa, irssi just crashed all of sudden there..... hope that wasn't an omen
<Sarvatt> i was going to say do a xlsclients and start killing off things until you find which it is, most likely something in there
<Sarvatt> what mainline kernel did you install?
<Sarvatt> 2.6.33.2?
<ripps> Sarvatt: inux-image-2.6.33-020633-generic
<Sarvatt> do you see anything flooding ~/.xsession-errors when its slow? or dmesg?
<ripps> Sarvatt: fitst thing I checked, I didn't see anything
<Sarvatt> chromium has been acting kind of similar for me the past week of daily builds but its not making the X process CPU spike after closing it.. I was going OOM after a few hours and thrashing wildly even with 3GB ram, thats why I was asking about that
<ripps> Sarvatt: eh, I switched back to google-chrome, it's html5 video is a bit uglier, but it seems a little faster
<Sarvatt> but i did have flash using all of my cpu still doing what you said after i closed it one time
<Sarvatt> yeah I switched to the in-archive chromium and its alot better
<Sarvatt> think its from the beta channel
<ripps> I recently helped fta resolve a bug with sse2 with chromium, because chromium was crashing on any html5 video, but even with that fixed, I still think the equivalent version of chrome when compared to chromium is still a bit faster.
<ripps> It's probably just how it's compiled. Maybe google uses profiled builds
<Sarvatt> interesting if its really fixed by 2.6.33 and not the lucid kernel though, definitely not gpu related if so
<Sarvatt> you said mouse options affected it at some point?
<RAOF> Sarvatt: I've got a hacked-up nouveau/linux-2.6 building locally.  Mostly.
<ripps> Sarvatt: well, I didn't have this problem when I first installed 2.6.32-19. It first appeared after the large number of updates the day before. So I'm guess that an update in xserver earlier caused it.
<ripps> Sarvatt: well I was playing around with some stuff, and after disabling mousetweaks the cpu usage of Xorg dropped to around 5% instead of 20%, but a few minutes later it went back up.
<Sarvatt> well hopefully it was a client app that was screwed up and fixed, i think gnome-keyring gwibber desktopcouch and gnome-control-center were screwed up pretty bad recently but not sure if any of those had spiking X cpu usage as a side affect.. if you cant reproduce it after a day or so on that mainline kernel i'd be interested if you still have the problem on -19 or -20
<Sarvatt> dont know what generation ati you're using but there were a bunch of fixes in mesa 7.7.1 too
<ripps> I'm using r300 ati radeon 9600
<ripps> I'm wondering if the 2.6.33 has something in it's scheduler that prevents whatever's happening in Xorg to occur
<ripps> On an unrelated note, I couldn't get the 2.6.34-rc3 kernel to work because it would turn my monitor off when X started. I couldn't figure out a way around it.
<Sarvatt> did you use the lucid or karmic one? i can't use 2.6.34-x-karmic at all, panics right when it starts :( there's always radeon.modeset=0
<ripps> the karmic ppa only had header packages
<Sarvatt> check your /var/log/dmesg.0 after booting it, and rebooting into a good kernel?
<ripps> Sarvatt: the archived dmesg log doesn't say anything that stands out to me
<ripps> and the Xorg.1.log says that it couldn't find any screen(s)
<ripps> it seems my monitor wasn't initialized
<ripps> y'know, every once in a while, I get an audio stutter and Xorg goes up to 15% for a moment, but than it seems to recover and go back to ~3%. I wonder if the problem is still occuring but the kernel is able to recover more elegantly than lucids
<Sarvatt> 2752 objects
<Sarvatt> -2109001728 object bytes
<Sarvatt> kaaay
<Sarvatt> thats with stock lucid packages too, hmm..
<Sarvatt> ahh my mesa texture tiling setting was carried over after the downgrade
<Sarvatt> ripps: try installing linux-backports-modules-alsa and use the lucid kernel?
<ripps> Sarvatt: really? okay, I don't know how it could be related...
<ripps> Hmmm... I'm getting a lot of gdk errors for gmpc in my .xsession-errors log... think that could also be a cause?
<Sarvatt> what errors?
<ripps> (gmpc:8052): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels: assertion `GDK_IS_PIXBUF (pixbuf)' failed
<ripps> I have gmpc start at boot, and leave running a seperate workspace
<JanC> hm, question, could anybody recommend a (cheap) graphics card that supports OpenGL 2 with open open source drivers in lucid?  âº
<ripps> Does any oss driver have complete opengl 2?
<JanC> I wish I knew...
<johanbr> according to http://www.x.org/wiki/RadeonFeature , the radeon driver has that on R600/R700
<johanbr> on the other hand, most of the 3d features say "Mostly done"
<JanC> I suppose some of the newest Intel drivers might support it on their newest hardware too
<johanbr> I hear the intel drivers have been in pretty bad shape lately, though
<JanC> but intel doesn't sell "cards"
<ScottK> johanbr: My experience has been Intel was 'unfortunate' in Jaunty/Karmic, but pretty good so far in Lucid.
<JanC> sointel has been good on karmic for me
<johanbr> ahh... happy to hear that's improved
<JanC> only jaunty was bad
<JanC> and I have 3 different intel systems...
<ripps> Hmm... according to xlsclients, ubuntuone-login and ubuntuone-preferences are in use, is there any way to stop them?
<ripps> hmm killing them seems make things a little smoother
<ripps> Well, I'm going back to the lucid kernel to see if I can isolate use xlsclients to see if there's a particular app that's causing cpu hogging.
<Sarvatt> 965+ intel, R600+ ati with mesa 7.8+
<ripps> My new favorite tool: watch. easy to check changes to various logs at a glance from my screen terminal
<JanC> Sarvatt: was that an answer about my OpenGL 2 question?  if so, I was looking at recommendations about R600+ ATI cards that actually work well I suppose...  ;)
<bjsnider> JanC, i'm going to regret asking this question i guess, but why the "open source drivers" condition?
<JanC> bjsnider: because I prefer that, even if only to give a "message" to manufacturers  âº
<JanC> and I don't really need it, I just wanted to try out an application that apparently needs OpenGL 2
<tjaalton> Sarvatt: yes, have you seen http://sourceforge.net/mailarchive/forum.php?thread_name=alpine.DEB.2.00.1004091001160.30959%40deckard.hut.fi&forum_name=linuxwacom-devel :)
<tjaalton> Sarvatt: merged the waltoptablet kernel driver with wacom
<RAOF> JanC: I recently got a radeon 43something or other for $60 that Just Worksâ¢ and supports OpenGL 2.0 with the free drivers.
<ripps> Does anybody know how to read straces of Xorg? What exactly is normal?
<ScottK> bryceh: Any objection t me uploading a fix for Bug #560814?
<ubottu> Launchpad bug 560814 in xserver-xorg-video-r128 "Conflicts/Replaces version needs bumped for Hardy -> Lucid upgrades" [Medium,New] https://launchpad.net/bugs/560814
<Sarvatt> wow, didn
<Sarvatt> t realize it was so easy to edit insyde efi bioses
<Sarvatt> ahh wrong channel sorry :)
<Sarvatt> ugh so it looks like theres quite a few lenovo laptops with intel needing powersave=0 too.. maybe we should have just made it opt-in globally
<Ng> what actually happens when you set that?
<Sarvatt> depends on the chipset, it disables things like self refresh CxSR and framebuffer compression
<Sarvatt> Ng: do you have one of the machines experiencing the problem?
<Sarvatt> can you boot with drm.debug=0x04 and watch dmesg to see what happens when it flickers? that'll help alot figuring out what feature is causing it
<Ng> Sarvatt: my X301 (Gm45) intermittently has flashing issues. I can't really say whether powersave=0 changes anything yet, it's so annoyingly rare :(
<Sarvatt> yeah all the affected ones i've seen still are gm45 too, all lenovo too oddly
<Sarvatt> can you describe the flicker at all?
<Ng> I have a vast selection bias towards lenovos, since a lot of canonicalers buy them, but fwiw one of them is an IdeaPad, which I think is quite different internally to a Thinkpad, but I'm not sure
<Sarvatt> ideapad shouldn't be flickering at all anymore..
<Ng> it could be that it stopped, I'll check with ivanka tomorrow
<Sarvatt> those should have been fixed in the -18 or -19 kernel
<Ng> I'm booted without powersave atm and I've not seen it for a while, but it's not that predictable
<Sarvatt> Ng: if you can boot with drm.debug=0x04 on your x301 and send along your dmesg it would help
<Sarvatt> like does the whole screen shift for a fraction of a second? or is it isolated to part of the screen? does it black out or just shift the screen contents over a little?
<Ng> Sarvatt: just attach the output after booting, or when it actually flashes?
<Sarvatt> and does it happen when the system is idle or right after you do something?
<Ng> it's like the bottom 1/3-1/4 goes slightly out of sync and corrupted for like 1 or 2 frames
<Sarvatt> either, preferably the latter but you said it was hard to trigger
<Ng> hmm, I'm not sure about the idleness factor
<Sarvatt> any idea if its isolated to something like during video playback?
<Ng> I'm pretty sure it's not related to video playback, but perhaps I had flash open in browser tabs at the time. certainly not something like totem though
<Sarvatt> Ng: do you have another monitor plugged in?
<Ng> Sarvatt: it generally seems to only happen when I have no monitor attached. At work I have an LCD hooked up to the DisplayPort connector and it's *never* happened then
<Sarvatt> self refresh is disabled when you have more than one monitor plugged in
<Sarvatt> Ng: yeah a dmesg just after boot with drm.debug=0x04 would be handy
<Ng> ok, lemmie just close everything down and get that now
<Sarvatt> appreciate it Ng
<Ng> very much likewise :)
<Sarvatt> heyo tormod
<Ng> Sarvatt: added
<Sarvatt> Ng: bug number?
<tormod> konnichi wa Sarvatt :)
<stgraber> hey tormod !
<Ng> Sarvatt: bug #538648
<ubottu> Launchpad bug 538648 in xserver-xorg-video-intel "[gm45] Irregular sync flashes with compiz on (Lenovo T500)" [Medium,Incomplete] https://launchpad.net/bugs/538648
<Sarvatt> thanks, odd that it didnt show up in my ubuntu-x-swat mail
 * ScottK says "What the heck" and uploads.
<ScottK> bryceh: Nevermind.  Uploaded it.
<tormod> bonsoir stgraber :)
<Ng> Sarvatt: what influence does the idleness of the machine have? some part of the chip being powered down or so?
<Ng> ooh
<Ng> it just flickered
<Ng> and again
<Ng> the drm debug thing is only logging cursor changes, and it doesn't seem to be related to that
<stgraber> tormod: it's still the afternoon here ;)
<Sarvatt> thats odd, Ng can you try drm.debug=0x05 then?
<Ng> Sarvatt: sure, lemmie just close everything down again ;)
<Sarvatt> looks like self refresh and fifo watermark updates are 0x01 not 0x04 so 0x05 will get both of those
<Sarvatt> Ng: actually just drm.debug=0x01 would be enough
<Ng> ok
<tormod> stgraber, guess you're in Quebec then :)
<Sarvatt> sorry about that, I thought that info was given in 0x04
<stgraber> tormod: yep, will be in Switzerland for two weeks between the 24th of April and the 9th of May. Not sure if there's anything getting planned for the release there though.
<Ng> Sarvatt: wow that's a lot of output :D
<Sarvatt> yeah :( save it now if you can before it overflows then save the rest after it happens (if it does)
<tormod> stgraber, not much cooking for an RP here (yet) except something in Winterthur
<Ng> Sarvatt: looks like it overflowed pretty quickly after booting, as soon as my desktop appeared I launched a terminal and did dumped dmesg to a file
<Ng> and it's lacking kernel boot messages
<Ng> but I'm guessing it's all gone to syslog
<Sarvatt> thats ok you'll have the boot stuff in /var/log/dmesg
<Ng> syslog from boot->now is 116MB :o
<Ng> I'm not sure I can leave this on, but hopefully it'll flicker soon
<Sarvatt> well can ya just run intel_reg_dumper and attach that, and attach the /var/log/dmesg from this boot to the bug too?
<Sarvatt> i'll upstream it after ya put those on there and I get home
<Ng> Sarvatt: sure thing
<Ng> Sarvatt: done
<Sarvatt> i dont know why g4x_update_wm and i965_update_wm self refresh info goes to DRM_DEBUG when i9xx_update_wm and older goes to DRM_DEBUG_KMS, thats what threw me off
<kklimonda> hey, what to do if crt monitor sends invalid edid info?
<kklimonda> http://pastebin.org/146979 Xorg.0.log is anyone is interested
<Ng> Sarvatt: just had a glitch and I hadn't rebooted :)
<Ng> snagged dmesg and gpu regs and added them to the bug
<Ng> and now I'm definitely rebooting to get this debug mode cleared ;)
<Sarvatt> Ng: just to be clear, it only happens with compiz enabled for you too?
 * Sarvatt is filling out the upstream bug report and using your info
<Ng> Sarvatt: I've only seen it with compiz because I haven't tried without compiz :/
<Sarvatt> ah ok, too bad theres nothing in that new dmesg you posted since it was only a seconds worth :D
<Ng> woah
<Ng> hrm
<Ng> syslog will have it even though I've rebooted
<Ng> current syslog is 1.9GB :O
<Sarvatt> sheesh! :D
<Ng> I might wait until I'm in the office tomorrow to upload that ;)
<Sarvatt> grep it for [drm:g4x or [drm:intel ?
<Ng> grepping out drm:drm_ioctl and gzipping gets it down to 869K
#ubuntu-x 2011-04-04
<cnd> LLStarks, thanks for the report, I marked it as a duplicate of a similar report
<cnd> basically, the functionality isn't gone, it's just not enabled by default in natty anymore
<RAOF> What are you doing up this late on a Sunday, cnd? :)
 * bryceh <-- doing taxes
<bryceh> bleah
<RAOF> Fun!
<RAOF> Hm.  The espresso machine should have warmed up by now.  Coffeeeeeeeeeeee!
<LLStarks> cnd, that's not very nice. the "two-fingered scrolling" option now provides ZERO SCROLLING
<LLStarks> no side-of-trackpad scrolling. nothing. if you try to scroll, the cursor jumps.
<LLStarks> *very nice behavior
<cnd> LLStarks, if you set the mouse preferences to edge scrolling it should work
<cnd> it's not like we just decided that two finger scrolling shouldn't be allowed :)
<cnd> but enabling it by default for certain trackpads can cause erratic behavior
<cnd> RAOF, wife is gone for two months biking across the US
<cnd> just left yesterday
<cnd> so I've got quite a bit more time on my hands
<cnd> I spent most of today watching "Weeds"
<cnd> which is really good, btw
<cnd> bryceh, I hope doing taxes means you get a nice refund :)
<cnd> I had to pay a little bit back this year
<RAOF> cnd: That sounds both interesting and kinda sucky.
<cnd> pretty much :(
<LLStarks> cnd, if we're  sticking with this change. the mouse properties interface needs to reflect it. like a greyed out.
<LLStarks> *out option.
<LLStarks> should i inform the proper people?
<LLStarks> btw, is this only for certain touchpads or all?
<LLStarks> *all synaptics
<RAOF> Sarvatt_: Is there any particular reason mesa -0ubuntu4 is UNRELEASED, or was it just beta-freezed?
<jcristau> iirc there was some confusion over some snb stuff?
<tjaalton> http://www.ispyce.com/2011/04/video-explains-multitasking-and-user.html
<tjaalton> pre-X11 multitasking :)
<alkisg> I'm trying to get nvidia/vanta going on a netbooted hardy chroot on my lucid server
<alkisg> The nvidia logo displays, but glxgears complains about the glx extension missing
<alkisg> xorg.6.log claims that it loaded glx, so I'm at a loss, any help?
<tjaalton> what does glxinfo say?
<alkisg> It produces some output (can't copy/paste), but every other line it also says "Xlib: extension "GLX" missing on display :6.0"
<tjaalton> put the xorg logfile somewhere
<alkisg> tjaalton: http://paste.ubuntu.com/589189/
<alkisg> and xorg.conf: http://paste.ubuntu.com/589191/
<tjaalton> (EE) GLX is not supported with the Composite extension
<alkisg> Thank you, so how would I disable composite?
<tjaalton> Section "Extensions" Option  "Composite" "Disable"
<tjaalton> EndSection
<alkisg> Thank you very much
<tjaalton> with a linebreak before Option
<alkisg> Works fine, thanks again. Now to do this via LTSP instead of manually...
<alkisg> xterm scrolls sooooo fast remotely... 5-6 times faster than gnome-terminal, gedit or firefox... :-/
<cnd> LLStarks, we can't disable two finger scrolling as an option because these trackpads can still do it, but they have to be tweaked to be able to do so
<cnd> this is only for trackpads that report the pressure but not the number of fingers on the trackpad
<cnd> I believe this is a small minority of all synaptics trackpads
<tjaalton> cnd: is bug 749493 dupe of bug 742567?
<ubot4> Launchpad bug 749493 in xserver-xorg-input-evdev (Ubuntu) "evdev ignores axis swap and inversion for Cando touch screen (affects: 2) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/749493
<ubot4> Launchpad bug 742567 in xserver-xorg-input-evdev (Ubuntu) (and 1 other project) "multitouch events do not respect swap/invert axes properties (affects: 1) (heat: 8)" [Undecided,Won't fix] https://launchpad.net/bugs/742567
<cnd> tjaalton, looks like it
<cnd> I'll dupe it
<tjaalton> cnd: thanks
<cnd`> tjaalton, would you be able to upload a new version of evdev: http://people.canonical.com/~cndougla/utouch/
<cnd`> it fixes bug 573006
<ubot4> Launchpad bug 573006 in xserver-xorg-input-evdev (Ubuntu) (and 1 other project) "Touch screen driver clicks at wrong location (affects: 8) (heat: 50)" [Medium,Incomplete] https://launchpad.net/bugs/573006
<tjaalton> cnd`: I've got a quirk to add to it, but after that yes
<tjaalton> a quirk for the ubuntu-branded two-button mouse
<cnd`> ahh
<cnd> tjaalton, let me push my change to git
<cnd> I forgot to do that
<cnd> then you can make your change and upload
<tjaalton> yep
<cnd> ok, pushed
<tjaalton> ..pulled :)
<tjaalton> cnd: uploaded and pushed
<cnd> tjaalton, thanks!
<seaLne> hi, for the last few weeks in natty i've lost the ability on my laptop (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller) to be able to use the external vga or hdmi outputs. they don't appear in xrandr output (or kde system settings display module). all xrandr shows is an output called default whereas before i had something like LVDS1, HDMI1 and VGA1
<seaLne> if i connect a monitor to either of those outputs i get what looks like a 1024xsomething view of my laptop screen which is 1366x768
<seaLne> i'm not even sure where to start looking to track down what is causing it
<seaLne> Xorg.0.log: http://paste.kde.org/8905/
<JanC> seaLne: looks like there is no 'intel' driver on your system, so X uses the 'vesa' driver ?
<seaLne> JanC: arrg some conflict must have uninstalled it and i never noticed, let me check that
 * seaLne hugs JanC 
<seaLne> JanC: thanks i can't believe i never noticed it got uninstalled
<JanC> seaLne: I'm not sure you're familiar with the Xorg logs, but lines that have (EE) near the front are error messages, in this case the error at line 107 in your paste was relevant
<JanC> also, (II) = information and (WW) = warning
<seaLne> yeah thanks, not sure how i missed that. i think i some how got it into my head that it must be something really complex so missed the obvious things a few years ago when X was harder i'd have noticed instantly
<cnd> tjaalton, there's an update to empcommand (the multitouch game you uploaded a while back): bug 749755
<ubot4> Launchpad bug 749755 in empcommand (Ubuntu) "unclear licensing for the enclosed font and some samples (affects: 1) (heat: 8)" [Undecided,Fix committed] https://launchpad.net/bugs/749755
<cnd> if you're not too busy could you upload it?
<bryceh> cnd, I got it
<cnd> bryceh, ahh, thanks!
<cnd> we at least will have one multitouch game in natty at release :)
<bryceh> cnd, :-)
<kees> what's the best way to answer the question, "Which versions of Ubuntu's X server have upstream commit 5725849a1b427cd4a72b84e57f211edb35838718 in it?"
<bryceh> kees, simplest would be to grep for the commit in the various versions' ChangeLog
<bryceh> kees, however that will miss if the commit was added as a patch, so also grep in debian/patches/* for completeness (and then doublecheck patch is enabled in debian/patches/series)
<bryceh> kees, an alternative method would involve using git show in the ubuntu git branch for each release
<bryceh> however I think we only have branches for maverick and natty, and can't guarantee that someone didn't upload something without committing to the stable branch
#ubuntu-x 2011-04-05
<kees> bryceh: where are the ubuntu git branches? if I was doing this for the kernel, I would just do   git tag --contains 5725849a1b427cd4a72b84e57f211edb35838718
<kees> and see which releases had it
<kees> but I have no idea where to find the ubuntu X git trees :)
<RAOF> debcheckout
<kees> I guess reading https://wiki.ubuntu.com/X/GitUsage might help
<kees> RAOF: ah, yeah, that works too. I'm so used to only doing that with bzr that I didn't even try with git. durrr
<RAOF> It works with anything that's got a VCS-* tag :)
<kees> yeah :)
<bryceh> kees, yeah they're kept at alioth
<kees> RAOF: that appears to only be the debian/* tree...
<RAOF> kees: You've run âdebcheckout xorg-serverâ, right?
<kees> and xserver-xorg and xorg.
<kees> s/^and /only /
<kees> doing xorg-server now :) silly names!
<kees> \o/ much nicer
<RAOF> Yeah.  xorg is just a wrapper :)
 * kees nods
<ScottK> I got the sandybridge laptop today.  Mostly good so far.  Let me know if there's stuff you need tested.
<gsedej_work> hi! I have problems with x-updates ppa
<gsedej_work> I did purge
<gsedej_work> but under synaptic when I check e.g. libdrm-nouveau1, I still see maintainer Ubuntu X-SWAT <ubuntu-x@lists.ubuntu.com>
<tjaalton> and it is
<gsedej_work> I also tried to add ppa again, update
<gsedej_work> and then again remove
<gsedej_work> but it's still there
<tjaalton> what's the problem then?
<gsedej_work> how to get ubuntu 10.10 default drivers
<tjaalton> 10.10 does have that package you know
<tjaalton> also the maintainer is the same
<gsedej_work> My problem is that I have GF GTS 250. Prop drivers does not work good with comput (very slow!) and opensource driver is just too bad
<gsedej_work> but it's fast
<gsedej_work> here is also my ubuntuask question http://askubuntu.com/questions/27907/compiz-slow-under-proprietary-nvidia-driver
<tjaalton> yes, it sucks
<gsedej_work> oh, I didn't know
<gsedej_work> I mean x-updates nouveau driver is FAST on compiz
<gsedej_work> 300PFS with blur
<gsedej_work> 150 FPS in expo
<gsedej_work> BUT, after time I get texture errors
<gsedej_work> blinking etc...
<gsedej_work> it's useless
<gsedej_work> and it's doesn't even run google earth
<tjaalton> yes, it's not mature yet
<gsedej_work> it uses mesaSW fallback
<tjaalton> even less so on 10.10
<gsedej_work> any idea why nvida prop driver works bad for compiz? (it is good for 3D games)
<tjaalton> nope
<gsedej_work> but it's not only me who had problems?
<tjaalton> no
<gsedej_work> darn... what do you suggest. What about xorg-edgers? I didnt spot difference between x-updates and edgers for my graphics
<tjaalton> there are unresolved crashers with nouveau, doesn't matter what version you run
<gsedej_work> problem is with "newer" GPU-s, right? my GF8600GT works very well with prop driver on ubntu 10.04
<tjaalton> i've got the same, and it's sluggish on 11.04
<gsedej_work> GTS 8600 or GTS 250?
<tjaalton> gf8600gt
<gsedej_work> but under 10.04 works just great? did it worked good for you under 10.04?
<tjaalton> dunno, i guess
<gsedej_work> any idea where is the problem for slow compiz? maybe old driver version could help?
<tjaalton> not that interested tbh :)
<tjaalton> old version wouldn't work with the server
<gsedej_work> darn...
<gsedej_work> you said that many people has problem with slow nvidia driver (compiz)?
<tjaalton> no i didn't
<tjaalton> just confirmed it's not just you
<gsedej_work> sorry I confused
<gsedej_work> tjaalton, can you help me with this? http://askubuntu.com/questions/27907/compiz-slow-under-proprietary-nvidia-driver
<tjaalton> gsedej_work: how?
<gsedej_work> how to get nvidia prop driver work fast under compiz?
<gsedej_work> I get like 5 FPS when in expo screen
<tjaalton> i've no idea, ask nvidia
<gsedej_work> ok, thx
<gsedej_work> Hi! I wanted to use xorg-edgers. when I did apt-get upgrade I get next line. What does it mean? how to solve it
<gsedej_work> E: /var/cache/apt/archives/ia32-libs_20090808ubuntu10+maverick~xorgedgers0.20110325.1_amd64.deb: trying to overwrite '/lib32/libncursesw.so.5.7', which is also in package lib32ncursesw5 5.7+20100626-0ubuntu1
<cnd`> tseliot, I've got a dell mini 10 with the "trackpad from hell"
<cnd`> in natty, it now has multitouch support
<cnd`> I've found it to be sooo much better with the jumpycursorthreshold
<cnd`> but that setting is disabled if the trackpad is multitouch
<cnd`> why is that?
<cnd`> I've hacked around that for now so I could play with it on my machine
<tseliot> cnd: I didn't know that feature would be disabled with multi-touch. I guess it only made sense with single-touch touchpads
<cnd> tseliot, why does it only make sense with single-touch touchpads
<tseliot> cnd: also when I wrote that patch there was no such thing as multi-touch so I'm wondering if some other patch prevents it from working
<cnd> hmmm
<cnd> tseliot, the patch actually disables it for multi-finger
<cnd> but it calls that multitouch in the man page
<tseliot> cnd: because in theory putting 2 fingers on the touchpad shouldn't cause a jump
<cnd> yeah
<cnd> though it does on mine :)
<tseliot> cnd: maybe someone modified my original patch or maybe my memory is really bad ;)
<tseliot> let me check
<cnd> tseliot, I'm thinking that we should enable it for all touchpads, especially since the touchpads its meant for now are multifinger/multitouch too
<tseliot> cnd: if that's still a problem then I agree
<tseliot> cnd: btw where does it say that it's not supposed to work with multi-touch?
<tseliot> cnd: I'm looking at 114_jumpy_cursor_first_part.patch
<cnd> tseliot, look at the man page diff
<cnd> "+Set the threshold above which movement events are ignored on single-touch touchpads."
<cnd> and at line 127 is the check for has_double
<tseliot> cnd: good catch. I guess I really forgot about my code ;)
<tseliot> I'll fix it
<cnd> I tseliot, ok, thanks!
<tseliot> cnd: thanks for reporting the problem
<cnd> tseliot, btw, with this fix and the additions I made with the multitouch data, these trackpads actually work quite well now :)
<tseliot> cnd: excellent :)
<cnd> we even can do some three finger gestures in unity, though it won't be pushed to ubuntu till oneiric
<cnd> tseliot, you tried to push the jumpy cursor patch upstream right?
<tseliot> cnd: yes and it's not going to happen
<tseliot> cnd: have you seen the upstream bug report?
<cnd> no
<cnd> could you paste a link?
<tseliot> cnd: https://bugs.freedesktop.org/show_bug.cgi?id=21614
<ubot4> Freedesktop bug 21614 in Input/synaptics "Touchpad cursor jumps when two fingers are used" [Normal,Assigned]
<tseliot> it seems that Yan Li (Intel) even refreshed my patch
<tseliot> long story short Peter said no and that's it ;)
<cnd> tseliot, don't upload the fixed package quite yet
<cnd> I want to review things some more
<tseliot> cnd: ok
<rodrigo_> hi
<rodrigo_> any idea why a call to XSyncInitialize can fail?
<rodrigo_> is there anything that I should enable/install?
<tseliot> rodrigo_: one of the cases listed here perhaps? http://www.x.org/releases/X11R7.6-RC1/doc/libXext/synclib.html
<rodrigo_> hmm, maybe
<rodrigo_> although this is gnome-session 3.0, which has the same code as 2.32, and 2.32 works, but 3.0 fails
<rodrigo_> so, which case you mean? different protocol and lib versions?
<tseliot> rodrigo_: yes. Is this in Natty?
<rodrigo_> yes
<rodrigo_> hmm, maybe the gnome-session 3.0 package got compiled with a different version than the one I have, that might be
 * rodrigo_ upgrades
<cnd> tseliot, I think the issue is actually resolved by the addition of semi-multitouch functionality in the kernel
<cnd> allow me to explain :)
<cnd> the devices that were jumpy were likely all semi-multitouch devices
<cnd> but we didn't know at the time how to turn that functionality on
<cnd> in natty, the semi-multitouch mode is turned on for these devices, which also turns on multi-finger mode
<tseliot> ah
<cnd> with multi-finger mode, the jumpy cursor issue should be handled by http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=a6ca4d2523904b7ce49edc29ba408979bdf0d45e
<cnd> however, in my multitouch patches I have the wrong ordering of a key function
<tseliot> right, I remember that commit
<cnd> and this causes the change in number of fingers to be reported one frame too late
<cnd> so here's what I suggest:
<cnd> 1. I push a commit to fix the ordering of the function that affects the finger changes
<cnd> 2. leave the jumpy cursor patch in for natty just to be safe
<cnd> 3. remove the jumpy cursor patch for oneiric going forward
<cnd> my hope is that the jumpy cursor patch is now a no-op if all the jumpy devices were really multitouch devices in disguise
<tseliot> cnd: ok, it sounds like a good plan. Have you tested your fix together with the jumpycursor patch?
<tseliot> to see if there are regressions of any kind because of my patch?
<cnd> yeah, but it's just a noop here because has_double is now true
<tseliot> cnd: oh, right
<tseliot> cnd: if your fix makes the Dell mini 10 work correctly then you have my +1000 vote ;)
<cnd> it does!
<tseliot> I guess it's a kernel fix isn't it?
<cnd> with the jumpy cursor threshold it caused the cursor to stall if you moved it around too quick
<cnd> and this gets around that issue
<cnd> it's both a kernel fix and a synaptics fix
<cnd> I added multitouch support to synaptics
<cnd> and the functionality to make this work properly is built on top of that
<tseliot> cnd: yes, the threshold patch was meant to be a workaround since I couldn't find the real cause of the problem
<cnd> yeah
<cnd> it would have been sooo much easier if synaptics would just release their documentation
<cnd> what have they gained by keeping the semi-multitouch mode a secret?
<tseliot> cnd: I doubt that will happen
<tseliot> cnd: I can't talk about that in public but I agree with you ;)
<cnd> heh
<tseliot> thanks a lot for your work, I'm glad we can get rid of that hack and have things work out of the box :)
<cnd> yep :)
<geser> Hello, I'm giving "fglrx" from natty a try again and try how to get my dual-screen setup back. Do I need a xorg.conf to have a virtual size bigger than 1920x1920? (I need 3200x1920)
<cnd> bryceh, I just pushed a fix for synaptics to git
<cnd> if you get a chance please upload it
<bryceh> cnd, ok
<cnd> bryceh, I'm so excited cause the trackpad from hell is fixed now :)
<Sarvatt> hrm, is there a standard way to tag CVE's in debian/changelog? http://git.debian.org/?p=pkg-xorg/app/x11-xserver-utils.git;a=blobdiff;f=debian/changelog;h=62bf1e211dc7d39097d25e683a27ba26d99b2ce1;hp=9f37d5a08c71030e9c2a11ee0af62b37fe3c338e;hb=52b85a64989483df69812ea78e00666dbdcec993;hpb=a976b76500dafd6274b40bc255f93064b66f7559
<bjsnider> Sarvatt, does the cve string really have to be 450 characters long?
<bjsnider> that seems like it may be overkill
<Sarvatt> huh?
<bjsnider> isn't that the version you just posted?
<Sarvatt> +  * xrdb 1.0.9 (Fixes CVE-2011-0465)
<ubot4> Sarvatt: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0465)
<Sarvatt> ?
<bjsnider> no, the a976b76500dafd6274b40bc255f93064b66f7559
<bjsnider> i mean the commit
<bjsnider> maybe i'm thinking of cvs
<bjsnider> which one is the version control system that's been abandoned?
<Sarvatt> jcristau: gnome3 requires the pointer barrier patches that arent even in xserver master yet, libx11 1.4.3 isn't as crazy as that :P
#ubuntu-x 2011-04-06
<bryceh> RAOF, so what I've been thinking is the more bugs we can get sent upstream right now in this period between betas, the better
<bryceh> at the moment most of the software is relatively up to date enough that upstream will care, 
<bryceh> and its still early enough we can pull in patches if/when they become available
<RAOF> And we've got time to do something about any fixes!
<bryceh> past beta2, we're probably going to see diminishing returns
<bryceh> so after beta2 it makes sense to focus on key bugs and general testing
<bryceh> I'm not sure what we should or can do about the proprietary driver bugs
<RAOF> Neither am I.
<bryceh> time spent on them may not be as high a pay off as time spent on foss drivers, so focusing on the latter seems to make the most sense
<RAOF> Well, I guess we can try to work out whether it's a packaging problem or not and fix those.
<bryceh> yep
<RAOF> I'm somewhat surprised we haven't seen more nouveau bugs, actually.
<bryceh> yeah me too
<bryceh> I think I've heard more people *say* they have nouveau troubles than we have bug reports
<bryceh> but it's been such a quasi-supported driver for so long maybe they've become accustomed not to report stuff
<RAOF> I'm somewhat suspicious, yeah.  Particularly with some of the newer nvidia cards; there's a possibly resolved bug upstream that causes the newer cards to hang quite frequently when accel is enabled, but we don't *seem* to be seeing many of those bugs.
<RAOF> Maybe you're right; we've conditioned people to expect poor outcomes :/
<bryceh> it was the same with -ati long ago, I think things'll change, but the driver needs to get closer to par first probably
<RAOF> And maybe not have the 3d in -experimental-no-really-don't-report-bugs.
<bryceh> from http://nouveau.freedesktop.org/wiki/Bugs it sounds like they accept 3d nouveau bugs now, filed against mesa, so that sounds promising
<RAOF> Yeah.  It's new and shiny and interesting.
<bryceh> maybe it would be sensible to organize a nouveau 3d testing week next cycle or something
<RAOF> It would, yes.
<RAOF> I suspect we'd find that most things work well, newer cards hang after a while, and some things just don't work.
 * bryceh nods
<bryceh> probably what would give the most bang for the buck is some gpu hang debugging tools for nouveau
<bryceh> since judging from other drm drivers that seems to be the primary bugbear with 3d
<RAOF> Yeah.
<tjaalton_> RAOF, bryceh_, Sarvatt: so what do we do with 1.10.1 when it arrives? there are a whole bunch of memleaks fixed, among others
<tjaalton> i'd also like to push libx11 1.4.2 in natty, been using it for a couple of weeks without problems
<RAOF> What does it fix?
<tjaalton> "Additionally, Jamey Sharp has provided some fixes for Display lock handling
<tjaalton> that caused some deadlocks when using xcb for transport (which was optional
<tjaalton> in 1.3.x and is required in 1.4.x), so this update is highly recomended to
<tjaalton> users of multi-threaded Xlib applications.
<tjaalton> "
<tjaalton> oops
<tjaalton> there's bug 507602 which could be cured by that
<ubot4`> tjaalton: Bug 507602 on http://launchpad.net/bugs/507602 is private
<tjaalton> hell it is
<tjaalton> oh
<tjaalton> bug 507062
<ubot4`> Launchpad bug 507062 in libx11 (Ubuntu Natty) (and 3 other projects) "synaptic assert failure: synaptic: ../../src/xcb_io.c:385: _XAllocID: Assertion `ret != inval_id' failed. (affects: 388) (dups: 266) (heat: 2410)" [High,Triaged] https://launchpad.net/bugs/507062
<RAOF> Sounds like a reasonably useful fix.
<tjaalton> rest are here http://www.spinics.net/lists/xorg/msg52211.html
<tjaalton> do we still need ffe's for bugfix-releases
<tjaalton> ?
<RAOF> No.
<tjaalton> oh, so this could just go in? sweet
<tjaalton> if you are for it, of course :)
<RAOF> :)
<tjaalton> there's also 1.4.3 which only adds some define for sinhala
<RAOF> I remember reading a lot of those patches; they looked trivially correct.
<RAOF> Do you have test packages available?  I guess they're in alioth git?
<tjaalton> let me check
<tjaalton> at least they are on my local trees
<tjaalton> hum, should be fine yes
<RAOF> I'll give 'im a try, then.
<tjaalton> cool
<RAOF> As for 1.10.1, I guess that depends on how soon it's out.
<RAOF> I haven't followed the patches flowing there quite so much.
<tjaalton> yeah, there's 1.10.0.901 from last week, after that it got the memleak fixes from tiago
<tjaalton> I'll merge it locally and see if it fixes the menus on my savage
<bryceh_> I'd like to get as many fixes in as possible between now and release.  Cherrypicking is great, if there are bugfix releases available which we're reasonably certain don't add regressions, those are good too
<tjaalton> there are no regression fixes merged to the branch after .901
<tjaalton> not that it means there couldn't be regressions, but
<bryceh_> we've still got 3 weeks to go, plus sru's after that.  So there's time to fix things as long as we're attentive to bug reports coming in
<bryceh_> I feel a lot more comfortable given that the bug queue has been kept under control.  We're not drowning in bug reports, so I feel we're going to be able to spot and respond to regressions that come up between now and release very quickly
<bryceh_> so I'm not super worried if we pull in 1.10.1 and it has a regression or two, that it's going to be a huge deal.
<tjaalton> right
<bryceh_> but like raof says, sooner is better :-)
<tjaalton> so I'll prepare .901 in git
<tjaalton> and test it here
<bryceh_> oh, also, I just noticed http://lwn.net/Articles/437018/ - has anyone pulled that fix in yet?
<tjaalton> then it's closer to .1 once it's released
<tjaalton> sarvatt pulled it in x11-server-utils
<bryceh_> ok
<tjaalton> xrdb 1.0.9 that is, x11-s-u isn't released yet though
<tjaalton> i'll close bug 312756, it just messes up my mailbox
<ubot4`> Launchpad bug 312756 in xorg-server (Ubuntu) (and 2 other projects) "MASTER: support graphics card hot switch (affects: 249) (dups: 2) (heat: 1350)" [Wishlist,Triaged] https://launchpad.net/bugs/312756
<bryceh_> heh
<tjaalton> nice that the "hybrid graphics linux" -project uses that bug to gather dst information
<tjaalton> and not their own project bugs (there are none, of course)
<tjaalton> Sarvatt, bryceh_: bug 752315 done apart from the uploads
<ubot4`> Launchpad bug 752315 in x11-xserver-utils (Ubuntu Karmic) (and 5 other projects) "[SECURITY update] Sync x11-xserver-utils 7.6+2 (main) from Debian unstable (main) (affects: 2) (dups: 1) (heat: 18)" [Undecided,New] https://launchpad.net/bugs/752315
<tjaalton> used the same bug for hardy/karmic/lucid/maverick
<tjaalton> and pushed ubuntu-{lucid,maverick} to git
<Sarvatt> RAOF: I went ahead and reverted the sandybridge speedup in git, never managed to get it working on just GT2 and not GT1 :(
<tjaalton> merged xserver 1.10.0.901 from experimental
<jcristau> had to redo your xrdb updates?
<tjaalton> yeah they wanted the patch separate, not inline
<jcristau> ok
<tjaalton> and fixed the changelog too
<jcristau> i was too lazy to bother with quilt so i just edited the patch and git am'ed it
<tjaalton> i cherry-picked it, applied fine on every release :)
<tjaalton> i think
<jcristau> yeah
<tjaalton> didn't build-test them though
<jcristau> just had to s,xrdb.c,xrdb/&,g
<jcristau> because of the bundle thing
<tjaalton> ah right
<jcristau> other than that, yeah, it applied without fuzz or anything :)
<jcristau> yay for slow-moving sw
<tjaalton> yep :)
<jcristau> tjaalton: do you get to fix dapper as well?
<tjaalton> jcristau: hmm, I believe this falls under the 3y desktop support, but I'll confirm
<tjaalton> mdeslaur: ^
<tjaalton> ha, lp lists it as supported
<tjaalton> so, yes
<jcristau> 6 months release cycles make for too many branches :)
<tjaalton> yep!
<tjaalton> i'd favor 1y cadence, and then every other release would be LTS
<tjaalton> there, I said it :)
<tjaalton> hmm doesn't apply
<tjaalton> two hunks failed
<mdeslaur> tjaalton, jcristau: this is the list for the current dapper supported packages: http://people.canonical.com/~ubuntu-security/dapper-lts-server-supported.txt
<tjaalton> yeah
<bryceh_> tjaalton, thanks
<bjsnider> ricotz, is gnome 3 fully built in the ppa now or...?
<ricotz> bjsnider, kind of -- it is still missing some stuff
<bjsnider> does it actually work at this point?
<ricotz> i am using for some weeks now
<ricotz> but you will loose the gnome2/unity session
<bjsnider> gnome-shell works ok?
<ricotz> so far it does
<ricotz> but it will be more stable with 3.2 ;)
<bjsnider> is it playing well with the nvidia driver?
<ricotz> yes, besides the message-tray-slowness
<bjsnider> how soon before the rest of the packages are in the ppa?
<ricotz> i dont know, the desktop-team is quite busy with natty, and my time is limited too
<ricotz> do you miss something?
<ricotz> i hope gdm will get in soon
<bjsnider> i just want to test it after everything's in
<bjsnider> probably has a better chance of working
<ricotz> bjsnider, you are not brave enough? ;)
<bjsnider> ricotz, unity is already more than unstable enough for me. i will not tempt fate any more.
<ricotz> ;)
<bjsnider> at least it works fast with nvidia, when it isn't crashing
<ricotz> i havent used unity yet -- i am obviously more a docky fan :P
<bjsnider> why do you need docky if you have gnome-shell?
<ricotz> bjsnider, i like to have dock
<ricotz> i know there is a dock extension, but it dont have the features
<bjsnider> http://www.youtube.com/watch?v=7Nbi8JuC8JM
<bjsnider> ricotz, is that what it looks like to you?
<ricotz> bjsnider, yes
<cnd> bryceh_, help me out :)
<cnd> I can't find the release notes on the wiki anywhere
<cnd> neither google nor wiki searching help
<cnd> do you remember where they are?
<bryceh_> https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview
<bryceh_> cnd, release notes are at https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview
<bryceh_> probably ought to be linked to more prominently.  Wonder if we can update the topic here?
<bryceh_> nope
<cnd> bryceh_, they used to be at MaverickMeerkat/ReleaseNotes
<cnd> it's not so obvious anymore :)
<bryceh_> yeah
<ScottK> RAOF or Sarvatt: I've got this sandybridge laptop now.  It' mostly good, but there's some pretty bad screen corruption in some cases.  Any hope for this getting better?  Any thing I can help with on testing/bug filing?
#ubuntu-x 2011-04-07
<tjaalton> mesa 7.10.2, go/no-go ?
<RAOF> tjaalton: The diffstat is (somewhat surprisingly) not too scary.  Everything seems to work, too.
<tjaalton> RAOF: oh, you've tested it already?
<RAOF> A bit today.
<tjaalton> ok, nice
<tjaalton> next week the kernel will be frozen, so if we want to disable nouveau acceleration by default we should make it now
<tjaalton> OTOH fedora doesn't do it anymore
<tjaalton> so maybe it would be too invasive a change at this point
<RAOF> And we don't seem to have users screaming about it, either.
<tjaalton> right
<tjaalton> let's keep status quo then
<RAOF> I've got a nouveau upload that supposedly fixes an EXA crash, but, again, people don't seem to be hitting it.
<tjaalton> got a link to a bug?
<RAOF> No; it was just talking with darktama.\
<tjaalton> ok
<tjaalton> great, can't install maverick on a spare machine because of ati kms fail
<tjaalton> have to use a dvi-dsub dongle, and it doesn't seem to recognize it
<tjaalton> radeon.modeset=0 to the rescue, of course..
<tjaalton> except X still doesn't work
<tseliot> is it a new card?
<tjaalton> no, an ancient X800
<tjaalton> hum no, some firegl device actually, but from the same era
<tjaalton> I'll try natty next
<tseliot> hmm..
<tjaalton> x starts, just no picture to prove it
<tjaalton> logfile looks innocent as well
<tjaalton> same with natty
<tjaalton> works with the dvi cable
<tseliot> tjaalton: what cable was the one that didn't work?
<tjaalton> tseliot: d-sub, with a dvi dongle
<tseliot> ah, ok
<kklimonda> hey, any chance that one of you, X people have seen something like that on nouveau: http://people.ubuntu.com/~kklimonda/wtf.png ?
<bryceh_> heya sarvatt
<Sarvatt_> heyo! sorry, swapping between 4 different machines and missed IRC
<Sarvatt_> btw
<Sarvatt_> Error:  Failure creating backup file for /etc/default/grub.  Changes not applied.
<Sarvatt_> [Errno 13] Permission denied: '/etc/default/grub.bak'
<Sarvatt_> bryceh_: doesn't look like this runs update-grub after?
<Sarvatt_> bryceh_: hrm, second run thinks "disable bootloader graphics" isn't applied 100% of the time
<Sarvatt_> but its there
<bryceh_> Sarvatt, yeah I just added update-grub yesterday
<bryceh_> Sarvatt, those errors are because it has to run as sudo 
<bryceh_> need to figure out gksudo or some such to request privs
<bryceh_> Sarvatt, yeah sorted the disable bootloader graphics issue out yesterday too; that was kind of a hard one
<bryceh_> Sarvatt, fixes pushed to bzr
<Sarvatt_> bryceh_: cool, everything working now
<bryceh_> I also got the packaging squared away.  Just need to test it on a virgin machine then I think I can upload.
<bryceh_> ok, X blueprints filed
<bryceh_> I made 3, one for stakeholders, one for discussing tools/processes/debugging/etc., one team huddle one
<bryceh_> RAOF, ^ please review and see if I missed anything
<tjaalton> subscribed to them
<bryceh_> tjaalton, I'm looking forward to having so many X folks at one UDS :-)
<tjaalton> bryceh_: yeah, there might even be <gasp> discussions :)
<tjaalton> the previous planning session I attended took maybe 15min :)
<bryceh_> yeah
<Sarvatt_> hopefully they dont overlap private sessions I have to go to this time around :)
<tjaalton> uds-j
<bryceh_> tjaalton, Sarvatt_, yeah make sure you're subbed as essential to these so you don't get too cross-scheduled
<bryceh_> tjaalton, Sarvatt, also if you guys think we need additional topics just shout.
<bryceh_> although it seems from past uds's that 3 X sessions was about right
<bryceh_> but now that there's more of us we could probably handle more if we see the need
<tjaalton> sure
<bryceh_> tjaalton, sarvatt: I'm kind of disappointed -intel is still proving quite buggy - http://tinyurl.com/3jrqgat
<tjaalton> yeah..
<bryceh_> I have been pumping bug reports upstream but the patches we've been getting have been more miss than hit lately
<tjaalton> btw, was the apport-collect script broken for a while?
<bryceh_> I'm kinda stuck on what else to do... any ideas?
<bryceh_> tjaalton, yeah, a couple typos
<tjaalton> ok, that's why ubuntu-bug reported ~empty bugs
<bryceh_> sorry about that; have them run apport-collect <bug-nr> and that should fix them up
<tjaalton> so are these intel bugs without the trigger-happy apport script?
<tjaalton> ie. nothing we can turn off?-)
<tjaalton> left
<bryceh_> the GPU lockup ones are from the gpu lockup hook, and are mostly legit bugs
<tjaalton> right
<bryceh_> I think I got the script a lot less trigger-happy now, although the vesafb conflict or whatever that causes the false positives is still  there
<bryceh_> bugs with ESR 0x00000010 are often that issue
<tjaalton> ok, so unless we educate ourselves as gpu programmers there's not much to do than report them upstream and be nice to ickle :)
<bryceh_> bug #2 is whatever causes freezes on 915/945, we get tons of those, and upstream tends to dupe them all together, point to a patch, and close as fixed.  Then we have to pull that fix in, and wait for another series of 915/945 bugs to get reported.  Rinse, lather, repeat.
<ubot4`> bryceh_: Bug 2 on http://launchpad.net/bugs/2 is private
<bryceh_> there's a third class which is arrandale specific
<bryceh_> I had thought the new ia32-libs would resolve that since it seems to only affect x86_64, but we're still getting bugs reported
<bryceh_> so like "[arrandale] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000024)" is typical error codes on that
<tjaalton> ah
<bryceh_> fourth class is 965-specific, bug #686388
<ubot4`> Launchpad bug 686388 in xserver-xorg-video-intel (Ubuntu Natty) (and 4 other projects) "[i965gm] GPU lockup - Invalid GTT entry during Display B Fetch (affects: 11) (dups: 8) (heat: 80)" [High,Incomplete] https://launchpad.net/bugs/686388
<bryceh_> I think that covers the common classes for the gpu lockups
<bryceh_> then there's a whole bunch of other random assorted bugs
<bryceh_> oh, and various 865 lockups, but we just wontfix those
<bryceh_> tjaalton, yeah I think you're right regarding needing gpu programming education ;-)
<tjaalton> i'll probably buy a second hand fujitsu laptop (v5535) with sis 671 on it, and see how the damn driver works first :)
<tjaalton> or, rather, doesn't
<bryceh_> heh
<bryceh_> well, like one thing I'm wondering is it'd be nice if when Intel posts a patch that "fixes" it, that we have some easy way to roll a kernel with that patch so reporter can easily verify that no, it doesn't
<tjaalton> don't the kernel team do that, provide a ppa with a kernel that has a proposed patch
<bryceh_> we have daily builds of intel-drm-next, but I think they're being stricter about putting untested patches into that
<bryceh_> tjaalton, yeah they do, but I wonder if bugging them each time there is a patch needing packaged is the right solution?
<bryceh_> and maybe it is; technically they are kernel bugs after all...
<tjaalton> bryceh_: no, but can't we make use of the infrastructure directly?
<Sarvatt_> tjaalton: do you have an account on tangerine? its so friggin fast for building kernels, I can walk ya through it tomorrow if you want
<bryceh_> right, that's what I'm wondering
<tjaalton> Sarvatt_: t.c.c?
<Sarvatt_> tangerine.buildd
<tjaalton> doesn't seem like I do
<tjaalton> "Permission denied (publickey)."
<Sarvatt_> gotta pivot in from chinstrap
<tjaalton> that's where i tried from
<Sarvatt_> you'd know if you had an account, lets see
<Sarvatt_> its a 64 core 64gb ram machine in one of the datacenters for kernel building, takes <10 minutes for a kernel build
<tjaalton> hah
<tjaalton> hmm, at my previous job I built mesa in 8min on a shell server, which had 12cores + hyperthreading, and 96GB RAM
<tjaalton> can't remember the time it took, but it was fast
<tjaalton> could've been less than 8min
<bryceh_> it would be totally awesome if we could go from a) patch posted in upstream bug tracker, to b) built kernel (or mesa) .debs for reporter to test, in under 10 min
<bryceh_> heck, even 30 min would be nice
<bryceh_> currently it seems the turnaround is >5 hrs for such a case
<JanC> tjaalton: I once talked with somebody who builds a kernel in < 1 min at his job  ;)
<tjaalton> yep, it should be doable. like create a branch, pull the fix, push the package to the builder (with some script, lp# as an argument) and then the bug would get the link
<tjaalton> JanC: ok, that's quick :)
<JanC> he works/worked at http://sara.nl/ though  :P
<Sarvatt_> thats a really freaking good idea
<tjaalton> i got a couple of friends at http://csc.fi
<tjaalton> they have all the toys :,I
<Sarvatt_> bryceh_: https://wiki.canonical.com/KernelTeam/BuildResources
#ubuntu-x 2011-04-08
<RAOF> ayan: Hi again :)
<RAOF> Also, the contents of /var/log/Xorg.0.log and the output of dmesg are likely to be useful in debugging this.
<ayan> ROAF: hi!
<RAOF> (In a pastebin, if that's not obvious âº)
<RAOF> ayan: Still here?
<RAOF> Hm, interesting.  Compiz seems to have kernel-panicked nouveau, but ssh soldiers on.
<RAOF> Balls.  There's an X crasher in -radeon's DRI2 swapbuffers handling again.
<tjaalton> what, have I pushed something to our xorg-server branch..
<tjaalton> oh, the merge. just the diff post on debian-x@ looks funny
<RAOF> tjaalton: Would you like to test some mesa 7.10.2? :)
<tjaalton> RAOF: sure
<RAOF> I'll push it to git.
<tjaalton> ok, I'll build from there
<RAOF> Oh, yeah.
<RAOF> I'll throw my binaries into http://cooperteam.net/Packages for you!
<tjaalton> cool, clean it up a bit and I can wget the whole dir :)
<tjaalton> i have intel to test it on
<tjaalton> 965
<RAOF> tjaalton: Now available for your pleasure.  i386 & amd64!
<tjaalton> RAOF: thanks, downloading..
<JanC> I suppose Radeon HD 6950's are supposed to work in natty?
<RAOF> Are, or aren't?
<RAOF> I *think* they are, actually.
<JanC> are
<JanC> somebody complained his new HD 6950 didn't work in 10.10, I told him to try the natty beta live cd
<tjaalton> what happened?
<RAOF> It should be supported by fglrx if nothing else.
<JanC> he's downloading...
<tjaalton> heh, ok
<JanC> I'll let you know  ;)
<JanC> download is going to take 3 hours...   :-(
<tjaalton> at 64k/s?
<tjaalton> slow..
<tjaalton> RAOF: mesa seems to not burst into flames here
<RAOF> It also hasn't burst into flames on my radeon card, where the bulk of the changes were.
<RAOF> However, I don't have an r300 to test, and that would be good.
<tjaalton> i do, actually
<tjaalton> at least I think it is one
<RAOF> Anything r300-r500 would do; that's 9600 (I think) - HD 2xxx (again, I think) :)
<tjaalton> yesh, R300 NG [FireGL X1]
<tjaalton> seems to work
<tjaalton> RAOF: ^
<tjaalton> so, we have libdrm, xorg-server, mesa, libx11 bugfix releases pending.. next thursday is beta2
<tjaalton> when do we start uploading these?-)
<RAOF> Now, I think.
<RAOF> Although we might not want libdrm 2.4.24
<tjaalton> ok
<tjaalton> because of then nouveau changes?
<tjaalton> great, the 10.10 installer doesn't recognize my ssd drive
<tjaalton> so I can't test the joystick patch on it
<tjaalton> don't have a spare hd
<tjaalton> tseliot: looks like the dvi-dsub -dongle works after all, just had to make sure it's connected to the right dvi port
<tjaalton> and the "no ssd" problem is a bios failure
<tjaalton> sometimes it doesn't seem to probe it
<tseliot> tjaalton: what is it that makes a dvi port the right port?
<tseliot> does it have to be the 1st dvi connector?
<tjaalton> probably
<tjaalton> dvi cable works on both
<tjaalton> cnd: hey, there's bug 745065 which says that wacom multitouch is broken in natty when it worked in lucid & maverick
<ubot4`> Launchpad bug 745065 in xf86-input-wacom (Ubuntu) "Touchscreen not detected as multi-input (affects: 1) (heat: 6)" [Low,Confirmed] https://launchpad.net/bugs/745065
<tjaalton> cnd: ideas about that on?
<tjaalton> *one
<cnd> tjaalton, I'll take a look
<tjaalton> cnd: thanks
<tjaalton> RAOF: forgot to push mesa?
<tjaalton> probably too late to ask :)
<lamont> so when I resize a window, it should actually resize, right?
<lamont> (natty beta)
<lamont> though to be fair, that's from a day or 3 ago - dist-upgrading now
<tjaalton> works here
<lamont> tjaalton: uxterm and resize it
<lamont> pulling down the bottom of the window
<lamont> and then resize it again
<tjaalton> lamont: yep
<tjaalton> looks fine to me
<Sarvatt> yep thats busted here too, the xterm doesn't resize
<lamont> I'm using "ubuntu classic" atm
<tjaalton> me too :)
<Sarvatt> ah wait
<Sarvatt> it works on an updated system
<tjaalton> Sarvatt, bryceh_: the archive will beta-freeze on monday :/
<lamont> let me finish the dist-upgrade and confirm that I'm still broken (hoping I can just go "all better, thanks")
<Sarvatt> 3 day old natty + nvidia blob doesnt resize, fully up to date intel resizes properly
<lamont> and that says 8 minutes
<lamont> intel chipset here
<tjaalton> nvidia here, upgraded yesterday
<lamont> 1 day 25 min uptime here, but that's 12-18 hours post-upgrade
<lamont> 8 min download, nfc how long after that for processing
<tjaalton> xterm hasn't changed
<lamont> the server has
<Sarvatt> compiz has
<lamont> yeah - was just going to say "or has the server..."  compiz has
<lamont> gnmoe has
<lamont> gnome even
<Sarvatt> lamont: 
<Sarvatt> compiz (1:0.9.4+bzr20110406-0ubuntu1) natty; urgency=low
<Sarvatt>   * new upstream bzr tarball:
<Sarvatt>     - display/size problems with xterm (LP: #748137)
<Sarvatt> sure is nice when bugs are already fixed :P
<tjaalton> hehe
<lamont> heh
<lamont> ta
<Sarvatt> ok got 7.10.2 on all my machines, now to break things!
<tjaalton> it's indestructible
<tjaalton> i'll upload libx11 1.4.2-1u1
<tjaalton> 1.4.3 would need newer xutils-dev
<tjaalton> bryceh_: btw, xutils-dev doesn't show on versions-current.html?
<Sarvatt> [     5.435]
<Sarvatt> X.Org X Server 1.10.0
<Sarvatt> so friggin fast!
<tjaalton> heh
<tjaalton> ssd luv
<lamont> it does, indeed, appear to be fixed.
<tjaalton> libx11 uploaded
<tjaalton> guinness-time \o\ |o| /o/ :)
 * Sarvatt is jealous
<Sarvatt> speaking of which, need to put more in the fridge :)
<Sarvatt> darn, new libva in sid but its too late for natty
<Sarvatt> into x-updates it goes
<Sarvatt> hrm 270.40 nvidia driver but its not a normal release, just on the CUDA page
<Sarvatt> tjaalton: looks like the buildds are screwed up? libx11 failed
<Sarvatt> oh nevermind klingon failed
<tjaalton> Sarvatt: great, i get to drop it
<tjaalton> oh
<tjaalton> how the hell did it build here then
<tjaalton> series file was all fail
<Sarvatt> tjaalton: 100_latin_locale_alias.diff101_klingon_locale_alias.diff yea :)
<Sarvatt> 102_double_arrows_Compose.diff is failing after fixing that
<tjaalton> yeah i dropped the double
<tjaalton> err, the other entry i mean
<Sarvatt> klingon is fine
<bryceh_> tjaalton, ah, +packagebugs changed from "in ubuntu" to "in Ubuntu", which broke my regex.  So it has been using an old list of our X packages.  Page is being refreshed now.
<tjaalton> bryceh_: great, thanks
<Sarvatt> tjaalton: http://sarvatt.com/downloads/patches/102_double_arrows_Compose.diff
<Sarvatt> oh bah wait
<Sarvatt> 102_double_arrows_Compose.diff was in the series twice..
<Sarvatt> lol
<bryceh_> http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/versions-current.html updated
<Sarvatt> https://bugs.launchpad.net/ubuntu/natty/+source/nvidia-graphics-drivers/+bug/752634  -- isn't that the intended behavior from the nvidia blob? I've never used multi monitor on it but fairly sure you have to set up additional monitors through the nvidia-settings gui and not xrandr
<ubot4`> Launchpad bug 752634 in nvidia-graphics-drivers (Ubuntu Natty) (and 1 other project) "[Lenovo T410] Displayport cannot output to a monitor (affects: 1) (heat: 6)" [Medium,New]
<bryceh_> Sarvatt, yes that's correct
<Sarvatt> phew, only 2 bugs from the cert runs, I was worried :)
<bjsnider> ram usage with the blob in natty is outrageous
<bjsnider> compiz ends up at >500 mb after a couple of days
<Sarvatt> bjsnider: update
<Sarvatt> new cairo should be published now
<bjsnider> well, i ran all updates as of this morning
<Sarvatt> it was uploaded like an hour ago I think
<bjsnider> what is it, libcairo?
<bjsnider> it's not in there so far
<Sarvatt> https://lists.ubuntu.com/archives/natty-changes/2011-April/011061.html
<Sarvatt> hmm should be published, might not be on your mirror yet
<Prf_Jakob> Sarvatt: what are the issues?
<Sarvatt> cairo linking to a 24MB nvidia libGL making the world use outrageous amounts of memory :)
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/725434
<ubot4`> Launchpad bug 725434 in nvidia-graphics-drivers (Ubuntu Natty) (and 3 other projects) "Nvidia drivers lead to extra memory usage for each process using libGL (affects: 32) (dups: 1) (heat: 188)" [Medium,Won't fix]
<Prf_Jakob> Sarvatt: eh? clearly the Linux VM should handle that well or is allocating a lot of data as well?
<kees> RAOF, bryceh_ : what are your thoughts on bug 738687? should that patch be added to our mesa?
<ubot4`> Launchpad bug 738687 in mesa (Ubuntu) "R600 driver crashes when adding effects in kwin (affects: 2) (heat: 18)" [Medium,Triaged] https://launchpad.net/bugs/738687
<Sarvatt> kees: thats actually queued up to upload in mesa 7.10.2 whenever RAOF comes on next
<bryceh_> kees, yeah if it's in the stable tree should be a no-brainer to include
<bryceh_> kees, how'd you run into this issue?
<kees> cool; thanks guys. how should I mark that bug so it disappears from the sponsorship queue?
<kees> bryceh_: I'm patch pilot, and it was marked for sponsorship
<bryceh_> oh patch piloting, of course
<bryceh_> kees, hmm
<bryceh_> kees, good question...  
<bryceh_> kees, raof probably won't be on until monday and since the freeze comes monday there could be a chance it gets missed
<bryceh_> kees, so maybe go ahead and sponsor the patch in?
<bryceh_> sarvatt, what do you think?
<kees> I'd rather not disrupt RAOF's schedule...
<seb128> bryceh_, the freeze will not be before the european day so there is time for an upload for .au guys
<tjaalton> but RAOF is no core-dev
<kees> okay, I'll just mention in the bug it's scheduled...
<tjaalton> if he could just push the git branch we could upload during the weekend
<seb128> kees, yeah do that
<bryceh_> ok well fwiw, I'm on vacation monday7
<seb128> it's likely we will clean pending uploads on monday
<tjaalton> I've tested 7.10.2 on r300 and intel
<tjaalton> and RAOF took care of r600 i think
<Sarvatt> i've been running it on 945 and sandybridge
<bryceh_> kees, sounds like assign to RAOF I guess
<kees> bryceh_: yeah, was just doing that :)
<tjaalton> 965 intel here
<tjaalton> if the archive is frozen at 9:00 UTC on monday, I'll have plenty of time uploading it :)
<ScottK> I've got a Sandybridge laptop that is having what seems to be KDE specific screen corruption issues.  Is there a way I can turn specific driver features on/off at runtime to see if I can narrow down where the issue is?
<ScottK> It's not tied to compositing as it happens with that totally disabled.
<bryceh_> ScottK, modinfo on the drm driver gives the kernel tunables; man intel gives some X driver options; driconf has the mesa tunables
<ScottK> bryceh_: The bug is https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/750964 - Any suggestions on where best to start?
<ubot4`> Launchpad bug 750964 in xorg (Ubuntu) "Screen corruption in menus and titlebars (affects: 2) (heat: 12)" [Undecided,New]
<bryceh_> ScottK, maybe rerun apport-collect xorg and see if it'll pick up the missing log files
<ScottK> I'll try it.
<bryceh_> ScottK, if you suspect it's particular to kwin, I'd suggest starting with driconf since that controls 3D and is pretty easy to use
<bryceh_> also, an important factoid is when the issue first started happening
<ScottK> It happened since I got the laptop on Monday.
<bryceh_> since if it's a recent regression, then downgrading packages one by one can be a straightforward way to pinpoint things
<ScottK> So no idea how long it's been a problem.
<bryceh_> ah, so not a regression then
<ScottK> Nope.
<ScottK> Just really, really annoying.
<ScottK> I assume I need to restart X after making changes in driconf?
<bryceh_> you can also flip on kernel drm debug (drm.debug=0x03) although it'll spew a lot of output
<bryceh_> yep
<ScottK> Let me play with driconf first.  It's got a lot of knobs to turn.
<bryceh_> yep
<tjaalton> i really don't understand bug 754565
<ubot4`> Launchpad bug 754565 in xorg (Ubuntu) (and 1 other project) "Regression: shift+click on a launcher icon to open a new application instance gone (affects: 2) (heat: 10)" [High,Triaged] https://launchpad.net/bugs/754565
<bryceh_> tjaalton, hum yeah me neither
<bryceh_> tjaalton, isn't really much of a bug report
<tjaalton> bryceh_: nope
<bryceh_> tjaalton, close it and tell them we're not mind readers?  ;-)
<tjaalton> hehe
<tjaalton> I'll think of something
<tjaalton> there
<ScottK> No luck with driconf
<albert23> ScottK: the config in freedesktop bug 35808 comment 11 may be worth to test
<ubot4`> Freedesktop bug 35808 in Driver/intel "[SNB] KDE graphic glitches" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=35808
<ScottK> albert23: Thanks.
<Sarvatt> ScottK: also if it doesn't and you want to see if it does with updated drivers - https://launchpad.net/~sarvatt/+archive/gold
<ScottK> Thanks.
<ScottK> Mine is a 6320 (vice 6420) so it's very close.
<ScottK> I don't have the kms issue he has.
<Sarvatt> i've got 2 6420's here, it must really be KDE specific
<ScottK> Ah.  That did it.
<ScottK> Option "DebugFlushBatches" "True" and it's all better.
<ScottK> Sarvatt: I do believe it's KDE specific.  Even non-KDE apps in a KDE session are OK.
#ubuntu-x 2011-04-09
<ScottK> Any way to set that option if it's sandybridge and a KDE session?
<Sarvatt> nope, and it's a pretty nasty performance hit to do globally on sandybridge :(
<Sarvatt> lets see just how much, time for some cairo-trace runs
<ScottK> OK.  Any suggestions on what I might tell KDE to do to avoid such problems?
<Sarvatt> I really don't, I'm sorry. the intel guys dont know why its needed even
<ScottK> OK.
<Sarvatt> worst case scenario we flip it over to default in time for release if its still busted
<ScottK> OK.
<ScottK> I linked my bug with the upstream bug.
<ScottK> (commented upstream as well)
<tjaalton> xserver 1.10.1rc2 merge pushed to git
<albert23> 32 bit dri drivers on amd64 cannot be used in natty because they cannot find the 32 bit libdricore and libglsl libraries.
<albert23> The 64 bit dri drivers seem to find these libraries using an RPATH, but in the 32 bit drivers the RPATH points to /usr/lib/dri instead of /usr/lib32/dri.
<albert23> Is that an ia32-libs bug or should mesa set the correct RPATH when it builds 32 bit frivers on amd4?
<albert23> ah, ia32-libs doesn't build the packages, just uses the 32 bit debs
#ubuntu-x 2012-04-02
<Darxus> Looks like my radeon, which works great in Oneric, does not work with the radeon drivers in Precise.
<Darxus> Normal mode, it boots to a dark purple flickering screen, entirely unusable, using the radeon driver.  Safe mode, it boots with the vesa driver:
<Darxus> <  (II) [KMS] drm report modesetting isn't supported.
<Darxus> <  (II) GPU only supported with KMS, using vesa instead.
<Darxus> Fresh precise beta 2 install, doing a dist-upgrade now to see if that helps.
<RAOF> Darxus: Got a dmesg?
<Darxus> Sure, I'm booted into save graphics mode now, that good?
<Darxus> http://www.chaosreigns.com/tmp/precise.safemode.dmesg.txt
<RAOF> You'd need to boot without nomodeset to get a useful dmesg.
<Darxus> Okay.
<Darxus> What are you looking for in dmesg?
<RAOF> Anything drm related; adding âdrm.debug=0xeâ to the kernel command line would be useful.
<Darxus> Okay.
<Darxus> So add "nomodeset drm.debug=0xe" to the end of the kernel args?
<RAOF> Yeah.
<RAOF> Another thing to check would be the grubâdrm handoff; you'd want to remove the âset gfxpayload=$STUFFâ stuff when booting.
<Darxus> Still waiting for the dist-upgrade.
<Darxus> Okay.
<Darxus> Rebooting.
<Darxus> Doesn't look like it includes what you're looking for: http://www.chaosreigns.com/tmp/precise.dmesg.txt
<Darxus> ah, I typed the drm.debug part wrong, trying again.
<Darxus> Uploaded over the last one, http://www.chaosreigns.com/tmp/precise.dmesg.txt
<Darxus> Still doesn't look useful.
<Darxus> X is still using the vesa driver.
<Darxus> X log still says
<Darxus> [    15.733] (II) [KMS] drm report modesetting isn't supported.
<Darxus> [    15.733] (II) GPU only supported with KMS, using vesa instead.
<RAOF> You've kept ânomodesetâ in the kernel command line.
<RAOF> Which, indeed, will disable kms, which will mean that nothing interesting happens.
<Darxus> I guess I misunderstood what you wanted me to do.  What should I do?
<RAOF> Remove the ânomodesetâ from the kernel command line, add the âdrm.debug=0xeâ bit, and boot.
<RAOF> That will, presumably, fail to work correctly, and the dmesg should give an idea as to why.
<RAOF> Then, try the same thing, but removing the âset_gfxpayloadâ bit from the grub entry (you can do this from the grub menu)
<Darxus> Okay, thanks.
<Darxus> fglrx looks like it works, which is nice.  But not useful with wayland.
<RAOF> Indeed :)
<Darxus> I neglected to mention when this fails I can't get any usable console :/
<Darxus> dmesg isn't written to a file anywhere by default, right?  So, init script or something to run it?
<RAOF> dmesg is sent to /var/log/kern.log
<RAOF> Well, and also syslog.
<RAOF> And probably a couple of other places :)
<Darxus> Ah, okay.
<Darxus> So just giving you a copy of /var/log/kern.log from a boot where the graphics fails would be good?
<RAOF> That'd be good.
<Darxus> Okay.
<Darxus> http://www.chaosreigns.com/tmp/kern.log
<Darxus> That's only the boot with the graphics failing.  Booted to oneric, renamed that log, booted to precise with drm.debug=0xe, rebooted back to oneric...
<RAOF> EPERM
<RAOF> Or, translated through perror: I don't have permissions to view that :)
<Darxus> Fixed, sorry.
<Darxus> Apr  1 21:08:55 dancer kernel: [   10.663848] [drm:radeon_process_aux_ch], dp_aux_ch flags not zero
<Darxus> Apr  1 21:08:55 dancer kernel: [   10.663849] [drm:radeon_dp_i2c_aux_ch], aux i2c too many retries, giving up
<Darxus> I guess that shouldn't cause this problem.
<RAOF> Yeah.
<RAOF> radeon thinks it's brought up 1600x1200 on your VGA output.
<Darxus> And no useful errors?  :/
<RAOF> The *other* option might be that X is starting too soon - do you have a corresponding Xorg.0.log
<Darxus> Sure.
<RAOF> I'm less familiar with how radeon looks when stuff goes wrong than intel, but I can't see anything obvious there.
<Darxus> http://www.chaosreigns.com/tmp/Xorg.0.log
<RAOF> Oh.
<RAOF> And *X* thinks everything worked, too.
<Darxus> I swear it's a horribly flickering dark purple mess :/
<RAOF> I'm sure it is, but it seems that neither the kernel nor X is aware that anything's wrong.
<RAOF> Did you try dropping the gfxmode bit in grub?
<Darxus> No.
<RAOF> Give that a whirl; the framebuffer handoff can confuse things, and may well be the cause here.
<Darxus> With everything else as defaults?
<Darxus> Radeon driver version isn't in the Xorg log?
<RAOF> With everything else as defaults (assuming that your defaults don't include nomodeset)
<Darxus> Right.
<RAOF> The version is in the log - 6.14.99
<RAOF> Not that that's particularly useful, as we habitually take git snapshots of the ati DDX, since it's (a) usually stable, and (b) has a slow release cycle.
<Darxus> Worked!
<Darxus> I just removed the setgfxpayload... line.
<RAOF> Sweet.
<RAOF> Please file a bug with âubuntu-bug linuxâ.  We may need to add your card to the blacklist.
<Darxus> A blacklist of cards to effectively skip the setgfxpayload stuff?
<RAOF> Yup.
<Darxus> Nice.
<Darxus> What info do I need to provide on the card, just "lspci | grep -i vga" output?  Should I attach the kernel log and X log?
<Darxus> And what should I title the bug?  What do you call that blacklisting?
<RAOF> If you use âubuntu-bug linuxâ it'll attach all the relevant information.
<RAOF> Title the bug something like âgraphics fails with setgfxpayload=keepâ
<Darxus> Thanks.
<Darxus> Then I can finally test out the wayland packages in precise, and attempt to run some stuff that's built against gtk3 with it :)
<Darxus> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/971204
<ubottu> Launchpad bug 971204 in linux (Ubuntu) "graphics fails with setgfxpayload=keep, AMD Radeon" [Undecided,New]
<RAOF> Darxus: Excellent; I'll ensure that gets looked at by the kernel team.
<Darxus> Great, thanks.
<Darxus> I'll be happy to test a fix.
<RAOF> Oooh, I see you've got a system built by the well-respected âSystem manufacturer System Product Nameâ.  Second only to that great paragon of computing, âTo Be Filled In By OEMâ.
<Darxus> Haha.
<Darxus> You got something against people putting their own machines together?  :P
<Darxus> http://www.chaosreigns.com/dancer/  <- more detail than you could possibly care about.
<Darxus> Except pictures :/  Need to fix that.
<joumetal> xorg-edgers radeondrigetversion failed because of version mismatch. required 1.17.0 but kernel reports 2.12.0. known issue?
<jcristau> means you need to load radeon.ko sooner
<mlankhorst> noon
<Darxus> I just had a hang where my monitor went off and alt-sysrq reisub didn't work :(  I suspect there are more substantial problems between my video card and the radeon driver in precise.
<Darxus> Just using eog triggered it.  
<alex_mayorga> bryceh: ping
<alex_mayorga> anyone here that could help fix https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/551668 before 12.04 ships?
<ubottu> Launchpad bug 551668 in nvidia-graphics-drivers (Ubuntu) "Fn+F5 and Fn+F6 don't modify brightness on Sony VAIO VPCCW (GT 230M)" [Undecided,Confirmed]
<tjaalton> alex_mayorga: aiui you need to quirk it in the xorg.conf
<alex_mayorga> tjaalton: Can you dumb down that a bit for me please?
<tjaalton> alex_mayorga: you need a driver option in xorg.conf
<tjaalton> don't ask which one
<mlankhorst> blob?
<mlankhorst> Option "EnableACPIBrightnessHotkeys" "boolean"
<mlankhorst> http://us.download.nvidia.com/XFree86/Linux-x86/295.20/README/xconfigoptions.html
<tjaalton> yeah
<alex_mayorga> would that work with nouveau?
<alex_mayorga> I'm using nouveau now
<mlankhorst> nvidia-graphics-drivers is nvidia blob right?
<jcristau> mlankhorst: yes
<jcristau> alex_mayorga: then why are you linking to a blob bug?
<bryceh> jcristau, the bug he linked to was open against both -nvidia and -nouveau
<alex_mayorga> jcristau: I put it affects both
<jcristau> ah.
<jcristau> so it's just the url being confusing.  fair enough, sorry.
<alex_mayorga> sorry, don't know how to get the nouveau link
<tjaalton> the nouveau upstream ug was marked as fixed
<mlankhorst> https://bugs.freedesktop.org/show_bug.cgi?id=31920
<ubottu> Freedesktop bug 31920 in Driver/nouveau "Brightness control is erratic (/sys/class/backlight/nv_backlight/max_brightness is wrong)" [Normal,Resolved: fixed]
<alex_mayorga> I think it's https://bugs.freedesktop.org/show_bug.cgi?id=23023 instead
<ubottu> Freedesktop bug 23023 in Driver/nouveau "no backlight support in /sys or /proc ; xbacklight not working" [Normal,Reopened: ]
<alex_mayorga> the other one worked for the original reporter but not much else
<alex_mayorga> anyhow, thought I could stop by in case any more detail is needed
<alex_mayorga> the fact is, backlight levels do not work on this laptop
<alex_mayorga> even if the display shows =(
<bryceh> related to 819002 maybe?
<alex_mayorga> bug 819002
<ubottu> Launchpad bug 819002 in Linux "Brightness level control is not working properly on Sony Vaio" [Medium,Incomplete] https://launchpad.net/bugs/819002
<bryceh> the patch for that bug appears to come from http://code.google.com/p/vaio-f11-linux/wiki/KernelSupport
<alex_mayorga> bryceh: Looks very similar
<alex_mayorga> mine is another model though
<alex_mayorga> bryceh: Got powers on https://bugzilla.kernel.org/show_bug.cgi?id=41652 ?
<ubottu> bugzilla.kernel.org bug 41652 in Power-Other "Brightness control keys not working" [Normal,Needinfo]
<bryceh> patchset proposed on platform-driver-x86 via http://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg02399.html
<alex_mayorga> How come the keys are caught, OSD shows, but in the end nothing happens?
<alex_mayorga> Guess kernel devs don't care as long as their mac book pros work, right? ;-P
<hyperair> maybe kernel hackers just don't buy vaios.
<mlankhorst> pretty much..
 * hyperair wouldn't either.
 * alex_mayorga doesn't have much sayin on what he gets for "saturnalia"
<bryceh> http://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg01975.html
<bryceh> Added support for handle 0x0143 (Vaio SA/SB/SC, CA/CB). Minor corrections included. 
<bryceh> guess that doesn't fix vaoi vpccw though
<alex_mayorga> bryceh: the patched were never taken, were they?
<alex_mayorga> The guy seems to have a Launchpad account https://bugs.launchpad.net/~marco-absence
<bryceh> alex_mayorga, doesn't appear so to me
<alex_mayorga> What is there to do then? Upstream doesn't seem to care =(
<mlankhorst> it's not cc'd to lkml..
<bryceh> mlankhorst, yeah, presumably because he wanted to finish the v2 set of patches first?  I'm not really familiar with the platform-driver-x86 list.
<bryceh> alex_mayorga, as far as next steps, some random ideas...
<mlankhorst> reading that mail-archive, there were some technical problems with that patch anyhow..
<bryceh> alex_mayorga, 1.  contact the patch author, Marco Chiappero, to get an update about the patch and if he plans to re-propose it.  (And if he can update it to include your model).
<bryceh> alex_mayorga, 2.  try sweet talking the ubuntu kernel team into building a kernel with that patchset for you to test.  This might not be possible though, if there's problems with the kernel or if it's hard to figure out how to apply it to a mainline kernel.
<bryceh> alex_mayorga, 3.  If you feel like hacking on some C code, see if you can figure out which chunk from all those patches provide the backlight fix, extract it and revise it to work with the current kernel, and then verify that bit alone fixes it for you.  If so, then propose inclusion of that into the kernel.
<bryceh> that last one could be rather labor intensive
<bryceh> alex_mayorga, 4.  join the platform-driver-x86 mailing list, and post an email asking for an update on the status of Marco's vaio patchset
<bryceh> alex_mayorga, meanwhile, I've added my findings to the bug reports and tagged them to get some attention from our kernel team.  However I think they'll be more likely to take action if one of the above steps is taken.
<alex_mayorga> bryceh: Thanks! I'll put those in my to-do
<cnd> bryceh, RAOF, Sarvatt: the only other input option breakage I was aware of was bug 969495
<ubottu> Launchpad bug 969495 in xserver-xorg-input-evdev (Ubuntu) "evdev stopped remapping events" [Medium,Invalid] https://launchpad.net/bugs/969495
<cnd> which is invalid, the user was using someone else's evdev and now is using the Ubuntu version
<cnd> so I think we're ok
<Sarvatt> cnd: still can't close my lid due to https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/948697 but ya guys touched on that in #ubuntu-kernel earlier
<ubottu> Launchpad bug 948697 in xorg-server (Ubuntu) "[bcm5974] Xorg crashed with SIGSEGV in valuator_mask_set_double()" [High,Confirmed]
<cnd> Sarvatt, oh, it causes X to crash?
<cnd> or is that just an old title
<Sarvatt> yeah it crashes X
<Sarvatt> but i have suspend on lid closed disabled, sforshee has suspend enabled
<Sarvatt> it crashes it after about 8 hours with the lid shut with it sending constant streams of input crap :)
<cnd> yeah, I see
<cnd> that's quite the stress test :)
<cnd> Sarvatt, do you think we should lower the priority of that bug?
<cnd> I guess it's a normal configuration though...
<Sarvatt> cnd: done
<Sarvatt> yeah its specific to this model macbook air with the non default lid close change from what i can see
<cnd> Sarvatt, a full stack trace with symbols would help too
<cnd> even better if synaptics and the server are built with noopt
<cnd> but it's still low priority since we really need a fix for the lid closure issue
<cnd> and the bug likely won't show up once that's fixed
<Sarvatt> all the dupes of this one are getting duped to https://bugs.launchpad.net/bugs/933504 which is completely unrelated
<ubottu> Launchpad bug 933504 in xorg-server (Ubuntu Precise) "Xorg crashed with SIGABRT in __libc_message()" [High,Confirmed]
<Sarvatt> hey someone with a macbook pro 5,1 hitting it https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/967286
<ubottu> Launchpad bug 933504 in xorg-server (Ubuntu Precise) "duplicate for #967286 Xorg crashed with SIGABRT in __libc_message()" [High,Confirmed]
<Sarvatt> sucks the retracer is removing good info when it dupes to the unrelated bug
<bryceh> Sarvatt, yeah I hate that
<Sarvatt> uhoh test rebuild going, libxaw is going to fail with new xutils-dev
<Sarvatt> oh cjwatson fixed it already
<bryceh> Sarvatt, it's probably not a huge concern though; looking at the dupes I think we already have independent bug reports for each of those (with better stacktraces)
<bryceh> Sarvatt, as long as I've worked on X I don't recall ever seeing these types of "double free or corruption" bugs.  Certainly never to this volume.  Something has to be screwed up in our stack.
<bryceh> a lot seem to occur in the input layer, and most of those seem to occur in some sort of input deletion
<bryceh> makes me wonder if the 1.12 input code might be freeing memory already freed by the 1.11 side of the server?
<pzanoni> I just love LaunchpadÂ´s feature of posting freedesktop bug comments to launchpad
<cnd> bryceh, hard to say
<cnd> you mentioned there are dupes with good stack traces?
<bryceh> cnd, yes a handful
<bryceh> cnd, want me to sub you to ones that look relevant and have good traces?
<cnd> bryceh, my subscriber folder is a bit large :(
<cnd> if you could just paste a one or two here I can take a look
<bryceh> cnd, alright
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/971182
<ubottu> Error: launchpad bug 971182 not found
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/950162
<ubottu> Launchpad bug 950162 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT: double free or corruption, ErrorF (f=0xc69 <Address 0xc69 out of bounds>) at ../../os/log.c:604" [High,Confirmed]
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/943880
<ubottu> Launchpad bug 943880 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in __libc_message() from XIDestroyDeviceProperty" [High,Confirmed]
<bryceh> cnd, ^^ that one has many dupes
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/933504
<ubottu> Launchpad bug 933504 in xorg-server (Ubuntu Precise) "Xorg crashed with SIGABRT "double free or corruption (out)" from DeleteInputDeviceRequest" [High,Triaged]
<mlankhorst> fun
<cnd> bryceh, do we know if any of these still exist after the fix in -0ubuntu6 (or 7, can't remember)?
<bryceh> cnd, check dates on final comments
<cnd> yeah, I see now
<cnd> odd
<cnd> bryceh, have you seen any good reproduction scenarios
<cnd> running the X server under valgrind would be very enlightening
<bryceh> cnd, no  the ones we had good repro on I sent your way already
<cnd> ok
<bryceh> cnd, here's one that repro's pretty easily and has a good trace, but it's a different bug I think - https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/948587
<ubottu> Launchpad bug 948587 in xorg-server (Ubuntu) "hid-wiimote driver causes Xorg crash in GetPointerEvents" [High,Confirmed]
<cnd> yeah, that looks different
<cnd> I'm going to run X under valgrind here
<cnd> just to see if anything obvious shows up
<cnd> maybe it doesn't crash all the time, but it always attempts to do something bad
<bryceh> sounds good
<bryceh> meanwhile, I'll check if any have not tested against latest and prompt them to do so
<Sarvatt> oh goodie, more SRU paperwork to file https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/968218
<ubottu> Launchpad bug 968218 in xorg-server (Ubuntu) "ssh x11 forwarding precise to oneiric causes glibc malloc(): memory corruption" [High,Incomplete]
<bryceh> Sarvatt, yeah was looking at that last week.  is there a fix identified?
<Sarvatt> yup superm1 says what i put in the ppa fixed it
<bryceh> great
<bryceh> Sarvatt, you going to take care of the sru, or shall I?
<Sarvatt> http://cgit.freedesktop.org/xorg/lib/libXi/commit/?h=libXi-1.4-branch&id=22e9ace88d57803ecda95db7c9355a614db1902a was the fix, i had to extend it to XITouchClass and XITouchValuatorClass because of 1_xi2.1.patch
<Sarvatt> bryceh: I'm completely bugged out for the day here, will do it tomorrow unless you want to get it in
<cnd> bryceh, har har, got a segfault while running under valgrind and disconnecting my magic trackpad :)
<bryceh> cnd, 8-D
<bryceh> Sarvatt, ok, I might have time later today
<cnd> we (I) really need to get the build conflict on libxtst-dev removed from synaptics
<cnd> every time I switch from building synaptics to the x server I have to install/remove it
<cnd> bryceh, when I run Xorg under valgrind, I get a segfault when a device is disconnected, the mtdev has returned an error from attempting to read an event from the event node, and then we try to log the error
<cnd> the actual segfault occurs in this line:
<cnd> sprintf(tmpBuffer, "[%10.3f] ", GetTimeInMillis() / 1000.0);
<cnd> there is nothing wrong with that, AFAICS
<cnd> I fear there's some corruption in SIGIO
<cnd> specifically, when an input event node returns an error from read()
<bryceh> mmm
<bryceh> yeah unless tmpBuffer is an invalid chunk of memory
<cnd> tmpBuffer is: static char tmpBuffer[1024]
<cnd> so it should be fine
<bryceh> hmm yeah
<cnd> I can't see anything that would cause an issue with sigio in mtdev_get though
<cnd> when it errors out, it mainly just returns the error code directly from read()
<bryceh> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/971767 also has a stacktrace passing through GetTimeInMillis()
<ubottu> Error: launchpad bug 971767 not found
<bryceh> although I think the problem would have started from CreateCallbackList() in that one
<cnd> when I remove the error message in synaptics, valgrind no longer gets a segfault
<bryceh>         ar_ptr = <error reading variable ar_ptr (Asked for position 0 of stack, stack only has 0 elements on it.)>
<cnd> but it doesn't complain about anything else either
<bryceh> weird
<cnd> so I can't reproduce the issue
<bryceh> what about an error message without the GetTimInMillis() call in it?
<cnd> I'll try it, but it's really just a red herring
<bryceh> yeah
<bryceh> bug 971767 looks like it might be a bug deeper down than X
<ubottu> Error: Launchpad bug 971767 could not be found
<cnd> bryceh, it doesn't appear to have anything to do with GetTimeInMillis()
<cnd> I replaced it with "0", which is confirmed when I look at the Xorg.log file
<cnd> but it still died
<cnd> so the bug is being hit from within sprintf, where it is given completely valid data
<bryceh> intriguing
<cnd> argh, I wasn't looking closely enough at the backtrace
<bryceh> oh?
<cnd> http://paste.ubuntu.com/912157/
<cnd> I don't think sprintf is signal safe :)
<cnd> it's not listed as being signal safe in man signal (7)
<cnd> so we're calling sprintf
<cnd> then that somehow generates a bad signal
<cnd> so we are now in OsSigHandler printing a backtrace
<cnd> which then itself fails
<bryceh> hmm, grepping for 'signal' in our patches shows only 100_rethrow_signals.patch
<cnd> I'm going to have to leave it for now though
<cnd> more important bugs to work on
<bryceh> can you update the bug report with your findings/theories?
<cnd> I don't have any :(
<cnd> I never saw a bug using valgrind that would give me any idea
<cnd> I just saw the weird bug when it was trying to print a message
<bryceh> cnd, well, that'd be a finding...
<cnd> true
<cnd> bryceh, fwiw, in bug 943880 the stack trace from *after* we fixed the synaptics corruption is from when the server is shutting down
<ubottu> Launchpad bug 943880 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in __libc_message() from XIDestroyDeviceProperty" [High,Confirmed] https://launchpad.net/bugs/943880
<cnd> while it's not cool, it's also not terrible
<bryceh> ok
<bryceh> yeah I figure once apport is turned off a lot of these bugs will "disappear"
#ubuntu-x 2012-04-03
<mornau> hi, i'm having trouble starting X with the radeon driver on oneiric with Sarvatt's x updates: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/972024
<ubottu> Launchpad bug 972024 in xorg (Ubuntu) "RADEONDRIGetVersion failed because of version mismatch (1.17.0 -> 2.10.0)" [Undecided,New]
<mornau> I would appreciate any help you can provide, or hints on how to improve my report 
<lesshaste> hi
<lesshaste> I have had to turn off 3d as the system freezes regularly 
<lesshaste> I get
<lesshaste> [ 1934.458109] [drm] nouveau 0000:01:00.0: fail pre-validate sync
<lesshaste> [ 1934.458114] [drm] nouveau 0000:01:00.0: validate vram_list
<lesshaste> [ 1934.458238] [drm] nouveau 0000:01:00.0: validate: -16
<lesshaste> is this a known problem?
<lesshaste> also seems to be this bug
<lesshaste> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663763
<ubottu> Debian bug 663763 in xserver-xorg-video-nouveau "xserver-xorg-video-nouveau: X server freeze" [Important,Open]
<RAOF> lesshaste: On what chip?
<lesshaste> 01:00.0 VGA compatible controller: nVidia Corporation NV44 [Quadro NVS 285] (rev a1)
<lesshaste> RAOF, does that answer the question?I am not sure how to find out the exact chip
<RAOF> That's enough, yeah.  The other way would be âdmesg | grep nouveau | grep Detectedâ
<RAOF> So, when you asked in #nouveau mumpf suggested that might be fixed by a new libdrm.
<lesshaste> RAOF, well yes but one in the future
<lesshaste> it's a pretty fatal bug
<lesshaste> and 11.10 doesn't have the latest kernel/X
<lesshaste> so I was hoping there might be interim fixes
<RAOF> You can try a newer kernel, but that doesn't look particularly promising.
<lesshaste> RAOF, ok thanks.. so just a newer kernel, not a new X ?
<RAOF> (You can try, for example, the 3.3.1 kernel here http://kernel.ubuntu.com/~kernel-ppa/mainline/ )
<lesshaste> I am not sure where all the parts of nouveau live
<RAOF> Newer X is unlikely to be interesting.
<lesshaste> so the driver is entirely in the kernel?
<RAOF> Much of it is.
<lesshaste> ok
<lesshaste> I vaguely remember this debate :)
<RAOF> 3D lives in mesa, which would be another candidate for update.
<lesshaste> oh well it's definitely  a 3d problem
<lesshaste> it all works fine in 2d
<scientes> epiphany flickers for me
<scientes> im using nvidia
<RAOF> lesshaste: But a lockup is always a kernel bug :)
<scientes> RAOF, :P
<scientes> also, xorg-edgers
<RAOF> scientes: You're using the binary nvidia driver, and edgers?
<scientes> no i am not
<scientes> im using stock precise all over
<scientes> and epiphany is flickering with h264 video
<scientes> i was just participating in the conf on mainline kernel
<bryceh> RAOF, you in?
<scientes> bryceh, he is
<RAOF> Indeed.
<bryceh> RAOF, been poking at those memory corruption bugs this afternoon, think I got a feel for what's going on
<bryceh> RAOF, 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=precise&field.tags_combinator=ALL
<bryceh> that should get the main ones
<bryceh> now, the bugs all have different back traces and seem to occur under a random variety of situations
<bryceh> however they have a few things in common
<bryceh> a ton are going through __libc_message
<bryceh> so, like it could be they're trying to print out an error message, or generate a stacktrace in Xorg.0.log, or even just print out the usual input device spew
<bryceh> they hit malloc_printerr(), then __libc_message, and poomph
<bryceh> so this is characteristic of Ye Olde buffer overflow or other out-of-place memory write
<bryceh> and I'm betting ALL of these bugs are going to be traceable to the same flaw
<RAOF> https://launchpadlibrarian.net/93074590/Stacktrace.txt looks like the initial error is in malloc, and the reason why it's going through __libc_message is that libc is abort()ing.  That would be entirely consistent with memory corruption due to out-of-place writes.
<bryceh> afaict this is not afflicting upstream, so that would suggest it's either the fault of frankenserver, or one of our patches added in precise
<bryceh> (or maybe somehting underneath X, but slangasek didn't think that was likely)
<bryceh> it is *possible* we could narrow things down by finding the earliest one of these reports
<bryceh> if we were able to reliably reproduce it, then we could try iterating through the patches or some such
<bryceh> however while some people are able to get it reliably, there aren't steps identified to reliably reproduce it independently
<Sarvatt> it's going to be the first frankenserver that did it so not much narrowing down, guaranteed :(
<RAOF> Other option is in my barrier patch (again!)
<bryceh> Sarvatt, yeah I'm afraid of that too.  Offhand I think I recall seeing these reports right after we put it in
<bryceh> anyway, I'm EOD so wanted to hand that off to you.  also hoping maybe you're more clever than me and can figure it out from here
<bryceh> now, one bit of good news, it seems that while we have a lot of reports, a large chunk of these occur on shutdown only, so won't be noticeable once we shut off apport
<bryceh> but enough are occurring otherwise, that I think this might be our #1 bug in X for the release
<bryceh> I'm wondering if it might be something as simple as a some struct or memory chunk that changed size between 1.11 and 1.12, but some code is using the wrong size when writing it or freeing it
<bryceh> RAOF, one thing you might try is running valgrind with and without your patch, to see if anything turns up in just a static analysis?
<Sarvatt> from what i saw from every bug i've filed its mostly, sigsegv in X for the actual bug, signal handler called, trying to print a backtrace for that crash, some input closedown "stuff" is going on past that and trying to write to the log at the same time, memory corruption bug duped to doko's even if its unrelated because its looking at the __libc_message abort higher up
<Sarvatt> aka 100_rethrow_signals.patch causing it most likely
<bryceh> yes, some portion of the bugs are double crashes.  Crash, then in the segfault handler it's crashing again when trying to print the crash out
<bryceh> and yes the signal throw in that patch might be partly to blame; it's always been a bit of a  klunker
<RAOF> bryceh: Yeah.
<bryceh> or I should say, we've had to debug it a few times in the past...  we might want to consider disabling that patch for the release, just to mitigate any chance of it contributing to the problem
<bryceh> that'd mean we'd need to have people gather crash dumps manually, but that's nothing new
<lesshaste> RAOF, sorry.. back
<lesshaste> RAOF, it isn't a lock up exactly.. I mean you can ssh in
<lesshaste> RAOF, and the mouse pointer moves :)
<RAOF> lesshaste: Eh, so it's a GPU lockup then.  Still, try a newer kernel.
<lesshaste> RAOF, k
<RAOF> You could also try a Precise livecd; there's a newer mesa on it, but I don't think there's been much work on 3d for the nv4x family.
<lesshaste> RAOF, ok thanks. I still don't understand if mesa can cause a gpu lockup
<RAOF> It can, by submitting an invalid command stream.
<RAOF> The kernel would ideally disallow that, but there's all sorts of fun ways to kill the GPU.
<lesshaste> ah ok
<lesshaste> thanks
<tjaalton> meh, desktop hung during the night, ssh works
 * RAOF suddenly remembers he has a bunch of *tests* that can easily be run under valgrind.
<tjaalton> hmm, turns out that turning the kvm box on really helps in getting to the session.. :P
<RAOF> Heh.
<RAOF> Bah.  That valgrind session has not been very helpful.
<RAOF> Although at least I know that the barrier event overflow code works.
<tjaalton> hmm, should some part of the system save the brightness setting or not?
<mlankhorst> already happens afaict, at least on kde
<tjaalton> oh
<tjaalton> gnome-settings-daemon then :)
<seb128> tjaalton, known feature request, no need to file it
<tjaalton> seb128: ok, it was filed already so I moved it there..
<seb128> tjaalton, well you can guess that such requests got filed several times ;-)
<seb128> like that's one of those coming back regularly
<tjaalton> seb128: ok found the master bug
<seb128> tjaalton, I'm not sure what was the current trend upstream, I think some of the upstream people think it shouldn't be an user thing
<seb128> but rather a system one
<tjaalton> yeah, we probably needs systemd for that ;)
<tjaalton> -s
 * seb128 slaps tjaalton
<seb128> tjaalton, you also need systemd to make you coffee right? ;-)
<tjaalton> seb128: good thing I don't drink that stuff :)
<tjaalton> ah, downgrading freetype to the oneiric version fixed monospace font size issues..
<tjaalton> seb128: ooh, your commit fixed that too :) bug 966654 should be duped to the one you just fixed
<ubottu> Launchpad bug 966654 in freetype (Ubuntu) "Monospace fonts have too much space between glyphs" [Undecided,New] https://launchpad.net/bugs/966654
<seb128> tjaalton, oh, feel free to close it then ;-)
<tjaalton> seb128: sure thing, upgrading now and comparing the terminal size to the one with 2.4.4
<tjaalton> i mailed ubuntu-desktop@ early in the cycle about the regression, but didn't look deeper into what caused the bump in the font size
<seb128> tjaalton, upstream reply seems the old style is wrong
<seb128> tjaalton, upstream just replied to my email
<seb128> "For years, FreeType had this metrics
<seb128> bug, and unfortunately the users got used to the appearance of far too
<seb128> widely spaced lines.  What FreeType now returns is what the font
<seb128> designer has had in mind while designing the font, and what can be
<seb128> found in the font."
<tjaalton> meh
<seb128> tjaalton, well I've no strong opinion on rendering but I want _ to display in gtk when underline markup is set ;-)
<tjaalton> seb128: yeah, my vote is to keep it this way for lts and fight the issues with upstream for q->?
<seb128> tjaalton, that's sort of what my upload and email to upstream just set up for ;-)
<seb128> i.e revert to avoid regression and let them time to deal with it
<tjaalton> yup
<tjaalton> and confirmed that I get the same font as on 11.10, whee
<tjaalton> yup, total horizontal size of the terminals 344 -> 416 characters :):)
<tjaalton> of course now i've used this for months, takes some time to get used to the old again
<RAOF> bryceh: I've got a valgrind log of one of those X crashes in abort().  From which I can determine three things: (1) the Intel driver *still* does a huge bunch of stuff valgrind considers suspicious on initialisation, (2) in this case the crash is triggered by the [mi] EQ overflow message being written, and (3) there seems to be some valgrind-suspicious ioctls in synaptics initialisation, but I didn't have debugging symbols for that.
<RAOF> Given that trigger, and that X under valgrind is hella slow, I should be able to trigger it again with more debugging symbols.  Tomorrow, though âº.
<mornau> ricotz, Sarvatt: could one of you help me with this one by chance? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/972024
<ubottu> Launchpad bug 972024 in xserver-xorg-video-ati (Ubuntu) "RADEONDRIGetVersion failed because of version mismatch (1.17.0 -> 2.10.0)" [Undecided,New]
<Sarvatt> mornau: I just looked into it and apparently ati just needs a rebuild, but the machine i do my uploads from got hosed from the grub update and i'm fixing that so it'll be about an hour until i can upload it
<Sarvatt> ati built against libdrm 2.4.32 when it requires 2.4.33 for KMS support
<tjaalton> that's an edgers bug?
<Sarvatt> so it silently dropped kms support when it built - checking for LIBDRM_RADEON... no
<Sarvatt> tjaalton: yeah edgers bug and argh this iso needs to download faster so i can fix it :)
<Sarvatt> stupid macs using rEFIt that can't boot a liveusb unless they are created a certain way. you have to make the vfat file system on the usb stick directly, it wont boot off a partition
<ricotz> Sarvatt, hmm, which grub update caused this trouble?
<Sarvatt> 20ubuntu1
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/972250
<ubottu> Launchpad bug 972250 in grub2 (Ubuntu) "regression from 4k_sectors.patch: "non-sector-aligned data is found in the core file"" [Critical,In progress]
<ricotz> ah, just wanted to ask if this is gpt related
<Sarvatt> yup it was, silly me left the laptop unplugged last night and got stuck with the screwed up grub install that was full of errors after the upgrade :)
<ricotz> that is bad indeed :\
<ricotz> mornau, the fix is on its way
<mornau> thanks guys, you're great
<mornau> btw. should i have added some tag to the bug report to ensure you get notified? (It's a pity that common tags aren't documented on launchpad)
<ricotz> mornau, i think you could use something like "[xorg-edgers ppa] ..." as bug title
<mornau> alright, i'll try to think of it next time if it turns out it's likely PPA related.
<ricotz> mornau, you probably want to use a newer kernel too to get the kernel-space drm-updates while using edgers
<mornau> I remember there's a PPA for newer kernel builds but i tend to forget its name, and have trouble finding it on a search engine then.
<ricotz> the edgers ppa contains a rebuild of the precise kernel
<ricotz> currently 3.2.0-20.32 (and 3.2.0-21.34 building)
<mornau> "apt-cache search linux-image" doesn't seem to list it on this oneiric amd64 system
<ricotz> https://launchpad.net/~xorg-edgers/+archive/ppa/+sourcepub/2321458/+listing-archive-extra
<mornau> okay, this is not yet built for amd64
<mornau> hmm actually it is, sorry
<mornau> the availability of this updated kernel image might also be a good hint to add to the edgers page on launchpad
<bryceh> RAOF, ah interesting findings.Â If you happen to still be around and can post one of the valgrind logs somewhere, I wouldn't mind perusing it a bit myself.
<Sarvatt> RAOF: building libdrm with valgrind installed should fix most of that
<mornau> so just to report back: linux-image-3.2.0-20.32-generic with libdrm-radeon1 2.4.33+git20120403.43704256-0ubuntu0ricotz~oneiric fixes radeon X output via DRM/DRI.
<mornau> this kernel image looks a little buggy (gives me trouble with apparmor -> libvirtd keeps respawning, and dhcp fails somehow (haven't looked closer into it, yet)) but i guess that's why a newer image is just building now.
<Sarvatt> phew, good thing cairo 1.12 didn't get shoved in at the last second https://lists.debian.org/debian-x/2012/04/msg00076.html
<Sarvatt> exa's all kinds of busted with it
<bryceh> heh
<RAOF> bryceh: http://paste2.org/p/1965772 is the valgrind log.
<RAOF> Sarvatt: Oooh, if I build libdrm with valgrind installed it fixes a bunch of those ioctl warnings?  How?
<RAOF> Also, could we build-depend on valgrind for libdrm âº
<bryceh> RAOF, thanks
<RAOF> This *is* easy to trigger; firing up a unity session under valgrind and thrashing around on the touchpad will overflow the EQ and trigger.  I'll rebuild libdrm to clear *that* noise out and go again.
<Sarvatt> RAOF: http://cgit.freedesktop.org/mesa/drm/log/?qt=grep&q=valgrind
<RAOF> Yeah, found it by updating my libdrm git and grepping.
<bryceh> RAOF, you might also try comparing a valgrind run with patch 100 commented out
<RAOF> I'll give that a whirl.  I *think* what will happen is that it'll die in exactly the same place; the rethrow-signals codepath is only being hit once ErrorF has thrown a SIGSEGV anyway.
#ubuntu-x 2012-04-04
<bryceh> I did a diff between the upstream 1.11 git tree's include/ dir and ours (before applying debian/patches):  http://paste.ubuntu.com/913875/
<bryceh> didn't spot any commonalities with your valgrind output.  mostly it's cnd's touch bits
<cnd> RAOF, valgrind ioctl warnings are either: correct, or they need wrappers to tell valgrind how they really work
<cnd> RAOF, I just added wrappers for the uinput ioctls to the precise valgrind
<cnd> you might be interested in doing the same for drm?
<RAOF> cnd: Apparently upstream already has; in the libdrm sources - we just need to build-depend on valgrind to get those intrinsics added.
<cnd> RAOF, that seems odd
<cnd> the fixes should be in the valgrind sources
<cnd> I suspect libdrm is either really fixing the issues, or just papering over them
<RAOF> Ah, no; what it's doing is using some intrinsics to annotate stuff for valgrind - VALGRIND_MAKE_MEM_DEFINED(bo_gem->gtt_virtual, bo->size) and such.
<RAOF> I think they've *also* fixed an issue or two.
<cnd> RAOF, ahh, that looks like it makes some sense for drm
<cnd> drm is funny in how it uses memory :)
<cnd> RAOF, btw, the ioctl warnings at device init time are red herrings again, I'm fairly certain
<RAOF> Hm.
<cnd> the evdev ioctls probably need wrappers too
<cnd> just like the uinput ones
<cnd> valgrind assumes that all ioctls take an argument, and the argument is a pointer to valid userspace memory
<RAOF> There don't seem to be any suspicious writes, which is annoying.
<cnd> you have to manually tell it if a specific ioctl either: doesn't pass an argument, or passes an argument by value
<RAOF> But, given I can reproduce this easily, I guess it's time to go poking around in the core.
<RAOF> To the bat-gdb!
<cnd> RAOF, what trackpad are you thrashing on?
<RAOF> A synaptics one.
<cnd> RAOF, thrashing with one finger?
<RAOF> Two finger scrolling was the last thing I reproduced it with.
<cnd> RAOF, does xinput list a touch class for your touchpad?
<cnd> hooray! a one-liner in the server fixes compiz touchscreen interactions
<RAOF> cnd: Hm, how do I get xinput to do that?
<cnd> RAOF, xinput list <device name|id>
<RAOF> Hm.
<RAOF> EBADATOM
<RAOF> For some reason that fails.
<cnd> I've started seeing that too...
<cnd> it's next on my list of bugs :)
<cnd> I was hoping it was just me
<RAOF> It reports 8 classes though, from which I think you can work out if there'll be a pair of touch classes or not.
<cnd> RAOF, install utouch-frame-tools
<cnd> then run utouch-frame-test-x11 <window>
<cnd> where window is some window other than the root window
<cnd> it will spit out all devices that have touch classes
<RAOF> Two touches
<RAOF> http://paste2.org/p/1965826
<cnd> ok
<cnd> cool
<cnd> so what you are seeing could be multitouch related
<cnd> once I fix this bug, I'll thrash on my magic trackpad to see if I can cause any misbehavior
<cnd> RAOF, is this on a netbook or something else that is less performant?
<RAOF> Nope, it's on my shiny sandybridge i5
<RAOF> However, it's on my shiny sandybridge i5 while running under valgrind, so you may assume it is significantly non-performant :)
<RAOF> And, as you might note in the valgrind backtrace, the initial SIGSEGV comes from the ErrorF in mieq saying â[mi] EQ overflowingâ
<cnd> RAOF, oh, you're running under valgrind
<cnd> I'm guessing that you are hitting the queue overflow because it's so slow
<cnd> is it crashing?
<RAOF> Yes.
<RAOF> Yeah, that's exactly what's happening.
<RAOF> It's queue overflowing.
<cnd> RAOF, oh, I bet you're hitting the same bug I was seeing yesterday :)
<RAOF> But! It's SEGVing when trying to print the queue overflow.
<cnd> if you hit ErrorF within signal context under valgrind
<cnd> then it will segfault
<cnd> I think sprintf is technically signal unsafe
<RAOF> But only under valgrind?
<cnd> it seems to work when not under valgrind
<cnd> though that may mean that valgrind always crashes, while in real world it only crashes 1/1000 times
<RAOF> Right.
<RAOF> It is indeed not listed as signal safe
<RAOF> This lacks awesome.
<cnd> yeah...
<cnd> I had to stop to look at other things
<cnd> it should probably be brought up on xorg-devel at the very least though
<RAOF> Yes.
<cnd> RAOF, the sprintf is only used to print the timestamp in the X log
<cnd> so we may be able to get away without it, with some manual number printing
<cnd> when I commented the sprintf out, I didn't get the crash anymore
<RAOF> Aha.
<RAOF> Hm.
<RAOF> Practically nothing done in ErrorF is signal-safe.
<RAOF> fwrite: no, memcpy: no, fflush: no.
<RAOF> Oooh, and if you're unlucky it'll try to realloc
<RAOF> vsnprintf: no.
<cnd> fun
<cnd> RAOF, maybe there should be a separate code path for ErrorF if in signal context?
<RAOF> Quite possibly.
<cnd> don't attempt to do anything other than just write directly to the log file
<cnd> actually, maybe a separate function altogether
<RAOF> Yes.
<cnd> and then in ErrorF, merely print "you're dumb" if in signal context
<cnd> :)
<cnd> because ErrorF attempts to print a vararg printf style message
<cnd> which I think may be impossible without reimplementing vsprintf in signal safe code :)
<RAOF> Probably, yes.
<cnd> RAOF, bryceh, Sarvatt: I have a one-liner fix for compiz touchscreen interactions for xorg-server
<cnd> any issues if I upload now?
<RAOF> None from me.
<cnd> fixes bug 972985
<ubottu> Launchpad bug 972985 in xorg-server (Ubuntu) "XQueryPointer does not return button 1 set when touch on touchscreen is active" [High,In progress] https://launchpad.net/bugs/972985
<RAOF> Although what would be much more awesome is to just have a gorram input *thread* and stop futzing around in the SIGIO context.
<cnd> heh
<RAOF> We call *so much* code in that context.
<RAOF> It's scary.
<cnd> yeah
<cnd> it seemed like we were so close too...
<bryceh> cnd, pastebin the patch?
<cnd> bryceh, 505_query_pointer_touchscreen.patch
<cnd> oops
<cnd> http://paste.ubuntu.com/913912/
<cnd> I guess it's technically a two-liner :)
<bryceh> cnd, ok; looking at event_get_corestate this effectively just ORs in mouse->touch->state if defined
<cnd> bryceh, yep
<bryceh> heh, you know what, this might fix an issue that I *just* saw about 3 minutes ago
<bryceh> on my fujitsu touch screen, it responds to touch drag events, but if I just tap with my finger, nothing happens
<cnd> bryceh, really?
<bryceh> cnd, does that sound like this?
<cnd> bryceh, what are you trying to tap?
<cnd> are you trying to raise a window?
<bryceh> yeah, or click buttons on the launcher
<cnd> bryceh, btw, I still have a bug that is locking up the desktop after some touch interactions
<cnd> I was hoping this would fix it for good, but apparently not
<bryceh> drags work
<bryceh> well sort of work.  the initial touch doesn't move the cursor, so you end up dragging offset
<cnd> hmm
<cnd> bryceh, oh, we just pushed up a fix in utouch-grail
<cnd> touchscreens are quite broken without version 3.0.5
<bryceh> ok.  I just updated a couple hours ago
<cnd> without 3.0.5, grail was holding on to touches until they physically ended
<bryceh> ok, I've got 3.0.4 installed, I'll try that
<cnd> that sounds like the issue you are seeing
<bryceh> fwiw, stylus and eraser work fine in gimp
<bryceh> ok
<cnd> good :)
<cnd> so I see that my pointer lockup is a core passive button grab
<cnd> I think there are issues in the compiz stack...
<RAOF> Really?  Heaven forfend!
<RAOF> :)
<cnd> having peeked at their code today, I'm very afraid
<Darxus> Same problems with my Radeon with the upstream kernel.  
<RAOF> Darxus: Sarvatt was saying something about lack of radeon-kms in the -edgers packages earlier, but it's dropped off my backscroll.
<Sarvatt> that was in xorg-edgers
<Sarvatt> (which its not recommended to even use)
<Sarvatt> until mesa 8.1 builds in there, its still going through automake changes breaking it every few days and i cant keep up so its on 8.0 branch
<Sarvatt> which is the same as in precise
<Sarvatt> wayland egl builds have been broken since the beginning of march for out of tree builds aka what the debian packages do
<Sarvatt> every automake commit breaks something new because they always include $(top_srcdir) instead of $(top_builddir)
<Sarvatt> like http://cgit.freedesktop.org/mesa/mesa/commit/?id=ca760181b4420696c7e86aa2951d7203522ad1e8 doing -I$(top_srcdir)/src/mapi ,but that ones fixed already
<Sarvatt> Darxus: i'm going to push libdrm 2.4.33 and newer x-x-v-ati to x-updates tomorrow for precise, might as well be using that and not have screwed up input like you will in xorg-edgers if you're using that :)
<Darxus> Sarvatt: I'm not using xorg-edgers.
<Sarvatt> then again i dont know what problems you really have with radeon, might be assuming too much that you're using edgers because of RAOF :)
<Darxus> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/971204
<ubottu> Launchpad bug 971204 in linux (Ubuntu) "graphics fails with setgfxpayload=keep, AMD Radeon" [Medium,Incomplete]
<RAOF> Darxus: Sorry, I was confusing you with someone else.
<Darxus> No problem.
<Sarvatt> hmm how does grub-gfxpayload-lists have nothing but vmware added in it in precise, i know tjaalton added a bunch of systems to it
<Sarvatt> all the systems added in the natty lists that were SRUed aren't there, hmm
<Sarvatt> tjaalton: any idea whats going on there? surely those should be forward ported to later releases
 * Sarvatt hopes nothing failed certification in 11.10 because it was dropped
<bryceh> cnd, btw even after updating to 3.0.5, the fujitsu touchscreen still misbehavin
<cnd> bryceh, describe what it's doing
<cnd> I still see some issues here
<bryceh> the pointer is at position x,y
<bryceh> you touch at position x+100,y+100
<bryceh> the pointer remains at x,y
<bryceh> you drag your finger from x+100,y+100 to x+150,y+150
<bryceh> the pointer moves from x,y to x+50,y+50 
<cnd> whoa
<cnd> that's weird
<cnd> I've not seen that
<bryceh> actually it's a bit worse
<cnd> bryceh, it sounds like X thinks your touchscreen is a touchpad
<cnd> bryceh, can you pastebin your x log?
<bryceh> there is some scaling going on, so moving by +50/+50 moves pointer say +100/+80
<bryceh> pastebin.ubuntu.com/914024
<cnd> bryceh, it's using the wacom driver
<cnd> I think it thinks your touchscreen is a tablet
<cnd> so its behaving like it's a trackpad for pointing
<bryceh> ah, hum
<cnd> bryceh, I don't know if it's multitouch, but the only way to get the full touch experience would be to use the evdev driver
<bryceh> it is multitouch, but it is a serial interface
<cnd> bryceh, I think that means you have to use set_serial first
<cnd> bdmurray was trying to get it to work
<cnd> I don't know if he made it work out of the box in ubuntu though
<bryceh> set_serial via xinput?
<cnd> no, it's a separate utility
<cnd> bryceh, http://www.murraytwins.com/blog/?p=103
<bryceh> alright, well I'll mess with it more some day.
<cnd> looks like I meant inputattach
<Sarvatt> sucks most all touchscreens are wacom these days :(
<cnd> or ntrig..
<Sarvatt> cnd: xt3 and m6600 were the only ntrigs that ever shipped with ubuntu, everyone else switched to wacom in the past few years :(
<Sarvatt> (since i started tracking it in 2010)
<Sarvatt> x220 tablet, all lenovo W series touchscreens switched to wacom
<Sarvatt> reviews of xt3 were saying it was a negative it still used "ntrig crap"
<cnd> Sarvatt, the dell xps 15 and 17 are still available with it
<cnd> but yeah, I don't blame them
<cnd> I don't know why we can't get an atmel maxtouch touchscreen in an x86 laptop
<tjaalton> Sarvatt: they worked with 3.0, so the quirks were only needed for 11.04
<mornau> hi, i'm trying to get a copy of the linux 3.2.0-21.34 kernel build by/for xorg-edgers: https://launchpad.net/~xorg-edgers/+archive/ppa/+build/3379667
<mornau> but i can't seem to find it in the repository.
<mornau> is it still awaiting an upload?
<ricotz> mornau, it should be available, try run "apt-get update" again
<mornau> ricotz: i did this right before posting but there was no updated package available, yet. it worked this time, though. 
<mornau> btw i'm gettnig this warning when installing the package: W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for module r8169
<mornau> i also got it for the current image (the last 3.2 kernel from the edgers repository), though, and it least for me networking isdoing fine.
<ricotz> right, linux-firmware isnt updated to include the new firmware binaries
<ricotz> Sarvatt, do you think it is safe and worth to put an update linux-firmware package in edgers too?
<mornau> ricotz, Sarvatt: i'm on your linux-image 3.2.0-20.32 now, but DHCP issues remain: "dhclient: Error creating socket to list interfaces; Permission denied." this then results in: "NetworkManager[1520]: <info> (eth0): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]". also the libvirt-bin process keep getting terminated by apparmor and keeps respawning.
<mornau> type=1400 audit(1333548406.883:1402): apparmor="DENIED" operation="create" parent=1 profile="/usr/sbin/libvirtd" pid=31996 comm="libvirtd" family="inet" sock_type="dgram" protocol=0
<mornau> both doesn't happen with the oneiric linux image. i'm happy o file proper bug reports if that's of help. if so, please explain what to file those against.
<ricotz> mornau, please try 3.2.0-21.34 first, note this is a plain rebuild of the current official precise kernel
<ricotz> mornau, so you have a r8169 ethernet device and not having the updated firmware files seems to cause problems?
<mornau> ricotz: sorry i pasted the wrong version there, i'm actually on 3.2.0-21.34 and the above report refers to this version (but also to 3.2.0-21.34)
<mornau> ... but also to 3.2.0-20.32
<ricotz> mornau, could you try https://launchpad.net/ubuntu/+source/linux-firmware/1.78/+build/3380028/+files/linux-firmware_1.78_all.deb
<mornau> i do have a r8169 ethernet device. i would be surprised if this caused dhcp to fail but static ip assignment to work
<mornau> i'm currently using static ip assignment
<mornau> (i also have multiple NICs)
<ricotz> mornau, the newer kernel seems to rely on the newer firmware and this might fix this problem
<mornau> okay, i'll try with the firmware, thanks
<Sarvatt> ricotz: no problems from me putting firmware in there
<Sarvatt> thats really strange he's hitting that though, maybe libvirt's apparmor profile in oneiric doesn't work wth precise's kernel apparmor?
 * Sarvatt has no clue about apparmor really
<ricotz> Sarvatt, ok, -21.34 contains a lot appamor changes/fixes
<ricotz> Sarvatt, i will copy the firmware package to the ppa
<ricotz> Sarvatt, but this is probably a problem for lts-backports of the kernel too
<ricotz> apw, hi ^
<mornau> ricotz: i installed the firmware package you pointed me to, ran "sudo update-initramfs -u -k all", rebooted, to no effect.
<mornau> # dpkg -l linux-firmware\* | grep ^ii ii  linux-firmware                                1.78                                                                         Firmware for Linux kernel drivers
<mornau> hmm silly qwebirc, it eats line wraps. but i guess you know what this output should loook like.
<mornau> i also reinstalled the kernel image and there were no more warnings about possibly missing firmware.
<apw> ricotz, you saying there is a new dependancy between the kernel and firmware in precise?
<apw> ricotz, there won't be a precise lts backport to lucid iirc
<ricotz> mornau, i see, i am not that familiar with libvirt
<ricotz> apw, ok, but i saw a similar issue with the 3.0 backport
<ricotz> apw, .. complaining about missing nouveau firmware files
<apw> ricotz, stupid backports, make life so difficult
<ricotz> apw, so this also effects the oneiric ltsp backport
<ricotz> *lts
<apw> ricotz, could you file a bug against the kernel with the details
<ricotz> apw, yeah, i know, another problem is also not having an updated linux-libc
<mornau> ricotz: it's an issue with its apparmor profile, i guess. i don't need libvirt really so i just purged it. dhclient not working is a bit of a show stopper though. (so unless you want me to look into this more) i guess i'll just downgrade to the oneiric images until precise is released. thanks so far.
<ricotz> mornau, yeah, might be the best to use the oneiric kernel then, sorry for the trouble
 * Sarvatt would just purge apparmor instead :P
<Sarvatt> looking at the apparmor bugs it looks like mismatched apparmor kernel and userspace breaks dhclient all the time though :(
<Sarvatt> same bugs filed in maverick and natty
<ricotz> so much for abi stability ;)
<mornau> :))
 * ricotz is surprisingly happy with 3.4rc1 so far
<Sarvatt> and karmic and jaunty, thats a deep rabbit hole of a problem :)
<mlankhorst> still on 3.2 here :)
<apw> ricotz, linux-libc-dev being 'downrev' is deliberate as in theory at least the interfaces are backwards compatible
<apw> therefore you want to build things for the oldest interface on the machine
<ricotz> apw, hmm, i see, putting the kernel package in xedgers is mostly for this reason to have an updated linux-libc-dev
<apw> ricotz, well in there you may be using newer things which need the newer interfaces for instance
<ricotz> since it is expecting people using xedgers would use a newer kernel too
<apw> ricotz, its all a bit of a mess.  actually we should not really offer a backport kernel, but a backport ppa for each release to contain this crap
<ricotz> yeah, while having libdrm git and kernel git would fit more
<ricotz> apw, having a ppa might lead to more inconsistencies while x-backports are starting next cycle
<apw> ricotz, well i think i mean there needs to be one PPA for each source series destination series, with kernel, mesa, X etc in for that combination
<ricotz> ah, i see
<apw> there is no other safe way to do it imo, anyhow ... fun
<ricotz> i think this should also get stricter tied together
<ricotz> so wanting a newer x should suggest you a newer kernel
<ricotz> (or even force you)
<Sarvatt> ricotz: like having a new pocket for each backport series, and having the kernel be called linux and all of the x packages having the same names too? :P
<ricotz> Sarvatt, yeah, this would be way easier to be maintained
<Sarvatt> we're gonna get so much wrong namespacing all of x/mesa/libdrm the way lts backport kernels do
<apw> Sarvatt, you describe Nirvana
<cnd> bryceh, RAOF: just got a good valgrind trace on X :)
<cnd> oh wait, it might be in the area where I was patching stuff in
<cnd> for debugging :(
<cnd> hmm, I think I found issues though
<cnd> I don't know if people would see them outside of touchscreen cases though
<bryceh> cnd, awesome
<cnd> yeah, the way we look for pointer listeners for direct touch devices is all wrong right now
<cnd> the code is looking at the wrong event masks
<cnd> it's looking at the core event mask, but interpreting it as a pointer to an XI2 event mask
<cnd> so it's all wrong
<bryceh> cnd, is that something due to the mixed server stack, or a legit upstream bug?
<cnd> legit upstream
<cnd> it just hasn't been tested properly, basically
<bryceh> ok
<tjaalton> bryceh: the 'touchscreen is reset to relative mode' is likely a bug in g-s-d or so, since it's happening after login
<tjaalton> bug 949097 was filed earlier
<ubottu> Launchpad bug 949097 in xf86-input-wacom (Ubuntu) "Serial Wacom Tablet touch not in absolute mode when logged in" [Undecided,Incomplete] https://launchpad.net/bugs/949097
<bryceh> friggin gnome
<tjaalton> :)
<bryceh> so yeah, then 973133 would be a dupe of that.  was just looking at that a bit ago
<bryceh> is there a bug against g-s-d yet?
<tjaalton> no, probably would be right to add it to the earlier bug, until it's clear the bug is there
<tjaalton> since the login screen should be running g-s-d as well..
<tjaalton> hmm
<tjaalton> would be easy to test
<tjaalton> by disabling the wacom plugin
<Sarvatt> its not running g-s-d plugins though
<tjaalton> right
<tjaalton> realized that
<tjaalton> actually, the bug might be that the touchscreen isn't actually reported as one by the kernel
<tjaalton> but a tablet
<tjaalton> where relative mode makes sense
<tjaalton> hmm no
<tjaalton> it should be in relative mode in the login screen as well then
<tjaalton> bryceh: so, flip the wacom plugin off, org.gnome.settings-daemon.plugins.gsdwacom:active, and login again
<bryceh> alrighty, is there a utility for turning it off, or a config file?
<tjaalton> dconf-editor, or gsettings
<tjaalton> gsettings set org.gnome.settings-daemon.plugins.gsdwacom active false
<tjaalton> then 'get ... active' to check that it worked
<bryceh> yep, that did the trick
<bryceh> works properly on both login screen and logged in
<tjaalton> whee
<bryceh> stylus and eraser also working
<tjaalton> yeah those should've worked before too
<bryceh> they did, was just checking that they still did ;-)
<tjaalton> hehe, right
<cnd> bryceh, have you seen any bugs where people are attempting to perform a two touch tap on a trackpad and it is generating a middle button click instead of right?
<cnd> olli ries, my manager, is seeing it
<cnd> first, the defaults in X are wrong due to a distro patch from 2009 :)
<cnd> but then gsd should be overwriting the config
<cnd> which is why no one sees the issue
<bryceh> cnd, not that I remember offhand, but I can take a quick scan
<cnd> bryceh, this is the bug olli filed: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/973784
<ubottu> Launchpad bug 973784 in gnome-settings-daemon (Ubuntu) "configuration not set properly" [Undecided,New]
<cnd> it seems like something someone might toss in the X package bugs mistakenly
<bryceh> bug 972125 maybe
<ubottu> Launchpad bug 972125 in xserver-xorg-input-synaptics (Ubuntu) "Right and middle mouse button do not work on clickpad" [Undecided,New] https://launchpad.net/bugs/972125
<bryceh> there's lots of reports of touchpads that just stop working entirely after thus and such
<bryceh> bug 972727
<ubottu> Launchpad bug 972727 in xinput (Ubuntu) "Synaptics Clickpad functionalities incomplete: Right button area, two-tap disabling" [Undecided,New] https://launchpad.net/bugs/972727
<cnd> ok, I got another patch for the xserver today :)
 * cnd knocks down more bugs
<bryceh> :-)
#ubuntu-x 2012-04-05
<tjaalton> right, so g-s-d doesn't distinguish tablets with touch support from touchsreens when it's resetting the touch device to relative mode
<tjaalton> oh gee, one guy wanted nvidia-173 so bad he downgraded X to 11.10
<tjaalton> and posted the instructions on the bug report
<tjaalton> ..
<c10ud> so, this might be slightly OT here but: did anyone try Precise with an AMD APU? i'm considering in upgrading my workstation but i fear fglrx drivers and stuff
<c10ud> btw, hello ;)
<tjaalton> bryceh: pushed g-s-d to my ppa, so once it's built please test :)
<tjaalton> tested that my intuos5 is still in relative mode after update..
<tjaalton> dinner ->
<seb128> tjaalton, still there?
<tjaalton> seb128: on an off
<tjaalton> *and
<seb128> tjaalton, g-s-d, do you want your fix uploaded?
<seb128> tjaalton, I'm about to do an upload
<tjaalton> seb128: well, does it fix things? :)
<seb128> tjaalton, dunno, I will upload http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=d07807ca68e7d3f0b94fdce9bc2a88a71d4324ef
<seb128> tjaalton, which is another touchpad devices issue
<seb128> tjaalton, so I was just wondering if you want extra testing through the archive, we can always revert next week if it's not good
<tjaalton> seb128: ah yeah in that case why not
<seb128> tjaalton, ok, can you push it to the vcs?
<seb128> tjaalton, I will add my patch on top
<tjaalton> i did test that it didn't break touch capable tablet support
<tjaalton> but the touchscreen part is still a mystery, but the logic should be right now
<seb128> tjaalton, ok, let's get extra archive testing during the w.e
<tjaalton> upstream probably would like to add a new class for those, so the condition would be more like (type != SCREEN) or such
<seb128> well until they do your patch might be better than what we have ;-)
<tjaalton> yeah, hope so :)
<seb128> tjaalton, can you push your changes then? ;-)
<tjaalton> seb128: to the bzr branch?
<seb128> tjaalton, yes
<seb128> tjaalton, lp:~ubuntu-desktop/gnome-settings-daemon/ubuntu
<tjaalton> ok let me get off the phone irc then :)
<tjaalton> hmm, can't login to my laptop
<FernandoMiguel> ahahhaha
<tjaalton> last message on lightdm.log is "user foo authorized"
<tjaalton> seb128: ^ ideas? I upgraded it this evening, noticed there was a new lightdm too
<tjaalton> just in time for the long weekend :)
<seb128> tjaalton, no, is there anything special on your pam or login?
<seb128> tjaalton, is there any session process started?
<tjaalton> auth.log looks ok
<tjaalton> no user processes started
<tjaalton> i mean, owned by the user
<tjaalton> greeter.log says auth complete
<bryceh> tjaalton, I've tested your g-s-d
<tjaalton> bryceh: works?
<bryceh> tjaalton, here's what I did
<tjaalton> *bites fingernails*
<bryceh> I re-set the gsettings active property back(?) to true
<Sarvatt> guessing no since its a story :)
<bryceh> then I added your ppa, updated, upgraded
<bryceh> rebooted
<tjaalton> Sarvatt: yeah :)
<bryceh> now, on the *login* screen, it does work great
<bryceh> but after logged in, same behavior
<tjaalton> meh
<bryceh> but
<bryceh> what I'm wondering is that since I set it to true specifically, does that override your changes?
<bryceh> maybe I need to UNset it?
<bryceh> or should it matter?
<tjaalton> bryceh: no it's just the setting for the plugin, use it or not
<tjaalton> true is the default
<bryceh> gnome-settings-daemon:
<bryceh>   Installed: 3.4.0-0ubuntu3.1
<tjaalton> so the plugin does it's own thing, and the relative/absolute for the touch functionality is not configurable by gsettings
<bryceh>  *** 3.4.0-0ubuntu3.1 0
<bryceh>         500 http://ppa.launchpad.net/tjaalton/ppa/ubuntu/ precise/main i386 Packages
<tjaalton> yeah, so it's not complete, bah
<tjaalton> either the logic is all wrong after me looking at it for too long :) or it can't be called from there. compiles fine though and doesn't break my setup
<seb128> tjaalton, ok, so pre-release freeze is in 3 minutes, do you want to commit your stuff or should I upload my patch without it?
<bryceh> tjaalton, I can mess around with the patch locally if you'd like.  get some more data on what's going on, etc...
<tjaalton> seb128: withouth, bryce tested and it's flawed in some way
<seb128> tjaalton, bryceh: we aware of http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=d07807ca68e7d3f0b94fdce9bc2a88a71d4324ef as well
<seb128> we->be
<seb128> not sure if that could impact on what you are testing
<seb128> that's the patch I want to update, but now I'm late, it's freeze time, I shouldn't have waited for tjaalton :p
<tjaalton> what prerelease freeze?
<tjaalton> seb128: sorry :)
<seb128> tjaalton, the one starting at 21utc today
<seb128> i.e now
<seb128> which also suprised me, they were discussing it today on #ubuntu-release, from now one archive should be frozen again and uploads will be approved
<tjaalton> i thought it was next week
<seb128> skaet argued that previous cycle we didn't unfreeze after beta2
<tjaalton> ok then
<seb128> release freeze is next week
<seb128> bug fixes should still be ok meanwhile
<seb128> they just need to be approved
<tjaalton> right
<seb128> not sure there will be lot of approvers during the long w.e though
<tjaalton> guess I should get uploads rolling and not fight with silly sponsors who question my skills to package a source package for debian :)
<tjaalton> and then merge those
<seb128> ;-)
<seb128> tjaalton, btw while you are there
<seb128> tjaalton,  https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/934445/comments/19
<ubottu> Launchpad bug 934445 in gnome-settings-daemon (Ubuntu) "hits g_assert (device->priv->styli) when my Wacom Bamboo 2FG 4x5 is plugged in" [High,Triaged]
<seb128> tjaalton, what do you think about that?
<seb128> tjaalton, it's a workaround until g-s-d learns to not get unhappy on unknown devices but seems it could still be worth to ship with libwacom until then?
<tjaalton> seb128: can't check the details, but there are some fixes in the driver git which might help there
<tjaalton> meh, i'll switch to the desktop so I'll have a browser
<tjaalton> seb128: checking the code
<tjaalton> seb128: yeah, the device-id is the same, so adding the new stylus id should be ok
<tjaalton> adding it to the same data file that is
<seb128> tjaalton, can you do it in the next upload?
<tjaalton> seb128: sure thing
<seb128> tjaalton, thanks
<tjaalton> hmm, I could upload it to debian now, and sync
<bdmurray> bryceh: you said something about a disconnect between where you touch on your screen and the cursor location?  I've noticed the same thing
<tjaalton> I think it's the same with my intuos too
<tjaalton> Sarvatt: so it would cover your n-trig woes as well
<bryceh> bdmurray, yep
<bryceh> bdmurray, doesn't seem to affect the stylus, just touch
<bdmurray> bryceh: yeah same thing with the stylus
<bryceh> bdmurray, you see the same misbehavior with the stylus?  odd, I don't
<bryceh> tjaalton, would it be worthwhile for me to tinker with the patch locally? 
<bdmurray> bryceh: I meant yeah the stylus works for me too
<bryceh> bdmurray, aha
<tjaalton> bryceh: if you have the time then yes. you've seen what it tried to do, so it shouldn't be that hard to fix :)
<bryceh> alright, adding to the todo stack for today
<Sarvatt> tjaalton: WACOM_TYPE_TOUCH is only for actual touchpad capable wacoms
<Sarvatt> aka bamboo touch
<tjaalton> bryceh: the gsd plugin has the logic to check if the device is a screen tablet, so set_absolute should be true for those
<tjaalton> Sarvatt: well that has been proven wrong now? :)
<Sarvatt> ?
<Sarvatt> guess i should read scrollback, i've been looking at g-s-d
<tjaalton> the gsd code touches every device with the touch property
<Sarvatt> yeah which serial wacoms dont have
<Sarvatt> in libwacom
<Sarvatt> unless i missed something
<tjaalton> http://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/wacom/gsd-wacom-manager.c?id=5dd89a267e7c539e681851017b18261dc2e092f0
<tjaalton> this is where it broke
<tjaalton> not libwacom
<Sarvatt> tjaalton: oh they dont have Touch=false in the serial tablet definitions either
<Sarvatt> tjaalton: most everything else has Touch=false if its not usable as a touchpad, serial wacom definitions in libwacom dont
<tjaalton> well I changed that bit to use TRUE, and it turned my intuos to absolute mode, so I figured the condition was wrong
<Sarvatt> ./isdv4-e3.tablet:# this is for the Wacom pen + touchscreen as found in the HP Touchsmart tm2 laptop.
<Sarvatt> bdmurray's laptop is covered by a different set of definitions than generic serial wacom tablets
<tjaalton> let me finish this changelog entry first :)
<Sarvatt> so might explain why he sees different behavior
<Sarvatt> oh nevermind, i'm gonna stop talking without reading the scrollback fully
<tjaalton> bdmurray: so do you have the touch set in relative ("touchpad") or absolute ("pen tablet") mode?
<Sarvatt> hell it'd be better to just revert that commit
<bdmurray> Sarvatt: this is on an x201 tablet
<tjaalton> Sarvatt: no, then all bamboos would be set in absolute mode..
<tjaalton> or would they
<bdmurray> tjaalton: either way I set it the behavior is the same
<Sarvatt> i think there might be more laptops with touchscreens than bamboo tablets
<tjaalton> if only I could login to my laptop I could test it :)
<tjaalton> bdmurray: which is what? :)
<Sarvatt> and they can change it in the gui if they prefer it the other way :P
<tjaalton> Sarvatt: alas, no they can't :) it's not exposed for the touch
<tjaalton> only for the pad
<tjaalton> because of http://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/wacom/gsd-wacom-manager.c?id=389276ef566342c3c61547326c070a0d6914622a
<tjaalton> bdmurray: I mean, is the touchscreen functionality in absolute mode on both the login screen _and_ in the session, or just the login screen
<tjaalton> the latter is what everyone else is seeing
<Sarvatt> ok touch is a weird thing here, some people are referring to it for touchscreens where you want absolute, other people are referring to it for touchpads where you want relative.. you'd only want relative on tablets with a touchpad on them which is a smallllllllll minority of them
<Sarvatt> like the definitions for the touchsmart tm2 have it listed as a touch device
<Sarvatt> when its just the screen
<tjaalton> well the only one complaining about it upstream is a bamboo user/dev
<tjaalton> ie jason gerecke, the wacom dude :)
<bdmurray> tjaalton: ah at the login screen it is 'absolute mode' if that means the cursor follows my finger
<tjaalton> bdmurray: yess, and that's what it should always have
<tjaalton> a lazy person would just reopen gnome bug 670655 and let them know that touchscreens are broken, but why not try to create a patch in the meantime
<ubottu> Gnome bug 670655 in plugins "Wacom 'touch' devices are initialized to absolute mode by default" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=670655
<Sarvatt> bryceh, bdmurray: if you have a moment, can you add Touch=false to the bottom of /usr/share/libwacom/serial-wacf004.tablet and try logging in again?
<tjaalton> that would just disable the touch part?
<bryceh> sure
<Sarvatt> there is no touch part
<tjaalton> huh?
<Sarvatt> its a friggin touch screen not a touchpad
<tjaalton> yes, touch screen with finger + pen touch
<Sarvatt> the touch detection i see in g-s-d is only for wacom touchpads built into tablets to put them in relative mode..
<bryceh> Sarvatt, alright done.  what am I looking for?
<Sarvatt> just if its absolute after logging in
<bryceh> nope, same misbehavior as before
<Sarvatt> ok cool, thanks for checking it wasn't something that easy
<bryceh> that was added to the [Features] section fwiw
<Sarvatt> bryceh: wait, one more? Pad=false ?
<bryceh> okie
<Sarvatt> i'm just thinking maybe its assuming things if its not explicitly defined
<tjaalton> doesn't that only change the configurator?
<Sarvatt> tjaalton: what a headache :)
<bryceh> nope, 
<tjaalton> hmm
<bryceh> btw in that file I see a DeviceMatch for serial:0000:0000
<bryceh> are there pci ids to be checked?
<Sarvatt> nope its serial
<tjaalton> gsd_wacom_device_is_screen_tablet() does seem to ask stuff from libwacom
<tjaalton> so looks like both need an update
<tjaalton> libwacom_is_builtin
<Sarvatt> /usr/share/libwacom/isdv4-e3.tablet is what blows my mind
<Sarvatt> Touch=true for touchscreen, its only wacom for the touchscreen..
<Sarvatt> libwacom is a ton of bug reports waiting to happen
<tjaalton> what do you mean "its only wacom for the touchscreen"?
<Sarvatt> tjaalton: oh wait a second here
<tjaalton> surely isn't, there's Stylus etc there
<Sarvatt> Builtin means it doesn't parse the external files doesnt it..
<Sarvatt> ah nope
<Sarvatt> so maybe you can make g-s-d not apply relative if BuiltIn=true
<Sarvatt> since those are all touchscreens
<Sarvatt> tjaalton: BuiltIn=false + Touch=true is ok for relative, just people using the pad surface with touch as a touchpad
<tjaalton> yes, that's bamboo
<Sarvatt> should be able to use the BuiltIn definition to separate out touchscreens where you'd want absolute from touchpads where you'd want relative
<Sarvatt> ah yea libwacom_is_builtin like you found earlier
<tjaalton> right
<tjaalton> and it should work..
<tjaalton> I mean, libwacom should be ok
<Sarvatt> yeah
<Sarvatt> its already used elsewhere to determine what graphics are shown in the ui
<tjaalton> yep
<Sarvatt> nifty, fedoras actually generating wacom udev rules from libwacom
<Sarvatt> thats a great idea
<tjaalton> yep
<Sarvatt> bryce is going to try http://kernel.ubuntu.com/~sarvatt/wacom-touch-fix.patch out
<tjaalton> alright :)
<bryceh> also got some debuggery folded in with that in case it doesn't work
<bryceh> btw, I see BuiltIn=true in the .tablet file if that matters...
<tjaalton> yes, as should be
<bryceh> bingo sarvatt
<bryceh> http://paste.ubuntu.com/916692/
<bryceh> (gnome-settings-daemon:7808): wacom-plugin-WARNING **: gsd_wacom_device_is_screen_tablet = 0
<bryceh> (gnome-settings-daemon:7808): wacom-plugin-WARNING **: libwacom_is_builtin = 1
<tjaalton> wth?
<Sarvatt> my thoughts exactly...
<Sarvatt> oh
<Sarvatt> gsd_wacom_device_is_screen_tablet
<Sarvatt> that might just check if its assigned to a screen tjaalton
<Sarvatt> since you can bind the tablet to specific screens
<tjaalton> hum, ok
<bryceh> ftr this is the patch I used - http://paste.ubuntu.com/916697/
<tjaalton> Sarvatt: or maybe device->priv->is_screen_tablet isn't initialized yet?
<tjaalton> oh well, I don't care :) bryceh thanks for checking that out!
<tjaalton> btw, downgrading to lightdm 1.1.9 didn't help my laptop
<tjaalton> still can't login to the X session
<tjaalton> the greeter seems stuck
<tjaalton> doesn't bail out
<bryceh> tjaalton, sure thing
<bryceh> so, do we have a pushable patch?
<tjaalton> bryceh: uploaded an update to the ppa
<bryceh> great
<tjaalton> likely so, but I'm not sure if seb pushed something already
<tjaalton> so maybe it's best to let people test the ppa version and upload the fix to the distro after easter
 * bryceh nods
<bryceh> bdmurray, ^^
<bdmurray> what ppa and package?
<tjaalton> ppa:tjaalton/ppa
<tjaalton> gnome-settings-daemon
<tjaalton> 3.4.0-0ubuntu3.2
<tjaalton> takes some time to build
 * bryceh uploads xdiagnose 2.4
<bryceh> I added a script xpci
<bryceh> humber:~/src/xdiagnose/xdiagnose$ xpci
<bryceh> RV770 (1002:9442) xserver-xorg-video-ati
<bryceh> humber:~/src/xdiagnose/xdiagnose$ xpci 10de:0604
<bryceh> G92 (10de:0604) GeForce 9800 GX2 xserver-xorg-video-nouveau,nvidia-graphics-drivers
<bryceh> humber:~/src/xdiagnose/xdiagnose$ grep 'VGA ' /tmp/lspci_vvnn.txt | xargs xpci
<bryceh> gm45 (8086:2a42) cantiga xserver-xorg-video-intel
<bryceh> * skaet not feeling that comfortable about libwacom though....
<tjaalton> bah :)
<Sarvatt> bryceh: the libwacom change is so straight forward it isnt funny, i'm sure it'll pass review :)
<tjaalton> me mentioning the "merge" probably scared her off
<Sarvatt> then again there is this nasty change: +DM-Upload-Allowed: yes
<tjaalton> doesn't affect ubuntu at all
<Sarvatt> yeah was a joke
<tjaalton> hah, ok
#ubuntu-x 2012-04-06
<mlankhorst> noon
<cnd> bryceh, so I'm working on fixing signal-unsafe logging
<cnd> the issue is that I fear it will make quite a bit of logging broken
<cnd> and I haven't seen any logging break the X server so far, but then again it might only show up as memory corruption...
<jcristau> i thought you were only allowed X_NONE in signal context, which didn't add the timeout
<jcristau> maybe i misremember
<jcristau> apparently i do...
<jcristau> s/timeout/timestamp/
<mlankhorst> heya
<cnd> jcristau, what do you mean?
<cnd> I think there's been some misconceptions about what is actually allowed in signal context
<jcristau> cnd: yeah i thought people had been careful about that, and the log was ~ just an fwrite().  guess not.
<cnd> jcristau, even fwrite isn't signal safe
<cnd> you have to use write
<cnd> http://linux.die.net/man/7/signal
<cnd> it has a list of signal safe functions
<jcristau> i guess that can take locks...
<bryceh> cnd, great, let me know how I can help
<cnd> bryceh, the question is: do we want to take the patches
<cnd> that could ultimately make our logging less useful
<cnd> but for which we can be sure there will be no memory or other corruption
<bryceh> cnd, fewer crashes trumps better logging I should think
<cnd> I think so too, I just wanted to get a second opinion
<bryceh> depends on the patch and actual effects of course.  I suspect much of the logging we don't really care about that much, and if we lose something that we do, there's probably more than one way to do it
<bryceh> cnd, the one thing is that I'm wondering why it'd be crashing only now; we haven't seen these types of crashes in natty/oneiric afaict
<cnd> bryceh, yeah, I don't think the logging is the real cause of the crashing
<cnd> but we can't be sure
<cnd> however, the logging does prevent us from running X under valgrind
<cnd> under certain circumstances
 * bryceh nods
<cnd> bryceh, my current task for today is:
<cnd> 1. fix logging
<cnd> 2. run valgrind again to try to resolve bug 974017
<ubottu> Launchpad bug 974017 in unity-2d (Ubuntu) "Crash when touching trackpad with 10 fingers" [Undecided,New] https://launchpad.net/bugs/974017
<cnd> which may be the root cause of some of the memory corruption issues?
<bryceh> hope something turns up!
<cnd> bryceh, is it normal for the archive to be frozen now?
<cnd> I just saw skaet's email on ubuntu-devel
<Sarvatt> cnd: wow, just reproduced it and thats my same bug
<Sarvatt> [ 11090.523] 3: /usr/bin/X (valuator_mask_set_double+0x0) [0x7fa1c508cb00]
<cnd> Sarvatt, yep
<Sarvatt> that happens when the lid is closed here
<bryceh> cnd, they froze it after beta last release too
<cnd> bryceh, ok
<bryceh> cnd, historically no, it's usually been unfrozen.  But they think this will help ensure a higher quality level at release
<cnd> it seems like if they are going to freeze the archive, they should be putting it in the release schedule methinks
<bryceh> cnd, you can still get stuff in, it just takes an extra layer of review and chance getting kicked out
<cnd> yeah
<bryceh> cnd, showing evidence of thorough testing appears to help minimize those chances
<cnd> bryceh, can you review the patch for bug 975356?
<ubottu> Launchpad bug 975356 in xorg-server (Ubuntu) "Logging from signal context is unsafe" [Medium,In progress] https://launchpad.net/bugs/975356
<cnd> the patch is attached
<bryceh> cnd, on it
<bryceh> cnd, did you check that 100_rethrow_signals.patch is not adding unsafe calls?
<cnd> no, I didn't
<bryceh> ok, we'll need to remember to do that.  it might be ok, I don't remember
<cnd> bryceh, it may be easier to review the patches sent to xorg-devel
<cnd> since they are split up into easier to review commits
<bryceh> ok
<cnd> the only difference is the ubuntu patch includes an extra patch from upstream 1.12 that splits out the logging type string to a separate function
<cnd> it backported without issue
<cnd> hmm... well, valgrind now works properly
<cnd> as in, it won't die
<cnd> but I don't get any hits
<cnd> no leads as to what the real bug is when putting lots of touches down
<cnd> bryceh, so now I can't get it to crash anymore
<cnd> which may mean that the logging in signal context was the real culprit all along!
<bryceh> cnd, ok finished reviewing the patches
<bryceh> cnd, well that would be pretty sweet if it's true
<cnd> bryceh, the results of your review is?
<bryceh> yet still I wonder why we didn't see this behavior previously?
<cnd> bryceh, the only two code paths that I know of that log in signal context are touch-specific
<cnd> so they didn't exist before
<bryceh> cnd, +1, I didn't spot anything erroneous, so sent my reviewed-by to the list.  my knowledge of signal code is sketchy though so dunno how useful that is...
<cnd> oh, I didn't check the list
<cnd> bryceh, if you could comment in the bug too, that would be helpful
<bryceh> okie
<cnd> I am going to go take this to #ubuntu-release
<cnd> to get their sign off
<bryceh> cnd, should we get a bit more testing before we push it into the distro?
<cnd> bryceh, how do you propose we do it?
 * bryceh ponders
<bryceh> well, we've got tons of bug reports.  Might be one or two who can reproduce the bug (or a similar bug) pretty easily and have them test it?
<cnd> yeah
<cnd> bryceh, I'll throw it up in a ppa
<bryceh> I suppose the thing we're more concerned about is regressions.  I could just slap it on a couple machines here and just make sure they boot and basically work
<bryceh> but yeah if you can ppa it, I'll scare up some testing
<cnd> k
<cnd> bryceh, I've uploaded to ppa:chasedouglas/jupiter
<bryceh> ok
<bryceh> wow, that built surprisingly fast
<bryceh> wait dah, looking at the wrong one
<bryceh> cnd, hmm bunch of test failures on the build
<cnd> hmm
<cnd> I must admit I had tests turned off
<cnd> I'll enable them and check
<bryceh> PASS: xfree86
<bryceh> /bin/bash: line 5: 14823 Segmentation fault      (core dumped) MALLOC_PERTURB_=15 ${dir}$tst
<bryceh> FAIL: touch
<bryceh> ========================================================================
<bryceh> 1 of 8 tests failed
<bryceh> here's where it started failing:
<bryceh> Testing bytes_to_int32()
<bryceh> Testing pad_to_int32
<bryceh> Unlinking from front.
<bryceh> [mi] Increasing EQ size to 512 to prevent dropped events.
<cnd> it helps having a quad core hyperthreaded behemoth when compiling the x server :)
<bryceh> full output http://paste.ubuntu.com/917885/
<bryceh> hmm, output is out of order there
<bryceh>         config_tests = --disable-unit-tests  ?
<bryceh> can that be set via DEB_BUILD_OPTIONS?
 * bryceh tries 'nocheck'
<cnd> bryceh, it's an issue with the test basically
<cnd> it creates a test device, but doesn't give the device a name
<cnd> so the logging code segfaults when it tries to print the device name
<bryceh> ah
<cnd> I've got a fix and am test building now
<Sarvatt> ricotz: man that took way too long, here's a refreshed pointer barriers patch for newer xserver http://kernel.ubuntu.com/~sarvatt/patches/500_pointer_barrier_thresholds.diff
<Sarvatt> gonna test it out now
 * Sarvatt refreshed an older version of the patch first like an idiot and had to redo it
<Sarvatt> heh go figure, i refreshed it against master not 1.12 branch, have to fix up one hunk
<cnd> bryceh, if this logging is the cause of the corruption, any corruption bugs where we have the X log from the crash should also contain messages from error context, i.e. messages about not finding touches or having to resize the touch array
<Sarvatt> ricotz: thank you so freaking much for refreshing our entire patch stack against the coding style changes :P
<ricotz> Sarvatt, except 190 ;)
<Sarvatt> got it building now to see if i screwed up the barriers patch somewhere
<ricotz> good, let me know if it works
<ricotz> i like to push it to the ppa :P
<bryceh> cnd, ok, so they'd have to involve touch in some fashion
<bryceh> cnd, not sure we have any matchers there but I'll take a deeper look
<bryceh> cnd, the good news is I stuck it on 6 machines and they all still boot at least
<bryceh> unfortunately I did get a SIGABRT on one of them (the serial touchscreen one).  Dunno if it's related though.  Didn't notice the system crash myself, and it hasn't done it again.
<Sarvatt> well in the past few releases only input related crashes were caught by 100_rethrow_signals so it makes sense
<Sarvatt> s/few/5/
<bryceh> ricotz, \o/ !!
<Sarvatt> ricotz: bah /usr/bin/install: failed to extend `/home/sarvatt/source/bzr/xorg-pkg-tools/xorg-server/debian/tmp/main/usr/bin/Xorg': No space left on device
<Sarvatt>  20 minutes into it :P
<bryceh> Sarvatt, do you know why it was only catching the input crashes?
<bryceh> Sarvatt, doh.  SSD?  ;-)
<Sarvatt> bryceh: we had to disable it a bit because it wasn't working in the karmic timeframe, then pitti did some magic to get it working again and after that only input related crashes triggered it, i never could figure out why
<Sarvatt> input and proprietary drivers, let me rephrase that :)
<bryceh> yeah
<Sarvatt> yeah SSD, i run on 2gb free space 99% of the time :)
<bryceh> I certainly remember going through it with pitti.
<bryceh> problem is it's kinda hard to test
<bryceh> we would just send signals to the server.  probably would be better if we deliberately introduced various kinds of faults, and checked that apport caught them
<bryceh> but we've never been short on bugs, and people are willing to run gdb (which gives better backtraces anyway), so hasn't been that high on my todo list
<ricotz> bryceh, ;)
<ricotz> Sarvatt, will testbuild and push it then
<bryceh> plus signal handling code hurts my little brain
<mlankhorst> bryceh: Heheh, no longer the case here somehow :-)
 * ricotz uses pbuilder on tmpfs ;P < Sarvatt 
<Sarvatt> but i like to use a web browser, 4GB isnt even enough for chromium
<ricotz> yeah i am struggling with 8gb here which isnt enough in many cases :\
<mlankhorst> ricotz: Yeah I'm using 16gb atm :x
<Sarvatt> ricotz: it builds, ship it!
<ricotz> Sarvatt, done
<Sarvatt> cnd: Warning: attempting to log data in a signal unsafe manner while in signal context. Please update to check inSignalContext and/or use LogMessageVerbSigSafe(). The offending log format message is:
<Sarvatt> %d: %s (%s+0x%lx) [%p]
<cnd> Sarvatt, right, but backtrace printer is running in signal context...
<cnd> s/but/the/
<cnd> hmmm
<Sarvatt> its awesome its not crashing the server anymore, can finally close my lid :)
<cnd> Sarvatt, is it fixed with the patch I added?
<Sarvatt> [mi] EQ overflow continuing.  %lu events have been dropped.
<Sarvatt> yeah i'm using your newest one http://paste.ubuntu.com/918083/
<cnd> ok
<cnd> Sarvatt, so based on your testing, the printing in a signal-safe manner fixes things?
<cnd> just want to be sure
<Sarvatt> it fixes things but the printing is screwed up and its screwing up the mieqEnqueue printing too
<cnd> yeah
<Sarvatt> thats me 10 finger + puppy paw pressing on the touchpad repeatedly in the log
<Sarvatt> (canonical-tech email humor)
<cnd> heh
<Sarvatt> going to dupe all the bugs related to the crash i have on lid close on macs to the 10 finger one, its the same darn thing
<cnd> yay
<Sarvatt> bryceh: if you see [291943.052] 3: /usr/bin/X (valuator_mask_set_double+0x0) [0x7fea24624ab0] in any crash logs its a dupe of 974017
<Sarvatt> macs are wigging out sending input events constantly from the lid when its closed
<Sarvatt> there were a few duped to doko's bug
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/933504 going through those now
<ubottu> Launchpad bug 933504 in xorg-server (Ubuntu Precise) "Xorg crashed with SIGABRT in __libc_message "double free or corruption (out)" from DeleteInputDeviceRequest" [High,Triaged]
<Sarvatt> cnd: is it known xinput testxi2 stopped working on macs in the past 2 weeks or so?
<Sarvatt> BadAtom xerrors
<cnd> Sarvatt, I know of it :)
<cnd> haven't had a chance to look at it
<Sarvatt> tried git xinput but no go, this was working a few weeks ago when i used it to see that input crap was happening from the lid
<cnd> yeah
<cnd> I don't have any idea what might have changed
<Sarvatt> something in x-x-i-synaptics no doubt
<cnd> might be
<Sarvatt> i'll bisect that
<Sarvatt> cnd: surprised you didn't think it would be good to enable the right button area even if it didn't apply to macs :P
<Sarvatt> it was just mac people complaining
<cnd> Sarvatt, I think it would be good
<cnd> but it was a feature that came really late in the cycle
<cnd> if we had another RC or beta release I would have pushed for it
<cnd> and I certainly won't stand in the way if people who are interested want to raise it with the release team
<cnd> I just didn't feel I had the justification to enable it myself
<Sarvatt> i would have totally done it no questions asked, it only affects non apple clickpads which all do need it
<Sarvatt> but yeah too late now with the freeze :(
<bryceh> Sarvatt, ok thanks, valuator_mask_set_double sounds familiar
<cnd> Sarvatt, hmm... olli ries has managed to crash X still by drumming on his magic trackpad
<Sarvatt> with your new one?
<cnd> unfortunately, the backtrace in signal context doesn't help :)
<cnd> yeah
<Sarvatt> hmm wth is the touchpad sending e for
<Sarvatt> drumming my finger on the pad its going eeeee in irc
<cnd> Sarvatt, do you have ginn running, by any chance?
 * Sarvatt has 10 finger drumming going on and still hasnt crashed
<Sarvatt> nope
<cnd> dunno then
<Sarvatt> i'm using utouch daily too
<Sarvatt> the e's stopped
<Sarvatt> is he clicking when hes drumming?
<Sarvatt> 4 minues of drumming hasnt crashed anything here on bcm5974
<Sarvatt> cnd: nothing new is getting sent to my Xorg.0.log which is weird
<cnd> Sarvatt, what are you expecting?
<Sarvatt> it stopped at [    34.404] [mi] Increasing EQ size to 512 to prevent dropped events.
<Sarvatt> [    34.404] [mi] EQ processing has resumed after 249 dropped events.
<Sarvatt> [    34.404] [mi] This may be caused my a misbehaving driver monopolizing the server's resources.
<Sarvatt> stopped logging totally
<Sarvatt> that log i pastebinned is still the same, nothing new is getting written to the log
<Sarvatt> 5 minutes of drumming on the touchpad should have sent tons of spam :)
<Sarvatt> yeah i plugged in an external monitor and it didnt log any of the edid probes
<Sarvatt> cnd: ignore me, it did just now, thought i found a bug but nope
<cnd> ok
<Sarvatt> heh then X crashed
<bryceh> %-}
<Sarvatt> it stopped logging input stuff for a good 30 minutes, then plugging in an external and the edid probe writing to the log got it back where 10 fingers on the touchpad would crash it again
<Sarvatt> 10 finger press spams the log like hell with your patches, so i know it stopped logging input related things after that EQ processing message
<cnd> huh
<cnd> I should add an fsync to the logging function
<cnd> maybe that'll fix things
<bryceh> Sarvatt, no dupes for 974017 in xorg or xorg-server with valuator_mask_set_*
<Sarvatt> bryceh: your dupe checker isnt checking for bugs that are already duped to another bug :)
<Sarvatt> every time i filed it it tried to get duped to dokos bug
<bryceh> Sarvatt, hum true
<Sarvatt> has anyone asked doko if he still hits the bug?
<Sarvatt> its eating up other valid bugs
<Sarvatt> i just asked on the bug
<Sarvatt> dont think apport will dupe to closed bugs
<Sarvatt> when apport dupes it removes the useful info so will be good to start fresh if hes not hitting it, his specific bug he was hitting when glibc busted nvidia proprietary drivers
<Sarvatt> which was fixed forever ago
<bryceh> Sarvatt, sounds good
<bryceh> Sarvatt, or we can add a tag to make apport recollect stuff
<Sarvatt> proprietary drivers taking down X, signal handler called, input stack trying to print messages still to the log while its printing the backtrace from the real crash, every bug where input is writing to the log unsafely is getting duped to it
<Sarvatt> bryceh: theres a tag for that?
<bryceh> yep
<bryceh> needs-retrace I think, lemme check
<Sarvatt> i filed a bug, duped to doko's bug and all good logs removed, unduped it, and it automatically duped it yet again so i gave up and filed a new one and changed the info/deleted the core before it got retraced so it could be permenant
<Sarvatt> pain in the butt
<bryceh> nope, it's apport-request-retrace
<bryceh> http://www.piware.de/2011/11/apport-1-90-client-side-duplicate-checking/
<bryceh> $ ./search-attachments xorg-server ThreadStacktrace.txt valuator_mask_set_
<bryceh> 948792 Confirmed Xorg crashed with SIGSEGV in valuator_mask_set_double
<bryceh> 948697 Confirmed [bcm5974] Xorg crashed with SIGSEGV in valuator_mask_set_double()
<bryceh> so, including dupes I only found those two
<bryceh> both already properly duped
<Sarvatt> you knew pinged me about someone who could reproduce it easily and had 2-3 bugs already filed last month
<Sarvatt> think it was a canonical employee so it showed up on the bug radar management pushes
<Sarvatt> google to the rescue, just duped 3 more
<Sarvatt> of course the master bug is filed against unity when its not a unity problem
#ubuntu-x 2012-04-07
<ricotz> MCR, i havent updated all my systems yet, but here on nvidia blob it runs fine
<ricotz> MCR, you can follow that to get a trace of your problem https://wiki.ubuntu.com/X/Backtracing#Backtrace_with_gdb
<ricotz> Sarvatt, hi, xedgers server 1.12.1rc1 problem on intel ^
<MCR> Thx a lot for your help.
 * ricotz hopes it isnt a screwed up patch
<ricotz> jcristau, hi
<ricotz> jcristau, maybe you could take a look at this if you are around http://paste.debian.net/162432/
<ricotz> Sarvatt, MCR, i uploaded a new xserver with a patch which fixed the problem on my intel box
<jcristau> looks like a driver bug to me
<ricotz> jcristau, yeah, but you see the workaround in the first place
<jcristau> i'm not sure what you want me to do about this
<ricotz> which actually needs to be done in the second place too imo
<ricotz> jcristau, i am kind of considering you upstream ;)
<ricotz> but i also wanted an opinion about it
<ricotz> jcristau, this doesnt happen with an older xserver 1.12 checkout though
<jcristau> how about http://paste.debian.net/162433/ instead?
<ricotz> (all other things are the same)
<ricotz> yeah adding the comment makes the problem more clear
<ricotz> not sure about removing the first try though
<ricotz> but i guess it should be the same screen in both cases
<ricotz> jcristau, would be great if you can get this upstream
<jcristau> i won't
<ricotz> ok
<jcristau> if you want it upstream you can test it and send it to xorg-devel
<ricotz> i see
<MCR> ricotz: 8-) thx a lot. will try soonish and report here then. :)
<MCR> ricotz: I hoped to get back from bleeding edge to cutting edge, but there is no update to find in your PPA yet ? Or is it my fault ?
<MCR> ricotz: Oh, I can see the upload on launchpad though: http://ufoai.org/forum/index.php/topic,4540.msg36732.html#msg36732
<MCR> sry wrong link: https://launchpad.net/~xorg-edgers/+archive/ppa/+packages?field.name_filter=&field.status_filter=published&field.series_filter=precise
<MCR> ricotz: Finally it updated. Seems although I was aborting ppa-purge it still removed the xorg-edgers ppa, but without downgrading the packages. So I had to add it again.
<MCR> ricotz: There is still a small unreported problem with the xorg-edgers PPA: If you add it the file contains 3 lines, but the 3rd line consists just of "ain", which then throws an error ofc.
<MCR> ricotz: The PPA user has to manually edit /etc/apt/sources.list.d/xorg-edgers-ppa-precise-list and remove the 3rd line to make it work. This bug happened on Precise repeatedly, maybe it could be fixed also... (but not a big problem for me, just FYI)
 * MCR is rebooting 12.04 now
 * MCR is happy to confirm the xorg-edgers PPA is working again
<MCR> ricotz: Thx a lot for not making me debug X ;)
<ricotz> MCR, ncie to hear it worked, so it seems you got the same problem i found
<ricotz> MCR, your screwed up source.list.d is probably caused by using ppa-purge/add-apt-repo somehow
<ricotz> the ppa itself isnt responsible for that
<MCR> ricotz: Are you sure that not the PPA is causing it ? I had this "ain" problem 3rd line several times...
<MCR> ricotz: That is why I reported it.
<MCR> ricotz: Good to know that you have some Intel gfx machine, too...
<horstle> does anybody know why glxinfo doesnt show the version of the driver under oneiric?
<horstle> +anymore
<Sarvatt> RAOF: hmm nvidia-textire-tools is in the archive now, looks like a green light for libtxc-dxtn0 to me :)
<Sarvatt> and in debian, surprised it was allowed
<Sarvatt> then again --enable-texture-float in mesa is way riskier than s3tc support since that patent is actively enforced
<Sarvatt> wow xbmc uploaded to ubuntu directly too, crazy
<Sarvatt> crazy awesome that is, i just have nightmares about actually looking at the packaging in the ppa version a few years ago
<bjsnider> Sarvatt, what do you think about this: http://pastebin.com/RH7kG2Wf
<bjsnider> it looks like nouveau loads, but vesa does too and takes over
<Sarvatt> bjsnider: nouveau doesn't work without kms
<Sarvatt> you've got nomodeset there
<bjsnider> i see
<bjsnider> this guy says nomodeset is what allows it to boot
#ubuntu-x 2012-04-08
<FernandoMiguel> evening
#ubuntu-x 2013-04-02
<bjsnider> nvidia-current is still at 304 in raring, so are users with modern hardware going to be using that by default?
<bjsnider> i thought the system would upgrade modern stuff to 310
<bjsnider> and leave users with older junk than the geforce 8 on the nvidia-304 package
<mlankhorst> ok, rt priorities are evil..
<Prf_Jakob> btw, do you guys have any bug filed against X, because it failing to start?
<Prf_Jakob> I have a bug here where what it seems like lightdm sometimes fails to start.
<Prf_Jakob> like once every 8ish boots.
<Sarvatt> Prf_Jakob: https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/982889
<ubottu> Launchpad bug 982889 in lightdm (Ubuntu) "X trying to start before plymouth has finished using the drm driver" [Critical,Triaged]
<Prf_Jakob> Sarvatt: is that fix in the wild?
<Prf_Jakob> Sarvatt: I'm using a fully updated 12.10 vm.
<Sarvatt> not yet, still being debated as there are multiple ways to hit it that need different fixes, not fun :(
<Prf_Jakob> okay
<Sarvatt> Prf_Jakob: are you hitting it with hybrid graphics, or booting too fast?
<Prf_Jakob> this is vmwgfx so too fast.
<Prf_Jakob> I dunno about the user tho.
<Sarvatt> Prf_Jakob: if you need a workaround ASAP you can cp /etc/init/lightdm.conf to /etc/init/lightdm.override, and add a sleep 2 or sleep 3 right above the exec lightdm line
<Prf_Jakob> Sarvatt: thanks, I don't think so, just need enough to say not our bug and move on :)
<Prf_Jakob> thanks for the info, I'll see if can't reproduce it tho.
<Prf_Jakob> Sarvatt: I'll try that on my host system which seems to have a similar problem, that I can reproduce every time (regular Radeon SI workstation).
<Prf_Jakob> Sarvatt: yupp that worked for my host system at least, thanks!
 * mdeslaur shakes fist at stupid bug #982889
<ubottu> bug 982889 in lightdm (Ubuntu) "X trying to start before plymouth has finished using the drm driver" [Critical,Triaged] https://launchpad.net/bugs/982889
<Prf_Jakob> < Sarvatt> Prf_Jakob: if you need a workaround ASAP you can cp /etc/init/lightdm.conf to /etc/init/lightdm.override, and add a sleep 2 or sleep 3 right above the exec lightdm line
<Prf_Jakob> mdeslaur: ^ that worked for me.
<mdeslaur> Prf_Jakob: yeah, thanks
<mlankhorst> mdeslaur: does start on started plymouth-splash fix it?
<mdeslaur> mlankhorst: I'll try it a little later
#ubuntu-x 2013-04-03
<RAOF> Hey, cool. UVD support for radeon.
<bjsnider> i don't think any player supports that
<RAOF> bjsnider: UVD isn't the client-facing API, it's the hardware decode engine.
<RAOF> ie: It's now possible for mesa's vdpau support to work on radeon, and use the actual hardware decode engines.
<Dandel> some major patches just landed for radeon hardware w/ mesa. ( I wonder how long it'll be before test packages are made )
<RAOF> xorg-edgers gets updated roughly nightly, so...
<Dandel> RAOF: Yea, well this is a set of patches that modifies the 3.8 kernel
<RAOF> So, you'll need the kernel nightlies from the pseudo-ppa then :)
<Dandel> it involves 10 patches to the kernel and adds UVD support. 
<Dandel> Oh, how would i go about setting that up.
<RAOF> You'd be looking for http://kernel.ubuntu.com/~kernel-ppa/mainline/
<Sarvatt> and mesa hasnt been updated in edgers in over a month, lack of caring on my part :) plus it doesnt package mesa vdpau
<Sarvatt> one more thing to enable that breaks the build every week
<RAOF> Heh
<Sarvatt> mesa doesn't have enough of those already
<RAOF> Got sick of clover, then? âº
<Sarvatt> radeon llvm shader compiler this month
<Dandel> I sort of noticed that.
<Sarvatt> needs a new llvm checkout every few weeks :)
<bjsnider> is mesa vdpau actually getting commits and whatnot?
<Dandel> bjsnider: yes, and a MAJOR one just landed.
<Sarvatt> not really but the build system has enough churn its annoying for fringe compile time options
<RAOF> The build system should have seen the majority of its near-term churn by now though, right?
<Sarvatt> i havent built it in a month, maybe? :)
<Dandel> I dunno about the compile issues, but I think getting a test repo up would be good since the patches are aimed at all cards from amd that have some form of UVD decoder included.
 * Sarvatt will look tomorrow and see about enabling vdpau in the ubuntu+1 branch if nothing critical work related comes along
<bjsnider> haha
<bjsnider> always conditiions
<Dandel> bjsnider: well that's not too bad. Many radeon HD2000 line cards have UVD, and it's guaranteed on radeon hd4000+
<Sarvatt> s/many/all/
<Sarvatt> or is it limited to newer UVD?
<Dandel> No, UVD/UVD2/UVD3
<Dandel> RV610/RS780C - good example of unsupported
<bjsnider> with the libav-mt, i'm not sure any of this is necessary anymore
<Dandel> bjsnider: you'd be surprised
<Dandel> ever try running 1080p on the amd e series?
<bjsnider> you must be joking
<Dandel> No.
<Dandel> i'm dead serious.
<Dandel> that's what is used by many htpc users
<bjsnider> only intel
<bjsnider> hm, strange choice
<Sarvatt> good to finally have a real use for mesa vdpau at least, there have been bugs about enabling it in debian/ubuntu for years :)
<Dandel> AMD C-50 ( found in netbooks ) is a good example... it's a dual core at 1ghz. ( the C-30 is a single core at 1.2ghz )
<Sarvatt> yeah fat lot of good libav-mt will do there
<bjsnider> why not use intel/nvidia hardware?
<bjsnider> too expensive?
<Dandel> Too expensive.
<bjsnider> is there an echo in here?
<Dandel> not an echo. lol... it is that it is too pricy
<Sarvatt> C-50 is more people buying cheap $199 laptops thinking they are actually useful..
<bjsnider> well, i say pay the extra ducats
<Dandel> well for real world, I know that the AMD E-350 is what a lot of htpc's have and that uses a dual core at 1.6ghz
<bjsnider> but nvidia hardware would have worked since 2008
<bjsnider> with vdpau i mean
<Sarvatt> err, "The R6xx and RS780/RS880 chipset generations are currently not supported, but might be added in the future."?
<Sarvatt> whee
<Dandel> Radeon 3000/3100
<Dandel> igp
<Sarvatt> 2-3k and igp excluded yeah, i see what you mean now
<Dandel> Anyways I know of two applications that are going to benefit from this a lot... it'll be flash and xbmc
<Sarvatt> so we need glamor packaged, ddx building with glamor support, new firmware and mesa 9.2, fun stuff for 13.10
<bjsnider> surely not flash
<Sarvatt> flash will use it yeah
<Sarvatt> i was kind of worried about packaging mesa vdpau because things might try to actually use it and fail, like nouveau needs extra firmware too
<Sarvatt> not sure if it gracefully falls back or flat out fails
<bjsnider> adobe has stabilized and enabled gpu acceleration on linux?
<Sarvatt> vdpau only for years actually, yeah
<Sarvatt> dont remember the smurf bug? :)
<bjsnider> i think you are wrong
<bjsnider> it's there, but not stable and not enabled by default
<bjsnider> and if you enable it, you will get an x lockup
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/968647
<ubottu> Launchpad bug 967091 in flashplugin-nonfree (Debian) "duplicate for #968647 Wrong tint in flash when it uses video acceleration" [Undecided,New]
<Dandel> vdpau is enabled by default in flash ( at least with chrome )
<Sarvatt> well https://bugs.launchpad.net/ubuntu/+source/adobe-flashplugin/+bug/967091
<ubottu> Launchpad bug 967091 in flashplugin-nonfree (Debian) "Wrong tint in flash when it uses video acceleration" [Undecided,New]
<bjsnider> Dandel, is that with the internal flash?
<Dandel> it actually is a flash plugin. ( just happens to be that firefox fails to implement the api to use it )
<Sarvatt> vdpau was broken out of the box on nvidia until libvdpau got updated to work around it
<Sarvatt> err flash was broken, used vdpau by default
<bjsnider> i didn't have the red/blue reverse bug, i had the one that took down x
<bjsnider> at the same time as adobe announced they would no longer be developing linux flash
<bjsnider> Dandel, have you got an nvidia card to test that on?
<Dandel> google took that up in chrome, so you get version 11.7.700.141
<Dandel> bjsnider: Yea, but i doubt it'll be any good... 7300gs
<Sarvatt> bjsnider: pretty sure you said you were on 11.04 or 11.10 at the time? it was during the precise dev cycle
<bjsnider> well, google may have fixed it by now, who knows
<Dandel> bjsnider: adobe still maintains flash on mozilla for linux ( security updates only )
<Sarvatt> crappy but i just found out flash 11.2 in the distro doesnt work with amazon prime videos tonight, no more prime videos on linux (they block chrome flash because no drm)
<bjsnider> i know
<Sarvatt> anyway have a good night everyone :)
<Dandel> actually, depending on the ffmpeg setup, lightspark can get accelerated decoding.
<Dandel> ah and gnash too 0o' so it appears a lot of places are ready.
<bjsnider> ffm-what?
<Dandel> bjsnider: i say ffmpeg but it's libav or whatever else is in use.
<mlankhorst> morning
<Dandel> good morning. 
<mlankhorst> wow.. people still use xcompmgr?
<ogra_> with openbox ;)
<seb128> ogra_, is openbox hype or something?
<seb128> ogra_, I learnt yesterday that some french people were working on an openbox ubuntu remix :p
<seb128> ogra_, http://beta.linuxvillage.net/index.php/topic,248.0.html
<ogra_> haha
<seb128> OBUbuntu remox
<seb128> remix
<ogra_> its not hype, but people that find lubuntu to bloated (?!?) seem to like such a setup
<ogra_> i wonder what happened to fluxbuntu 
<seb128> right, I chatted a bit with one of the people working on it and asked about lubuntu
<ogra_> which would be largely the same 
<seb128> it seems lubuntu needs 512M ram to run nowadays
<seb128> they claim they can do better
<seb128> I'm waiting for the remix which claims that 640k is enough :p
<ogra_> hnn, my lubuntu test installs on the ac100 never use more than ~120M
<ogra_> HAHA !
<ogra_> wow ... they want to run in less than 512M but ship all the LibreOffice bits by default ?
<ogra_> and a ton of gnome bits too that will fire up g-s-d and friends in the background once you start them
<ogra_> phew, but at least it will have xsnow ...
 * ogra_ is relived
<seb128> lol
<seb128> ogra_, well, they said that having nothing to run is what let them run libreoffice on the liveCD on a 512M box :p
<seb128> which seems like a selling point for them compared to xubuntu/lubuntu ;-)
<ogra_> well, to me it looks like lubuntu with lxpanel replaced with tint2 ... and shipping LibO instead of goffice
<seb128> yeah, I would just contribute to lubuntu
<ogra_> ++
<seb128> but it's their pet project, if they like it, good for them ;-)
<ogra_> but up to them 
<dholbach> hiya
<dholbach> so... I just had apport come up
<dholbach> and it directed me to https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1099394
<ubottu> Launchpad bug 1099394 in xserver-xorg-video-intel (Ubuntu) "[sandybridge-m-gt2+] GPU lockup IPEHR: 0x0b160001 IPEHR: 0x01000000" [Undecided,Fix released]
<dholbach> which has been closed since 2 months
<mlankhorst> oh fake hang?
<dholbach> I'm not quite sure why I answer all of apport's questions when it directs me to an already closed bug :)
<dholbach> so either it's a different bug, or it's not fixed yet
<seb128> I get regular gpu hangs on intel/raring as well
<tjaalton> apport can dupe the bugs if the two numbers match, but there could be something else going on making it a new bug
<seb128> got one yesterday after docking back my laptop and doing a dnd of xchat between both screens
<dholbach> https://errors.ubuntu.com/ counts 286 times  "xserver-xorg-video-intel [sandybridge-m-gt2] GPU lockup" bugs
<tjaalton> I get a compiz hang when returning to my session, fixed by mesa 9.1 but it's getting late to push it to raring
<dholbach> it directs to https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1159536 which is a duplicate and also fix released
<ubottu> Launchpad bug 1140716 in linux (Ubuntu Quantal) "duplicate for #1159536 [regression] 3.5.0-26-generic and 3.2.0-39-generic GPU hangs on Sandybridge" [Critical,Confirmed]
<seb128> tjaalton, can we backport the patch?
<tjaalton> seb128: which patch?
<tjaalton> the one on the bug above is in -intel, already in raring
<tjaalton> dholbach: Sarvatt duped it :)
<dholbach> I get the feeling that these lockups happen quite often, but that the data can't be forwarded to LP correctly
<dholbach> tjaalton, if it's a dup that's fine with me - it's apparently just not fixed :)
<seb128> tjaalton, the one for your hand when returning to your session fixed by mesa 9.1
<seb128> hand->hang
<tjaalton> ah, not sure yet
<tjaalton> doesn't happen every time, but maybe 1/3
<tjaalton> killing compiz fixes it
<tjaalton> with all the issues it brings
<tjaalton> like global menu not working anymore :)
<tjaalton> the reason why 9.1 is not in raring yet is that blur was broken/slow on newer intels
<tjaalton> it's fixed now..
<seb128> I'm familiar with that compiz lock
<seb128> I get it several time a week when coming back from guest session :p
<tjaalton> yeah
<tjaalton> the same
<seb128> tjaalton, one way to avoid the menus, etc not working is to sig11 compiz and go back to your session
<seb128> if gnome-session respawns it for you, you win ;-)
<seb128> the env is the same and menus, etc keep working
<tjaalton> ah, cool
<bjsnider> good thing i don't run compiz
<sforshee> I'm trying to figure out what interface into the kernel is used when userspace wants to power off a display. Can anyone here tell me?
<agrestringere> does anyone know the status of the recent CVE and Nvidia drivers 304.88 and 310.44?
<agrestringere> http://nvidia.custhelp.com/app/answers/detail/a_id/3290
<tjaalton> being worked on
<agrestringere> okay, so I don't need to file a bug?
<agrestringere> Thank you for the information, have a good one...
#ubuntu-x 2013-04-04
<ogra_> Fatal server error:
<ogra_> [    62.328] Inconsistent depth 24 pixmap format.  Exiting
<ogra_> that seems to happen on all arm test installs for beta2 ... did anything in xorg change recently that makes 24bit being considered bad ?
<tjaalton_> doubt it
<ogra_> tjaalton, well, the point is that neither the kernel, nor the binary driver nor the xorg driver changed on the pandaboard ... its all just a copy from quantal (not even recompiled afaik)
<ogra_> so the only part failing can be xorg itself
<seb128> bah, hate you intel driver, compiz frozen again while doing a dnd between screens and I can't restart it
<seb128> "intel_do_flush_locked failed: Input/output error"
<seb128> Apr  4 13:53:06 localhost kernel: [16594.405422] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
<seb128> Apr  4 13:53:06 localhost kernel: [16594.405430] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
 * seb128 reboots
<tjaalton> seb128: maybe try 3.9rc kernel?
<seb128> tjaalton, it's not like I was having the issue every time, I could try those, but even if that works that doesn't me a fix for raring, just a workaround for me
<seb128> or is there a specific fix in there that you are considering asking for backport to the raring kernel?
<tjaalton> seb128: no, but it would give some working baseline to bisect from
<tjaalton> if it's fixed
<seb128> tjaalton, I will try to see if I can easily reproduce and then test the new kernel if it makes a difference
<seb128> I wonder if that's the same gpu hang that dholbach was asking about yesterday
<seb128> seems quite frequent, I hit an hang a day on raring on my i5 laptop :-(
<tjaalton> that's too bad.. I only get the compiz hang after user-switch on my ivybridge desktop
<tjaalton> "only"
<tjaalton> seb128: hey, you could test new mesa too :) https://launchpad.net/~ubuntu-x-swat/+archive/x-staging
<tjaalton> there's a ffe for it
<tjaalton> so it's not completely crackful
<seb128> do you have a dual screen setup? ;-)
<tjaalton> no
<tjaalton> it makes a difference I bet
<seb128> k, no luck then
<seb128> well, the hang I just hit seems to happen when dnd between the 2 screens
<tjaalton> 3.9 got some pageflip rewrite so it might help
<seb128> I hit it several times this way this week
<tjaalton> hmm, wonder if it was you or someone else who said the same
<tjaalton> isn't the dpi hardcoded to 96 somewhere?
<seb128> tjaalton, in GNOME?
<tjaalton> yes
<tjaalton> i think
<seb128> yes, it is
<seb128> why?
<tjaalton> bug 1164379
<ubottu> bug 1164379 in xorg (Ubuntu) "DPI not detected" [Undecided,New] https://launchpad.net/bugs/1164379
<tjaalton> was about to close it as wontfix
<seb128> tjaalton, https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xsettings/gsd-xsettings-manager.c#n67
<tjaalton> thanks
<seb128> yw
<marvin24> tjaalton, mlankhorst: xserver segfaults on some ARM in xf86platformBus.c
<marvin24> the problem is that on my machine, the pci busid is NULL around line 226
<marvin24> and strncmp doesn't like this
<marvin24> this is on raring btw
<marvin24> adding a check in the if expression fixes it for me
<tjaalton> marvin24: bug 1161981
<ubottu> bug 1161981 in xorg-server (Ubuntu) "Boot stalls after Ubuntu Raring desktop ARM (Panda board) install" [High,Confirmed] https://launchpad.net/bugs/1161981
<tjaalton> maybe?
<tjaalton> yeah
<ogra_> hmm, i just had marked that as duplicate 
<ogra_> i thought ...
<marvin24> tjaalton: no, xserver crashes very early
<marvin24> before loading any module
<ogra_> tjaalton, thats not on a panda 
<ogra_> marvin24, thats raring, right ?
<marvin24> http://sprunge.us/hdfT
<marvin24> ogra_: yes
<ogra_> intresting is that it works with a 3.1 kernel 
<ogra_> but not with 3.8
<ogra_> i wonder what changed 
<marvin24> http://paste.ubuntu.com/5677653
<marvin24> ogra_: related to pci
<marvin24> seems pci is detected but no busid
<marvin24> it worked a few weeks ago
<marvin24> I also wonder what changed
<marvin24> (it worked with 3.8 until xserver was upgraded)
<tjaalton> it's the same bug
<ogra_> well, then it is probably the same but manifests differently 
<marvin24> tjaalton: at so different places in the start process?
<ogra_> ah, to slow :)
<tjaalton> marvin24: yes
<marvin24> ah, just read comment #21
<marvin24> so seems you are right
<ogra_> awesome 
<mlankhorst> marvin24: oh on arm we could ignore the platform string, I tried to be careful and require pci, but I guess I messed up
<ogra_> well, there are arm boards with PCI buses
<mlankhorst> my point is that it shouldn't have crashed to begin with
<ogra_> i havent seen one that had a graphics card in there ever, but they exist
<mlankhorst> that's all
<ogra_> ah, yeah
<mlankhorst> and it should be a straightforward fix but im asleep
<mlankhorst> xorg-server only seems to care about busid for pci devices
<mlankhorst> i think
<marvin24> well, busid should be checked against NULL in any case
<mlankhorst> oh it's loading modesetting too?
<marvin24> well, kind of
<marvin24> opentegra
<marvin24> which is modesetting + some stuff
<mlankhorst> I mean from the bug report
<mlankhorst> worst case, I guess it has to determine another way to check if those devices are identical
 * marvin24 is also tired 
<marvin24> I'm off
#ubuntu-x 2013-04-05
<mlankhorst> marvin24: ah.. I forgot to check if drivers used the platform id
<mlankhorst> I thought busid was only used in the xserver
<mlankhorst> I'll determine platform id from sysfs too, should be safe
<marvin24> mlankhorst: yes, opentegra also used busid from xf86_get_platform_device_attrib
<marvin24> but I guess it won't be NULL, because it's not a pci device
<marvin24> mlankhorst: notify me if you have a fix I can test
<mdeslaur> tjaalton: I think precise is going to need a nvidia-settings update too, does that make sense?
<mdeslaur> whoops tab fail
<mdeslaur> tjaalton: sorry, not you
<mdeslaur> tseliot: I think precise is going to need a nvidia-settings update too, does that make sense?
<tjaalton> :)
<tseliot> mdeslaur: ok, I can do that, is this only for nvidia-current-updates?
<mdeslaur> tseliot: I only tested nvidia-current in precise so far, and the nvidia-settings that goes with it doesn't allow me to change resolutions with the 304 driver
<mdeslaur> tseliot: precise's nvidia-settings-updates has a more recent 304.43, so it may work there
<tseliot> mdeslaur: ok, but are you going to upload both nvidia-current and nvidia-current-updates in precise?
<mdeslaur> tseliot: but, would it make sense to push 304.88 of settings everywhere?
<mdeslaur> tseliot: yes, that was my intention
<mdeslaur> tseliot: that's what you prepared for me, no?
<tseliot> mdeslaur: yes, it is entirely your choice though whether to update nvidia-current in Precise or not
<tseliot> mdeslaur: and yes, it's best if nvidia-settings matches the driver version it's supposed to be used with
<mdeslaur> tseliot: I don't think we have much of a choice...do you know if there are any issues in 304.x that 295.x doesn't have?
<mdeslaur> I'm sure we're going to break _some_ people
<tseliot> mdeslaur: I'm not sure but 304 is the only supported legacy branch, whereas the 295 branch was short-lived and is not supported any more
<mdeslaur> It's a damned if we do, damned if we don't scenario
<mdeslaur> does anyone else in here have an opinion on pushing 304.88 to precise as a security update?
<tseliot> mdeslaur: right. It still supports GeForce 6 series (which is pretty old)
<tseliot> mdeslaur: here's the list of supported cards for 295.40: http://it.download.nvidia.com/XFree86/Linux-x86/295.40/README/supportedchips.html
<tjaalton> mdeslaur: +1
<tseliot> and here's the list for 304.88: http://it.download.nvidia.com/XFree86/Linux-x86/304.88/README/supportedchips.html
<mdeslaur> if we push 304.88, do we need to get stuff re-tested on precise? like steam or such? or is everything pretty much better with 304.88?
<tseliot> mdeslaur: well, with Steam, you might really wanna use the experimental driver
<tseliot> mdeslaur: let me package nvidia-settings for you...
<mdeslaur> tseliot: awesome, thanks!
<bjsnider> mdeslaur, i think 304.88 should be pushed
<bjsnider> in fact i didn't know there would be any question of it
<mdeslaur> ok, I feel a lot better being able to blame #ubuntu-x when I get my usual security team death threats email :)
<bjsnider> blame nvidia
<bjsnider> should be pushed further back than precise too
<mdeslaur> oh! yeah, I keep forgetting I can just blame nvidia :)
<bjsnider> i'm just trying to get that done so i don't have to put it in the ppa
<tseliot> :)
<mlankhorst> marvin24: fixed, I think..
<mlankhorst> attached to the bug report
<mlankhorst> oops
<marvin24> mlankhorst: compiling ...
<marvin24> mlankhorst: no change
<marvin24> but removing your patch alltogther works :-(
<mlankhorst> ugh
<mlankhorst> whats the sysfs path?
<mdeslaur> tseliot: so, the issue I was seeing with nvidia-settings on precise is still there, even after upgrading to nvidia-settings 304.88...I can't change screen resolution on my laptop anymore
<mdeslaur> tseliot: all I have is "Auto" and "1680x1050" in the dropdown instead of the list of resolutions that was available with the 295 driver
<mdeslaur> tseliot: any ideas what it could be?
<tseliot> mdeslaur: I wouldn't know. Some failure to read the EDID? I'm not sure
<Sarvatt> mdeslaur: it uses system settings>display now instead of nvidia-settings
<mlankhorst> marvin24: are you sure it should be platform:omapdrm:0 ? I figured it would be platform:omapdrm:00
<mlankhorst> oh duh!
<mdeslaur> Sarvatt: system settings->display only has 1680x1050 in the dropdown also
<mlankhorst> marvin24: remove the \n on the asprintf line
<mlankhorst> that should make the patch work
<marvin24> mlankhorst: I'm on tegra ...
<marvin24> will check
<mlankhorst> that's fine, format should be the same
<mlankhorst> I only tested on x86 by copying that logic into a separate c program anyway, and hardcoded a test string, didn't notice the newline there :P
<Sarvatt> is there any kind of scaling options anywhere in nvidia-settings that might make it show more resolutions?
<mlankhorst> like scaling on a lcd is a good idea anyway....
 * Sarvatt looks over the readme
<marvin24> mlankhorst: nope
<marvin24> on tegra, there is no platorm device related to graphics I guess
<marvin24> why can't we just check if busid is NULL?
<mlankhorst> marvin24: $ udevadm info --query=all --name=/dev/dri/card0 ?
<mlankhorst> on the tegra
<marvin24> mlankhorst: /devices/host1x/drm/card0
<mlankhorst> oh right, I forgot that tegra reinvents the wheel
<marvin24> yes, that may change in the future maybe
<marvin24> should be platfrom/host1x ...
<marvin24> there was a long discussion about this
<mlankhorst> still wouldn't help
<mdeslaur> ah, seems nvidia 302.xx introduced this change: "Removed Flat Panel Scaling configurability in nvidia-settings."...so I guess it's normal when going from 295 to 304
<mlankhorst> where's the tegra git tree?
<marvin24> mlankhorst: mainlined
<mlankhorst> i mean for xf86-video-*tegra
<marvin24> ah
<mlankhorst> oh they're just using busid, sigh
<mlankhorst> marvin24: what's the busid on tegra?
<marvin24> git://gitorious.org/thierryreding/xf86-video-opentegra.git
<marvin24> mmh, no idea
<mlankhorst> blergh I guess I'll fall back if parsing fails
 * mlankhorst grumbls at busid being used to open device, rather than raw fd
<marvin24> mlankhorst: busid:platform:host1x:00
<mlankhorst> exactly what I expected it to be, I guess I'll special case host1x after adding a fallback probe :P
<mlankhorst> marvin24: but yeah, it should be /devices/platform/host1x.0 I suppose..
<marvin24> mlankhorst: you can ask tagr on #tegra why it isn't like this 
<mlankhorst> sigh
<mlankhorst> drmfreebusid takes a const char *
<mlankhorst> marvin24: http://paste.ubuntu.com/5680811/ last attempt for now
<marvin24> mlankhorst: yup - this worked
<marvin24> thanks!
#ubuntu-x 2013-04-06
<mlankhorst> for reference, that version was wrong, pci_str + 4 caused first 4 characters to be random garbage :P
#ubuntu-x 2013-04-07
<Sarvatt> agrestringere: you have a tesla? thats the only thing affected by the security update
#ubuntu-x 2014-03-31
<Mez> Is this the right place to ask about dbus stuf?
<jcristau> probably not
<Mez> Any idea where? (polkitd started by dbus == broken, but if I start it manually it works fine)
<mlankhorst> no idea, this just isn't the right place :-)
<jcristau> Prf_Jakob: fwiw i had to apply http://anonscm.debian.org/gitweb/?p=pkg-xorg/driver/xserver-xorg-video-vmware.git;a=patch;h=5544fe0de73e5144f43cec1896445ef522dda3a7
<Prf_Jakob> jcristau: thanks
<Prf_Jakob> jcristau: can you send that to the ml?
<jcristau> xorg-devel?
<jcristau> will do tomorrow.
#ubuntu-x 2014-04-01
<Prf_Jakob> jcristau: thanks again :)
<jcristau> Prf_Jakob: thanks!
<Prf_Jakob> jcristau: np, did you get a notification from patchwork?
<jcristau> nope
<jcristau> but i'm subscribed to xorg-commit
<Prf_Jakob> ah kay :)
#ubuntu-x 2014-04-02
<tjaalton> mlankhorst: how's the synaptics testing going?
<mlankhorst> it's in a ppa, let me try...
<mlankhorst> nothing bad happened at least when casually using it
<tjaalton> well, whot just found a "massive bug" in the driver
<tjaalton> so maybe wait the next release :)
<mlankhorst> again? :P
<tjaalton> well until tomorrow anyway
<Prf_Jakob> Hey, is it too late to get a patch into mesa? This is for bug 1284134 (we have one quick and dirty patch going and working on a more propper one)
<ubottu> bug 1284134 in xserver-xorg-video-vmware (Ubuntu) "Xorg crash" [High,Confirmed] https://launchpad.net/bugs/1284134
<tjaalton> nah it's fine
<Prf_Jakob> Cool
<tjaalton> there's another crasher too that needs fixing, and then adding bdw support..
<Prf_Jakob> Oh in our driver?
<Prf_Jakob> (the crasher?)
<tjaalton> no, intel
<tjaalton> aka bug 1299499
<ubottu> bug 1299499 in mesa (Ubuntu) "kwin crashes on desktop startup with wobbly windows enabled" [High,Confirmed] https://launchpad.net/bugs/1299499
<tjaalton> glad it's only on gen4
<Prf_Jakob> ah okay
<alkisg> Hi, in 14.04 I see e.g. xserver-xorg-video-all-lts-quantal, xserver-xorg-video-all-lts-raring, xserver-xorg-video-all-lts-saucy...
<alkisg> It would be very very nice if we had -lts-precise too, because that's the last one that supports cards with XAA
<alkisg> Without it, many thousands of clients that use sis, s3virge etc etc won't be able to upgrade to 14.04...
<tjaalton> just fixed -sis
<alkisg> Woww!!! Nice, that was the most significant one.
<tjaalton> besides, those are just dummy pkgs
#ubuntu-x 2014-04-03
<dholbach> hiya
<dholbach> in #ubuntu-touch the upstream for trojitÃ¡ just mentioned the following bugs:
<dholbach> <jkt> dholbach: https://bugs.freedesktop.org/show_bug.cgi?id=68056 , https://bugreports.qt-project.org/browse/QTCREATORBUG-9978 , https://bugreports.qt-project.org/browse/QTBUG-32760
<ubottu> Freedesktop bug 68056 in General "Fails to compile czech(qwerty) keyboard" [Normal,Resolved: fixed]
<dholbach> <jkt> dholbach: tag 0.4.1 is OK, 0.4.0 doesn't contain that fix, unfortunately
<dholbach> that's about libxkbcommon bringing problems on the desktop
<dholbach> mlankhorst, ^ do you know anything about the issue and if we plan to fix it in trusty?
<dholbach> <jkt> dholbach: you might want to ask the Qt guys about that library; my impression is that given it's a pretty new stuff and AFAIK nobody but Qt5 uses it, the old releases might be rather buggy
<dholbach> or tjaalton ^
<mlankhorst> dholbach: being sick cant look today (
<dholbach> mlankhorst, man... all the best - better take some rest!
 * dholbach hugs mlankhorst
<mlankhorst> hugs
<mlankhorst> so why not upload the newer version then :P
<dholbach> well, I'm no an expert
<dholbach> I just tried to bring people in touch about it :)
<mlankhorst> if it's n debian we could sync
<tjaalton> debian has 0.4.0
<tjaalton> we have 0.3.1
<dholbach> 0.4.1 seems to be the one which is good enough
<dholbach> mlankhorst, tjaalton: it looks like we could easily update the package to a newer version (just from a build perspective, etc.) - I just not sure what an impact it would have, if it would solve the bug - so I'd rather defer to some experts
<tjaalton> pushed 0.4.1 to debian git
<dholbach> yeehaw
<tjaalton> adds a new binary though which needs someone to poke through NEW if it's synced
<tjaalton> testing the build now
<tjaalton> builds
<dholbach> thanks a lot tjaalton
<tjaalton> so it needs a sponsor to upload to debian, or I could upload it directly to trusty.. but it would need a FFe
<tjaalton> both cases do
<dholbach> tjaalton, does the upload look generally harmless? or is it something we'd want in trusty?
<tjaalton> well it's been in debian for two months
<tjaalton> 0.4.0 that is
<tjaalton> .1 is a bugfix release
<dholbach> that sounds good then
<tjaalton> so mir depends on it
<tjaalton> I'd rather hear from them before uploading :)
<dholbach> tjaalton, ok... to whom should I send a mail about this?
<popey> kgunn probably?
<tjaalton> well maybe mir-devel to reach them all
<popey> true
<tjaalton> RAOF is zzz right now
<tjaalton> i'll push it to a ppa
<dholbach> fair enough
<tjaalton> will appear here in a bit https://launchpad.net/~tjaalton/+archive/test
<dholbach> mail sent
<dholbach> tjaalton, thanks again
<tjaalton> np
<tjaalton> another option would be to pull that sha, but it's a fairly big one
#ubuntu-x 2014-04-04
<tjaalton> RAOF: did you notice the email from dholbach to mir-devel about libxkbcommon?
<tjaalton> noone has commented yet
<RAOF> Yeah, I haven't quite yet got around to testing it on the device.
<RAOF> Sorry.
<RAOF> It's almost certainly fine.
<tjaalton> i put it on my test ppa
<tjaalton> but you can surely build it too
<RAOF> Indeed.
#ubuntu-x 2014-04-05
<ricotz> mlankhorst, hi :), regarding the mesa-packaging-git, could you merge the mesa/ubuntu changes into mesa/ubuntu+1?
<mlankhorst> sure
<LiamW> hi guys, I recently installed Ubuntu 11.10 from a LiveCD on an iMac with a shot GPU (I used the kernel options "root=0 recovery nomodeset") to boot the LiveCD successfully. Now that I have installed Ubuntu, I can no longer start X (I can assure you that the NVIDIA drivers are installed. nvidia-xconfig does nothing.) I have ssh access to the machine, any help would be appreciated!
<LiamW> here is the output of "cat /var/log/Xorg.0.log": http://paste.ubuntu.com/7208968/
<tomreyn> LiamW: so have you read the "COMMON PROBLEMS section in the README"? also, does it work with nouveau?
<tomreyn> did you do what the channel topic suggests?
<LiamW> tomreyn: turns out it was an issue with the kernel. I installed Ubuntu 13 and now everything seems to work fine, despite that the GPU glitches out over 1280x720
<tomreyn> there's no such thing as "Ubuntu 13"
<LiamW> ... 13.04
<tomreyn> better install a version which is not EOL
<tomreyn> (unless you have no plans to connect to any networks nor connect any external storage.)
<LiamW> http://itsfoss.com/wp-content/uploads/2012/09/Linus-Torvalds-Fuck-You-Nvidia.jpg
#ubuntu-x 2015-03-31
<OEP> Should nvidia-opencl-dev be installable alongside the nvidia-340 (and friends) packages? I'm trying to rule out user error. (https://dpaste.de/ZTsP)
<bandit-led> any ideas on how to get  nvidia  349.12 from edgers to install and load with kernel 4.0rc6?
#ubuntu-x 2015-04-03
<tomreyn> Sarvatt, ricotz: could i convince one of you to look at a 160 MB apitrace trace (a 14 MB .XZ download) using mesa, since it may show a bug on 14.04 with both stock drivers and xorg-edgers?
<tomreyn> across r600 + i915 chipsets
<tomreyn> i mean drivers
<tomreyn> AMD RV730 + Intel GM45 would be the chips
#ubuntu-x 2015-04-04
<tjaalton> tomreyn_: file it upstream
<F_r_e_e_m_a_n> hi all, I have troubles using OpenCL with Nvidia 840M on Linux Mint 17.1. I have proprietary driver installed and running. I am testing according to http://wiki.tiker.net/OpenCLHowTo#Testing . clGetPlatformIDs returns only my Intel CPU. Screenshots https://www.dropbox.com/sh/n5vuph5r6qra8v4/AAA4rLUpPD_BV5Tsd8JGSu9Ea?dl=0 
<lyndel_> hey
<lyndel_> am having a problem after installing ur ppa
<lyndel_> my game on wine is crashing so and purge is not working how to remove it so that i get back the ones that was on the system before i did the update?
<lyndel_> hello
#ubuntu-x 2015-04-05
<furkan> tjaalton: so i figured out how to reproduce that checkerboarding bug... it happens after suspend/resume, and i found yet another symptom of it
<furkan> tjaalton: https://www.dropbox.com/s/7hj8qi3w3qc35jb/IMG_20150405_155434.jpg?dl=0
<furkan> both that and the checkerboarding in the global menu happen _only_ after a suspend/resume cycle
<furkan> and the checkerboarding only happens at the top area of the screen
<furkan> so if you recall that video i shared some time ago... https://www.dropbox.com/s/ez2v03oetppecgx/VID_20150324_020612.mp4?dl=0
<furkan> the checkerboarding only happens for the first few menu entries
<furkan> and similarly, if i launch say a new full-screen firefox window, there is checkerboarding along the top of the screen as the window appears
<furkan> i guess at this point i've got enough info to submit a bug report, so i'll do it
<furkan> here's the report: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1440602
<ubottu> Launchpad bug 1440602 in xorg (Ubuntu) "Graphics corruption after suspend/resume cycle" [Undecided,New]
<furkan> tjaalton: wanna +1 it if you can reproduce with your PC also?
<furkan> and also submitted a second bug... this one's even worse as it results in the system being unusable: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1440606
<ubottu> Launchpad bug 1440606 in xorg (Ubuntu) "Screen garbled after changing display settings" [Undecided,New]
#ubuntu-x 2016-04-04
<furkan> tjaalton: you're running 16.04 + x-staging right?
<furkan> my window shadows are gone for all gtk apps, it seems... i think it happened in a recent update
<furkan> not an update to x-staging
<furkan> but i'm just wondering if it's somehow related to xorg... i guess probably not
<furkan> i just don't see how anybody can push an update with such an obvious bug that's visible within minutes of installing it
#ubuntu-x 2016-04-05
<furkan> tjaalton: are you putting up xorg 1.18.3 soon? :)
<furkan> looks like very few fixes, most of which you've already included https://lists.x.org/archives/xorg-devel/2016-April/049281.html
<furkan> i'm interested in that CPU usage fix " present: Only requeue for next MSC after flip failure"
<tjaalton> furkan: already in the ppa that one
<furkan> ah ok
<tjaalton> i'll upload them to xenial today
<furkan> sometimes my X consumes like 10% CPU just sitting idle doing nothing
<furkan> i'm not sure why, i thought maybe that patch would help
<furkan> but i guess not then
<tjaalton> 1.18.3 in x-staging
<tjaalton> mesa will follow in a bit
<furkan> nice, installing now
<tjaalton> both uploaded to xenial too, not accepted yet
<tjaalton> a message via launchpad: "Thanks for all the hard work you all do.  My systems are running much
<tjaalton> better on the X Staging PPA (with DRI3 enabled), then they have in a
<tjaalton> long time."
<tjaalton> good
#ubuntu-x 2016-04-06
<tjaalton> all the bits are in xenial now, phew
<tjaalton> oh right, mesa still in depwait for libva
<JanC> in het geval van xscreensaver lijkt me dat iedere Debian-gebruiker die weet wat xscreensaver is (en dus geen "gewone" gebruiker) ook wel dat bugs in Debian stable in de Debian bugtracker horen of dat je anders eerst upstream moet testen?
<JanC> is iets anders voor echte eindgebruiker-toepassingen natuurlijk
<soee> http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-364.15-Released
 * mamarley slaps soee around a bit with a large trout.
<mamarley> soee: Actually, the driver doesn't seem to have been uploaded to the FTP site yet, which makes it impossible to get all the files necessary to package it.
<mamarley> tseliot: Also, it looks like they fixed the bug that was causing DRM KMS to break PRIME.  Do you want to enable DRM KMS by default now or leave it off?
<tseliot> mamarley: I would like to test it first. I can do that tomorrow
<mamarley> OK.  I can't even package the driver yet though because the .run files aren't on the FTP server.
<mamarley> Or, maybe I can, if I can get the -no-compat32 from the regular download site.
<mamarley> soee_: I will upload the new driver after I get home from work. :)
<ricotz> mamarley, e.g. "debian/rules get-orig-source" -- http://us.download.nvidia.com/XFree86/Linux-x86_64/364.15/NVIDIA-Linux-x86_64-364.15-no-compat32.run
<mamarley> ricotz: I was already able to grab the files by wgetting what I thought the URL should be.
<ricotz> alright
<soee_> mamarley: ok, thanks :)
<mamarley> soee_: ricotz: 364.15 is up in the normal place. :)
<soee_> mamarley: yes already updated but need will reboot soon, have to finish few things
<soee> mamarley: works fine :)
<mamarley> Yep, works for me too.
<tjaalton> JanC: ik versta het niet
<tjaalton> spreek je Engels?
<JanC> tjaalton: sorry, wrong channel  :)
<tjaalton> ha :)
#ubuntu-x 2016-04-07
<ricotz> mamarley, thanks!, copied
<mamarley> ricotz: Thanks!
<mamarley> tseliot: 364.15 is now ready to test to see if it fixes the DRM KMS PRIME issue for you.  Right now the default is still off.
<ricotz> mamarley, make really sure to use the previous packaging as base
<ricotz> e.g. in 16.04 dkms.conf appeared again
<tseliot> mamarley: ok, thanks, I'll let you know how that goes
<mamarley> ricotz: Yes, I based all the 364.15 packages off of the 364.12 packages that were in the PPA.
<mamarley> I always do it that way.
<ricotz> debian/dkms_nvidia/dkms.conf
<tseliot> mamarley: passing modeset=1 in /etc/modprobe.d/nvidia-graphics-drivers.conf doesn't always seem to work
<mamarley> tseliot: What is the way to check if it is on again?
<tseliot> mamarley: sudo cat /sys/module/nvidia_drm/parameters/modeset
<mamarley> Hmm, yeah, it doesn't seem to be on here either.
<tseliot> shutting down lightdm and rmmodding/modprobing nvidia-drm work
<tseliot> *works
<tseliot> also the bug is fixed
<tseliot> let me check the initramfs
<mamarley> The nvidia-graphics-drivers.conf file is a symlink.  Perhaps that has something to do with it?
<mamarley> I replaced the symlink with a regular file and it seems to work now.
<tseliot> yes, that's the problem
<mamarley> That file is managed with the alternatives system though, so I'm not sure what the real solution would be.
<tseliot> I can customise the hook to copy the actual file
<mamarley> Ah, OK.
<tseliot> mamarley: ok, I have a hook that seems to do exactly what I need
<mamarley> Great!
<mamarley> tseliot: I am going to be either at work or away from a computer pretty much all day, so it would probably be better if you uploaded it.
<tseliot> mamarley: sure, I will
 * tseliot -> lunch
<soee> mamarley: i tested new driver in some games etc. all works fine. Thanks for packaging :)
<mamarley> No problem :)
<tseliot> mamarley: the hook is in place, the file is not a link in the initramfs, yet modesetting is disabled
<mamarley> Argh!
<mamarley> Is it always disabled or does it work sometimes and fail other times?
<ogra_> grrr !!!
<ogra_> did someone just upload livecd-rootfs 
 * ogra_ starts over 
<tseliot> mamarley: not sure
<ogra_> err
<ogra_> echn
<tseliot> ogra_: I doubt complaining in this channel will help :P
<ogra_> haha, yeah 
<mamarley> tseliot: When I replaced nvidia-graphics-drivers.conf with a regular file, it worked on both systems I tried it on the first time.  I needed to leave though so I didn't have time to try again.
<tseliot> mamarley: no, I'm an idiot. I forgot to set modeset=1 when I rebuilt :P
<mamarley> That would do it :p
<tseliot> success
<tseliot> ok, I'm going to upload then
<tseliot> mamarley: actually, I'll do it tomorrow and get rid of the whole grub-gfxpayload thing too, since that shouldn't be needed any more
#ubuntu-x 2016-04-08
<furkan> has anybody noticed this text corruption in LibreOffice? https://www.dropbox.com/s/ypr3q8si3br2kze/libreoffice2.png?dl=0
<furkan> i wonder if it's X-related
<furkan> i'm guessing probably not, but figure it doesn't hurt to ask
<furkan> this is with 16.04
<tjaalton> not here on intel
<alkisg> Hi, I'm trying to use glxgears in order to benchmark various window managers, compiz, metacity, xcompmgr etc.
<alkisg> But in one case I'm getting very weird results: http://paste.ubuntu.com/15682185/
<alkisg> I.e. 472 FPS for one minute, then dang, 572 FPS the next minute
<alkisg> Nothing running on the client, no cron jobs or dmesg or xorg messages etc etc
<alkisg> It's even somewhat reproducible
<alkisg> ...what can possibly boost glxgears to have an additional 100 FPS after 1 minute of it running?!
<alkisg> (intel 855 graphics)
<alkisg> (ubuntu 16.04, plain xinit xterm)
<tjaalton> glxgears is not a benchmark
<alkisg> I've seen everyone saying that, and then offering no alternatives :)
<alkisg> But the numbers I care about are e.g. metacity --no-composite=500 fps, --composite=200 fps
<tjaalton> glmark2?
<alkisg> So it's some indicator. The performance difference in e.g. youtube is visible with the naked eye, I just want some hard numbers to get the developers interested in addressing them
<alkisg> Thanks, let me check that...
<tjaalton> also very good at hanging intel in the past..
<tjaalton> skylake at least
<alkisg> Error: Glmark2 needs OpenGL(ES) version >= 2.0 to run (but version string is: '1.3 Mesa 11.2.0')!
<tjaalton> too bad
 * alkisg will try it with some newer client
<alkisg> But any idea what could cause such a big performance difference in glxgears from one minute to the next, though?
<tjaalton> no
<alkisg> Thanks for the glmark2 hint, tjaalton :)
<tjaalton> sounds like it's running asynchronously, unlike on modern hw where it reports fps ~= vert refresh
<alkisg> I'm running it with vblank_mode=0
<alkisg> Otherwise yeah I'm getting a constant 60 fps
<tjaalton> since you have obsolete hw just benchmark using gtkperf or such
<tjaalton> not that the wm matters there
<alkisg> It appears to matter a whole lot, metacity --composite has 1/3 of the performance of metacity --no-composite
<alkisg> ...in gtkperf, x11perf and glxgears
<alkisg> ...so I'm trying to convince them to put back --no-composite as the default (they changed it in 16.04)
<tjaalton> ok then
<alkisg> https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/1566157
<ubottu> Launchpad bug 1566157 in metacity (Ubuntu) "Metacity's compositing is too slow" [Undecided,New]
<tjaalton> I don't think anyone cares, really :)
<alkisg> Well, it makes the difference of "usable" vs "unusable" in thousands of pcs here... 5 fps in youtube vs 15 is a very big difference
<tjaalton> then change the default there
<alkisg> They replied that --no-composite is unsupported
<alkisg> So I'm evaluating different DEs currently, Mate seems to fare much better...
<alkisg> glmark2 score without wm: 2058, marco --no-composite: 1894, compiz : 1878, metacity --no-composite: 742, marco --composite: 708, metacity --composite: 441
<tseliot> ricotz, mamarley: I've just uploaded 364.15 with KMS enabled, the initrd hook, and without the gfx blacklist. This is for 16.04, 15.10, 14.04
<mamarley> tseliot: Yay, thanks!
<tseliot> :)
 * tseliot -> EOW
<mamarley> Have a good weekend!
#ubuntu-x 2016-04-09
<ricotz> mamarley, hi
<ricotz> mamarley, did you and tseliot tested the last 364 upload?
<darkxst> mamarley, ricotz its probably not the best idea to turn on KMS yet by default
<ricotz> darkxst, at least plymouth and fbtty work ;)
<ricotz> mamarley, I thinking about reverting the last changes of 364
<darkxst> ricotz, mutter still crashing?
<ricotz> darkxst, gpu-manager failing and gdm not starting, so yeah
<darkxst> in cogl_framebuffer_allocate()?
<ricotz> no time to look into that
<darkxst> check the core dump ;0 
<ricotz> but leaving the users with it seems not nice
<darkxst> yeh, it should be tested on all compositors before enabling by default
<darkxst> its not a native KMS implementation, so likely there are going to be more bugs still
<ricotz> 364 is not installed without forcing it and it is still a beta though
<darkxst> wont run at all, is < beta
<ricotz> yeah, that is why I said I am tempted to revert the last changes
<ricotz> since it seems broken besides modeset too
<ricotz> bbl
<mamarley> darkxst: Will it work if you change "options nvidia_364_drm modeset=1" in /etc/modprobe.d/nvidia-graphics-drivers.conf from 1 to 0?
<mamarley> If it does, we can just disable KMS again without un-fixing the initramfs hook or the GRUB payload thing.
<darkxst> mamarley, I can't test right now, but that did work on 364.12
<darkxst> (so far as mutter is concerned)
<darkxst> I will try test it tomorrow and let you know
<mamarley> OK
<darkxst> mamarley, ok so quick test modeset=0 works, but you get plymouth loading on a fb which probably is not supported by nvidia without KMS
<darkxst> so probably best to leave the grub blacklist for now
<darkxst> I mean revert grub stuff
<mamarley> darkxst: Is it an EFI system?  If so, it may be using the EFI framebuffer.
<darkxst> no
<mamarley> What resolution is the framebuffer?  Is it native or just 1024x768 or something?
<darkxst> low res not even 1024x768
<mamarley> Hmm, that's interesting.
<mamarley> I will go ahead and reupload with modesetting turned off again, but if the plymouth framebuffer thing isn't causing you any issues, I would like to wait and ask tseliot about that before I change it.
<darkxst> well not really it just uses the BIOS resolution
<darkxst> mamarley, well it worked, but there was a reason why nvidia was blacklisted for so long ;) 
<mamarley> I think tseliot's reasoning was that all the cards supported by the 364 driver are new enough to not have whatever the original problem was.  That was really before my time though, so I suggest you talk to him about it.
<darkxst> mamarley, ok, just fix the modeset option then
<mamarley> Working on that now. :)
<darkxst> cool
<ricotz> (so much for an friday afternoon upload)
<ricotz> darkxst, do you have problems with gdm besides that?
<darkxst> ricotz, no
<ricotz> e.g. being thrown at tty1 after login with some delay
<darkxst> ricotz, oh yes I get that unrelated to the KMS modeset though
<darkxst> it was happening before 364
<ricotz> darkxst, there is an upstream permission fix
<ricotz> maybe related?
<darkxst> not sure? havent seen it
<darkxst> also we may have pam configuration issues
<darkxst> tho that should only affect passwordless accounts I think
<ricotz> hmm, I see
<mamarley> darkxst: Uploaded. :)
<darkxst> also gnome-control-center crashes here on nouveau
<darkxst> but then I do have a gtx750
<darkxst> mamarley, thanks!
<mamarley> darkxst: Looks like everything is published now.
<darkxst> mamarley, ok, I can't reboot again yet
<mamarley> OK
<darkxst> diff looks fine though, so should be good (though maybe ricotz had further issues?)
#ubuntu-x 2016-04-10
<darkxst> mamarley, things are working ok here with your latest package
<mamarley> Great!
#ubuntu-x 2017-04-05
<jcastro> tseliot: got a sec? our team ran into a nvidia/cuda problem that sounds simple but I wanted to ask you your opinion
<tseliot> jcastro: sure
<jcastro> tseliot: so we're installing the nvidia cuda bits for kubernetes on our nodes, but we're kind of hamfisting it so it's bringing in a ton of ubuntu desktop stuff which obviously fails when trying to install on a server
<jcastro> https://github.com/juju-solutions/layer-nvidia-cuda/blob/master/reactive/cuda.sh
<jcastro> we're not too familiar with packaging, so I think we're just kind of downloading a ton of stuff and splatting it on disk
<jcastro> so the question is, is there a way we can do GPU drivers without dragging in a bunch of desktop bits?
<tseliot> jcastro: what is it exactly that's failing? Seeing the actual error might help me understand things a little better
<jcastro> working on that now
<jcastro> https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/248
<jcastro> so at some point in the dependency chain it brings in parts of unity
<tseliot> jcastro: err... dpkg: error processing package bluez
<tseliot> what does that have to do with nvidia?
<jcastro> right, by trying to install the cuda stuff it starts to bring in parts of the desktop
<jcastro> so it fails because there's no bluetooth on a server
<jcastro> I was hoping you would know how we can do an nvidia driver installation without bringing in all the other stuff, we're already doing a --no-install-recommends
<tseliot> jcastro: how do I reproduce the problem here?
<mbruzek> tseliot: does your laptop have a GPU
<tseliot> mbruzek: I've never seen one without a GPU ;)
<mbruzek> conjure-up --channel candidate kubernetes-core
<mbruzek> You will have to snap install conjure-up --channel beta
<tseliot> error: snap "conjure-up" requires classic or confinement override
<tseliot> (the output of snap install conjure-up --channel beta)
<jcastro> tack a --classic on the command
<tseliot> ok
<jcastro> http://paste.ubuntu.com/24308435/
<jcastro> looks like kos was able to get a full log
<tseliot> BTW things failed here http://pastebin.ubuntu.com/24320717/
<tseliot> jcastro: it is still trying to install both nvidia-prime and nvidia-settings (which are only recommended by nvidia-375) 
<tseliot> jcastro: because this is the command that installs nvidia: apt install -yqq --allow-downgrades --allow-remove-essential --allow-change-held-packages cuda
<tseliot> and there's no mention of not installing recommended dependencies there
<jcastro> aha!
<tseliot> it sounds like an easy fix
<jcastro> \o/ ok we'll try that
<jcastro> I was hoping there was just some cuda_headless magical deb somewhere heh. :)
<tseliot> :)
<mbruzek> tseliot: so on 239 use --no-install-recommends ?
<tseliot> mbruzek: I'm not sure if apt supports that
<mbruzek> changing it to apt-get
<tjaalton> I hope everyone is running zesty by now and upgraded to the shiny new xserver 1.19.3
<alkisg> ...if you backport that to 16.04, we will :P
<tjaalton> later
#ubuntu-x 2017-04-06
<soee> mamarley: packaging new beta driver ? :)
<mamarley> soee: Is the Pope Catholic?  Does a bear crap in the woods?
<mamarley> ;)
<soee> who knows, who knows :D
<ricotz> mamarley, don't bother doing it for precise ;)
<mamarley> It doesn't technically go EOL until April 26.
<ricotz> imo just ignore that
<mamarley> OK
#ubuntu-x 2017-04-07
<amish>  Hi! I need some help here. I have a laptop with intel core i3 + amd radeon r5 m330. I am running ubuntu 16.04. It has xserver-xorg-video-ati installed but I cannot use the amd card for games. It always uses the intel card. steam system info also shows only intel card. Can someone help me?
<mamarley> ricotz: I did get 381.09 uploaded to my staging PPA.
#ubuntu-x 2017-04-08
<mamarley> ricotz: Can I go ahead and copy 381.09 to the main PPA?  I have users bugging me about it.
<ricotz> mamarley, yeah, do it
<mamarley> Done
#ubuntu-x 2018-04-03
<soee> mamarley: you have pcs with Bionic right?
<mamarley> About 5 of them, yes. :)
<soee> mamarley: the nvidia drivers performacne it similar to teh 14.04 or it might be a bit better on 18.04 ?
<mamarley> I do not benchmark the drivers and it has been a very long time since I have used 14.04 on anything, but I have not noticed any performance issues.
<soee> mamarley: also this is true now: http://news.softpedia.com/news/canonical-s-snappy-now-supports-latest-nvidia-drivers-on-ubuntu-18-04-lts-520506.shtml
<soee> ^?
<mamarley> I haven't heard anything about that and I don't use Snappy, so I don't know.  Sorry.
<soee> Ah ok :)
#ubuntu-x 2018-04-04
<ricotz> tseliot, hi :\, the gpu ppa is not a playground
<tseliot> ricotz: oh, no, sorry, I uploaded to the wrong PPA
<tseliot> that was meant for my GLVND ppa
<ricotz> you dropped a bunch of transitionals and the 4.16 compat patch
<tseliot> I used my sources, that's why
<ricotz> tseliot, https://launchpadlibrarian.net/363210244/nvidia-graphics-drivers-390_390.48-0ubuntu0~gpu18.04.1_390.48-0ubuntu1~ppa1.diff.gz
<ricotz> please revert it
<tseliot> ricotz: sure, give me a minute
<ricotz> tseliot, I will do it
<tseliot> I am doing it
<tseliot> ricotz: ^^
<ricotz> tseliot, ok, then do it fast
<tseliot> ricotz: I'll version it 390.48-0ubuntu1+gpu18.04.1, ok?
<ricotz> no
<ricotz> 1~ppa18.04.1
<tseliot> ricotz: ok
<ricotz> or if you don't intend to add a 4.16 then +gpu18.04.1 is better
<tseliot> I'm reverting everything
<tseliot> that upload wasn't meant for that PPA
<ricotz> tseliot, ok, I could have uploaded/reverted it 5 mins ago
<tseliot> ricotz: ok, do it then
<tseliot> having a git repository would make things much easier
<ricotz> pushed
<ricotz> tseliot, this is ppa specific
<ricotz> the 4.16 patch is a hack, the transitionals could be made official, but they would still clutter the packaging
<tseliot> I'm not sure why having a branch for the PPA (and different releases) would be a bad thing
<ricotz> this would not have made a difference in this case
<tseliot> sure it would have. Git revert, update the changelog, upload, done
<ricotz> I will let you known if there is a archive-worthy change
<ricotz> but you would still had it uploaded to the wrong ppa
<tseliot> sure, but it's easier to amend mistakes
<ricotz> tseliot, btw, I used a tweaked version of the old packaging to xenial/artful to update 390 there with it new tarball layout
<tseliot> ricotz: I'm going to rewrite the old packaging anyway, but I'll have a look at that too
<ricotz> tseliot, you still intend the backport the new packaging?
<tseliot> ricotz: yes, partially, though, since we won't have glvnd
<ricotz> oh, so not real backporting to the multiarch'ed package?
<ricotz> right, the gl-alternatives and glvnd are the tricky parts
<tseliot> yep. I haven't quite figured out the details yet though
<ricotz> tseliot, this is basically it -- https://paste.debian.net/plain/1018472
<ricotz> so just the essentials to use the new tarballs
<tseliot> right
<ricotz> tseliot, I assume you are aware of https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic/commit/?h=master-next&id=527d1e11406d4416fe4e0a79ca41a04414f25493
<ricotz> dkms nvidia obviously fails currently due the missing of "scripts/ubuntu-retpoline-extract-one"
<tseliot> ricotz: no, I didn't see that. Yesterday I came back from holidays
<ricotz> ok
<tseliot> ricotz: you said it fails now?
<ricotz> yes, with 4.15.0-14.15, this commit will be included in the next build
<tseliot> apw: ^^
<ricotz> 4.15.0-14.15 is in -proposed
<ricotz> he is aware and this mentioned commit is the fix
<tseliot> oh, ok
<apw> ricotz, yep, we know about that one, it is being applied to places as we speak
<apw> all a bit of a mess
<apw> luckily that kernel is only in -proposed and won't 
<apw> be going anywhere else soon
<tseliot> good
<mamarley> ricotz: The nvidia-390 package you uploaded earlier fails to build with 4.15.0-14 with "/bin/bash: ./debian/scripts/retpoline-extract-one: No such file or directory".
<mamarley> It builds fine against 4.16.0 from the mainline kernel builds.
<ricotz> mamarley, this is kernel package bug
<mamarley> Ah, OK, sorry to bother you.
<ricotz> mamarley, the upload was just to revert an accident
<mamarley> I know, I read that part earlier.
<ricotz> mamarley, ok, this bug was mentioned as well ;)
<mamarley> I guess I didn't read it closely enough them.
#ubuntu-x 2018-04-07
<mamarley> https://nvidia.custhelp.com/app/answers/detail/a_id/4654  Dang, more legacy drivers to support shortly. :(
 * mamarley wishes he had just ordered his newer laptop with the Intel graphics.
<ricotz> mamarley, note the 304 is EOL
<ricotz> so I guess "only" 340, 390 and whatever comes next
#ubuntu-x 2019-04-03
<communicate[m]> Hello, how do I change the behavior (configure which character to be displayed) of SHIFT + "? The setxkbmap command for the layout I am trying to configure is 'setxkbmap -layout us -variant intl', and the layout can be seen here https://i.imgur.com/HYxf51f.png
 * communicate[m] uploaded an image: keyboard-US-International.png (35KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/OoQskiOeqMNXRhRIfTnpnoiG >
