#ubuntu-x 2006-11-06
<Ubugtu> New bug: #70523 in linux-restricted-modules-2.6.17 "ACX111/ACX100 based WLAN Card (DWL-G650+) wont connect to AP with wep key in edgy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/70523
<Ubugtu> New bug: #70546 in xorg-server "X Resolution switch keys no longer work in Edgy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/70546
<Ubugtu> New bug: #70581 in Ubuntu "Consoles locked out and screen show complete garbage." [Undecided,Confirmed]  http://launchpad.net/bugs/70581
<Ubugtu> New bug: #62234 in linux-source-2.6.17 "Knot 3: ATI 9600xt black screen freeze with Desktop CD" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62234
<Ubugtu> New bug: #70609 in xinit "duplicate startup files" [Undecided,Unconfirmed]  http://launchpad.net/bugs/70609
<Ubugtu> New bug: #69340 in acpi "Edgy suspend/hibernate fail (regression worked in Dapper)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/69340
#ubuntu-x 2006-11-07
<Ubugtu> New bug: #67985 in xserver-xorg-driver-i810 (main) "dual monitor setup with xinerama & i810 stopped working in Edgy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67985
<Ubugtu> New bug: #69876 in xorg (main) "ATI radeon 9600 pro broken dri acceleration with fglrx (asking how to integrate the fix to main)" [Undecided,Confirmed]  http://launchpad.net/bugs/69876
<Ubugtu> New bug: #70744 in xorg "With Nvidia Geforce2 MX400, the max. resolution to change is 800x600 at 60 Hz." [Undecided,Unconfirmed]  http://launchpad.net/bugs/70744
<Ubugtu> New bug: #69781 in xserver-xorg-input-synaptics (main) "Touchpad works even if switched off" [Undecided,Unconfirmed]  http://launchpad.net/bugs/69781
#ubuntu-x 2006-11-08
<Ubugtu> New bug: #70764 in xorg "Logitech Keyboard and Mouse (wireless) with evdev protokoll restarts xserver " [Undecided,Unconfirmed]  http://launchpad.net/bugs/70764
<Ubugtu> New bug: #70913 in linux-restricted-modules-2.6.15 "New Processor Option" [Undecided,Unconfirmed]  http://launchpad.net/bugs/70913
<Ubugtu> New bug: #70969 in xserver-xorg-driver-i810 (main) "Crash when try to run OpenOffice using Multihead setting" [Undecided,Unconfirmed]  http://launchpad.net/bugs/70969
#ubuntu-x 2006-11-09
<Ubugtu> New bug: #70995 in xorg (main) "Identifying True Resolutions" [Undecided,Rejected]  http://launchpad.net/bugs/70995
<Ubugtu> New bug: #67178 in Ubuntu "Dell Inspiron 600m: right alt key doesn't work" [Undecided,Confirmed]  http://launchpad.net/bugs/67178
<Ubugtu> New bug: #71070 in xserver-xorg-video-ati "OOwriter does not open "*.pdf" files" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71070
#ubuntu-x 2006-11-10
<Ubugtu> New bug: #71156 in xorg-server "Acceleration fails to work with Dual-Head configuration." [Unknown,Unknown]  http://launchpad.net/bugs/71156
<Ubugtu> New bug: #71167 in xorg (main) "installer and livecd should detect vmware mouse device and use the right driver" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71167
<Ubugtu> New bug: #71138 in xkeyboard-config (main) "Meta is mapped to Win keys, not respected by certain applications" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71138
<Ubugtu> New bug: #71265 in xserver-xorg-video-ati "Radeon Mobility M6: No DRI" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71265
#ubuntu-x 2006-11-11
<Ubugtu> New bug: #71330 in mesa-utils "Just installed latest NVIDIA driver NVIDIA-Linux-x86-1.0-9629-pkg1.run" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71330
<Ubugtu> New bug: #71338 in iceauth "iceauth crashed" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71338
<Ubugtu> New bug: #71364 in xserver-xorg-video-i810 "Google earth very slow on i915" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71364
<Ubugtu> New bug: #71368 in xserver-xorg-video-ati "Laptop backlight stays always on" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71368
<Ubugtu> New bug: #67039 in xorg (main) "unable to detect LG 1520 LCD properly" [Undecided,Needs info]  http://launchpad.net/bugs/67039
<Ubugtu> New bug: #70940 in linux-restricted-modules-2.6.17 (restricted) "Xlib:  extension "GLX" missing on display ":0.0"." [Undecided,Unconfirmed]  http://launchpad.net/bugs/70940
#ubuntu-x 2006-11-12
<Ubugtu> New bug: #71173 in xfonts-core (main) "Xfontsel, xterm etc broken due to bad font directories" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71173
<Ubugtu> New bug: #69326 in xserver-xorg-input-keyboard (main) "Danish keyboard for Apple white USB keyboard AWOL in Edgy final." [Undecided,Unconfirmed]  http://launchpad.net/bugs/69326
<Ubugtu> New bug: #71218 in xorg (main) "Qt: Locales not supported on X server - Ubuntu 6.10 AMD64" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71218
<Ubugtu> New bug: #70963 in xorg (main) "Cannot change resolution after resuming from hibernate" [Undecided,Unconfirmed]  http://launchpad.net/bugs/70963
<Ubugtu> New bug: #70579 in xorg (main) "Random crashes" [Undecided,Unconfirmed]  http://launchpad.net/bugs/70579
<Ubugtu> New bug: #71494 in xserver-xorg-video-unichrome "Conflicts with xserver-xorg-video-via" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71494
#ubuntu-x 2007-11-05
<ubotu> New bug: #160111 in xorg (main) "Ubuntu lacks most drivers for TTX monitors" [Undecided,New] https://launchpad.net/bugs/160111
<ubotu> New bug: #122043 in xkeyboard-config "backslash+pipe key \| misbehaving on english layouts if english not primary" [Undecided,Confirmed] https://launchpad.net/bugs/122043
<ubotu> New bug: #160183 in xorg (main) "please sync from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/160183
<ubotu> New bug: #160225 in xorg (main) "Mice with >5 buttons do no work by default" [Undecided,New] https://launchpad.net/bugs/160225
<ubotu> New bug: #160233 in xorg (main) "ATI Radeon 9200 SE not recognized on Gutsy" [Undecided,New] https://launchpad.net/bugs/160233
<bryce_> heya all
<_bernie> hello
<ubotu> New bug: #160277 in xserver-xorg-video-intel (main) "intel gma3100 hdmi not working properly" [Undecided,New] https://launchpad.net/bugs/160277
<tepsipakki> bryce__: howdy!
<Q-FUNK> well, AMD provided a patch to the -amd driver for the -config option
<Q-FUNK> I added it to the bug
<ubotu> New bug: #160309 in xserver-xorg-video-intel (main) "X crashes when idle" [Undecided,New] https://launchpad.net/bugs/160309
<ubotu> New bug: #160326 in xserver-xorg-video-intel (main) "No video. No crash. Intel driver problem. Vesa driver works." [Undecided,New] https://launchpad.net/bugs/160326
#ubuntu-x 2007-11-06
<ubotu> New bug: #152034 in xserver-xorg-video-ati (main) "font rendering problem" [Undecided,New] https://launchpad.net/bugs/152034
<ubotu> New bug: #160357 in xorg (main) "[Gutsy] System freezes with mouse cursor moving fast on Firefox and Nautilus - ATI Open driver 1.6.7.195" [Undecided,New] https://launchpad.net/bugs/160357
<ubotu> New bug: #160469 in xserver-xorg-video-intel (main) "kdm fonts oversized" [Undecided,New] https://launchpad.net/bugs/160469
<ubotu> New bug: #160535 in linux-restricted-modules-2.6.22 (restricted) "Installing nvidia-glx-new restricted drivers increase gnome login time" [Undecided,New] https://launchpad.net/bugs/160535
<ubotu> New bug: #160575 in xserver-xorg-video-intel (main) "X server crashes when using Xinerama with "intel" driver" [Undecided,New] https://launchpad.net/bugs/160575
<ubotu> New bug: #155026 in ubuntu "totem-xine.when i want to run totem it crash (dup-of: 130696)" [Medium,Incomplete] https://launchpad.net/bugs/155026
<Q-FUNK> re
<ubotu> New bug: #160624 in xserver-xorg-input-synaptics (main) "synaptics driver disregards some xorg.conf settings" [Undecided,New] https://launchpad.net/bugs/160624
#ubuntu-x 2007-11-07
<ubotu> New bug: #55928 in xorg (main) "wrong primary display selected in multihead setup (PCI bus enumeration order)" [Undecided,Confirmed] https://launchpad.net/bugs/55928
<ubotu> New bug: #160657 in linux-restricted-modules-2.6.22 (restricted) "[gutsy] cdromupgrade errors on nvidia-glx" [Undecided,New] https://launchpad.net/bugs/160657
<tepsipakki> Q-FUNK: so the new patch works?
<Q-FUNK> tepsipakki: hard to tell, as my own test environmnet for the thincan is on Etch.
<Q-FUNK> that's why I aksed others to test it.
<tepsipakki> ok
<tepsipakki> I'm amazed how hard it is to find an ltsp-cabable terminal with dvi..
<tepsipakki> hey bryce__ 
<tepsipakki> bryce__: could you once more ask pitti why those x-x-video -syncs are not in the archive?-)
<tepsipakki> they should be by now..
<tepsipakki> hmm, I'll bite the bullet and ask myself :)
<tepsipakki> sweetness, pitti promised to do the syncs, also x11-* packages
<tepsipakki> and I'll grab my laptop from work and hope to push the git-branches on git.d.o :P
<tepsipakki> jcristau_: ^^ fear
<tepsipakki> :)
<jcristau_> :)
<bryce__> heya tepsipakki
<tepsipakki> bryce__: hi, so pitti synced the rest of the video drivers, and I'm about to fakesync the four which have a different tarball
<bryce__> awesome
<tepsipakki> and apparently the x11-* packages are being synced later today
<bryce__> good news
<tepsipakki> which means that only xorg missing from the puzzle
<bryce__> I'm hoping to get three packages sru'd today, but I've been innundated with various meetings and things so may not happen
<tepsipakki> heh, I'm sure it's busy there
<tepsipakki> btw, we had our own columbine today :/
<tepsipakki> some nutcase apparently killed seven before getting caught
<tepsipakki> but the details are still a bit vague
<tepsipakki> anyway, fakesyncs ->
<ubotu> New bug: #136628 in linux-restricted-modules-2.6.22 (restricted) "linux-restricted-modules-2.6.22.10-rt does not include nvidia modules" [Undecided,Fix released] https://launchpad.net/bugs/136628
<rawler> 34 <- the number of screws you need to unscrew to cleanse orange juice from your apple wireless keyboard.. (if someone needs to know ;) )
<bryce_> tepsipakki: ah, sad to hear about the shootings
<tormod> OMG horrible
<tepsipakki> yeah
<tepsipakki> jcristau: ping, using git to make a release
#ubuntu-x 2008-11-03
<tjaalton> http://lwn.net/Articles/305047/
<wgrant> tjaalton: Saw that a few days ago. Haha.
<wgrant> THey must have better things to flame about.
<wgrant> seb128: I have an SRU for g-s-d.
<tjaalton> wgrant: yeah, it's the small changes that annoy some people the most :)
<wgrant> seb128: Bug #280148, and I've had the patch committed upstream. Am I OK to start the SRU process?
<ubottu> Launchpad bug 280148 in gnome-settings-daemon "g-s-d needs to set mouse properties when a new device appears" [Medium,In progress] https://launchpad.net/bugs/280148
<seb128> wgrant: hi, it's monday morning and I got over 700 bugs mails during the weekend so add yours to the list
<seb128> let me look
<wgrant> seb128: Sure, no rush.
<seb128> wgrant: the change seems to be a sru candidate indeed, start on it and subscribe the sponsor team if you need sponsoring
<wgrant> seb128: Great, thanks.
 * wgrant wonders about u-m-s latency.
<mvo> superm1: did you had a chance to check if your card works with fglrx from intrepid? 
<Q-FUNK> wgrant: to answer the question, aptitude handled the dist-upgrade from hardy.
<wgrant> Q-FUNK: That is not allowed.
<Q-FUNK> where is that said?
<wgrant> Q-FUNK: The dist-upgrader is the only supported upgrade mechanism.
<wgrant> ie. update-manager or do-release-upgrade
<wgrant> https://help.ubuntu.com/community/IntrepidUpgrades
<wgrant> You will find a single reference to dist-upgrade there, and it isn't used as an action to apt-get or aptitude.
<Q-FUNK> that doesn't say that apt-get or aptitude are not allowed.
<wgrant> They haven't been supported in Ubuntu for a *very* long time.
<wgrant> Anyway, have you tried to suspend?
<Q-FUNK> I just rebooted without the xorg.conf now.  
<Q-FUNK> let's try it
<Q-FUNK> brb
<tseliot> mvo: new NVIDIA legacy drivers (compatible with X.org) are available in intrepid-proposed now. Maybe update manager can stop migrating users to "nv" after these drivers are moved to the stable repositories
<mvo> tseliot: sure. both versions are updated in -prpopsed?
<tseliot> mvo: yep
<tseliot> mvo: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-96/+bug/251107
<ubottu> Launchpad bug 251107 in nvidia-graphics-drivers-96 "[Intrepid] nvidia_drv.so: undefined symbol: AllocateScreenPrivateIndex" [Medium,Confirmed] 
<mvo> thanks tseliot
<tseliot> mvo: you're welcome
<Q-FUNK> wgrant: nope.  bug still present. :(
<wgrant> Q-FUNK: So your hardware manages to partly vanish? Great.
<wgrant> Q-FUNK: Which setting is dropping?
<Q-FUNK> wgrant: maybe.  the strange thing is that going to the gnome mouse preference capplet and manually clikcing right, then left again restores it.
<Q-FUNK> left-handed buttons
<wgrant> Q-FUNK: On all devices?
<Q-FUNK> which devices?
<wgrant> Does the left-handed setting drop from all devices, or just the touchpad?
<Q-FUNK> this laptop only has a touchpad.  4 buttons.  2 above and 2 below.  mirrored by X default.
<Q-FUNK> it also has a trackpoint, but it shares the buttons used by the touchpad
<wgrant> Ah, lots of people use an external mouse as well.
<wgrant> OK, let's see...
<wgrant> Try flipping horizontal edge scrolling on, and check the Synaptics Edge Scrolling property on the device before and after suspend.
<Q-FUNK> this Dell D430 was a common sight at the last IDS in Prague.  other people had the previous D420 also.  there should be plenty of people who can test this, but I'm not sure if any of them are left-handed
<wgrant> As well as checking if it still works after suspend, of course.
<Q-FUNK> all touchpad options are enabled, here.
<wgrant> And horizontal scrolling persists over a suspend/resume?
<Q-FUNK> good question.  the only place where I sometimes need it is in forefox.
<Q-FUNK> firefox
<Q-FUNK> let's try.
<Q-FUNK> brb
<wgrant> I test it by checking if the bottom edge moves the cursor orr not.
<Q-FUNK> ok
<Q-FUNK> doesn't move the cursor here
<Q-FUNK> vertical scrolling works, so I'd presume that horizontal does too.  I just dont have a web site with fixed page size to test with
<wgrant> Right.
<wgrant> Now, does it still work after a suspend and before you reset settings?
<Q-FUNK> ah, wait. I purposely downsized the firefox window.  horizontal works too.  let's suspend and try this again.
<Q-FUNK> brb
<Q-FUNK> horizontal scrolling NOT restored after suspend.
<Q-FUNK> oh... wait.  it takes a while to restore, but it eventually comes back
<wgrant> Hmmmmmmmmmmmmmmmmmmmmmmmmmmmmm.
<wgrant> But the button mapping is still not back?
<Q-FUNK> indeed not
<wgrant> Curses.
<Q-FUNK> hm. wait. that came back too.
<wgrant> Check Xorg.0.log to see if the device disappears and reappears now.
<wgrant> Hmm.
<Q-FUNK> could it be dependant upon touchpad requring non-default settings, if the buttons are attached to it, to restore buttons too?
<wgrant> No.
<Q-FUNK> hm
<Q-FUNK> odd
 * wgrant -> bed
<Q-FUNK> ok
<Q-FUNK> good night!
<superm1> mvo, so it turns out the workstation quality r3xx (FireGL) aren't broke; it's only the consumer grade
<superm1> mvo, so that's why mine still works
<superm1> and yes it does work on Intrepid
<mvo> superm1: ok, thanks for testing this
<tjaalton> hehe, bug 292993
<tjaalton> lazy ubottu.. https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/292993
<ubottu> Launchpad bug 292993 in xorg "EE-I810(0):No video BIOS modes for chosen depth Mobile Intel 945GM" [Undecided,Invalid] https://launchpad.net/bugs/292993
<ubottu> Launchpad bug 292993 in xorg "EE-I810(0):No video BIOS modes for chosen depth Mobile Intel 945GM" [Undecided,Invalid] 
<mvo> tjaalton: what should be done about bug #292774 ? it seems like (some people) are not happy with the automatic xorg.conf rewrite
<ubottu> Launchpad bug 292774 in xorg "xorg.conf setup broken after upgrade to 8.10" [Undecided,New] https://launchpad.net/bugs/292774
<tjaalton> mvo: well, not commenting them out shouldn't hurt, since when HAL is used they are just ignored (for mice/keyboards anyway)
<mvo> hm, but his setup would be broken anyway in this case, right?
<tjaalton> yes
<mvo> ok
<mvo> IIRC one in the X team asked me to add the code to comment out the input devices because it would break something with "synaptics" (from memory) ? 
<mvo> is that no longer true ?
<tjaalton> ok, could be..
<tjaalton> evdev has since been modified to not grab the devices explicitly, but AIUI there were some problems and still might be
<tjaalton> wgrant is the synaptics hero, I don't have one :)
<tseliot> tjaalton: basically the InputDevice sections caused problems to touchpads tapping, etc.
<tseliot> removing such section solves the problem
<tseliot> tjaalton, mvo: I wasn't aware of how it could affect multi-seat setups though
<tseliot> of course having more information in the bug report will help me understand what went wrong
<mvo> tseliot: me neither, I think its not a big deal, given that the setup would have been broken even without the modifications
<mvo> tseliot: at the very least he had to add this "NoAuto" option (forgot the exact name)
<mvo> so no (more) harm done by the script, still would be nice to know more aobut it
<tseliot> right
<seb128> any idea if bug #290674 could be an xorg issue?
<ubottu> Launchpad bug 290674 in gnome-control-center "Setting the keyboard repeat speed has no effect" [Low,Confirmed] https://launchpad.net/bugs/290674
<tjaalton> seb128: yes, probably evdev
<seb128> tjaalton: ok thanks
<seb128> I'll reassign the bug
<tjaalton> thanks
<seb128> tseliot: could you look to bug #287062 ?
<ubottu> Launchpad bug 287062 in gnome-control-center "Screen resolution capplet unnecesarily tries to set virtual resolution" [Undecided,Fix committed] https://launchpad.net/bugs/287062
<seb128> ups
<seb128> bug #287082
<ubottu> Launchpad bug 287082 in gnome-control-center "Cannot go back to higher resolution after setting virtual resolution" [Undecided,New] https://launchpad.net/bugs/287082
 * tseliot has a look at the bug report
<tseliot> seb128: I think 287082 is a duplicate of 287062
<tseliot> my quick fix was uploaded to jaunty
<seb128> tseliot: feel free to close it as duplicate
<tseliot> and to intrepid-proposed
<tseliot> ok
<seb128> tjaalton: ok, bug #264196 seems to be the keyboard issue
<ubottu> Launchpad bug 264196 in xserver-xorg-input-evdev "[intrepid] keyboard Repeat Keys is failing to adjust, when AutoAddDevices is on" [Undecided,Confirmed] https://launchpad.net/bugs/264196
<seb128> could somebody in the xorg team triage it?
<tjaalton> seb128: sure, I think it's known upstream too
<tjaalton> later ->
<seb128> bugs.freedesktop.org seems to not reply
<seb128> tseliot: bug #284630 is yours too
<ubottu> Launchpad bug 284630 in gnome-control-center "Typo in gnome-control-center" [Low,Confirmed] https://launchpad.net/bugs/284630
<seb128> though don't change it in a sru because that would break translations
<tseliot> seb128: shall I fix it only in jaunty?
<seb128> tseliot: yes, not worth breaking the translations for intrepid
<tseliot> right
<tseliot> and that error shouldn't show up unless the virtual resolution can't be applied
<jcristau> tseliot: padding bytes in the wire protocol are necessary for alignment (re your question on xcb@)
<tseliot> jcristau: alignment of what?
<jcristau> of the data sent between server and client
<tseliot> jcristau: is there documentation on this?
<jcristau> see the spec, of the protocol headers, i guess
<jcristau> in this case, xRRSetCrtcConfigReq in randrproto.h has a 2-byte 'pad' field after 'rotation'
<jcristau> and the output list follows the xRRSetCrtcConfigReq
<jcristau> in general, every 2-byte field is aligned on a 2-byte boundary, and every 4-byte field on a 4-byte boundary
<tseliot> ok
<tseliot> thanks for the explanation
<jcristau> np
<jcristau> oh, also every request's length is a multiple of 32 bits, so the next one is aligned properly
<tseliot> aah
 * Ng curious, is there some kind of api for getting events from a touchpad? I expressly don't want to use mine for mouse events, but I'm curious if I could get some funky pinchyzoomyswipey gestures going
<Ng> like, flicking it to navigate workspaces
<pwnguin> theres xinput
<pwnguin> and i saw a gestures thing
<pwnguin> but honestly, i dont really like them
<Ng> pwnguin: I generally don't with mice, but I think they work with a touchpad, specifically because I have an iphone and being able to do the pinchyzoomy stuff is excellent
<pwnguin> oh
<pwnguin> thats a different thing
<pwnguin> a) your device has to support that
<pwnguin> and as usual, apple snapped up an exclusive on the patented hardware that does multitouch
<Ng> bah
<pwnguin> do you have a touchpad right now?
<Ng> yeah, but I disable it in the BIOS because I hate using them for mouse input ;)
<pwnguin> macbook?
<Ng> pwnguin: nah, thinkpad
<pwnguin> then i dont think you get pinchzoom
<pwnguin> you've probably got a synaptic device that does resistance calculation
<Ng> well that sucks
<Ng> maybe I could stick my iphone to the laptop and use that as a network touchpad ;)
<pwnguin> someone had this hilarious laptop
<pwnguin> 17 inch display, and a wacom tablet below the keyboard
<Ng> :o
<pwnguin> mine's built into the display, like sane people's laptops
<Ng> pwnguin: tablet thing? :)
<pwnguin> yea
<pwnguin> hey uh, about three hours before the release my intrepid install started kernel panicing
<pwnguin> i think its the video driver
<pwnguin> is nvidia known bad?
<Ng> how would you guys feel about an SRU for https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/282387 ?
<ubottu> Launchpad bug 282387 in xserver-xorg-input-evdev "scrollwheel emulation breaks after suspend with 2.6.27-7" [Undecided,Confirmed] 
<Ng> I'm testing the patch atm
<james_w> can someone help me reassign bug 293209 to the correct place?
<ubottu> Launchpad bug 293209 in gnome-control-center "External display - 1440x900 resolution not detected" [Undecided,New] https://launchpad.net/bugs/293209
<james_w> I suspect driver, but I'm not positive
<superm1> bryce, I think i might have a new piece of useful data in the debugging of that fn+brightness makes things go wacky.  If you run in failsafe terminal, you are somehow receiving a key release event *before* a keypress event...
<bryce> superm1: weird
<superm1> bryce, yeah i'm not even sure how to debug that.  i'm gonna have to compare with 8.04 and see if it's new.  showkey isn't even showing that event
<bryce> Ng: is 282387 a regression?  If not, I'd say leave it for Jaunty
<bryce> superm1: ok
<Ng> bryce: well previously one would set the input properties as driver options in xorg.conf and they'd stick. right now they are set with xinput and lost on suspend/resume. functionally it's a regression, but it's new code, so maybe that doesn't count
<jcristau> if you set them in something.fdi, they don't persist?
<bryce> james_w: Looks like the user has Virtual set to 2384x768 
<Ng> jcristau: I've not tried that route at all
<bryce> (EE) intel(0): Mode 1280x1024 does not fit virtual size 2384x768 - internal error
<bryce> james_w: that's listed several times in the Xorg.0.log.
<jcristau> Ng: that's pretty much today's equivalent of setting them in xorg.conf
<bryce> james_w: presumably gnome-control-center needs to take care not to set the y value too low when it hardcodes Virtual, or something
<james_w> bryce: I'll ask if they used the Virtual setting thing
<james_w> thanks
<bryce> james_w: if you get their xorg.conf that'd be proof of it
<james_w> http://launchpadlibrarian.net/19299532/xorg.conf
<james_w> so it is set
<bryce> yep
<Ng> jcristau: would that be rewritten on resume? re-setting them with xinput after suspend/resume is what's broken, so presumably they wouldn't be able to persist via fdi either?
<bryce> james_w: my guess is they did it via screen-resolution-extra
<Ng> s/rewritten/reread/
<james_w> bryce: thanks, I'll enquire
<bryce> james_w: also talk with tseliot; perhaps some logic needs added to g-c-c to not set X or Y Virtual below some threshold or something
<tseliot> bryce: maybe the virtual resolution was set also in clone mode, just like in the bug which I have recently fixed (still in proposed)
<jcristau> Ng: maybe i'm not thinking of the right bug..
<bryce> tseliot: ah could be
<tseliot> bryce, james_w: this bug: https://launchpad.net/bugs/287062
<ubottu> Launchpad bug 287062 in gnome-control-center "Screen resolution capplet unnecesarily tries to set virtual resolution" [Undecided,Fix committed] 
<superm1> bryce, yeah that keypress/keyrelease order is definitely a regression from hardy, i'm wondering if this is the root of that problem now...
#ubuntu-x 2008-11-04
<james_w> wgrant: bug 293318
<ubottu> Launchpad bug 293318 in gnome-settings-daemon "gnome-settings-daemon leaks memory" [Undecided,New] https://launchpad.net/bugs/293318
<wgrant> james_w: Argh. Let's see...
<james_w> hey wgrant 
<james_w> I don't see anything obvious in your change
<wgrant> Neither.
<james_w> I imagine it does call some functions more frequently, and so an existing leak would become an issue
<wgrant> I expected that my previous batch of changes could leak.
<wgrant> Hmm. Possibly.
<wgrant> This shouldn't be calling anything that often, though.
<james_w> ah, ok
<james_w> is it just on device insertion/removal?
<wgrant> Yes.
<wgrant> Well, actually, some of the code will be running on every X event.
<wgrant> Which narrows it down somewhat.
<james_w> shall I ask him if he's inserting 20 devices a second? :-)
<james_w> ah, ok.
<wgrant> The stuff outside the if in devicepresence_filter will be running lots.
<wgrant> But that looks perfectly safe.
<james_w> yeah
<james_w> you don't have to unref the return value of gdk_x11_get_default_xdevice() do you?
<wgrant> xdisplay, you mean?
<james_w> yeah
<wgrant> It doesn't look like it.
<wgrant> It certainly doesn't leak here, on i386.
<wgrant> Even with thousands of hotpluggings.
<james_w> so you think this could be amd64 specific?
<wgrant> I wouldn't think so, but all of the other regressions caused in my changes in Intrepid were my code exposing 64-bit unsafeness in the xserver.
<wgrant> (well, X libs, actually)
<wgrant> I thought I saw it leaking very slowly then, but its usage just dropped, so that can't have been it.
<wgrant> james_w: Do you have amd64 hardware you can test on?
<james_w> sorry, I don't
<ianloic> hey I'm having X freezing up
<ianloic> so I installed the debug version of libgl1-mesa-dri
<ianloic> but it's not being loaded
<ianloic> oh wait
<ianloic> nevermind
<ianloic> wait no
<ianloic> I didn't get it
<ianloic> setting the LD_LIBRARY_PATH doesn't seem to help
<ianloic> how can I actually use these debug packages to get more meaningful stack traces?
<jcristau> gdb
<ianloic> jcristau, how can I convince X to load debug versions of modules & libraries?
<ianloic> jcristau, here's my bug: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/292234
<ubottu> Launchpad bug 292234 in mesa "X Freeze in i965_dri.so" [Undecided,New] 
<ianloic> jcristau, I feel (perhaps naively) that if I could just get a little more out of that stack trace I'd be able to hack at it myself :)
<tjaalton> omg, now the wayland-crazyness hit brainstorm: http://brainstorm.ubuntu.com/idea/15205/
<wgrant> tjaalton: Already!?
<tjaalton> wgrant: yep..
<tjaalton> soo many "facts" are wrong..
<wgrant> Didn't he specifically say that it wasn't intended to replace X.org?
<tjaalton> right
<tjaalton> and to be useful it needs the xserver running on top of it
<wgrant> Do you have privs to close it and devcomment on it?
<tjaalton> yes
<wgrant> Good.
<tjaalton> done
<Ng> mvo: your HAL fdi thing for scrollwheel emulation - what led you to the properties you ended up setting?
<Ng> (wrt http://mvogt.wordpress.com/2008/08/15/xorg-evdev-and-emulatewheel/)
<mvo> Ng: you mean how I figured out the exact names? 
<Ng> mvo: yeah
<Ng> I'm curious why it worked at all
<mvo> Ng: I think I asked around here
<mvo> it seems to be not plagued by the bug that it does not work after supsend
<mvo> or rather, affected differently, it seems like every second resume its fine, but about half/25% of the time its not. but cures itself on the next resume again
<Ng> mvo: that is kinda weird. It would be interesting to know if the patch fixes that
<Ng> but I'd also like to construct a HAL fdi for it. Not for my own use, but to prove that it works with those settings as well
<Ng> the thing is, you don't specify the wheel emulation Y axis, so I'm wondering if it defaulted to 4 5. It can't be relating to the ZAxisMapping you set, because you actually spelt Axis wrong, so unless X corrects for that, that setting was probably ignored ;)
<Ng> (I built a deb of the current intrepid i386 package with the patch included, if you fancy giving it a test run, it's attached to the bug)
<Ng> I'd also like to figure out if it's possible to get horizontal scrolling going, but that's way less important
<Ng> oh, I just did that :)
<tjaalton> Ng: got an X300 to play with.. should it work with hardy?-)
<Ng> tjaalton: all the important stuff other than sound will work
<Ng> that just needs a newer alsa to get the driver
<Ng> should all work with intrepid, apart from the scrollwheel emulation ;D
<tjaalton> Ng: heh, ok.. I'll try with hardy first
<mvo> Ng: haha, I spelt it wrong? oh well
<Ng> ZAxsis
<Ng> tjaalton: are you borrowing it? why not chuck intrepid straight on? :)
<tjaalton> Ng: I'm installing it for a colleague, and yes intrepid it is since hardy refused to netboot
<tjaalton> or, failed to install the kernel
<Ng> ah
<Ng> steal it ;)
<tjaalton> it's tempting ;)
<crevette> X300 ... hmmm
<tjaalton> could swap my X61 for it
<crevette> X61 is not bad
<tjaalton> "look, it's smaller"
<crevette> :)
<tjaalton> no it's not
<crevette> I'm happy with y T6A but I should have wait some week to have a X400 with a powerful cpu
<crevette> T61
<crevette> damn technical evolution
<tjaalton> got my X61 last December, and a month after they released X300..
<Ng> crevette: the X61 and the X300 seem to have very similar internals
<Ng> the 301 has a much newer chipset
<crevette> I didn't know there is a 301
<Ng> hmm, or not, I can't remember exactly. i think I remember being surprised that it wasn't ICH10, which would make it ICH9 (where the 300 is ICH8)
<Ng> crevette: physically the same apart from DisplayPort, then a newer chipset and a faster CPU, with the option of a 128GB SSD instead of just 64GB
<crevette> Ng, DisplayPort is the external display port so is it DVI now ?
<Ng> displayport is supposed to replace DVI, I believe
<crevette> ah DisplayPort is a type of port
<Ng> yeah
 * crevette is not into hardware :)
<Ng> it's not compatible with DVI, although DVI signals can be passed over it, hardware support willing
<Ng> (the X300 just has VGA)
 * crevette reads wikipedia article
<crevette> yeah my T61 too :/
<Ng> having VGA is no bad thing, every projector in the world can talk to it, vs almost none talking displayport :)
<bryce> morning
#ubuntu-x 2008-11-05
 * tjaalton does the UDS dance ;)
<tseliot> tjaalton: I glad to read that you'll attend the UDS
 * tseliot > dinner
<bryce> tjaalton: wow great news :-)
<bryce> boy this year we're going to have a big X team
<bryce> jbarnes is coming too
<tjaalton> great :)
<wgrant> tjaalton: Excellent!
<rzr> hi
<bryce> drive-by greetings ;-)
<wgrant> At least they're easy to deal with.
#ubuntu-x 2008-11-06
<wgrant> I wonder if we might want to add a button in the recovery mode menu to remove ~/.config/monitors.xml.
<james_w> wgrant: good idea
<james_w> wgrant: or maybe make it automatic
<wgrant> I'm for now just going to add that hint to X/Config/Resolution.
<wgrant> james_w: How could it be automatic?
<wgrant> g-display-properties also needs to prompt before it sets a res permanently. I wonder where that feature went...
<james_w> don't add a button, just rm the file when recovery mode starts up
<james_w> yeah, it will be a false positive from time to time, but not that often will it?
<james_w> upstream didn't like the prompt so they dropped it, and we never resurrected the patch
<wgrant> It would be a bit strange to have simply booting into recovery mode fix the problem.
<wgrant> Eww.
<wgrant> They didn't like it!?
<james_w> apparently
<wgrant> If they won't fix it, I will.
<james_w> I think there's a bug open on it
<james_w> there's certainly a launchpad one
<bryce> yeah I like the idea of something to remove monitors.xml
<bryce> I'm not sure about removing it automatically vs. a button
<wgrant> I've only had to advise a few people on ubuntuforums about it so far.
<wgrant> Far more common are the complaints about the removal of displayconfig-gtk.
<bryce> heh, people are actually complaining about that?
<bryce> I wonder if the number of those complaints outweigh the number that were complaining of its brokenness
<wgrant> It is by far the most common complain on ubuntuforums.
<wgrant> s/complain/complaint/
<wgrant> I'm hoping your X/Config/Resolution will help.
<bryce> I hope it does too, and I also hope users will assist in improving the docs
<bryce> even better would be if they helped tseliot build on x-kit
<bryce> but I can understand many probably lack the time/tech to do that, so at least working on docs would be a good way to help their fellows out
<wgrant> We really need more people from somewhere.
<bryce> yep
<bryce> I used to participate in ubuntuforums myself a while back, but there's only so many info streams I can keep up
<bryce> +with
<bryce> plus even though I was trying to focus discussions towards constructive testing, it ended up people kept using/hijacking the thread for bug reporting
<bryce> wgrant: well the good news is that since I started, we seem to have accumulated +1-2 active ubuntu-x techies per release
<bryce> wgrant: I've really appreciated having your involvement lately, it's a big help
<wgrant> bryce: I try to track the devel forum to watch things that might crop up, but it gets insane at about T-2weeks.
<wgrant> Hah. I've been very little help in Intrepid, but I'll be better for Jaunty.
<wgrant> Exams finish in two weeks, then 3.5 months off.
<bryce> superm1: we've got EPR's!  :-)  https://bugs.edge.launchpad.net/fglrx/+bugs
<bryce> wgrant: kewl :-)
<bryce> wgrant: can you point me at some of the displayconfig-gtk complaints?  I skimmed around but didn't spot them
<bryce> I did see some issues relating to resolutions
<wgrant> Well, there are lots relating to resolutions.
<wgrant> Lots and lots and lots.
<wgrant> And a fair few about displayconfig-gtk. I'll dig some up soon.
<bryce> great thanks
<wgrant> http://ubuntuforums.org/showthread.php?t=965866, http://ubuntuforums.org/showthread.php?t=964212, http://ubuntuforums.org/showthread.php?t=966429, http://ubuntuforums.org/showthread.php?t=96426 are some recent ones.
<wgrant> There are more in the intrepid forum itself.
<wgrant> Is the proper solution to work out what's wrong with their EDID and quirk it? Or are people just going to have to continue to set things manually?
<bryce> thanks
<bryce> if we can solve it with quirks, that's the ideal
<bryce> there will be some cases that are unquirkable though
<bryce> and some (hopefully rare) cases where EDID is not available at all, that they'll have to configure manually
<wgrant> Of course.
<bryce> yep, so all of these sound like invalid EDID situations
<wgrant> Is there anything better than get-edid | parse-edid?
<bryce> 194760 is the master
<bryce> I'd love to know how to close that one
<wgrant> bug #194760
<ubottu> Launchpad bug 194760 in xorg-server "EDID fail" [High,Triaged] https://launchpad.net/bugs/194760
<bryce> ddcprobe is another way to get monitor settings
<bryce> xrandr --verbose also prints EDID
<wgrant> I couldn't work out how to get xrandr's EDID output into parse-edid.
<wgrant> Wait, so that bug is about the monitor not reporting an EDID at all?
<wgrant> Ah, no.
<wgrant> It's just a bit confusing and long.
<bryce> parse-edid works only on the raw binary produced by get-edid.  I don't know if xrandr's edid can be put into it, but it'd require converting it to binary
<wgrant> I tried converting it to binary, but it still didn't work. Mrh.
 * wgrant needs to learn more about X video stuff eventually.
<wgrant> bryce: Why isn't X/Config/* on help.u.c?
<bryce> wgrant: I want to keep the X documentation organized in one place
<wgrant> bryce: Ah, but user docs are meant to be on help.u.c/community.
<bryce> then they should write them
<bryce> if I have to write them, then they're going on wiki.ubuntu.com where I can maintain them all together easily
<wgrant> Ahh.
<wgrant> I see.
<tjaalton> hmm so there are two hotels being used during UDS? wiki talks about Wild Palms and the invitation mentions Domain Hotel
<wgrant> tjaalton: I've only heard about the latter.
<tjaalton> wgrant: maybe it's booked already, and Wild Palms is for non-sponsored guests.. who knows
<wgrant> That's quite possible.
<wgrant> I wonder when they're going to assign rooms.
<wgrant> Is in mildly active Ubuntu X person not going to UDS?
<wgrant> bryce: Erm, X has EDID issues.
<wgrant> http://ubuntuforums.org/showthread.php?t=969014
<wgrant> That EDID looks fine.
<wgrant> But X gives a dodgy res.
<wgrant> Oh. Hmm.
<wgrant> I was looking at the wrong monitor's xrandr output. Damn.
<superm1> bryce, wgrant, update to the proposed kernel and that keyrepeating issue affecting dell laptops should be handled
<superm1> (there is still something wrong with the OSD, but far less critical)
<bryce> superm1: excellent
<bryce> superm1: did you see my message about getting bug #'s from intel on the 4 upstreamed bugs?
<bryce> er
<superm1> s/intel/AMD/
<superm1> yeah
<bryce> s/intel/amd/
<superm1> that's great to hear
<superm1> so every public release we'll be able to close out the appropriate ones etc
<bryce> yep
<superm1> i anticipate there will be a demand for backports too for some of these, and i think the way the driver package is put together now, backports are feasible
<superm1> eg into the backports repo
 * bryce nods
<bryce> unfortunately, I also noticed on at least a couple of these bugs, that the activity on the issue stirred up users to start posting questions about unrelated issues to them
<superm1> well i think you run into that everywhere though when too many people subscribe to a bug
<superm1> eg bug 59695
<ubottu> Launchpad bug 59695 in dell "High frequency of load/unload cycles on some hard disks may shorten lifetime" [Low,Confirmed] https://launchpad.net/bugs/59695
<pwnguin> sigh
<pwnguin> something x related seems to be causing kernel panics
<bryce> superm1: yeah could be
#ubuntu-x 2008-11-07
 * bryce spams launchpad
<tjaalton> noted :)
<wgrant> bryce: Shouldn't you be asking people to try with Intrepid?
<wgrant> bryce: Development ISOs aren't likely to be very good right now.
<tjaalton> and no x related updates there either
<tjaalton> but maybe it'll take 1-2 months for the people to test, so then there'll be some alpha available .)
<tjaalton> :)
<wgrant> Heh.
<wgrant> Ohhhh.
<wgrant> Damn tablets.
<wgrant> Damn users, too.
<wgrant> It seems that the Synaptics stuff to gnome-settings-daemon
<wgrant> Bah.
<wgrant> it seems that the Synaptics stuff in gnome-settings-daemon causes a DevicePresenceNotify storm when there's a bad Wacom device entry.
<wgrant> Probably because it initially tries to set the properties on startup, so tries to open the device, which causes X to look for it again, which causes it to send a DevicePresenceNotify, because the device didn't previously exist because /dev/input/wacom doesn't exist.
<wgrant> Meanwhile the device has already disappeared again, so the device open attempt brings it back.
<wgrant> Also filling Xorg.0.log very, very quickly.
<tjaalton> hehe
<wgrant> At least I can reproduce it now.
<tseliot> jcristau: I'm trying to compile a small program which uses xcb but I'm getting an error. Any ideas? http://pastebin.com/d42d7a6ea
<wgrant> tseliot: libxcb-randr is a separate lib with a separate .pc
<wgrant> xcb-randr, unsurprisingly enough.
<tseliot> wgrant: ah, right
<tseliot>  gcc -Wall xrandr-xcb.c -o xrandr-xcb `pkg-config --cflags --libs xcb-renderutil xcb-randr xcb-aux` did it
<wgrant> Excellent.
 * wgrant also seems to have solved that g-s-d bug.
<tseliot> \o/
<wgrant> DeviceEnabled vs. DeviceAdded isn't well documented, except in the server code.
<wgrant> tseliot: Is Envy still meant to be used on Intrepid?
<tseliot> wgrant: envyng-core and envyng-qt
<wgrant> tseliot: OK, so that would be a yes. Thanks.
<tseliot> yes
<sbeattie> bryce: are you auto-spamming bugs now? I hardly think I need to provide lspci info for https://bugs.launchpad.net/ubuntu/+source/xfonts-utils/+bug/274266 a bug in a manpage
<ubottu> Launchpad bug 274266 in xfonts-utils "update-fonts-dir(8) manpage needs updating" [Low,Incomplete] 
<jcristau> sbeattie: care to write a patch for the manpage?
<bryce> sbeattie: yes I'm auto-spamming
<rzr> hi
<wgrant> Hi rzr.
<rzr> is ~tormodvolden here sometimes ?
<wgrant> I've not seen him speaking, but he might lurk.
<rzr> under which nickname ?
<wgrant> I have no clue.
<wgrant> rzr: ^^
<rzr> thx anyway
<tjaalton> rzr: 'tormod'
<rzr> oki makes sense
<bryce_> heya
<wgrant> Hi bryce_. You had a lot of fun spamming, I see
<bryce_> wgrant: I did
<bryce_> so far managed to get a few dozen confirmations of bugs fixed too
<bryce_> well, fixed or hw no longer available
<wgrant> And I finally got something more useful than "me too" out of people experiencing that damn g-s-d issue. It's like users are deliberately blocking it.
<wgrant> Right, I closed a couple this morning as well.
<wgrant> And in 60 days you can close lots more!
<bryce_> yep
<bryce_> I didn't keep a precise count, but there were over 400 New bugs moved to Incomplete
<wgrant> Oh, nice.
<wgrant> I just noticed my bugs/x folder rapidly approaching my bugs folder in number of messages.
<bryce_> wgrant: let me run this next idea past you
<bryce_> what do you think of this.  the next launchpad spam idea I have is to automatically move New bugs with Xorg.0.log + lspci, or Xorg.0.log + backtrace -> Confirmed
<wgrant> bryce_: I think a tag might be better for that.
<bryce_> I could tag them as well, but the point is to get them out of New state.
<wgrant> Hmm, good point.
<wgrant> I guess moving to Confirmed automatically and Triaged manually would be a reasonable workaround.
<wgrant> So that would work.
 * bryce_ nods
<bryce_> ok, switching to my other wireless ap.  brb
<wgrant> For fixing a regression in -proposed, do I attach the debdiff to the original or regression bug?
<wgrant> 10:34:11 < wgrant> For fixing a regression in -proposed, do I attach the debdiff to the original or regression bug?
<bryce> the regression bug
<wgrant> Great, thanks.
<bryce> well, either is probably fine
<bryce> I'd do the regression bug though.  easier to track.  Cross reference them for the release manager's convenience.
<wgrant> Yep.
#ubuntu-x 2008-11-08
<james_w> wgrant: nice work
<wgrant> I'm not entirely sure that X should be doing what it is, but it's easy enough to work around.
#ubuntu-x 2009-11-02
<tseliot> jcristau, tjaalton: what package does it launch X with parameters such as "-bg" or "-fg" in debian and ubuntu? I can't remember
<tseliot> ah, right it's /etc/X11/xinit/xserverrc in xinit. Never mind
<RAOF> Woop!  Woop!
<RAOF> Nouveau is now faster, cleaner, smoother than nv, *and* *supports* *suspend*.
<tormod> RAOF, cool. I copied your new stuff to xorg-edgers also. you might want to get a newer libdrm from there.
<RAOF> tormod: Oh, should I be uploading there?
<tormod> would be nice if you can copy the ddx and the modules package there, so people can get everything in one place
<RAOF> In future I'll just upload straight there, then.
<tormod> yeah
<tormod> I was just thinking you wanted to let people test nouveau without updating the whole xorg stack
<RAOF> Well, maybe.  So, I guess I'll upload it to both places.
<tormod> but they would profit from newer mesa as well
<RAOF> Not for nouveau they wouldn't.
<RAOF> Surely we don't build the nouveau DRI module, do we?
<tormod> you can do a no-build copy for the module package, and a rebuild-copy of the ddx
<tormod> oh well I guess not
<RAOF> Upstream would be most displeased if we were shipping their DRI :)
<tormod> ok :) I just have seen various nv50 and nouveau commits but I guess that's forbidden fruit then
<RAOF> Oh, apparently it works quite well - to the point of developers running compiz & such.
<RAOF> It's just aggressively unsupported still.
<tormod> ok, but users can profit from newer sw rendering then :)
<RAOF> Fair 'nuff :)
<RAOF> So, nouveau TODO: (1) enable kms by default in the ppa, so users get working suspend/resume. (2) play with the DRI. (3) Get people discussing nouveau as default open-source nvidia driver for lucid.
<bryce> hi guys
<RAOF> Howdie.
<Amaranth> RAOF: I've been told nouveau with metacity or kwin compositing feels as fast as nvidia with compiz
<Amaranth> so that's pretty cool, that means the XRender acceleration is _awesome_
<RAOF> Amaranth: I think they're underplaying the speed of nouveau.  I find it _faster_ than nvidia with compiz.
<Amaranth> hehe
<RAOF> And, yes.  The XRender acceleration is _awesome_.
<Amaranth> It's as good as intel but the hardware is like 6x faster
<RAOF> Right.
<Amaranth> hopefully people don't start thinking using cairo for video games is a good idea :)
<RAOF> This ~3 year old 7600go is tremendously faster than my new intel laptop.
<tormod> bryce, seems like a couple of intel issues out there in 9.10? what do you think?
<bryce> tormod, which ones?
<bryce> unfortunately all the checkbox bugs filed against X have been consuming my attention
<tormod> hangs with i8xx (but that's maybe nothing new) and resolution problems on i915
<tormod> but I am pretty new to intel bugs, so maybe it is just business as usual what I am seeing
<bryce> the resolution problems could be due to dropped monitor quirks due to KMS
<bryce> jbarnes might have an inkling
<tormod> and some have upgrade issues because they have cruft in xorg.conf I think
<bryce> yeah
<tormod> what are checkbox bugs?
<jbarnes> tormod: not sure if the 8xx fixes are in the ubuntu kernel (I think most should be) but there have definitely been a lot of fixes in that area in the past few months
<jbarnes> 9xx resolution stuff is new to me, what are you seeing?
<tormod> for instance bug 433326
<ubottu> Launchpad bug 433326 in xserver-xorg-video-intel "[i945g] maximum resolution: 800x600" [Undecided,Confirmed] https://launchpad.net/bugs/433326
<jbarnes> sounds like it's failing to get a decent edid?
<jbarnes> hm no xrandr looks good
<jbarnes> indicates things are running at 1360x768 even
<bryce> tormod, checkbox bugs -> there is now a 'System Test' tool under the System menu, which after you go through it lets you file bug reports against xorg
<bryce> bug 448913 is an example
<ubottu> Launchpad bug 448913 in checkbox "." [Undecided,Incomplete] https://launchpad.net/bugs/448913
<bryce> bunch more are in the xorg package that I haven't had time to move/close/deal-with
<bryce> jbarnes, on that bug I gather they hardcoded the h/v sync rates in xorg.conf to get their resolution
<tormod> bryce, great report there ;)
<bryce> bug 471246 is more typical
<ubottu> Launchpad bug 471246 in xorg "Screen resolution set to 800x600 or 600x480, Intel integrated" [Undecided,New] https://launchpad.net/bugs/471246
<pwnguin> RAOF: the only place where it's slow is with the UNR clutter UI
<bryce> jbarnes, ^ what do you think?  I'm not even certain what info is needed to debug such an issue
<jbarnes> xrandr --prop from a startup w/o an xorg.conf
<RAOF> pwnguin: Well, have you actually installed the DRI component?  Otherwise you're not really testing nouveau, you're testing how good mesa's software rasteriser is!
<jbarnes> that would tell us if it finds an edid at least
<bryce> jbarnes, wouldn't xrandr --verbose show the same?
<bryce> (that's what is attached by default)
<jbarnes> yeah that should have it, maybe I missed that
<bryce> oh wait
<bryce> checkbox seems to only use -q not --verbose
<jbarnes> oops
<bryce> wow, it's even more useless than I had thought
#ubuntu-x 2009-11-03
<pwnguin> RAOF: i guess i dont understand; i dont expect nouveau supports 3d on my laptop. should i?
<RAOF> pwnguin: Depends on your definition of "support", I think.
<RAOF> What I was actually getting at is "that's expected to be slow, because of no 3D".
<RAOF> Although, if your definition of "support" includes "probably works, but the developers still don't want bugs yet", then I believe that nouveau has sufficient 3d support for some devs to use compiz as their WM.
<pwnguin> all i was saying was it works fine everywhere one expects
<pwnguin> its a bit odd that UNR uses clutter, since ive never seen anything amazing animated via it
<AlanBell> morning all
<AlanBell> I am struggling with bug 428769
<ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor" [Undecided,Confirmed] https://launchpad.net/bugs/428769
<AlanBell> can anyone point me in the right direction to look at the code involved
<tormod> bryce, hi, do you plan syncing the xorg stack with Debian pretty soon?
<bryce> tormod, next week perhaps
<bryce> tormod, well, just depends on moving the box I'm on to lucid first ;-)
<tormod> ok, I guess "moving to lucid" just means upgrading a few packages for now :)
<tormod> is http://people.ubuntu.com/~bryce/Xorg/versions_current.html up to date?
<bryce> should be yeah
<bryce> although note it's not updated to lucid yet
 * bryce looks at the -nvidia bug list and shudders
<bryce> people are complaining a lot about -nvidia in forums and stuff, but it's unclear if it is a serious X error, or just mangled configs
<bryce> ugh, too many bug reports
<bryce> tormod, as we will be syncing from Debian testing, do you think this will cause any problems/confusion with xorg-edgers?
<bryce> hopefully not, guess we'll see
<tormod> bryce, there should be no big problem, since we don't have so many packages in xorg-edgers for Karmic
<tormod> it could have been a problem if a high-version package in xorg-edgers would "block" a Lucid package which has some needed Ubuntu patches
<tormod> actually the reason I brought this up is that I was thinking of seeding xorg-edgers/lucid with all the Debian stuff
<tormod> but then I might just wait for next week
<tormod> bryce, we need some AI for dealing with bug reports...
<tormod> apropos forum, I got a "forum warning" for RTFM'ing about xorg-edgers lol
<tormod> there are immense numbers of people subscribed to xorg-edgers (thanks to many "helpful" forum guides) which do not know what a PPA is, or how to install another version of a package etc
<bryce> yeah, i'm really getting frustrated trying to keep up with bug triaging
<bryce> heh, that's funny
<tormod> it's a great testament to upstream that git master is so stable - people were downloading their daily xorg-edgers crack as if it was normal package updates
<bryce> it's good the bleeding edge stuff is getting tested, but I wonder if people are using xorg-edgers too much as a "solution" rather than a testing tool
<tormod> only when -intel dropped UMS there was serious trouble...
<tormod> everything on the forums is a "solution" ;)
<bryce> ugh
<bryce> forum users seem like the worst bug reporters
<bryce> actually I've been thinking "bug report" is a bad term, it covers a whole range of different levels
<bryce> "complaint", "support request", "defect report", "change request"
<bryce> seems like most bug reports we see are towards the left end, but we need them towards the right before we can make action on them
<tormod> about forums: it's an own breed looks like, the forum is a bit separated from other Ubuntu venues. Got a private message from some people wanting to build up a new documentation structure in some closed-group fashion. wiki and doc team anyone?
<tormod> bugs: what about the "symptom" wizard in ubuntu-bug?
<bryce> yep, the apport-symptom stuff.  I added some logic there, but not sure if anyone has been using it
<bryce> my thinking though is that it would be able to handhold the user past the first two levels and be more likely to generate an actionable defect report
<tormod> is your apport logic enabled? it only asks about "storage devices"?
<bryce> dunno, I committed it to bzr but that may not have been uploaded to the distro yet
<tormod> guess not, just run "ubuntu-bug" and there are no "display issue" choice
<bryce> iirc it was the last thing I worked on before disappearing on paternity leave; I assumed pitti would upload it, but I never had a chance to look at it again after
<bryce> btw, the coding is quite easy, if you'd like to have a go at adding to it please do
<tormod> if it is working, maybe a SRU would be appropriate
<bryce> I would worry it might not be useful enough yet
#ubuntu-x 2009-11-04
<apw> bryce, tseliot, are we flodded with X issues on Karmic?
<tseliot> apw: we're always flooded with X issues :-) Anything in particular that concerns you?
<tseliot> (not all of them are real bugs)
<bryce> apw, it does seem we're getting more than normal; like tseliot said a lot of them are not valid
<apw> i saw the bug in which you were getting bashed and wondering if it was the tip of an iceberg or not
<apw> bryce, was trying to acertain if we are failing somewhere to turn off proprietry drivers cleanly enough to allow booting after upgrade or something?
<apw> which leads us into the gdm constant restart issue which is causing much complaining
<bryce> which bug was I getting bashed in?
<bryce> apw, it is possible
<bryce> apw, I've a sense something is wrong with -nvidia
<apw> the one about the proprietry drivers not letting them login, lots of flashing etc
<bryce> apw, like, did the kernel change and we forgot to rebuild it?
<apw> it got linked to slashdot
<bryce> oh?
<apw> yeah thats how i know about it
<bryce> hrm
<bryce> mvo, hey question on upgrades for you
<bryce> mvo, during the upgrade process, do the proprietary drivers get disabled?  I'm wondering if it is, then if it should also go ahead and remove the xorg.conf so the user doesn't hit problems on reboot.
<bryce> mvo, if it does not disable the drivers, perhaps it should do a reinstall in case there are xorg.conf changes needed - according to https://bugs.edge.launchpad.net/ubuntu/+bug/464591/comments/17 some people don't have busid listed there
<ubottu> Ubuntu bug 464591 in xorg "upgrade breaks graphic drivers and x, preventing login or startx" [High,Won't fix]
<mvo> bryce: it does not disable proprietary drivers
<mvo> bryce: but if after the upgrade the driver is no longer avaialble for whatever reason it will remove it from the xorg.conf 
<bryce> mvo, how does it do that removal?
<mvo> bryce: it comments them out (fglrx and nvidia are the ones that get checked
<bryce> mvo, does it just comment out the Driver line?
<mvo> bryce: it also creates a log file, so its easy to figure what it was doing ( /var/log/dist-upgrade/
<mvo> bryce: yes, just comments them out
<bryce> -nvidia installs several lines in addition to Driver, which I imagine could cause problems if -nv is used
<mvo> I think I asked about this a while ago and was told that unknown options will be ignored
<mvo> but I can't remember who it was I talked to :/
<bryce> hmm
<bryce> ok, thanks though, this could explain the failures we see
<bryce> I also would expect unknown options to be ignored though, so my guess may not be right
<mvo> well, we need more data, the bugreport is not great :/
<mvo> upgrade logs for a start
<bryce> mvo, how does it determine that the driver is no longer available?  I'm wondering if it may be that some upgrades are not noticing it
<bryce> yeah
<mvo> it simply check /usr/lib/xorg/modules/drivers/
<mvo> so it would have to be a chain of error a) nvidia driver no longer available b) xorg with options that cause "nv" to explode
<mvo> I asked for logs now
<mvo> the forums have:
<mvo> (EE) NVIDIA(0): Failed to load the NVIDIA kernel module!
<mvo> (EE) NVIDIA(0):  *** Aborting ***
<mvo> with instructions like this:
<mvo>     * Boot from the install disk into recovery mode
<mvo>     * download from nvidia.com the NVIDIA-Linux-*.run for your hardware and copy it to your PC (I did it with a second PC and transfered via scp)
<mvo>     * run the NVIDIA-Linux-*.run
<mvo>     * Follow the instructions
<mvo>     * reboot
<mvo> its no wonder it breaks on every upgrade :(
<mvo> what can we do to detect situations like ?
<bryce> hmm
<bryce> do you think they had hand-installed nvidia previously?
<mvo> hard to say, but at least one of them suggests it
<mvo> maybe tseliot knows if there is a way to reliable detect this 
<mvo> hm, I have a testsystem where I can try that I think
 * mvo searches for a old nvidia card
<bryce> apw, 438398 looks like an actionable nvidia bug
<apw> bug 438398
<ubottu> Launchpad bug 438398 in nvidia-graphics-drivers-180 "DKMS build fails, but package upgrade still successful" [Undecided,Triaged] https://launchpad.net/bugs/438398
<apw> yeah it does, i assume we should have a dep on the package for the tools it needs
<apw> though its possible it filaing to install is ok
<apw> as you can install the package kernel headers and kernel image in any order
<apw> and it should build on the last one installed i think
#ubuntu-x 2009-11-05
<johnf1911> a friend of mine is having a problem with the intel X driver on karmic
<johnf1911> sometimes, after suspend and resume, his display doesn't come back
<johnf1911> like it stays suspended
<johnf1911> this is on a lenovo X200s
<johnf1911> in dmesg, we get this lovely output
<johnf1911> http://paste2.org/p/500664
<johnf1911> this is where the fun starts: INFO: task i915/0:358 blocked for more than 120 seconds.
<johnf1911> we can ssh into the system after the failure
<johnf1911> though killing X still doesn't appear to solve the problem, it doesn't successfully restart
<johnf1911> bryce: ^ jcastro suggested you might be able to help
<johnf1911> one final item of note, the machine has two displays, and internal one as well as a second connected via "HDMI" (actually displayport in the ultrabase to a DVI converter to a panel)
<johnf1911> both displays blank when we have the issue
<tseliot> johnf1911: can you reproduce the problem when the external screen is not connected?
<johnf1911> hmm
<johnf1911> I'll ask him to remove the screen and test
<tseliot> it looks like it's failing to read EDID
<tseliot> i2c-adapter i2c-2: unable to read EDID block.
<tseliot> i915 0000:00:02.0: HDMI Type A-1: no EDID data
<johnf1911> I take it there are known problems like this one?
<johnf1911> those messages are a long time before the error
<johnf1911> 3840seconds after boot versus 40
<johnf1911> I don't believe that's related, it's probably at gdm/X startup
<tseliot> if you want to get modes you usually try to get EDID first
<tseliot> also your /var/log/Xorg.0.log should have interesting information (after reproducing the problem)
<johnf1911> there's nothing in Xorg.0.log
<johnf1911> when he runs the machine at home, without the second display, he's never seen the issue
<johnf1911> he's going to explicitly test it tonight to be sure though
<johnf1911> so it may be related to dual head
<tseliot> ok
<tseliot> johnf1911: also it would help if he could follow these instructions: https://wiki.ubuntu.com/X/Backtracing#Using Screen to get backtraces for Suspend/Resume crashes
<johnf1911> ok
<johnf1911> if it crashes again today (seems to be once every 2 days, though it may relate to how often he's away from his machine) we'll do that
<johnf1911> I think he's disabled display suspending
<johnf1911> so if it's related to that we won't have a crash, but we will know that it may be related
<johnf1911> thanks for your help
<tseliot> np
<tormod> jcristau, what are the rules (or best way) when upstream ships no configure, run autoreconf in debian/rules and/or add the generated files to orig.tar.gz?
<bryce> tormod, autoreconf is likely better
<tormod> bryce, ok but I see sometimes generated stuff added to the tarball, and googled up some comments about being able to build the package on a less equipped system and so on
<tormod> you know it's Debian when they talk about end-users running configure :)
<bryce> heh
<bryce> well, the autoreconf stuff would be run on the build system, not on the user's system (if I'm understanding the issue right)
<bryce> yeah I've been known to just redo the tarball with the config stuff in it myself, however I consider that pretty kludgy
<hyperair> tormod: autoreconf in debian/rules prior to configure, make maintainer-clean afterwards in the clean rule of debian/rules
<hyperair> i think that's the general approach
<hyperair> or rm -rf Makefile.in after make distclean
<bryce> the debian way is to ship the tarball as distributed by upstream, with no changes
<tormod> bryce, that's what I have heard also, but not what I have seen
<tormod> jcristau, if you have time to review, it is about http://git.debian.org/?p=collab-maint/intel-gpu-tools.git;a=summary
<tormod> RAOF, are your nouveau packages just upstream git + last ubuntu packaging?
<tormod> RAOF, ddx I mean
<RAOF> tormod: Yes they are.
<RAOF> Actually...  let me check the changelog. :)
<RAOF> tormod: Yes, yes it is.  The DRM component isn't, but the DDX is.
<tormod> RAOF, then I can just add it to my auto-xorg-git/update-ppa job
<tormod> the only catch is the version, you used git+2009, auto-xorg-git uses git2009 :)
<tormod> I can add a tweak for that to my nightly script and drop it when we have 0.11
<hyperair> tormod: you've got a nightly git building script?
<hyperair> may i see?
<hyperair> i might be able to use a few parts for my banshee daily script
<hyperair> (which doesn't handle anything other than karmic atm)
<RAOF> tormod: Sweet.  I was meaning to automate the nouveau uploads at some point, I just haven't got around to it.
<tormod> hyperair, it uses the auto-xorg-git so it will probably not help much for banshee
<tormod> and I still have to run it and type in my gpg key
<hyperair> ah
<hyperair> i've solved my gpg problems ;-)
<hyperair> with a little help from seahorse and alarm-clock-applet
<tormod> well since I use my personal gpg key it is not a problem but a feature that I have to enter it :)
 * hyperair pulls out the auto-xorg-git script from bzr
<tormod> but I would use a more loose key for some autobuilder thingy
<hyperair> tormod: well yes, i have to enter my passphrase as well. i just got it automated in the sense that it'll automatically run and prompt me
<hyperair> alarm-clock-applet inherits the GPG_AGENT_INFO from my gnome-session and runs the script at midnight, then seahorse bugs me for the passphrase
<tormod> hyperair, sure,  I have all that set up, and I use the seahorse(?) caching so I only type it once
<hyperair> ah. haha
<tormod> for anyone curious this is the script I run (almost) every night to keep xorg-edgers up to date: http://ubuntu.pastebin.com/m64eaaf69
<hyperair> ah auto-xorg-git manually creates the tarball eh
<tormod> I guess I will push it to the bzr repo as well
<hyperair> hmm interesting
 * hyperair uses git-buildpackage to build tarballs
<tormod> I got quite a bit of things automated there that took hours in the early xorg-edgers days
<hyperair> that's cool
<tormod> hyperair, we could maybe use git-buildpackage here also, but it works as it is
<hyperair> yeah
<pwnguin> eventually, you guys are gonna reinvent gentoo
<hyperair> ?
<hyperair> why so?
<hyperair> http://pastebin.com/f660a0a8 <-- this is my banshee building script
<tormod> pwnguin, we publish binaries...
<hyperair> pwnguin: by building we really mean preparing source packages to upload
<pwnguin> build everything from git head source
<pwnguin> i know
<hyperair> the difference is that we have our binaries all built in one place
<pwnguin> thats how it starts
<hyperair> so users don't have to go about wasting the world's precious energy compiling
<pwnguin> then one day someone decides they want to override the C FLAGS env var
<hyperair> unlike gentoo users >_>
<tormod> pwnguin, we stay close to the normal distro packaging, no CFLAGS tweaking etc
<hyperair> that's when they switch to gentoo. ubuntu will never become a source-based distro.
<bryce> hyperair, I think we lack sufficient drama to reinvent gentoo
<hyperair> bryce: strongly agree. =P
<tormod> hyperair, some nice use of git log in your script, instead of my sed/awk hackery
<hyperair> tormod: hahah thanks.
<hyperair> well i've no idea how to use awk =p
<hyperair> so i kinda make do with sed
<pwnguin> that never stops anyone
<hyperair> well yes, there are great possibilities with sed.
 * hyperair has never needed to learn awk
<pwnguin> Some people, when confronted with a problem, think
<pwnguin> âI know, I'll use regular expressions.â   Now they have two problems. 
<tormod> RE rulez
<hyperair> xD
<hyperair> that's a nice quote.
<pwnguin>     âIf you have a problem and you think awk(1) is the solution,
<tormod> it's the cellular automata of information processing
<pwnguin>     then you have two problems.â 
<hyperair> but yeah, RE rules.
<hyperair> pwnguin: then it's the same, isn't it? =p
<tormod> ok enough fanboying
<pwnguin> hyperair: predates RE
<pwnguin> "      make(1) is employed sparingly for very simple scripts. sed(1) only required to deal with yacc(1) defi-"
<pwnguin> ciency, namely eliminating name clashes. awk is used once in the bootstrap to perform a relatively simple task
<pwnguin> that should probably be done using ed(1), since: ââIf you have a problem and you think awk(1) is the solution,
<pwnguin> then you have two problems.ââ - David Tilbrook
<pwnguin> doh
<pwnguin> i'll stop
<hyperair> heheh
<hyperair> hmm i should probably make better use of set -e in my script
<hyperair> rather than those kludgy || return 1s
<tormod> hyperair, or at least chain them with &&
<tormod> bryce, I was thinking I would help out with bringing mesa git up to date
<tormod> I looked at bzr-fast-export and git-fast-import but could not really get it working so I scripting up something else
<bryce> tormod, that would be great
<bryce> fwiw, I probably won't be much help with xorg-edgers this cycle; I suspect for the LTS our eyes are going to be too far behind bleeding edge
<tormod> bryce, won't be done today, but I hope to get it done over the weekend
<bryce> kewl
<tormod> bryce, ok but please try to push radeon KMS
<bryce> yep that's the plan
<tormod> although not officially EOL'ing it, upstream seems to care less about non-KMS issues
 * bryce nods
<tormod> but you are aiming for mesa 7.7 at least?
<bryce> not decided yet
<bryce> if it makes it by the end of the year, quite possibly
<bryce> if it's late into next year, though, we may have to pass
<tormod> xorg 7.5 (and xserver 1.7) I guess since it's already in Debian
<bryce> yeah I think we'll be looking very strongly at what is in Debian Testing at chrismastime
<tormod> so you are not gonna sync everything in experimental at this point?
<tormod> I mean if there are things there which might not make it for Testing before Xmas
<bryce> dunno yet, I'm still kind of consumed by karmic stuff at the moment
<bryce> but I definitely intend to be more conservative this time through
<bryce> there's trade offs though
<bryce> the goal of LTS is not to have ancient stuff but rather to have stable stuff that can be supported well going forward
<bryce> in some cases the bleeding edge stuff *is* the best choice as it's gotten the most debugging and is more likely to be relevant upstream
<bryce> in other cases where a lot of development work has gone on compared with the level of testing, it may be safer to hold back a bit
<bryce> at this point I'm not sure where the line needs drawn, component by component, and I hope folks can help give good advice so we can make smart decisions on all of this
#ubuntu-x 2009-11-06
<Ng> has anyone else started seeing weird X crashes and kernel panics in karmic?
<Ng> my laptop's done it three times this evening, but not before
<Ng> nothing makes it to logs, and even though I get dumped to a console, there's no panic output there
<bryce> Ng, nope
<bryce> Ng, you could check launchpad
<Ng> bryce: I had a quick poke and didn't see anything
<bryce> -intel has been super sturdy here
<bryce> I've got 3 laptops running it with no problems
<Ng> it has been for me too until today. I re-installed with RC and I think I've only rebooted once since then, until I shut the laptop down last night, so some of -updates would only really have started running today, but looking at the logs it's all really boring stuff ;)
<Ng> it's weird that I get a console and a wedged kernel (flashing capslock) rather than just a hang in X, and there's no oops text
<bryce> did you talk with the kernel guys about it?
<Ng> not yet, they're my next stop
<Ng> and I'm going to check in with jerone/lool/robbiew tomorrow, all of whom have the same laptop as me
<bryce> ok
<bryce> out of curiousity, what made you check here first and then kernel?
<Ng> I think because it seems like X dies
<bryce> (a lot of people do this, but since there's more of them than me I'm wondering how to switch things around)
<Ng> heh, this is a fair point :)
<bryce> yeah as a general rule if you have a kernel failure, start by solving that.  A kernel fault could easily be the cause of X failing
<jg> Ng: or you may have DRAM failures, or the like...
<Ng> jg: the thought has crossed my mind, I think I'll leave the thing memtesting while I sleep
<jg> Ng: diagnostics are first written to prove hardware works....
<jg> (I guess I'm jaded on the topic...)
<Ng> hah
<jg> but certainly, if it shows problems you have problems.
<jg> Ng: I had DRAM problems on a microvax II once upon a time: the problem would only occur if the system was idle.
<jg> turns out that the DRAM manufacturer had left a wire off the chip; only if you never referenced the chip would it not get refreshed, and you'd see the failure first thing in the morning when you started to use the machine again.
<jg> would run diagnostics forever.  Digital had to hold up shipment of Microvax II's several months while this was figured out.
<jg> I happened to be the person who figured out that the systems only failed first thing in the morning after being idle all night....
<jcristau> bah no tormod.
<tormod> bryce I am getting there: http://git.debian.org/?p=users/tormod-guest/mesa.git;a=summary
<bryce> sweet
<tormod> some of the commit diffs are ugly because they include the upgrade of the upstream version
<tormod> and others are ugly because there is stuff in the package (tarball I guess) which is not in git (WINDOWS/ etc)
<tormod> but just to get up to date, maybe it is good enough
<bryce> tormod, maybe it needs a script to handle doing it (does debian have something?)
<tormod> bryce, I googled quite a bit before I started on it of course. I tried bzr-fast-export/git-fast-import but it failed, I don't know if
<tormod> that would handle upstream merges better
<tormod> oh I suddenly understood one reason it failed: git tags are more restricted than bzr tags
<bryce> oh?
<tormod> can not have "~" in a git tag AFAICS
<jcristau> tormod: fwiw, if you still want a review/comment on that thing from yesterday, mail works better.
<tormod> jcristau, thanks, yes. just mail me your comments if you want
<jcristau> no, i mean send me a mail if you want me to look at something :)
<tormod> jcristau, I'll do that the next time :)
<jbarnes> bryce: ping
<jbarnes> bryce: wanted to make sure you picked up http://lists.freedesktop.org/archives/intel-gfx/2009-November/004762.html
<jbarnes> along with the other ironlake fixes Zhenyu sent out (http://lists.freedesktop.org/archives/intel-gfx/2009-November/004758.html)
<bryce> jbarnes, thanks
<bryce> jbarnes, yeah I'm currently distracted from -intel due to -nvidia bugs, but am adding that to my todo list
<jbarnes> my ironlake desktop machine is pretty happy with karmic with those bits
<jbarnes> bryce: no problem, just wanted to make sure you saw them
<bryce> thanks
<bryce> yeah it seems (so far) that we've sped up boot speeds to the point that X can start booting before nvidia.ko has finished building.  whoops.
<jbarnes> heh
<jbarnes> good problem to have
<bryce> heh, not if you're active on ubuntuforums apparently
<tormod> bryce, is that why fedora is twice as fast as Ubuntu on nvidia according to Phoronix?
<bryce> tormod, with that opengl test?  nfi
<jbarnes> nv vs nouveau?
<bryce> last time I looked into one of the performance regressions they "found" it ended up being just too crackful to get any useful info out.  No one else had the same trouble.
<jbarnes> or nv vs nvidia? :)
<tormod> they installed nvidia drivers manually on both systems
<tormod> wonder what it would look like if they used jockey instead
<bryce> wish they published their tests in a way that was more easily reproducible
#ubuntu-x 2009-11-07
<cwillu> what fires graphics-device-added?
<bryce> dunno
<superm1> bryce, the new failsafe X stuff still isn't working in proposed
<superm1> trying to run sudo /etc/gdm/failsafeXServer gets me: http://pastebin.com/f41d318f3
<superm1> probably because dexconf doesn't do anything?
<bryce> could be
<bryce> that error prints if    /etc/gdm/failsafeDexconf $driver $xorg_conf_failsafe   fails
<bryce>   /etc/gdm/failsafeDexconf vesa /etc/X11/xorg.conf.failsafe
<bryce> what happens when you run that?
<superm1> returns error code 10
<superm1> no file created
<bryce> 10
<bryce> huh
<bryce> well maybe instead of generating an xorg.conf we should just provide a default one to slap in
<superm1> here's why http://pastebin.com/f28e82dc7
<superm1> i think just providing one is indeed the best solution
<superm1> and then during lucid we can have casper just grab that failsafe one when safe graphics mode is activated
<bryce> RET=10 xserver-xorg/config/device/driver doesn't exist
<bryce> yeah debconf just isn't seeded with the stuff we need anymore
<superm1> here's a bug to track this: https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/477149
<ubottu> Launchpad bug 477149 in xorg "Failsafe X support added in proposed upload still doesn't work" [Undecided,New]
<bryce> superm1, btw, I started page https://wiki.ubuntu.com/X/Bugs/Nvidia to keep track of the nvidia.ko failures.  Also see bug 453365
<ubottu> Launchpad bug 453365 in gdm "dkms should start before gdm if needed for video driver" [Low,New] https://launchpad.net/bugs/453365
<superm1> bryce, well actually nvidia.ko really shouldn't work here.... this is virtualbox :)
<superm1> i intentionally used it to try to test the bulletproof-x kicking in
<superm1> but that is another problem as anders is raising
<superm1> i think the only way to solve it is to introduce an upstart job for DKMS to ensure gdm doesn't try to start up until the DKMS upstart job is done
<bryce> can you review my proposed release note text on bug #474917 about the issue?
<ubottu> Launchpad bug 474917 in nvidia-graphics-drivers-180 "nvidia drivers 185.xx compile into kernel 2.6.28 instead of 2.6.31 on update from jaunty to karmic" [Critical,Triaged] https://launchpad.net/bugs/474917
<bryce> superm1, yeah you may be right.  I'm not certain if we could get an upstart job for that rolled out as an sru.  Probably worth trying though
<superm1> well you got one rolled out for the failsafe-x stuff (albeit not working :P)
<bryce> btw, on that bug they believe it is not a race condition but rather that dkms is targeting 2.6.28 and not 2.6.31, and not getting triggered at all on the boot
<superm1> well that compilation to 2.6.28 is caused by the way the postinst for nvidia-185-kernel-source operates
<superm1> but it should have gotten built against 2.6.31 later during the kernel.postisnt.d
<superm1> i think it's best to at least attempt to serialize the DKMS build process to happen before GDM, it's not just a race condition, it's two things that shouldn't be running in parallel
<superm1> longer term, slangasek's proposal for having a DKMS dpkg trigger might be a good idea too
<bryce> could be, I didn't quite grasp the full workings of the concept there
<superm1> the basic idea is that every package that would normally run DKMS in it's post install just registers a trigger to defer the DKMS run
<superm1> once dpkg finishes everything else, it's last thing to do is process those triggers
<bryce> ahh
<superm1> it's the same stuff that causes the initrd to only be rebuilt once when you install 15 things that normally like to live in the initrd
<bryce> yeah that makes sense
<superm1> definitely if you don't already have some spec for UDS to talk about this kind of stuff, can you make one?  there's tons of these little things that can probably help a lot with the breakage that can be done for lucid
<bryce> yeah not a bad idea
<superm1> by then hopefully should have a good idea of where most of the breakage is too to make for good discussion points
<bryce> just wish it didn't mean I have to write a spec afterwards ;-)
<superm1> well i'll help with the DKMS and any casper bits
<superm1> http://pastebin.com/f229bfe21
<superm1> just tested that, and it looks like it properly serializes DKMS before GDM
<superm1> i'll try to test that on real hardware early next week.  i've got a few other bits to fix for DKMS too that i'll try to squeeze into the same SRU upload
<bryce> ok cool
<bryce> I've got company this weekend, and will be on vaca wed-fri but will have mon/tue
#ubuntu-x 2009-11-08
<superm1> bryce, why do you keep changing the package on bug 477149 ?
<ubottu> Launchpad bug 477149 in nvidia-graphics-drivers-180 "Failsafe X support added in proposed upload still doesn't work" [Undecided,Confirmed] https://launchpad.net/bugs/477149
<superm1> the failsafe stuff comes out of xorg...
#ubuntu-x 2010-11-08
<RAOF> Well, looks like kernel panic output on radeon kms worksâ¦
<RAOF> Well, that was rather silly.  Yes, --fvisibility=hidden *does* make it hard to link against those symbolsâ¦
<ScottK> RAOF: FYI, we have the 'fix' for Bug 628930 in hand, just waiting for upstream review: http://reviewboard.kde.org/r/5774/diff/#index_header
<ubot4> Launchpad bug 628930 in mesa (Ubuntu Maverick) (and 4 other projects) "[i945GME] KDE Desktop effects not active by default (affects: 14) (dups: 1) (heat: 122)" [High,Fix released] https://launchpad.net/bugs/628930
<Sarvatt> bryceh: what was the link to the right versions_current.html on http://www2.bryceharrington.org:8080/ again? new pc and I only have http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html bookmarked
<Sarvatt> evdev and synaptics merges are looking to be "fun"
<Sarvatt> pretty significant changes in both since we used the same version all through lucid and maverick and lots of gesture patches
<bryceh> Sarvatt, http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html
<Sarvatt> bryceh: thanks! /X/ just took me to a fake LP page so I couldn't browse and http://www2.bryceharrington.org:8080/X/reports/ didn't work (whoops)
<bryceh> yeah I should fix that
<bryceh> but not today... way too many things to do already :-)
<bryceh> btw I got wayland packaged finally last night
<Sarvatt> nice!!
<ion> Nice
<Sarvatt> you want to disable the ARB_fragment_shader disabling patch in mesa for it btw
<bryceh> https://launchpad.net/~xorg-edgers/+archive/wayland/+packages
<bryceh> oh?  whyso?  any other mesa tweaks needed?
<Sarvatt> cairo-gl depends on that on 915-945 to work
<bryceh> I've not tested this out at all yet
<Sarvatt> shouldn't be any other mesa tweaks needed
<Sarvatt> hmm
<Sarvatt> actually Im not sure if you need to pick the drm backend or EGL for it to work on intel
<Sarvatt> on EGL rather
<bryceh> btw I'm basing this off of your mesa git snapshot from the 4th
<bryceh> does that have the patch?  I'm not spotting it offhand
<bryceh> Sarvatt, well there is one mesa/gallium issue I could use your help on
<Sarvatt> ahh I dont add that patch in edgers, thats right
<bryceh> Sarvatt, http://lists.freedesktop.org/archives/wayland-devel/2010-November/000068.html
<Sarvatt> yeah thats exactly the problem I thought you'd have
<Sarvatt> need to select the drm backend for egl in a launcher script
<bryceh> how?
<Sarvatt> unpacking my intel now to see how I've been doing it :)
<Sarvatt> its just an env variable
<Sarvatt> actually its in the mesa egl docs, that'll be faster. one sec
<Sarvatt> EGL_DRIVER=egl_dri2 yourapp
<bryceh> ok yeah I think that may be in the directions already
<bryceh> actually doesn't appear to be
<Sarvatt> its only for intel, everything else wants to use the default gallium backend
<Sarvatt> ah yeah build guide is saying to not build gallium at all so its used automatically on intel
<bryceh> yeah unfortunately when I flip gallium off I get build errors
<bryceh> so I've built mesa with gallium on
<bryceh> which means it probably won't work...
<Sarvatt> so, do we want to ship mesa 7.10 snapshots until release or just wait until december and do the real release and have things potentially change drastically all at once?
<ScottK> If you know you're shipping 7.10, the sooner you have something that ~works and you can switch the better.
<ScottK> (IME)
<bryceh> really, it depends on how much we want to be doing bug report management / forwarding
<bryceh> if we definitely do want to engage heavily with bug reports, then period snapshots make lots of sense
<Sarvatt> december is close enough that waiting might make sense, just worried about repeat the 7.9 problems. getting 7.9 in early wouldn't have mattered though because all the glx problems we hit were introduced a few days before our first snapshot :)
<bryceh> between what's queued up on my todo list and time I'm taking off this month I think I'm unlikely to be contributing much bug time this month.
<bryceh> but I'm going to try to get my bug forwarding tool stuff up and running by the end of the month, which should help make forwarding a lot simpler
<bryceh> Sarvatt, I imagine you and raof are probably also going to similarly be busy with stuff so won't be forwarding or following up on bugs this month, in which case it may make sense to hold off on snapshots
<bryceh> or, put out a call for testing of mesa in xorg-edgers on ubuntu-x@, with directions to file bugs upstream
<RAOF> We should start shipping 7.10 snapshots at *some* point, but I don't think that has to be now.
<Sarvatt> whoa, its weird having the aussies be online so early today :)
<RAOF> 8:30?
<RAOF> That's our normal start time :)
<RAOF> Oh.  Have you dropped out of summer time?
<Sarvatt> its 4:30 PM here
<bryceh> yeah we gained an hour yesterday
<Sarvatt> usually didn't see you guys on until closer to 7PM :)
<bryceh> btw what's the state of xorg-edgers?  Is it on track for what we plan to ship for natty?  If so, would it be helpful to steer folks to start installing and testing on that?
<bryceh> (helpful to us specifically)
<RAOF> I'll let Sarvatt take most of that question, but I know it hasn't flipped to Xserver 1.10.
<RAOF> It does have a useful mesa snapshot, though.
<Sarvatt> I'm not sure its late enough in the dev cycle to start shipping xserver 1.10 yet
<Sarvatt> I could if it'd be useful though but I wouldn't recommend it, been worrying about getting natty up to date today and been out of town the past 2 weeks :)
<RAOF> Actually, that raises a question: how are we doing on the âeverything should depend on xorg-video-abi-$Xâ front?
<Sarvatt> its painful having the abi broken constantly and people using it will hit periods where their system is unusable while all of the packages are fixed and uploaded and built
<RAOF> Yeah.
 * bryceh nods
<RAOF> At the moment it'll be more useful to be testing mesa from there, rather than X.
<bryceh> one other thing to think about, we may want to hold off major updates until after the holidays.  not much use in risking leaving people's systems broken over the holidays and just racking up bunches of bug reports.  ;-)
<Sarvatt> not sure a call for testing makes much sense until the abi is close to being finalized, but we could be putting a lot of the other components in x-updates
<bryceh> but guess it depends on when things start rolling in
<Sarvatt> like libdrm/ddx/mesa updates
<bryceh> *nod*
<bryceh> getting them all queued up and set up for people to test by xmas break would be a good goal
<bryceh> then depending how that turns out, slam them in Jan 2nd
<Sarvatt> sounds good, break things just in time for the plane trips to the sprint :)
<bryceh> or if they look bad, we can hold off until the sprint, work on it there, and then upload during the sprint or after depending on how brave we are ;-)
<RAOF> I've preciently planned ahead; I fly to the sprint a week early, so we can be staggered :)
<bryceh> generally in the past I've waited until the week after the sprint to upload the major changing bits
<Sarvatt> RAOF: noticed that on the wiki, taking a vacation first or is there another sprint before?
<bryceh> that way I minimize people bugging me during the sprint.  but with 3 of us there maybe we would like being bugged about stuff, where we can put our hands on the machines...?
<RAOF> Sarvatt: Vacation; A bunch of ex-Hobartians are catching up for some D&D :)
<bryceh> RAOF, awesome
<bryceh> a week of D&D?  gaaaa
<Sarvatt> at the latest the major changes will all be in in febuary, 2 months to stabilize is quite a bit better than natty at least!
<RAOF> bryceh: I liked uploading xserver-xorg-video-intel with the re-enabled pageflipping at the Prague sprint; its' nice to have the hardware on hand for that sort of simple ânoâ :)
<Sarvatt> RAOF: bryce just sponsored a natty with page flip reenabled a bit ago :)
<Sarvatt> need to keep an eye on the bug reports
<RAOF> Well, now we get to see whether 2.6.37 has all the hangs worked out :)
<bryceh> Sarvatt, actually I only uploaded that to wayland
<Sarvatt> bryceh: https://lists.ubuntu.com/archives/natty-changes/2010-November/001141.html
<bryceh> Sarvatt, oh that upload
<Sarvatt> bryceh: ohh just noticed the changes to the changelog, ChangeLog is no longer shipped in natty btw!
<Sarvatt> all upstream ChangeLogs are stripped at build time now to save cd space
<bryceh> Sarvatt, yeah another reason I think it's worthwhile to put highlights into debian/changelog
 * Sarvatt nods
<bryceh> not that I think many users read changelog info...
<Sarvatt> will be sure to do that from now on
<Sarvatt> I get too sloppy when I go into mass update mode, need to work on that :)
<bryceh> I used to also peruse the bug list to see if I could match up bug #'s to issues fixed in the upstream upload
<bryceh> however that's *quite* time consuming, esp. with our glut of bug reports now
<RAOF> I still do do that.
<bryceh> I like seeing the auto bug closures :-)
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=a44a63d2ff6c01c3dc61de6f736dd441ddd25e52
<Sarvatt> we need that *so bad*
<bryceh> also it used to be that brian maintained a list of "uploaders with most bug fixes" which looked only at bug #'s listed in changelogs, so was fun to try to get to the top of that list
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/?field.searchtext=IPEHR:+0x01820000&orderby=-importance&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_
<Sarvatt> no_package=
<Sarvatt> all of those are fixed by that commit
<bryceh> Sarvatt, small enough patch
<Sarvatt> the IPEHR: 0x01820000 bugs against intel
<bryceh> any risks to it?
<bryceh> or performance hits?
<Sarvatt> only reason I didn't cherry pick it is because intel 2.13.901 will be merged soon with it
<bryceh> well, would it be SRU-worthy?
<Sarvatt> but need to try backporting it to 2.12 and have maverick people test
<RAOF> It looks like the non-trivial code should only be hit on modeswitch, which isn't exactly in the hot-path.
<Sarvatt> not really a performance problem, it happens on dpms events, lid closing, suspend/resume, etc
<Sarvatt> enabling new monitors
<RAOF> It looks like a perfect candidate for an SRU, in fact.
<Sarvatt> that is a *major* problem though, one of the 3 major actual bugs apport caught
<bryceh> sorry, system locked up.
<bryceh> ironically
<bryceh> it sounds worth SRUing to me as well
<Sarvatt> x11-apps is painful, every single app has linking problems on natty
<bryceh> hrm
<Sarvatt> on the plus side maybe squeeze will ship over christmas and we can do the xserver 1.10/mesa 7.10 stuff directly in experimental
<RAOF> We should ask if we can do that regardless.
<RAOF> In fact, I'll send an email to that effect right now.
<Sarvatt> its occupied largely with xorg 7.6 releases at the moment
<RAOF> Do they care about the katamari particularly?
<Sarvatt> i'm trying to help out as much as I can there merging stuff in git, KiBi is going nuts releasing everything \o/
<Sarvatt> I do at least!
 * Sarvatt ducks
<Sarvatt> is it just me or does applying for PPU for all of X seem like a crazy idea?
<ion> PPU?
<Sarvatt> per package uploader
<ion> ah
<Sarvatt> bryceh: alrighty I'll backport libdrm and x-x-v-intel into x-updates as soon as we get 2.13.901 in, I just hate updating libdrm in there because all of the packages pick up the new libdrm dependency
<Sarvatt> by now I would hope a majority of people have figured out you cant just install single deb's from most PPAs :)
<ScottK> Sarvatt: It's probably enough packages that it might be worth creating a packageset for it.  
<bryceh> Sarvatt, don't apply for PPU, just shoot for gaining MOTU and core dev
<bryceh> the requirements for core dev are mostly about earned trust
<Sarvatt> well MOTU is what I was unsure about, I was thinking it might make more sense to apply for PPU for the few X packages that are perpetually merged instead of synced if anything
<bryceh> most anyone who does a lot of X uploads with care to not break stuff has demonstrated a sufficient amount of trust
<Sarvatt> there are admittedly not many packages in universe that I would end up taking care of, X/mesa/libdrm stuff takes up all my time and then some
<bryceh> Sarvatt, I think you more than sufficiently qualify for MOTU, but if it makes you feel more comfortable, do a dozen or so merges off of https://merges.ubuntu.com/universe.html and get them sponsored by pitti and one or two other guys
<bryceh> most merges should be pretty trivial for you, probably you can bang them out in a couple hours ;-)
<Sarvatt> I need more experience in non-xsfbs packages for sure, spoiled by the awesome xsfbs
<bryceh> if none of the universe packages look interesting, there's also tons of stuff at https://merges.ubuntu.com/main.html
<Sarvatt> so yeah I guess you're right MOTU is the way to go
<bryceh> at this point early in the release, it's easy to do merges since we're not yet frozen, so can be a good idea to spend an afternoon a week just doing some non-X merges and gain sponsors to give testimonial
<bryceh> next membership board meeting is the 22nd - https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
<bryceh> Sarvatt, RAOF, I think both of you ought to plan on attending to up your permission levels.
<bryceh> todo list for what you two need to do is at  - https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
<Sarvatt> yeah, I'll fill out my application this week, started a skeleton some time ago https://wiki.ubuntu.com/Sarvatt/MOTUApplication
<bryceh> and more info about expectations/abilities at https://wiki.ubuntu.com/UbuntuDevelopers
<bryceh> Sarvatt, yep
<Sarvatt> darn, looks like https://edge.launchpad.net/~sarvatt/+uploaded-packages only lists 1 upload per package per release when I've had multiples in a bunch of those
<bryceh> Sarvatt, I'm sure there must be a way to get the history
<bryceh> Sarvatt, btw see persia's comments on #ubuntu-devel
<bryceh> sounds like you should go for either MOTU or PPU, then use that as stepping stone to core-dev
<Sarvatt> argh, I knew I forgot to add a channel to auto-join on this new pc!
 * Sarvatt reads the logs
#ubuntu-x 2010-11-09
<Sarvatt> bryceh: wow, thank you very much for that endorsement! I haven't even filled out the application yet! :)
<bryceh> no prob
<bryceh> you can probably hit pitti, raof, and tjaalton up for them too I'd imagine.  Might be worth getting one from a non-X guy too if you know anyone
<bryceh>  "Wayland+Unity = Weyland-Yutani?"
<ion> hah
<ion> The combination should have a similar logo, but with a U in the background instead of the V. :-)
<ion> instead of the Y i mean.
<RAOF> Come on, build!  Poppa needs a new libdricore!
<bryceh> man, airlied is harshing on anyone with a ubuntu bent on #wayland
<bryceh> (and after mark's announcement, there's a *lot* of ubuntuers on #wayland)
<RAOF> I should probably add #wayland to my list of idling channels.
<bryceh> it's been rather humorous the last few days
<bryceh> TONS of newb questions.  "When will Ubuntu be moving to Wayland?"  "What the difference between X and wayland?"  "How does Wayland handle network transparency?"
<RAOF> MAGIC!
<ion> Hah
<RAOF> But you could actually do some rather funky network transparent stuff with fake drm devices if you wanted to.
<bryceh> randomly, I discovered two other canonical folks interested in doing wayland-related work on the channel, whom I'd never met or known before
<bryceh> yeah the n.t. stuff is a faux issue
<RAOF> I know Robert Ancell is interested in making lightdm work for wayland.
<bryceh> but if you're a magazine author, it makes it sound like you understand deep X jujitsu if you mention it
<RAOF> :)
<ion> I think it would be great for X to be a thin layer that draws Wayland windows, in equal position with native Wayland programs as well as implementations of other networked UI protocols. Adequately small programs that do one thing as well as possible, Unix style. :-)
<RAOF> You can run X as a wayland client right now; there's even some work to make it more performant in that case.
<ion> cool
<ScottK> Sarvatt: If you have something that needs sponsoring, let me know.  Then I could comment on your application as a sponsor (which carries more weight).
<bryceh> Sarvatt, http://launchpadlibrarian.net/58860810/buildlog_ubuntu-maverick-i386.xserver-xorg-video-intel_2%3A2.12.0-1ubuntu6~bryce_FAILEDTOBUILD.txt.gz
<ricotz> stgraber, hello, is there a new (minor) release of ltsp planned? will it be compatible with lucid?
<stgraber> ricotz: nothing is planned so far for lucid, though I know a colleague of mine backported my upstream snapshot of LTSP (ldm and ltsp) to lucid (currently in https://launchpad.net/~mgariepy/+archive/backports for testing, will be copied to https://launchpad.net/~revolution-linux/+archive/ppa once tested)
<stgraber> ricotz: once it's copied in ~revolution-linux, it means that my company is using it in production and that most features will have been tested
<stgraber> ricotz: we know that the current package has a small bug with ltsp-remoteapps (new feature we implemented last week) but should be fixed upstream this afternoon and backported again
<ricotz> stgraber, thanks for answering, i would use them in a critical environment, currently i use the maverick packages comiled under lucid
<ricotz> stgraber, i saw there was quite some progress since the latest release, so i was just curious
<ricotz> stgraber, so there no dependency changes which arent available with lucid
<ricotz> stgraber, introducing new features in a micro release update doesnt sound that good, arent there any sru update considered?
<stgraber> ricotz: well, sru are there for bugfixing and I'm not really sure of what I'd bugfix in lucid. For our customers we usually work with the PPA as we can do our changes upstream, release and then backport + test before deploying.
<ricotz> stgraber, there are always bugs ;-), and the lucid lts release is a good candidate for using it with ltsp in a buisness environment
<ricotz> stgraber, i will have a look at the ppas you mentioned
<Sarvatt> hmm, radeon mesa classic drivers support egl now too
<bryceh> heh http://www.phoronix.com/scan.php?page=news_item&px=ODc2Nw
<ion> :-)
<bryceh> Sarvatt, http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html
<Sarvatt> woohoo, thanks bryce!
<Sarvatt> hate how auto syncs dont show up on natty-changes
<Sarvatt> darn, just when I thought we could start syncing xterm - http://sarvatt.com/downloads/xterm_266-1_i386.build
<jcristau> sigh
<jcristau> and dickey's autoconf stuff is some custom weird version, so patching it is going to be fun
<Sarvatt> coming soon to a wheezy near you!
<jcristau> easiest would probably be to report it to him, and ask if he can add -lfontconfig for 267
<Sarvatt> more fun!
<Sarvatt> /usr/bin/ld: main.o: undefined reference to symbol 'XGeometry'
<Sarvatt> /usr/bin/ld: note: 'XGeometry' is defined in DSO /usr/lib/libX11.so.6 so try adding it to the linker command line
<Sarvatt> /usr/lib/libX11.so.6: could not read symbols: Invalid operation
<RAOF> What a pointless message!
<Sarvatt> and now this after -lfontconfig -lX11
<Sarvatt> /usr/bin/ld: cachedGCs.o: undefined reference to symbol 'XmuReleaseStippledPixmap'
<Sarvatt> /usr/bin/ld: note: 'XmuReleaseStippledPixmap' is defined in DSO /usr/lib/libXmu.so.6 so try adding it to the linker command line
<Sarvatt> /usr/lib/libXmu.so.6: could not read symbols: Invalid operation
<RAOF> Someone will have a good reason why ld can't just do the right thing.
<Sarvatt> like http://wiki.debian.org/ToolChain/DSOLinking ?
<RAOF> That doesn't seem
<Sarvatt> sane? agreed
<Sarvatt> it builds with http://sarvatt.com/downloads/patches/xterm-linking.patch
 * RAOF wants his desktop-unity.  Vertical space is a non-renewable resource.
<Sarvatt> plink.sh agrees the linking is needed at least
<Sarvatt> surprisingly I have way more than I know what to do with now :)
<Sarvatt> i've been using 1024x600 99% of the time for the past 2 years and just switched to 1920x1080, dont know what to do with it
<RAOF> Well, there's the first 3D bug to deal with in the compiz 0.9.2 switch; the new compiz hits an assert somewhere in r600g on evergreen.
<JanC> hm, Intel works on Xephyr-with-OpenGL-support? that would be useful to have...
<Sarvatt> looks like fedora links against ncurses instead of libtermcap and does a sed on the Makefile after configure to add the -lXmu 
<Sarvatt> xephyr? hosted X is the new hotness!
 * Sarvatt runs away from wayland talk
<RAOF> Bah.  Dear intel: kindly release Sandybridge, so I can get a faster laptop.  Kthxbye.
<Sarvatt> I broke down and got one now, not exactly confident sandybridge 3D on linux will be worth a crap in the next year and settled for a real GPU :)
<RAOF> But the CPU itself is so shiny and fast!
<RAOF> Someone just needs to make a 12" gaming laptop for me.  I'd even accept 13" :)
<RAOF> With nice new ATi graphics, a large rust-bucket hdd and a smaller superfast ssd, a quad core, 8GiB RAM, and 9 hour battery life.
<RAOF> And maybe a pony.
<JanC> Sarvatt: yeah, I saw something about the "hosted Xorg" too, not sure if it supports OpenGL? in any case, something that can be used to let multiple users use OpenGL on 1 multihead graphics card...  ;)
<RAOF> That should work now with kms, right?
<JanC> hm, I should look up documentation on that then
#ubuntu-x 2010-11-10
<JanC> if I could only find where to look  :P
<RAOF> You should just be able to start multiple X servers, IIUC.
<JanC> each on its own monitor?
<RAOF> Hm, probably.
<RAOF> You'd want to read the fine Debian XRandR documentation to do that: http://wiki.debian.org/XStrikeForce/HowToRandR12
<JanC> I don't see anything useful in there right now, unless not using a 2nd display in one X server makes it magically available in another one...  ;)...
<RAOF> That's what I'd try.
<Sarvatt> its not really documented anywhere yet, the X on wayland implementation is http://cgit.freedesktop.org/~krh/xserver/log/?h=hosted and http://cgit.freedesktop.org/~krh/xf86-video-intel/commit/?h=hosted&id=e0acdbd6f5f7ef8d9fc5b61fbd53041f4d74da06 but he said he's separating out the hosted stuff to allow X on X too
<Sarvatt> hah! I just got a 24000 euro quote for a week stay at the hotel in budapest where the next UDS is
<Sarvatt> $33,321, yeesh
<RAOF> â½
<JanC> huh, and I thought the UDS conference hotel in Belgium was expensive...  ;)
<JanC> Sarvatt: that's for 1 person?
<Sarvatt> thats for the presidential suite for 2 people, it hid the cheaper options :)
<Sarvatt> 249 euros a night, hopefully we get a good group rate so I can take the wife
<JanC> I mean, for that sort of money they should at least provide you with 10 personal slaves or something  ;)
<JanC> I remember when I went to Lisbon in 2001 or 2002, I had a room with a double bed, bathroom & sat TV for about 12-13 euro...
<bjsnider> and they gave you 10 personal slaves?
<JanC> no, not for 12-13 euro, but when comparing that to 24000 euro  ;)
<JanC> it's nly 2000 Ã more  :P
<ScottK> stgraber: re ltsp backports - Any reason we couldn't just put those in Ubuntu Backports once they are tested?
<ScottK> RAOF: re the problem we briefly discussed the other day with a monitor coming back on saying "out of range" - I disabled powering off the monitor as you suggested.  Last night my wife came back to it and the monitor (LCD actually) was powered on and said "out of range".  Further suggestions?
<RAOF> ScottK: Oh, wow.  That's weird.
<ScottK> This is Lucid Kubuntu, btw.  It was stable on Karmic.
<ScottK> (same hardware)
<RAOF> So, my next thought would be that a screensaver is crashing X, corrupting the card state, and causing the respawning X to go mad.
<ScottK> In which case I should find something about a crash in the logs.
<RAOF> Yes.
 * ScottK will have a look about for that then.
<ScottK> RAOF: Would an xorg.conf that was left over from Jaunty that still called for Option "AccelMethod" "EXA" and Option "MigrationHeuristic" "greedy" be a potential source of "bad things"?
<ScottK> No evidence of crashes, but I noticed that (along with setting dontzap) in the Xorg logs.
<RAOF> Probably not.  EXA certainly wouldn't.
<ScottK> That would just be a no-op at this point?
<RAOF> Yes.
<ScottK> I was thinking a reasonable next step would be to move the xorg.conf aside and see what, if anything, gets automatically generated.
<RAOF> Nothing will get automatically generated, at least on the filesystem.
<RAOF> Hm.
<ScottK> OK, move it aside and see if it's absence helps.
<ScottK> it's/its
<ScottK> http://paste.ubuntu.com/529083/ is the non-comment parts of what's there.
<RAOF> So, the out of range error suggests that something has triggered modesetting, and this modesetting has failed.
<ScottK> OK.
<RAOF> Oh, intel!   I don't think that AccelMethod option is going to take effect.
<ScottK> Other than power state changes what might trigger that when it's not in use?
<RAOF> Monitor hotplug, if it mis-detects a hotplug event.
<ScottK> Hmmmm.  That would show up in dmesg?
<RAOF> I can't really think of anything else.  Unless a screensaver is requesting a resolution change, but that would seem silly.
<ScottK> Last time it happened I didn't personally verify the power was still on.  Maybe she was mistaken.  I'll keep an eye on it.
<ScottK> In KDE there's more than one way to control monitor power state (of course) and I may have missed something.
<ScottK> RAOF: Thanks for the feedback.
<RAOF> Modesetting events won't turn up in dmesg unless you've got drm debug set; drm.debug=0x0e on the kernel commandline (or echoing to /sys/kernel/debug/dri/.../ at run time, I thikn) will set that.
<stgraber> ScottK: yes, we could, though currently what we backported to lucid isn't even in natty yet (it's a bzr snapshot from upstream). I'd prefer to wait for something stable to hit natty first (with an actual upstream version number), then backport that.
<RAOF> Well, that's pretty good.  30MiB on-disc saving in mesa!
<RAOF> Now the obvious caveat: does it still work? :)
<RAOF> Hm, and there's more to be had if gallium is added.
<ripps> does anybody know how make only 1 monitor my desktop, and the second only populated with widgets?
<ripps> How about starting X only on my DVI monitor and leaving my VGA at a VT?
<jcristau> can't do that.
<ripps> why?
<ripps> I just want a fullscreen terminal on my second monitor
<bryceh> ripps, ooh that'd be neat
<bryceh> ripps, sounds like a feature that'd have to be implemented in the kernel
#ubuntu-x 2010-11-11
<RAOF> Oh, dear.  You know things are going wrong when you start to think âyou know, this would be much easier if mesa just used autotools like a sensible project.  How much effort could it really be, I wonderâ¦â
<ilmari> let met guess, you found out just how much effort it was?
<BUGabundo> good morning
<BUGabundo> 3D accelaration broke last night
<BUGabundo> with the _unsupported_ 3D support in nouveau in natty
<kklimonda> bah, how can I see what makes my X use 30% of cpu all the time?
<kklimonda> well, it's probably firefox but why? :/
<hyperair> wasn't there an xtop or something
<ilmari> xrestop
<ilmari> not sure if it shows cpu time spent on behalf of clients, though
<kklimonda> I should probably restart my system anyway - X is using over 200MB..
<joumetal> does bug #674112 have enough information to be confirmed (backtrace)
<ubot4> Launchpad bug 674112 in xorg (Ubuntu) "XOrg Segmentation Fault with XServer when running MultiSeatX (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/674112
#ubuntu-x 2010-11-12
<apw> can anyone tell me if 'clickpad's are supported at the X server yet?  i have kernel patches which imply that X is handling the fact that the thing only has one button
<tjaalton> apw: not in the synaptics version in maverick, dunno what natty has
<apw> tjaalton, yeah this is for natty ... 
<tjaalton> apw: but the driver forces only one button (and 2-button emulation) for the device if it's a clickpad
<tjaalton> the upstream version anyway
<tjaalton> and natty should get 1.4.x at some point
<tjaalton> 1.3.0 should be good as well aiui
<tjaalton> that's waiting in experimental
<tjaalton> though there's one patch that doesn't seem to be upstream, though it should have gone there months ago
<tjaalton> https://bugzilla.redhat.com/show_bug.cgi?id=590835
<ubot4> bugzilla.redhat.com bug 590835 in xorg-x11-drv-synaptics "Clickpad unusable on Hp mini 210" [Medium,Assigned]
<ScottK> RAOF: I saw you mention planned work on multi monitor experience in #ubuntu-devel.  If I can find a KDE/Kubuntu person who's interested would you be willing to provide mentoring so we can do the same (No, I plan on implementing it for KDE too is a perfectly acceptable answer ;-))?
<tjaalton> apw: hum, it's not upstream yet it seems
<tjaalton> apw: fedora added it to their package
<tjaalton> but not upstream
<apw> tjaalton, ok ... so it sounds like we are good kernel wise, and we await x catching up
<tjaalton> apw: yep
<tjaalton> I'll ping peter (hutterer) when he's online
<tjaalton> weekend already down under ;)
<apw> tjaalton, thanks that get me down to only 4 patches not accounted for in the rebase
<jcristau> tjaalton: what's the plan for natty?  server 1.10 and mesa 7.10, or?
<tjaalton> jcristau: yeah something like that
<tjaalton> bryce sent an email to ubuntu-x@ about the planned versions
<Sarvatt> jcristau: yep
<jcristau> maybe i should be on ubuntu-x..
<jcristau> too many lists
<jcristau> focusing on trying to release squeeze in 2010 atm..
<tjaalton> hehe
<tjaalton> yeah maybe that could be sent to debian-x@ as well..
<tjaalton> hum the clickpad patch was reviewed by peter in April, but for some reason they never got in upstream git, even though there was no released kernel that supported it (f13 had it)
<Sarvatt> server 1.10 is still up in the air but preferred if the XI 2.1 stuff even lands in it
<Sarvatt> lucid had it too
<Sarvatt> the kernel side
<tjaalton> that was the old patch
<tjaalton> when the kernel handled it..
<tjaalton> and it's what apw is trying to get rid of aiui :)
<apw> tjaalton, oh its _gone_ it clashed with what was merged upstream
<tjaalton> ah of course
<apw> from what i can see the 3 button mode did not make it, a single button mode did.  the commentary in the patch imples that this is a normal thing and X can handle it (should handle it)
<tjaalton> yes, from what I can tell the synaptics driver will use emulation when only one button is reported by the kernel
<Sarvatt> wonder if anything is upstream for alps yet, using evdev for a touchpad really does suck and I'm surprised how many laptops ship with that alps crap
<sharkbird> Does anyone know of a multihead video card that supports three monitors and works well with ubuntu? Â Years ago I was able to set this up on debian using two video cards, but that method does not seem to work with recent X servers.
<Sarvatt> sharkbird: a radeon HD 5xxx or newer with at least 1 displayport monitor (or a digital connection with an active displayport converter on the third)
<sharkbird> Sorvatt:  with that card would I be able to configure all three monitors with Catalyst
<jcristau> 2 cards should still work depending on driver, luck, and enough prayers
<jcristau> not that i've tested that or anything
<Sarvatt> yep, the limitations on it are kind of complicated though, there is some info on it here http://www.botchco.com/agd5f/?p=51
<Sarvatt> there are people using 6 monitors on one GPU on those, if only displayport monitors that are required were more common..
<jcristau> hmm, memory bw for scanout to 6 monitors must be interesting :)
<sharkbird> Sarvatt:  thanks for the link  I appreciate your help.
<Sarvatt> active converters cost almost as much as a GPU or dp monitor last I checked
<Sarvatt> the things with 6 dp outputs have like 200GB/second memory bandwidth :)
<sharkbird> jcristau:  I must be really unlucky.  I have spent about a week trying various permutations of settings, and using various tutorials.  The closest I have come is having one display on built in video card and two cloned displays on a ati r4350.
<Sarvatt> I've never gone through the hell that setting up 2 cards like that is but from what I've seen I'd only even attempt it if I was using the nvidia proprietary drivers for both GPUs
<Sarvatt> only people I've talked to that got a remotely usable setup were using that I mean
<sharkbird> I had  4 monitor/ 2 card (one agp/ one pci) working on debian sid years ago.  I must have gotten lucky though.
<Sarvatt> anyone have any ideas on how to "fix" x11-apps on natty? every single one needs extra libs to build.. we dont run autoreconf on those so easy PKG_CHK_MODULES configure.ac patches wont fly.. patch configure.ac and have autoreconf patches for all of them or run autoreconf at build time with patches or what?
<Sarvatt> xbiff needs http://cgit.freedesktop.org/xorg/app/xbiff/commit/?id=070c9d45cc0678708d5766804d0c529bc6f8bee3 for instance
<jcristau> push the configure.ac patches upstream, release, pull in the distro? :)
<Sarvatt> oh hey thats actually appropriate for most of these so far, I failed at grepping
<Sarvatt> hmm bitmap doesn't even need a configure.ac change, just an autoreconf
<Sarvatt> configure:5709: checking for BITMAP
<Sarvatt> configure:5716: $PKG_CONFIG --exists --print-errors "x11 xbitmaps xaw7 xmu"
<Sarvatt> vs
<Sarvatt> configure:5700: checking for BITMAP
<Sarvatt> configure:5707: $PKG_CONFIG --exists --print-errors "xbitmaps xaw7 xmu"
<Sarvatt> nevermind, i'm gonna look at it later, git checkout + autogen.sh works but the tarball version doesn't
#ubuntu-x 2010-11-14
<hxcjonnysniper> ubuntu won't boot all the way. it gets stuck at "checking battery state" anyone know what to do?
<hxcjonnysniper> i can only login through failsafeX
<hxcjonnysniper> ubuntu won't boot all the way. it gets stuck at "checking battery state" anyone know what to do?
<kcj> Does anyone know if I can install the open-source video drivers for ati hardware that come with 9.10 in 10.10?
<RAOF> ScottK: I'd be happy to mentor a KDE/Kubuntu person on multi-monitor work.
<ScottK> RAOF: OK.  Thanks.  Now I just have to find one.
#ubuntu-x 2011-11-07
<bjsnider> you've also got an nvidia chip there, i'm not sure if you're able to use that exclusively
<LLStarks> i can, if i so desire
<LLStarks> rendering might be different since i'd be using nouveau or nvidia
<bjsnider> what o/s did that come with?
<LLStarks> no os
<bjsnider> cool
<LLStarks> but optimus... so...
<LLStarks> and yeah, i can confirm that the desktop tears during workspace switching
<bjsnider> well, you'll have no issues with the blob, if that's the way you want to go
<bjsnider> i'm sure sandybridge will be worked out in time
<LLStarks> thx
<bjsnider> snb is still slower than the slowest nvidia chip
<bjsnider> LLStarks, hard drive or flash drive?
<LLStarks> hard
<LLStarks> now's a pretty good time to buy an ssd tho
<LLStarks> hdds are so ridiculously expensive because of the thailand floods
<bjsnider> seems like a particularly good thing to have in a craptop, because motorized drives are not supposed to be moved, which is in conflict with the nature and purpose of craptops
<LLStarks> D:
<LLStarks> i take you like towers
<bjsnider> at least i can build them myself
<bjsnider> although no o/s is very spiffy
<bjsnider> no microsoft tax
<LLStarks> i picked every component of this laptop save for the gpu
<bjsnider> that's not the case in most situations with craptops
<bjsnider> my experience is they don't last very long
<bjsnider> LLStarks, join #gnome-shell on gimpnet and talk to the devs about the tearing
<LLStarks> ok thanks again
<bjsnider> irc.gimp.org
<RAOF> Prf_Jakob: Oh, dear.  What breaks on Radeon 6970?  I didn't know we actually had support for that chip?
<Prf_Jakob> RAOF: Graphical glitches.
<Prf_Jakob> Rendering sometimes is just random data.
<Prf_Jakob> Its probably the X driver thats at fault because the text in gnome-terminal got broken at one point.
<Prf_Jakob> RAOF: also turning adding 'Option "NoAccel" "TRUE"' to xorg.conf and then launch a normal Unity session is currently broken.
<RAOF> Prf_Jakob: As in: It doesn't correctly detect the lack of GL and fallback to unity 2D?  Urgh.
<Prf_Jakob> yeah
<RAOF> You know what would be awesome?  Having all the people who use the stable releases find bugs before they become stable releases :)
<bjsnider> did you try fglrx?
<RAOF> Also, I'd like a bug-triaging pony.
<Prf_Jakob> hehe :)
<Prf_Jakob> RAOF: If we are speaking of wanting things, I like a way to lock the Unity task bar and turning of the menu redirection.
<Prf_Jakob> Both are totaly pointless on a 30" screen.
<RAOF> I think there *is* an environment variable you can set for the menus...
<Prf_Jakob> oh
<RAOF> And compiz-config-settings-manager has knobs for the Launcher's autohide behaviour.
<Prf_Jakob> ah nice
<Prf_Jakob> Last one, anyways I can get a somewhat compitent theme config tool? I would like to be able to change the font size.
<RAOF> gnome-tweak-tool
<RAOF> That'll let you set various themey bits, most usefully the font, font size, and DPIish.
<RAOF> Yes, it depends on gnome-shell.  Yes, that's crap.
<Prf_Jakob> ah thanks
<Prf_Jakob> heh
<Prf_Jakob> there used be settings for that in the settings panel?
<Prf_Jakob> I'm hoping you are planning on adding that back to the settings panel?
<RAOF> Yeah, I believe that's intended.
<Prf_Jakob> ah good
<RAOF> I'm not sure if *we* are planning on adding that, but it's a GNOME-hasn't-yet-implemented rather than GNOME-is-philosophically-objecting-to-implementing.
<Prf_Jakob> Ah so the new config panel is a gnome thing not a Ubuntu rewrite?
<RAOF> Yeah.
<Prf_Jakob> Ah so compiz-config wont work since I'm running Unity2D.
<Prf_Jakob> Well now I know that so I can change that in the future.
<RAOF> In fact, there's a certain amount of friction there, as GNOME doesn't want it extensible, and we want to add things like jockey, Ubuntu One, and such.
<RAOF> I think compiz-config should work even when you're not running Unity3D?
<RAOF> At least, I don't know why it wouldn't work.  It doesn't actually talk to compiz, just twiddle configuration files.
<Prf_Jakob> dunno, Unity2D is based on metacity, or at least thats whats running.
<RAOF> Oh, it won't change the settings for Unity2D.
<RAOF> If that was what you were expecting.
<Prf_Jakob> Right :)
<Prf_Jakob> Not really expected it just didn't think that far ahead :)
<Prf_Jakob> expecting*
<RAOF> Heh.
<Prf_Jakob> but yeah getting a bunch of the most common requests for Unity in a config-panel under the SystemSettings would be nice.
<RAOF> There were some sessions at UDS about that.  Or, at least, something like that.  "More configurable Unity"
<Prf_Jakob> Ah cool
<RAOF> Thinking of which, our regular general X session happened, where we discussed what mesa version to ship in 12.04.
<RAOF> Thinking of which, our regular general X session happened, where we discussed what mesa version to ship in 12.04.  Consensus is 7.12/8.0, assuming that it's branched off by mid-January.
<Prf_Jakob> ok
<Prf_Jakob> The intel guys probably want to do a branch in december and a release in mid January.
<RAOF> That will make my "Decide if we can go with 7.12/8.0 in mid January" work item nice and easy, then :)
<Prf_Jakob> yeah we tried to poke them to do a earlier release because we wheren't sure what you guys would decide.
<Prf_Jakob> Good to know about that, we will keep a eye on intel and make sure we ship in mid january.
<Prf_Jakob> Okay so Unity2D looks good with NoAccel commnted out.
<Prf_Jakob> http://irc.walkyrie.se/ubuntu/unity-errors.png
<Prf_Jakob> RAOF: ^ thats what the errors looks under Unity3D btw.
<mgariepy> Sarvatt, can you upload the SRU for LP:#785280 natty and oneiric please ?
<tjaalton> mgariepy: uploaded already
<mgariepy> ha great :) thanks a lot
<Sarvatt> tjaalton: thank ya so much for that!
<tjaalton> Sarvatt: no prob
<Q-FUNK> any idea what could cause Bug #886833  in Lucid? where would I start to investigate this? could this be a -nouveau issue?
<ubot4> Launchpad bug 886833 in gdm (Ubuntu) "gdm-greeter unusable because filled with pixel garbage (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/886833
<Q-FUNK> yup, nouveau it is. broken on Lucid.
<Q-FUNK> nv works fine on the same hardware.
#ubuntu-x 2011-11-08
<Sarvatt> RAOF: crap, I forgot to get my huey off you! ha
<Sarvatt> RAOF: sprint?
<Sarvatt> hmm, we could actually sync libdrm if we didn't have to build libdrm-intel1 on linux-any, lets see if plymouth is fixed yet..
<Sarvatt> looks like its not. anyone willing to sponsor http://sarvatt.com/downloads/merges/libdrm-precise/ ? it's in git as well, build logs there also
<jcristau> plymouth was fixed upstream a while back
<jcristau> could just pull that in...
<jcristau> (no upstream release though...)
<broder> i believe i heard slangasek say that he doesn't want to do that for the lts cycle
<tseliot> Sarvatt: do you still need someone to sponsor the upload?
<Sarvatt> tseliot: yeah if you don't mind
<tseliot> Sarvatt: sure
<tseliot> Sarvatt: done
<Sarvatt> tseliot: thanks a ton!
<tseliot> yw
<tseliot> bye
#ubuntu-x 2011-11-09
<Sarvatt> wow intel_gpu_analyze looks awesome: http://eugeni.dodonov.net/webgl_firefox_lasso/
<bryceh> Sarvatt, yeah
<Q-FUNK> bryceh: hopefully, the update I provided to #738314 helps.
<Q-FUNK> bryceh: I'm a bit more worried about bug #886833
<ubot4> Launchpad bug 886833 in xserver-xorg-video-nouveau (Ubuntu) "xf86-video-nouveau: breaks GTK2 pixmap support (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/886833
#ubuntu-x 2011-11-10
<ricotz> cnd, hello
<ricotz> cnd, while updating the xserver isnt really decided yet, will things like libxi 1.4.99+ and x11proto-input 2.0.99+ be updated?
<cnd> ricotz, yes, they will both be updated to the latest upstream when those become available
<cnd> we're still working on them :)
<ricotz> cnd, alright ;), which is the "real" proto branch 2.0.99.1 or 2.1.99.1
<cnd> ricotz, what do you mean by "real"?
<ricotz> i mean which is the version you are following?
<cnd> ricotz, whot and I are working on 2.1.99.1, which adds multitouch support
<ricotz> cnd, does 2.1.99.1 already contain all bits of the current xi2 ubuntu patches?
<cnd> hard question to answer
<cnd> I have to board a plane right now
<cnd> I hope to be on wifi on the plane in a bit
<ricotz> cnd, i looked at the 2.0.99.1 release and merged the current patch into it to build xserver 1.12
<ricotz> which contained quite nothing of it
<cnd> ricotz, I'm now above 10,000 ft :)
<cnd> the ubuntu patches in natty and oneiric are a prototype version of XInput multitouch
<cnd> they differ in some key ways from what will become the official upstream XI 2.2 protocol and implementation
<cnd> we have the protocol and libxi extensions worked out
<cnd> we are about half way through the upstream x server implementation
<cnd> we'll be backporting the upstream server implementation into our server for precise
<ricotz> cnd, heh ;)
<cnd> so 2.1.99.1 contains all the bits needed, but those bits are different than what we have in ubuntu so far
<ricotz> ok, so the libxi and input-proto will contain everything needd
<ricotz> ok
<cnd> yeah, though I don't know if the libxi stuff has been pushed upstream yet
<cnd> let me check
<cnd> ricotz, the libxi stuff is only available in http://cgit.freedesktop.org/~whot/libXi/log/?h=multitouch right now
<cnd> I'll pester whot to push it to a multitouch-devel branch of the official libxi repo
<ricotz> cnd, alright, thanks
#ubuntu-x 2011-11-11
<broder> do our mesa packages build llvmpipe? i assume we wouldn't want to use it for the default install, but is it even available?
<LLStarks> hi, is iwlwifi missing from 3.2 debs? i can't find it outside of the precise.git repo.
<LLStarks> oops wrong chan
<Sarvatt> broder: libgl1-mesa-dri-experimental
<broder> what causes it to get used? the absence of any other renderer?
<Sarvatt> LIBGL_ALWAYS_SOFTWARE=1 yourapp would let ya try it out if that's what you're trying to accomplish, but yeah if it cant load a dri driver it falls back to that
<Sarvatt> *note: i haven't actually used it from the package in over a year, you may have to rename it to swrast_dri.so instead of swrastg_dri.so to have it be automatically used unless things changed. can tell with glxinfo, software rasterizer = not using the right one
<broder> yeah, forcing it was at least part of what i wanted to play with :). i'll experiment, then
<tjaalton> well get it by default soon anyway
<tjaalton> with the next mesa release
<broder> i assume that unity would still favor unity-2d over the software rendering?
<tjaalton> probably doesn't atm
<tjaalton> i tried this last summer
<tjaalton> didn't perform that well even on a core2duo, but apparently it should be better in master
#ubuntu-x 2012-11-05
<StFS> Sarvatt: thanks! Sorry for the stupid question but does that mean that it will appear in kubuntu 12.10? It seems to have KDE 4.9.2 currently and I'm just not sure, will that get upgraded once 4.9.3 is out?
<mlankhorst> Sarvatt: xorg package exists, now time for you to apply? :P
<mlankhorst> s/package/&set/
#ubuntu-x 2012-11-06
<tjaalton> whoa http://p4r.buzzleberry.com/?p=357
<mlankhorst>  The website is temporarily unable to service your request as it exceeded resource limit. Please try again later. 
<tjaalton> no wonder :)
<tjaalton> "Valve Officially Passes On Windows 8, Confirms Half-Life 3 is Linux Exclusive"
<tjaalton> unless it's fake news
<tjaalton> don't see newell attending linuxcon
<mlankhorst> tjaalton: sounds fake
<mlankhorst> I mean it would be awesome
<mlankhorst> besides there needs to be a half life 2 episode 3 first
<tjaalton> the article says newell mentioned it on stage yesterday, but haven't seen that mentioned elsewhere. should have broken the news already
<tjaalton> at least on phoronix :)
<mlankhorst> although it would make sense
<mlankhorst> tjaalton: yeah I doubt it's the case :P
<mlankhorst> https://events.linuxfoundation.org/events/linuxcon-europe/schedule don't see anything there
<tjaalton> right
<mlankhorst> tjaalton: oh lol just check the rest of the site :)
<tjaalton> I got it from a friend via facebook
<tjaalton> humor site?
<mlankhorst> guess so XD
<tjaalton> hah, touche
<tjaalton> hmm I haven't got the beta invite yet.. every uds attendee should get one
<mlankhorst> soon means soon for valve ;P
<tjaalton> on right
<tjaalton> *oh
<bryceh> there was a delay due to a couple remaining bugs
<bryceh> presumably they won't send the invite until they're ready to release
<tjaalton> so not for beta-testing?
<tjaalton> ah, when they release the beta?
<bryceh> right
<bryceh> I've added a section of "what we're working on now" to https://wiki.ubuntu.com/X/TODO .  I seeded it with people's public critical bugs that they're the assignee on.  If that's wrong, please feel free to edit.
<bryceh> (probably could be formatted more nicely...  I might tweak it some more later... suggestions welcomed)
<tjaalton> oh right, I emailed dandrader about the touch bug to see if he'd be able to help there
<bryceh> tjaalton, ah good
<tjaalton> too bad he has moved back to .br :)
<bryceh> I've written that script to query all the nvidia package versions.
<bryceh> Just posted the output to ubuntu-x@.
<mlankhorst> bryceh: oh I just reworked my entire patch series again today, hopefully for inclusion this time, didn't test much beyond compiling. :-)
<bryceh> mlankhorst, that's for 1055400?
<mlankhorst> nah, though we should enable that option in raring sometime soon by default, and fixup the fallout from that
<mlankhorst> it's for the synchronization rework, I changed the ordering to hopefully be more friendly toward inclusion
<bryceh> mlankhorst, oh ok; this the patch series for the hybrid work?
<tjaalton> don't see anything new on dri-devel@
<mlankhorst> tjaalton: I want to test it more tomorrow before I send it
<mlankhorst> heck at this point I only know for sure it compiles, but it was eod
<bryceh> mlankhorst, got it, thanks
<tjaalton> ah, ok
<mlankhorst> bryceh: looks like 3.7 had a bug though that someone reported about vblank not working right on fermi :)
<mlankhorst> fix is simple though
<bryceh> ooh -ati finally at 7.0.0
<bryceh> and drops UMS
<tjaalton> quantal had a snapshot that had dropped it already, aiui
<bryceh> yeah, git says it's been gone since june
<mlankhorst> yeah shortly after 6.14 release
<bjsnider> bryceh, i'm taking care of that new blob, so no worries
<bryceh> bjsnider, which one?
<bjsnider> 64
<bryceh> bjsnider, great thanks.
<bryceh> odd, they've not updated ftp://download.nvidia.com/XFree86/Linux-x86_64/latest.txt yet; wonder why...?
<bjsnider> they're jerks? i dunno
<mlankhorst> well didnt see a update on their unix page either
<bjsnider> they only tell phoronix when they add new drivers
<bryceh> sheesh
#ubuntu-x 2012-11-07
<bryceh> on the valve invites...  the invites went out to survey respondents first; uds invites are coming in a second wave.  pass it on.
<Azelphur> I managed to get in :)
<Prf_Jakob> bryceh: k, thanks for the update.
<Azelphur> is there a recommended way to grab that new nvidia driver?
<Azelphur> probably x updates?
<bryceh> Azelphur, no, it should be in your Additional Hardware Drivers right now
 * Azelphur has a look
<Sarvatt> if it's not thats a bug and would be good to know, i saw some updates saying never recommend -experimental that could go wrong
<Azelphur> bryceh: experimental-304?
<Sarvatt> should be a -310
<Azelphur> there's a 310 too
<Azelphur> so I go with the 310? righto :)
<Sarvatt> yah thats the good one, bryceh got 2x the fps in l4d2 with that over 304
<Azelphur> sweet
<Sarvatt> Azelphur: interested if serioussam 3 works for you with a real beta key :P
<bryceh> Sarvatt, it does; I was just playing it :-)
<Sarvatt> damn!
 * Azelphur is happy to test anything for anyone :p
<bryceh> rocket launcher all the thingees!
<Azelphur> whee \o/
<Sarvatt> it doesn't work without a key even though lots of other things do
<bryceh> the graphics performance was pretty crappy, and I spotted some (I think) corruption here and there.  Don't know if those are worth reporting.
<bryceh> and that's with:
<bryceh> xorg:nvidia_experimental_310 - NVIDIA accelerated graphics driver (**experimental** beta) (Proprietary, Enabled, In use)
<Sarvatt> http://paste.ubuntu.com/1338840/ and fails to launch because no linux binaries :( I bought that game in advance to try it
<Sarvatt> all the humble bundle games work fine but no surprise there
<ScottK> Anyone preparing a mesa SRU soon?  https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1065125/comments/10
<ubottu> Launchpad bug 1065125 in Mesa "Video-artefacts in KWin GLES" [Medium,Confirmed]
<Sarvatt> i'm just glad to have steam not taking 2-3 minutes to load to chat on it or redeem cd keys :) its surprisingly buggy though, GUI crashes but its still running all the time
<Sarvatt> ScottK: saw the responses with the fix right at EOD.. safe to say not yet :P
<bryceh> Sarvatt, yeah quite buggy, but a lot better than it has been
<Sarvatt> does kwin use gles by default now?
<Sarvatt> aka is it that urgent?
<ScottK> Sarvatt: OK.  As long as it's on the list.
<ScottK> It does on arm*
<Sarvatt> where blobs are used instead of mesa?
<ScottK> Other than that, no, but people are using gles version as a workaround for some of the problems in Bug #1061073 
<ubottu> Launchpad bug 1061073 in kde-workspace (Ubuntu) "Desktop effects are slow and desktop corruption using mesa 9" [High,Confirmed] https://launchpad.net/bugs/1061073
<ScottK> Yes.
<ScottK> The bigger potential impact is with people working around 106073 (only part of which is solve in kwin (the slow part)).
<Sarvatt> ScottK: is it urgent enough that it can't wait for mesa 9.0.1 in ~a few weeks? Just curious because SRUing it is no big deal but 9.0.1 is planned for SRU
<ScottK> Probably not that urgent.
<ScottK> I know RAOF saw the corruption at UDS, but I don't know about progress on in beyond that.
<Sarvatt> ah, yeah slowness was fixed in kwin, corruption still hasn't been figured out but the not updating isn't something i've seen a bug on
<ScottK> We just uploaded KDE SC 4.9.3 to raring today and it'll come soon as an SRU.
<Sarvatt> StFS: ^^ awesome
<Sarvatt> i wasn't sure how kde updates happend, if it would be SRUed or in -backports and he asked
<ScottK> We have a micro-release exception for KDE.
<Sarvatt> kwin point releases are kinda nuts when I looked at 4.9.0 to 4.9.2 changes so wasn't sure
<ScottK> There's a pretty good record on not regressing.
<ScottK> StFS: KDE 4.9.3 for quantal is available (except for translation updates that are still waiting to build) for testing in https://launchpad.net/~kubuntu-ppa/.
<ScottK> Please file bugs against the https://launchpad.net/kubuntu-ppa project if you find regressions.
<Sarvatt> ScottK: is there a default team to assign kde bugs to for that bug?
<ScottK> There are people that pay attention to the bugs filed against that project.
<Sarvatt> i added the kdebase-workspace task, part of it is fixed in 4.9.3 that'll eventually come
<ScottK> Oh, in bugs.kde.org it's very hit or miss.
<Sarvatt> just wondering how to make sure that part is auto closed when it does update
<Azelphur> seems like voice chat doesn't work
<ScottK> Reasonably likely not an #ubuntu-x related topic.
<Sarvatt> Azelphur: i'm amazed the overlay works and it doesn't take 3 minutes to start like it does in wine at least :P
<ScottK> Sarvatt: For 1061073, I think you wanted quantal-updates, not precise-updates.
<Azelphur> Sarvatt: indeed
<Sarvatt> but holy crap its buggy, gui crashes and it's still running in the background, kill off all the processes, still running
<Azelphur> another thing I notice, I have a different keyboard layout, but all my keybindings in game are qwerty
<Sarvatt> ScottK: oops, thanks
<ScottK> No problem.
<Azelphur> is there a way to file bugs?
<Sarvatt> nope :(
<Azelphur> ah
<Azelphur> also what's the deal with real full screen in Linux and dual screen, in order for an app to go full screen do you actually have to turn one monitor off so to speak?
<Azelphur> also, 170FPS at 2560x1440 on all max graphics settings, niiiiiiiice
<Azelphur> I have so many questions haha, does this work with nouveau yet?
<Sarvatt> wish I knew :) pretty safe to say theres problems though. best bet for bug reports is the forums
<Azelphur> yea guess so
<Azelphur> It seems to ignore xinerama info that's for sure
<Azelphur> Anyone with dual screen about to help me test something with the steam beta? You don't actually need to be in the beta to test it
<Azelphur> bryceh: I'm having an odd issue occasionally while playing TF2 where my entire system just locks up for 1-5 seconds every now and again
<Azelphur> does anyone know how you might solve this issue with dual screen + steam big picture? https://dl.dropbox.com/u/3832397/screenshots/2012/November/2012-11-07-063029_5120x1440_scrot.png
<bryceh> Azelphur, yeah dunno on any of that; worked for me.  I would check dmesg for errors, ditto Xorg.0.log.  Make sure you're running latest video drivers, etc.
<Azelphur> righto
<bryceh> Azelphur, btw whenever reporting issues always summarize your video card, video driver version, ubuntu version, and any other versions that might be pertinent.  Often we just play guessing game when we don't know that stuff.
<Azelphur> I see
<Azelphur> that dual screen thing, I've seen that issue with other apps too, such as flash player
<Azelphur> nvidia gtx 570 proprietary 310 xubuntu 12.04 64bit
<Azelphur> quad screen (2 separate X screens running twinview)
<bryceh> hmm, I haven't tested twinview too much myself
<Azelphur> hehe
<bryceh> now that nvidia supports xrandr, I'd probably just disable twinview entirely and set up using randr.  If the issue still exists there, switch on display debugging (xdiagnose, first checkbox), then examine dmesg for how it's laying out the screens.
<bryceh> er, s/screens/displays/
<mlankhorst> morning
 * bryceh waves
<mlankhorst> Azelphur: nouveau is unoptimized, I'm aware that are some things that could be done more efficiently there, so likely not getting as much fps
<mlankhorst> plus on fermi and kepler you're stuck on boot speeds, which is not very high
<Azelphur> interesting, I wonder if it'd actually work / be fast enough to be playable
<mlankhorst> well boot speeds limits you to 1/10th of the normal power, or maybe even 1/20th, didn't check..
<mlankhorst> however on geforce gtx < 400 it ought to work right
<mlankhorst> minus rendering bugs and general inefficiencies :-)
<tjaalton> fresh install, log in & out and there are four unity daemons left running plus pulseaudio and gvfsd-trash.. nice
<mlankhorst> oh i just spent a few hours finding out why this thing failed without a sign of life, network-manager got reinstalled and probably took down the network interface..
<mlankhorst> bryceh: do we want to be able to install mesa9 without the rest of the backports stack for steam?
<mlankhorst> oh bug on this system after all, stupid nfs state corruption
<bryceh> mlankhorst, yeah I think so
<mlankhorst> bryceh: ok in that case should I just make it require on libdrm-lts-quantal and rename mesa-lts-quantal to mesa9?
<bryceh> mlankhorst, how would users install it?
<mlankhorst> we could make an exception for it, and just install libgl1-mesa9-dri/glx{,:i386}
<mlankhorst> though the package itself would still be called mesa-lts-quantal because of how the rename script works
<mlankhorst> s/package/source &/
<bryceh> mlankhorst, let's just leave things as they are and see how things go.  I'm not clear that this would really be that much simpler for users than just the mesa9 ppa, and am worried it might make the backport stack a touch more complex.
<bryceh> mlankhorst, it's a good idea though, but I suspect users that need it should really just opt-in whole hog to the full stack.
<mlankhorst> hm might be better
<mlankhorst> I really want to see if I can get libdrm in unrenamed, should I apply to the technical board?
<bryceh> mlankhorst, no not for a one off backport, that's just an "ordinary" SRU.  You would have to convince RAOF or another SRU admin.
<mlankhorst> well suppose I'll have to try harder at convincing raof then, didn't want to do that in the session since the kernel team also hijacked it :)
<darkxst> I have a small patch that fixes pointer barriers under gnome-shell, would anyone here be able to review it?
<darkxst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724?
<ubottu> Launchpad bug 1073724 in xorg-server (Ubuntu) "Pointer barriers have gaps along the edge of the screen" [Undecided,Confirmed]
<bjsnider> gnome-shell apparently has a number of issues with multiple monitors
<bjsnider> i use it but with only one monitor so i guess i'm not seeing them
<darkxst> bjsnider, this issue was introduced by the patch that does the sticky edges for unity
<darkxst> my patch to that patch fixes the issue in gnome-shell and does not affect the velocity barriers for unity stick edges
<bjsnider> do you have other issues with gnome-shell using two monitors?
<darkxst> bjsnider, no not really, there are a couple of outstanding design issues (like workplace switchers), but overall it works well
<bjsnider> darkxst, is was talking to the designer of gnome-mplayer about this
<bjsnider> a few weeks ago i think
<bjsnider> darkxst, https://groups.google.com/forum/?hl=en&fromgroups=#!topic/gnome-mplayer/1sjcFsQQyoM
<bjsnider> that might be a link to hsi exact post, i'm not sure
<bjsnider> he obviously expresses some distaste for certain design decisions
<bjsnider> and i asked the gnome devs in their irc channel and they acknowledged problems in dual-head situations
<bjsnider> a lot of people seem to be using 2 monitors i guess
<darkxst> oh right, that is why I wrote this extension https://extensions.gnome.org/extension/323/multiple-monitor-panels/
<darkxst> I believe there was a session re multiple monitors at the gnome boston summit, so they are working to improve things
<bjsnider> well, they know about the issues so i'm sure there are plans in the works
<RAOF> mlankhorst: It's still not clear to me why renaming the libdrm *source* to libdrm-quantal-backport, bumping the SONAMEs to include some informative string, and then having the two libdrm stacks parallel installable wouldn't work.
<darkxst> anyway, who would be the best person to talk to about my pointer barrier patch?
<mlankhorst> RAOF: soname is going to be annoying, would mean patching everything to make it parallel installable, not really a good idea :/
<mlankhorst> though diversions might work for just generic libdrm stuff
<bjsnider> how about alternatives
<mlankhorst> would probably require changing original libdrm too, would rather have it wipe out original libdrm entirely 
<RAOF> mlankhorst: It won't mean patching anything to make it parallel installable.
<RAOF> mlankhorst: Oh, sorry - it does mean changing the -dev package name.
<RAOF> mlankhorst: But the rest of libdrm is already parallel installable. And I don't think we need to make the dev package parallel installable?
<mlankhorst> true
<mlankhorst> RAOF: what part is parallel installable you mean?
<RAOF> libdrm2, libdrm-{intel,radeon,nouveau}1
<mlankhorst> erm renamed conflicts with those
<RAOF> Why?
<mlankhorst> I suppose I could give it a shot again with the apt bug fixed, things went seriously wrong before there..
<RAOF> give me a moment to debaby
<RAOF> Ok.
<RAOF> So, here's what I would do - if you've already done it, and it didn't work, then say so :)
<mlankhorst> think it might work better now, but still leaves you at a point without libdrm at all
<RAOF> 1) Rename the quantal libdrm source package to libdrm-quantal-backports or whatever
<RAOF> 2) Add a patch to libdrm-quantal-backports to change the SONAME for libdrm2 and libdrm-{intel,nouveau,radeon} to libdrm2ubpq, libdrm-intel1ubpq, etc
<RAOF> 3) Rename the libdrm-dev in libdrm-quantal-backports to libdrm-quantal-backports-dev (or whatever)
<RAOF> 4) Profit! libdrm2ubpq is now parallel installable with libdrm2, so you don't have to worry about apt removing libdrm2.
<mlankhorst> hmz would have to look into step 2, would prefer automation as much as possible
<mlankhorst> are long filenames ok?
<RAOF> Things which Build-Depend against libdrm-quantal-backports-dev will Depend: against libdrm2ubpq, things which Build-Depend against libdrm-dev will Depend: against libdrm2
<RAOF> mlankhorst: Yeah, long filenames are fine. AFAIK we don't run into any path length restrictions on the ISOs.
<RAOF> mlankhorst: The patch in step 2 would be once-off; you'd only need to write it once (and make a trivial change for the raring-backports), and then it'd keep applying to the packages.
<mlankhorst> guess I'll create a base patch + suffix
<bryceh> so, the slow up with UDS attendees getting invites is that valve can't determine their steam id's from their launchpad record.  so they're working on an alternative way to get the keys out.
<mlankhorst> ah was wondering, was expecting them to just mail a key
<mlankhorst> my steam email isn't even the same as launchpad mail
<tjaalton> I don't even have an account there
<tjaalton> seems to be down too
<tjaalton> and up again
<darkxst> I have a small patch that fixes pointer barriers under gnome-shell, would anyone here be able to review it?
<darkxst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724
<ubottu> Launchpad bug 1073724 in xorg-server (Ubuntu) "Pointer barriers have gaps along the edge of the screen" [Undecided,Confirmed]
#ubuntu-x 2012-11-08
<darkxst>  I have a small patch that fixes pointer barriers under gnome-shell, would anyone here be able to review it?
<darkxst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724
<ubottu> Launchpad bug 1073724 in xorg-server (Ubuntu) "Pointer barriers have gaps along the edge of the screen" [Undecided,Confirmed]
<mlankhorst> darkxst: do you want it for quantal/precise or just for raring?
<mlankhorst> ah nm got it :)
 * mlankhorst should wake up before saying something
<tjaalton> so, where's the patch?
<tjaalton> oh
<tjaalton> that's an ugly diff
<mlankhorst> tjaalton: yeah it changes it to a onrmal diff from a git diff
<darkxst> mlankhorst, raring and quantal
<tjaalton> darkxst: please use at least "-p ab --no-timestamps --no-index"
<darkxst> sorry I struggled with quilt on that one
<tjaalton> QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"
<tjaalton> that's what I have in .quiltrc-dpkg
<tjaalton> and dquilt='quilt --quiltrc=${HOME}/.quiltrc-dpkg'
<tjaalton> alias
<mlankhorst> or if you never use quilt just make put it in .quiltrc ;-)
<mlankhorst> s/make//
<tjaalton> darkxst: we won't pull from that branch anyway, this is just to make reading easier..
<darkxst> ok, just redoing now
<tjaalton> now I just need to clone 100+ repos back..
<tjaalton> at least it's easy for pkg-xorg
<mlankhorst> tjaalton: er how come?
<tjaalton> mlankhorst: what?
<mlankhorst> 100+ repos :)
<tjaalton> oh sorry, pkg-xorg alone is 188
<mlankhorst> ah
<tjaalton> git clone git://git.debian.org/git/pkg-xorg/debian/xsf-tools.git
<tjaalton> then read mrconfig.README
<tjaalton> haven't used that before
<darkxst> mlankhorst, tjaalton, is this better ? http://bazaar.launchpad.net/~darkxst/ubuntu/raring/xorg-server/lp1073724B/revision/256
<tjaalton> darkxst: you didn't use -p ab?
<tjaalton> it's better but not by much
<darkxst> QUILT_DIFF_ARGS=-p ab --no-timestamps --no-index --color=auto
<tjaalton> oh..
<tjaalton> hmm
<darkxst> I also have QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
<tjaalton> then the original was created with something else :)
<mlankhorst> tjaalton: git diff probably
<tjaalton> darkxst: why the change in line 176
<darkxst> tjaalton, that not me
<tjaalton> your diff changes that
<darkxst> my patch only changes 395 and 422
<darkxst> tjaalton, quilt must have done that
<darkxst> so what should I do exactly, its a very simple patch, but patching patches seems hard
<darkxst> 422
<darkxst>  
<darkxst> -            nearest = barrier_find_nearest(cs, dir, ox, oy, *x, *y);
<darkxst> 423
<darkxst>  
<darkxst> +            nearest = barrier_find_nearest(cs, dir, ox, oy, unclamped_prex, unclamped_prey);
<darkxst>  
<darkxst> 403
<darkxst>              nearest = barrier_find_nearest(cs, dir, ox, oy, *x, *y);
<tjaalton> yes I saw that
<tjaalton> should be possible to just revert the diff from the patch directly..
<tjaalton> but I'm not that far yet, will take some time until these have cloned..
<tjaalton> mlankhorst: btw I never sorted out the xserver upload to.. precise?
<tjaalton> that got dropped from the queue
<mlankhorst> hm what was wrong there?
<tjaalton> some cruft left in the tree
<mlankhorst> that was the quantal one right?
<mlankhorst> but hey suppose i could give uploading a try now that i have the rights to
<tjaalton> sure
<tjaalton> I don't see either being accepted yet
<tjaalton> so dunno which one it was
<mlankhorst> didn't you ask for the quantal one to be dropped?
<tjaalton> as if I remember :)
<tjaalton> that was two weeks ago
<tjaalton> deleted the archive emails too
<mlankhorst> ah, glad I'm not the only one with bad memory then :P
<mlankhorst> darkxst: i can get it in the next quantal sru, but first wondering if you want it for precise too, and second if you could ask raof if he's ok with the fix since I have no clue about the pointer barrier patch
<darkxst> mlankhorst, yes I think it affects precise also
<darkxst> I no longer have a precise box to test, however I did have the same issue on precise
<tjaalton> it's basically the same patch there
<darkxst> ok, I will try check with raof tomorrow, I'm off to bed now
<mlankhorst> yeah was thinking of killing the sru for precise too then
<mlankhorst> and add it to both
<darkxst> mlankhorst, ok sounds good
<tjaalton> http://pastebin.com/84uQm4ZM
<tjaalton> that's enough
<tjaalton> ?
<tjaalton> diff of a diff is hard to read :)
<tjaalton> but basically just edited the patch directly, and dropped that change
<mlankhorst> syntax highlighting!
<darkxst> tjaalton, I think that looks correct
<tjaalton> mlankhorst: not with pastebinit :)
<tjaalton> oh
<tjaalton> it does support -f
<tjaalton> mlankhorst: oh right, I used the wrong branch for the upload
<tjaalton> mlankhorst: will you handle this or should I commit the diff?
<mlankhorst> either is fine
<mlankhorst> still trying to beat sense in my kernel patch series :)
<tjaalton> ok I'll commit it to raring, you can then do quantal/precise?
<mlankhorst> kk
<mlankhorst> I'm waiting for feedback from raof first though
<tjaalton> oh right
<tjaalton> I'll leave it unreleased in any case
<tjaalton> darkxst: it's in git waiting for review
<darkxst> tjaalton, mlankhorst, ok thanks for the help
<darkxst> I will chase up with raof tomorrow
<salty-horse> hey. are there plans to build the ubuntu-x-swat packages for quantal?
<mlankhorst> which ones
<bjsnider> not the blob, because the latest one is in there already
<mlankhorst> usually x is a bit later
<bjsnider> well, i guess it's not there at the moment, but i'm sure it will be uploaded soon
<bryceh> bjsnider, who's uploading it?
<bjsnider> alberto i guess
<mlankhorst> bryceh: what are our plans for x for raring, just leave it similar to quantal until x1.14 rc1 happens?
<bryceh> mlankhorst, yeah that's what I'm thinking.  Focus on bugs and srus and don't worry too much about syncing in new stuff yet.
<mlankhorst> yeah
<mlankhorst> going to be fun with nouveau anyway because of new kernel module
<bjsnider> bryceh, would you like to have the blob in x-updates for quantal?
<bryceh> bjsnider, yeah
<bjsnider> why do we have -updates and nvidia-experimental-xxx and all of the rest of it?
<mlankhorst> experimental is for steam
<salty-horse> sorry for the delay: I'm specifically interested in the new nvidia driver (304.64) for quantal
<bryceh> bjsnider, yeah I know we have so many places to get drivers, I don't know why users keep bugging me about getting them from the ppas
<salty-horse> ppas are comfortable :)
<bryceh> bjsnider, think we should just focus on having them use the sru'd versions rather than the ppas?
<bjsnider> well, i'm assuming the purpose of -updates is to have hte latest driver
<bryceh> salty-horse, fine, it's just that it's extra work for us
<bjsnider> right now it isn't even 60 let alone 64
<bjsnider> salty-horse, i'll get it in there in a few minutes dude
<salty-horse> thanks. I'm not pushing :)
<bryceh> bjsnider, I figure -updates probably takes a while to get new drivers in, so the ppas are useful to get the latest stuff out asap
<bjsnider> well i guess it does if it doesn't even have 60 yet
<bryceh> bjsnider, also for experimental-304, I think we may not be updating that going forward
<bryceh> experimental-310 we'll be updating for a while
<salty-horse> the new nvidia driver is "important" to me because of the reported substantial speedup
<salty-horse> aka the fix for the "performance issue"
<mlankhorst> bryceh: yeah just hoping to resubmit my patch series soon for kernel, and hopefully get it in -next
<bjsnider> salty-horse, there's always a fix for a performance issue, and a new performance issue introduced that needs a fix in the next driver
<salty-horse> bjsnider, so the reports of "doubled performance" are exaggerated?
<bjsnider> which reports are those?
<salty-horse> http://linux.slashdot.org/story/12/11/06/204238/nvidia-doubles-linux-driver-performance-slips-steam-release-date
<salty-horse> silly me: I mentioned the 304 drivers, and these are 310
<bjsnider> yeah, the 310 probably has a few showstoppers
<bryceh> salty-horse, yeah for 310 you want experimental.  see your hardware drivers dialog
<salty-horse> thanks! I was totally confused by the version mixup, and the version I wanted was available all along :)
<bjsnider> ok, nvidia-settings and blob uploaded, will take the rest of the day to build
<bryceh> bjsnider, thanks!
<darkxst> RAOF, hi, would you be able to review my pointer barrier patch? https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724
<ubottu> Launchpad bug 1073724 in xorg-server (Ubuntu) "Pointer barriers have gaps along the edge of the screen" [Undecided,Confirmed]
<Duke`> this is strange: I have some OpenGL apps which suffer "jittering", unless I stress my computer (by quickly shaking another window for example)
#ubuntu-x 2012-11-09
<darkxst> RAOF, ping
<RAOF> darkxst: Yo!
<darkxst> RAOF, can you take a quick look at my pointer barrier patch
<darkxst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724
<ubottu> Launchpad bug 1073724 in xorg-server (Ubuntu) "Pointer barriers have gaps along the edge of the screen" [Undecided,Confirmed]
<darkxst> are you happy with that fix?
<RAOF> I'm not actually at work this week, but re: your patch - my concern is whether it'll break BarrierNotify behaviour on the edges.
<darkxst> well the original patch is a bit hacky, but I don't believe my patch breaks anything further
<RAOF> Have you tested it? :) IIRC the gtest tests cover that behaviour
<darkxst> RAOF, I have tested under unity and the sticky edges still work as expected
<RAOF> Also testing hidden unity launcher reveal behaviour would be good
<RAOF> Cool. I'll give it a better read post-baby
<darkxst> the Barrier events use the clamped values anyway?
<darkxst> I think the unclampled values are only needed for the velocity calculation
<darkxst> hidden unity launcher = auto-hide dash right?
<darkxst> RAOF, there is not test case for barrier_find_nearest() function
<bjsnider> darkxst, you just never gave up on this. i need to learn to have that kind of perseverance
<darkxst> lol, just want to see it fixed, this bug has been annoying me since precise
<bjsnider> the way you bang down doors to get what you want is a skill i wasn't born with
<tjaalton> bryceh: https://bugs.freedesktop.org/show_bug.cgi?id=49347
<ubottu> Freedesktop bug 49347 in Server/Input/Core "Jumping tablet cursor with transformation matrix" [Normal,Reopened]
<tjaalton> so there was a bug open about the issue, and now there's a patch
<tjaalton> (that after rotating nexus7 with xrotate, the cursor would be jumping around)
<Sarvatt> input not working after one touch on the network manager indicator is pretty crappy :)
<tjaalton> dandrader is working on that
<tjaalton> he reproduced it on a dell laptop
<tjaalton> (touchscreen)
<tjaalton> opening the indicator menus quickly repro'd it
<mlankhorst> morning
<mlankhorst> bryceh: nice readup on triaging
<mlankhorst> should we sru 9.0.1 to quantal?
<mlankhorst> actually guess it's time I move to raring :)
<mvo> mlankhorst: speaking of SRU, I just uploaded the apt SRU, once its availalbe it would be great if you could sru-verify the version in quantal-proposed
<mlankhorst> sure np
<mlankhorst> actually quantal-proposed would be harder to test, but I can test the precise one
<mlankhorst> would the reduced testcase work?
<mlankhorst> i could probably just test the quantal one by installing it in precise and testing though, if that's ok
<mvo> mlankhorst: yeah, I think that would work, thanks
<mlankhorst> ah great raring chroot/netboot works
<mlankhorst> Sarvatt: ugh bzr is awful, can you check if I accidentally overwrote your changes with a merge?
<mlankhorst> RAOF: argh I remember why I needed to override xserver-common, sadly can't get rid of that, but I'll try dpkg-divert
<mlankhorst> ugh things get ugly fast, there..
<mlankhorst> guess I'll just try to install protocol.txt only and depend on normal xserver-common too for the Xserver manpage
<mlankhorst> mvo: hm seems i had a bug so it didn't do conflicts properly, might explain why I set that bug off in the first place :-)
<mlankhorst> RAOF: ok if mesa and intel build I'll do a ppa7 attempt with renamed libdrm, nothing should be hardcoded on the name any more. I should be able to change the soname to libdrm-ltsq.so.2 for example
<mlankhorst> hmm
<mlankhorst> RAOF: can I submit the libdrm hack anonymously? it's really really really fugly..
<ogra_> *giggle*
<jcristau> mlankhorst: git commit --amend --author=raof
<mlankhorst> jcristau: it's for the renamed stack, basically take libdrm from quantal, do some evil voodoo, end up with something that's libdrm but not quite
<mlankhorst> calling eod, enough messing around with libdrm
<bryceh> tjaalton, thanks, I'll test that out
<Yuioup> Hey all
<Yuioup> I have a question: I'm beta testing Steam for Linux and am using an AMD card. According to this wiki page: "https://wiki.ubuntu.com/Valve", the experimental driver has not been released yet. Does anybody know when those drivers might be released?
<Yuioup> Nobody here?
<bryceh> no eta yet.  whenever tseliot gets to the task
<Yuioup> Ah. Is there a way for me to download the driver somehow? Or is this something I cannot download seperately?
<bjsnider> why is he using an amd card, is what i want to know
<JanC> bjsnider: why not?
<bjsnider> because he isn't using windows
<JanC> I've had more luck using AMD cards then using Nvidia cards on linux
<JanC> but then again, I don't play games
<JanC> or at least not very often/many
<bjsnider> that's the first time i've seen someone say that
<JanC> in any case, things should just work if you use common hardware
<JanC> of course, I understand the people behind Steam worked more closely with Nvidia than with AMD until now...
#ubuntu-x 2012-11-10
<mlankhorst> JanC: it's harder than that, you first want to establish a well known testing base before you blow up the testing matrix :-)
<mlankhorst> RAOF: ugh that libdrm rename hack worked..
<mlankhorst> I'm genuinely surprised and kind of scared that it did work, but ah well..
<bjsnider> bryceh, the latest vaapi stuff in x-updates ok with you?
<RAOF> mlankhorst: Of course it worked, I suggested it! :) It'd be a serious bug in the libdrm packaging if it didn't work.
#ubuntu-x 2012-11-11
<mlankhorst> RAOF: actually I'm fairly sure it will fail spectacularly on newer intels in plymouth since it's not altered there, forcing a reverse anyway
<RAOF> mlankhorst: How can it fail? Plymouth will link with the existing libdrm2/libdrm-intel1, and won't see the new packages at all.
<mlankhorst> RAOF: yeah but not 100% sure existing libdrm won't break on the new intel cards
<RAOF> Plymouth uses only a tiny fraction of libdrm; I don't think that tiny bit is likely to break, and if it does we can probably SRU patches to enable it.
<mlankhorst> we'll see, otherwise the qbp stack seems to work though
<mlankhorst> you ok with updating x11proto, wayland, libdxtc-something directly?
<mlankhorst> if so everything should be ready
<Sarvatt> mlankhorst: why libtxc-dxtn0 btw? thats already in precise in the s2tc package
<mlankhorst> Sarvatt: blegh it wasn't updated between precise and quantal right?
<Sarvatt> only difference got SRUed
<mlankhorst> ah nm then :p
<Sarvatt> maybe it was just busted when ya first set it up
<Sarvatt> amd64/i386 weren't installable at the smae time
<Sarvatt> same
<mlankhorst> ah right
#ubuntu-x 2013-11-04
<mlankhorst> morning
<Prf_Jakob> morning
<mlankhorst> hey
<starks> hi, i'm a little confused about the nvidia-prime package. what does it setup? dri2 offloading? are there any limitations with power management or tearing?
<starks> i'd test this myself, but my optimus machine died a few weeks ago
<tseliot> starks: tearing is expected and currently you can't easily switch between the GPUs
<tseliot> starks: and the package uses RandR 1.4 offloading
#ubuntu-x 2013-11-05
<darthduck> hi all
<darthduck> I'm trying to get the "tip" of precise's xorg-server package.  I did a 'git clone git://anonscm.debian.org/pkg-xorg/xserver/xorg-server.git' followed by 'git checkout -b ubuntu remotes/origin/ubuntu-precise'
<darthduck> but I don't see the latest CVE patches, namely CVE-2013-1940.patch and CVE-2013-4396.patch
<ubottu> X.Org X server before 1.13.4 and 1.4.x before 1.14.1 does not properly restrict access to input events when adding a new hot-plug device, which might allow physically proximate attackers to obtain sensitive information, as demonstrated by reading passwords from a tty. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1940)
<ubottu> Use-after-free vulnerability in the doImageText function in dix/dixfonts.c in the xorg-server module before 1.14.4 in X.Org X11 allows remote authenticated users to cause a denial of service (daemon crash) or possibly execute arbitrary code via a crafted ImageText request that triggers memory-allocation failure. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4396)
<darthduck> Am I cloning the right repo?  Am I on the wrong branch?  Any help is greatly appreciated.
<tjaalton> darthduck: those are not in git (yet)
<darthduck> tjaalton: thanks.  I'll copy them into my local git tree for the time being from my 'apt-get source' directory.
<darthduck> It appears 190_cache-xkbcomp_output_for_fast_start_up.patch has differences as well.
#ubuntu-x 2013-11-06
<mlankhorst> Prf_Jakob: could you look at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1247680 ?
<ubottu> Ubuntu bug 1247680 in xorg (Ubuntu) "Screen goes black when in Live USB mode" [Undecided,Incomplete]
<mlankhorst> seems to be a vmware bug thingy
<Prf_Jakob> mlankhorst: thanks
<Prf_Jakob> mlankhorst: so whats in Thar now?
<Prf_Jakob> Have any of the mesa/xorg/xf-v-vm components been upgraded from 13.10?
<mlankhorst> nah
<mlankhorst> which is why I asked
<mlankhorst> well no major things anyway, mesa 9.2.1 -> mesa 9.2.2 iirc
<Prf_Jakob> Ok, really weird.
<mlankhorst> which is why I asked if it was a problem on saucy
<Prf_Jakob> I'm sure that saucy works
<mlankhorst> hm blackness here :P
<mlankhorst> on trusty though
<mlankhorst> gave up on trying vmware, so I run it in kvm with netboot from lan
<mlankhorst>  kvm -boot n -netdev tap,id=net0 -device e1000,netdev=net0
<Prf_Jakob> Oh
<Prf_Jakob> Heh
<mlankhorst> saucy too it seems
<Prf_Jakob> Odd
<mlankhorst> oh no screen now
<Prf_Jakob> I'm pretty sure I have installed saucy from iso
<mlankhorst> oh might be a out of memory thing then
<Prf_Jakob> He has 128mb of VRAM so it should be all good.
<Prf_Jakob> And 3D enabled.
<mlankhorst> ok it boots in default kvm memory -- barely :P
<mlankhorst> then it ran out and killed things
<Prf_Jakob> Hehe :)
<mlankhorst> 512 mb is enough though
<Prf_Jakob> Should be, I useally run 1gb or 4gb if I want to run heavy applications.
<mlankhorst> yeah from dmesg it says he allocated 1 gb
<Prf_Jakob> Okay, I'll take a look when I get to a computer with workstation on.
#ubuntu-x 2013-11-07
<ara> RAOF, ping
<RAOF> Hm. Can't pong ara when she leaves at 4:30am
#ubuntu-x 2013-11-08
<ara> RAOF, ping
<RAOF> ara: Pong.
<ara> RAOF, nice! you are around :) good, I need your help as both a X expert + member of the SRU team. You are da man!
<RAOF> Today is my "interrupted during the day, so stay late" day :)
<ara> there is a a version of xserver-xorg-video-intel-lts-raring that solves a couple of important certification issues
<ara> https://bugs.launchpad.net/bugs/1202524
<ubottu> Ubuntu bug 1202524 in HWE Next "[lts] Switch VGA mode will become black screen" [Undecided,In progress]
<ara> https://bugs.launchpad.net/bugs/1220645
<ubottu> Ubuntu bug 1220645 in xserver-xorg-video-intel (Ubuntu Raring) "Webcam capture plays green screen through xv on Haswell platform" [Critical,Fix released]
<ara> both have been verified in Precise with the raring stack but, because of how the SRU scripts work (not well with more than one package) it is not picking it up
<RAOF> I accepted that (and the -lts-quantal one) into precise-updates about 30 minutes ago :)
<ara> \o/
<tjaalton> yeah I got pinged about these the other day, that it needs manual love after verification
<ara> thanks! sorry, I had looked today to the SRU report (that is not yet updated) rather than the bugs themselves
<RAOF> Oh, I might also need to accept it from NEW
<tjaalton> if it was in proposed then they were already accepted from NEW
<tjaalton> ?
<tjaalton> it/they
<tjaalton> was/were
<RAOF> Probably?
<tjaalton> just that the verification notification doesn't work for these
<RAOF> Adding the tag âverification-done-preciseâ might have flipped those bugs to green?
<tjaalton> ah
<tjaalton> indeed
<tjaalton> maybe
<RAOF> Maybe :)
<tjaalton> can't remember what stgraber said
<RAOF> When I do my SRU sweeps I also check on bugs that have been in proposed for a while; I may have decided that those bugs had been there long enough next time. Or maybe not.
#ubuntu-x 2013-11-09
<dupondje> I'm playing around with Nouveau and Runtime PM. But still having an issue. Runtime PM is working fine (it shuts down my nvidia card). But when I startup gnome/lightdm, the card is started again.
<tjaalton> dupondje: maybe #nouveau can help you better
<dupondje> tjaalton: i'm there also thx
<dupondje> upgraded to 14.04 now, and i'm hitting another bug now
#ubuntu-x 2015-11-07
<ricotz> mamarley, hi, did you made progress with 358.09?
<mamarley> ricotz: Last I checked, we were waiting on tseliot to come up with something to autoload the nvidia-modeset module.
<ricotz> mamarley, is this module already in-use and actually needed?
<mamarley> ricotz: Yes, it is needed.  If it isn't loaded, you get a black screen when X tries to start.
<ricotz> I still haven't installed it here and I didn't want to interfere with your work
<mamarley> I would have tried to get some udev rule set up or something but I didn't want to interfere with tseliot.
<ricotz> what is the output of "modprobe --show-depends nvidia_358" ?
<mamarley> insmod /lib/modules/4.2.0-17-lowlatency/kernel/drivers/gpu/drm/drm.ko 
<mamarley> insmod /lib/modules/4.2.0-17-lowlatency/updates/dkms/nvidia_358.ko
<ricotz> ok
<ricotz> mamarley, I am going to push 358.09 to the ppa
#ubuntu-x 2016-11-08
<tjaalton> RAOF: what would be the rationale to statically link mesa to its deps?
<RAOF> tjaalton: Steam would stop breaking, mostly :)
<RAOF> But, from a technical perspective, Mesa is in the awkward position of exposing its implementation details in ways that break people.
<RAOF> It's implementing an ABI that isn't just the result of building its DSOs :)
<tjaalton> ah..
<tjaalton> btw, mesa 13 merged in git, no big changes to the mir patch
<RAOF> We'll upstream that *any time now* :)
<tjaalton> oh cool!
<RAOF> And by âany time nowâ I mean âprobably about the 17.04 release timeframe?â :)
<RAOF> The reasons for statically linking mesa are roughly the same as the reasons for statically linking the apitrace tracers - you're essentially injecting that code into arbitrary processes, so you need to be careful not to disturb them.
<RAOF> Also, because we should be able to have automatic rebuilds anytime a Built-Using package changes.
<RAOF> This is a lie, but it's something we *should* have :)
<tjaalton> alrighty
#ubuntu-x 2017-11-06
<soee> nvidia driver works with kernel 4.14 rc8 :)
<mamarley> Cool, I guess they fixed that GPL symbol issue in the kernel then.
#ubuntu-x 2017-11-10
<tjaalton> which ppa does versions like "~gd~z" etc?
<tjaalton> guess oibaf used to
<suret> Hi there. Is it possible (in 16.04 or later) to use the integrated Intel GPU for the display and -- at the same time -- use an AMD GPU for OpenCL computations?
<tjaalton> maybe
<tjaalton> dunno how the ocl driver is configured
<suret> tjaalton: the devs in #dri-devel say there should be no problems in theory
#ubuntu-x 2018-11-08
<michael-vb> Hello there.  I wanted to ask about a crash I am seeing with Ubuntu 18.10 in VirtualBox with Additions installed and 3D pass-through enabled.  The crash is in strstr, seemingly called from glamour_egl_init.
<michael-vb> It looks like what this patch: <https://lists.x.org/archives/xorg-commit/2018-April/041045.html> is meant to prevent.  I see that check in the "apt source" sources, but I can't see it in the disassembly.
<michael-vb> (Caveat that I am not good at reading disassembly.)  Also, the line numbers in the debug symbols do not seem to match the apt source source, though the version numbers do.
<michael-vb> Can anyone comment there?  Didn't want to go reporting a bug before I know that it is not a problem at my end.
<tjaalton> doubt anyone here uses such a setup
<michael-vb> I am wondering about rebuilding the xserver-xorg-core package from the apt source sources to see if the problem goes away... but does it sound very silly that the binaries and sources do not match?
<tjaalton> yes
<michael-vb> Still rebuilding.  Can you think of anything else I might have done to cause a mismatch?
<tjaalton> you just assume that patch would help
<jcristau> silly question.. are you sure you're looking at source and disassembly of the same version?
<tjaalton> it's in 1.20.1, a rebuild won't help
<jcristau> apt-get source sometimes does weird things
<michael-vb> jcristau: that is roughly the lines I am thinking along.
<michael-vb> tjaalton: it may still help me to match up line numbers.
<michael-vb> Worst case it behaves exactly as it did.
<tjaalton> if you have the source and a proper backtrace, you should be able to match the lines without a rebuild, no?
<michael-vb> I have debug symbols installed and can reproduce the crash in gdb, but the line number is inside a comment in the source.
<tjaalton> apply patches
<tjaalton> which file
<tjaalton> ?
<tjaalton> source file
<tjaalton> debian/patches/dont-init-glamor-on-llvmpipe.diff modifies glamor/glamor_egl.c
<michael-vb> The source file as unpacked by apt source.  Might that be missing patches?  I thought it applied them on unpacking, but I often get confused with Debian source packages.
<tjaalton> quilt push -a
<jcristau> patching on unpack is not universal
<tjaalton> and happens only on source 3.0 packages iirc
<tjaalton> xorg-server isn't
<michael-vb> quilt push -a applies the patches?
<tjaalton> should
<michael-vb> In which folder?
<tjaalton> source root
<michael-vb> Says "No series file found".
<tjaalton> QUILT_PATCHES="debian/patche
<tjaalton> s
<tjaalton> QUILT_PATCHES="debian/patches" quilt push -a
<michael-vb> It liked that better.
<tjaalton> now check the line
<michael-vb> Ah...
<michael-vb> Yes, that adds a new strstr.
<michael-vb>     renderer = glGetString(GL_RENDERER);
<michael-vb>     if (strstr((const char *)renderer, "llvmpipe")) {
<tjaalton> that patch is in current master
<tjaalton> so file a bug upstream
<tjaalton> and also in 1.20.2
<michael-vb> Not until I am sure that the problem is not on my end.
<tjaalton> though, maybe it sholud be tested with 1.20.3 just in case
<michael-vb> Thanks.
<michael-vb> Now it looks a lot more like our Additions messing something up.
<tjaalton> I could push 1.20.3 to a ppa if you like
<tjaalton> well, I'll do it anyway because we want that in 18.10 and then in hwe-18.04
<michael-vb> I could give it a test if I can't quickly solve it in my own code.  Shall I wait on IRC?  You could also drop me an e-mail at michael dot thayer at oracle.
<tjaalton> I'll push it to ppa:canonical-x/x-staging
<tjaalton> in a bit
<tjaalton> michael-vb: uploaded
<michael-vb> Thanks.  Will check later if I don't find anything in my code.
<michael-vb> tjaalton: I fixed the problem in my code.  I can still give the updated X server package a sanity run on my host system though if you like.
<michael-vb> I assume it is mainly for Xwayland?
<tjaalton> michael-vb: updates in it? mostly
<michael-vb> I will give it a try out on my laptop when I have a chance.  Don't know if that will be tomorrow though.
<tjaalton> no worries
<soee> hi, there is new driver version  :)
<mamarley> soee: What driver? :P
<soee> mamarley: oh you... :D
<soee> https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-415.13-Linux-Released
#ubuntu-x 2018-11-09
<soee_> mamarley: https://i.imgur.com/EUo7d3S.png ;)
<mamarley> Yep. :)
<mamarley> ricotz: NVIDIA 415.13 is ready: https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages
<ricotz> mamarley, thank you
<michael-vb> tjaalton: for your information, I am now on the new server after something got OOM killed.  I will let you know if I see anything I think I shouldn't.
#ubuntu-x 2019-11-08
<douglas_br> hello all!
<douglas_br> we have ltsp clients that not show a good resolution (only 640x480), after help was indicate to install "old" xorg server in ubuntu 18.04 lts to fix (or accept) the resolution at clients. My doubt: installing this pacakge can broke something, or its secure to install it?
<tjaalton> what do you mean by old xserver?
<douglas_br> that mean that accept old cards to run in 1024x768
<douglas_br> video card
<tjaalton> no, which version
<tjaalton> well?
<douglas_br> was indicate to follow: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<tjaalton> anyway, installing a package from an older distro will likely break, yes
<tjaalton> and what about that?
<douglas_br> that I want if can give me error or broke something
<tjaalton> I don't understand
<douglas_br> let me tell: there are two clients that maybe do not have support resolution screen (only 640x480), so, was indicate that install follow steps in https://wiki.ubuntu.com/Kernel/LTSEnablementStack that after this, the ltsp client can work fine (1024x768). Is it secure to install package at the server side
<tjaalton> but you're saying "install older xserver"
<tjaalton> you have two choices; either use the stock one that 18.04(.1) shipped with or use the HWE version from a newer ubuntu release
<tjaalton> but more interesting is knowing the display hw, because usually it's the kernel driver that says what resolution to use
<tjaalton> so, is it intel or amd or what?
<douglas_br> S3 UniChrome Pro
<tjaalton> what does 'apt-cache policy xserver-xorg-core' say?
<tjaalton> ...
<tjaalton> I'm assuming you don't have xserver-xorg-core installed, so you'd need to downgrade to it.. 'apt install xserver-xorg xserver-xorg-video-openchrome' should be a start
<tjaalton> that gpu needs -openchrome
<douglas_br> pt-cache policy xserver-xorg-corexserver-xorg-core:  Instalado: (nenhum)  Candidato: 2:1.19.6-1ubuntu4.3  Tabela de versÃ£o:     2:1.19.6-1ubuntu4.3 500        500 http://br.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages     2:1.19.6-1ubuntu4.2 500        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
<douglas_br> 2:1.19.6-1ubuntu4 500        500 http://br.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
<douglas_br> nothing
<tjaalton> so, roll back to non-hwe X stack
<douglas_br> intalling that you tell yeah
#ubuntu-x 2019-11-10
<Sarvatt> hope you've all been well over the years
