#ubuntu-x 2006-07-25
<rodarvus> just to keep everyone informed: right now I'm working on update of Mesa to version 6.5
<rodarvus> this is necessary for xorg-server 1.1.1
<rodarvus> fabbione, ping
<fabbione> rodarvus: pong but i am going to take off in less than 10 minutes
<rodarvus> plenty of time :)
<rodarvus> I just want to ask you a quick question ;)
<rodarvus> I have a package of Mesa 6.5 semi-ready on my computer
<rodarvus> (needed for current X.Org)
<rodarvus> but to upload it I'll have to (at least for now) drop the Xgl patches Daniel Stone added a few months ago
<rodarvus> is it ok to upload this package "as is", and work on it one week from now? (when I expect to have X basically up to date)
<fabbione> rodarvus: your call..
<fabbione> i would prefer to see everything done from the first upload
<fabbione> but if you think it's not reasonable, make sure to document properly what's left todo
<rodarvus> yeah, that was the idea
<fabbione> because if by any chance a metorite will crash on .br, somebody will have to take care of the mess you left on earth
<rodarvus> document the missing stuff on the wiki
<rodarvus> *nods*, quite reasonable
<rodarvus> fabbione, just for reference, I was able to forward-port our patches to Mesa 6.5
<rodarvus> Xgl was applied upstream
<rodarvus> (the rest of our patches applied manually)
<rodarvus> xft uploaded
<rodarvus> mesa uploaded
<rodarvus> (finally)
<rodarvus> I also have xorg-server ready to be uploaded, pending on publish of Mesa 6.5
<rodarvus> just for reference, the previous upload of Mesa 6.5 has a broken mesa-swx11-source, meaning xorg-server FTBFS
<rodarvus> I've prepared an updated version of Mesa locally, with fixes for this
<rodarvus> as soon as I have Mesa locally built/installed and xorg-server locally built/installed, I'll upload the new Mesa package
<rodarvus> libdrm uploaded
<rodarvus> (new versioned build-depends for Mesa 6.5)
#ubuntu-x 2006-07-26
<rodarvus> mesa_6.5.0.cvs.20060725-0ubuntu1 uploaded
<rodarvus> (with versioned Build-Depends on libdrm-2.0.2-0ubuntu1)
<rodarvus> xorg-server_1.1.1-0ubuntu1 uploaded
<rodarvus> (with versioned Build-Depends on mesa-swx11-source_6.5.0.cvs.20060725-0ubuntu1)
<rodarvus> xserver-xorg-input-acecad uploaded
<rodarvus> (btw, I'm starting to check for new upstream versions of all drivers)
<rodarvus> so you can probably expect quite a few driver uploads today
<rodarvus> xserver-xorg-input-aiptek uploaded
<rodarvus> xserver-xorg-input-calcomp uploaded
<rodarvus> xserver-xorg-input-citron uploaded
<rodarvus> xserver-xorg-input-digitaledge uploaded
<Mithrandir> hmm
<Mithrandir> : tfheen@golem ~ > xfontsel
<Mithrandir> Warning: locale not supported by Xlib, locale set to C
<Mithrandir> also, my emacs fonts are busticated.
<rodarvus> Mithrandir, yes, I heard (but haven't seen bug reports) about this too
<rodarvus> I haven't got around doing a dapper->edgy upgrade since then to actually test
<rodarvus> (I'm kind-of waiting for vmware modules for 2.6.17 to be able to do that)
<Mithrandir> the nb_NO.UTF-8 locale seem to be missing from locale.alias
<rodarvus> which locale.alias, from libc or from libx11?
<Mithrandir> libx11-data: /usr/share/X11/locale/locale.alias
* rodarvus sighs
#ubuntu-x 2006-07-27
<rodarvus> xserver-xorg-video-nv_1.2.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-ati_6.6.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-i810_1.6.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-apm_1.1.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-acecad_1.1.0-0ubuntu2 uploaded
<rodarvus> xserver-xorg-video-ark_0.6.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-aiptek_1.0.1-0ubuntu2 uploaded
<rodarvus> xserver-xorg-input-calcomp_1.1.0-0ubuntu2 uploaded
<rodarvus> xserver-xorg-video-chips_1.1.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-synaptics_0.14.6-0ubuntu1 uploaded
<rodarvus> lunch time, I'll be back soon
<rodarvus> xserver-xorg-input-digitaledge_1.1.0-0ubuntu2 uploaded
<rodarvus> xserver-xorg-input-citron_2.2.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-dmc_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-elo2300_1.1.0-0ubuntu1_source.changes uploaded
<rodarvus> xserver-xorg-input-elographics_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-dynapro was also uploaded (forgot to announce here)
<rodarvus> xserver-xorg-input-evdev is FTBFS :/
<rodarvus> we already had latest upstream version available (needed for X.Org 7.1) but a recompilation is necessary to adjust its ABI with xorg-server
<rodarvus> just for reference, current status of X.Org migration is always available on the staging area, at http://people.ubuntu.com/~rodarvus/packages/xorg/status.txt
<rodarvus> http://people.ubuntu.com/~rodarvus/packages/xorg/ also has a staging apt repository, with debs and sources for all packages, as they are uploaded
<rodarvus> including binaries for i386 (the ones I use locally for testing)
<rodarvus> xserver-xorg-input-evdev_1.1.2-1ubuntu2_i386.build is available on the xserver-xorg-input-evdev/ subdirectory, on this tree
<rodarvus> xserver-xorg-input-fpit_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-evdev will wait until I get any feedback on #ubuntu-devel
<rodarvus> xserver-xorg-input-hyperpen_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-jamstudio_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-joystick_1.1.0-0ubuntu1 uploaded
<rodarvus> I need a short break - brb
<rodarvus> xserver-xorg-input-magellan_1.1.0-0ubuntu1 uploaded
<rodarvus> uhh, xserver-xorg-input-keyboard was uploaded earlier too
<rodarvus> xserver-xorg-input-magictouch_1.0.0.5-2ubuntu1 uploaded
<rodarvus> xserver-xorg-input-microtouch_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-mouse_1.1.1-0ubuntu1 uploaded
#ubuntu-x 2006-07-28
<rodarvus> uploaded xserver-xorg-input-mutouch_1.1.0-0ubuntu1
<rodarvus> xserver-xorg-input-palmax_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-penmount_1.2.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-spaceorb_1.1.0-0ubuntu1 uploaded
<rodarvus> xorg_7.0.22ubuntu7 uploaded
<rodarvus> xserver-xorg-input-summa_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-tek4957 uploaded
<rodarvus> xserver-xorg-video-via_0.2.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-vesa_1.2.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-vga_4.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-ur98_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-void_1.1.0-0ubuntu1 uploaded
<rodarvus> ok, first pass on xserver-xorg-input-* is done
<rodarvus> moving to xserver-xorg-video-* now
<rodarvus> xserver-xorg-video-cirrus_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-cyrix uploaded
<rodarvus> xserver-xorg-video-dummy_0.2.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-fbdev_0.3.0-0ubuntu1 uploaded
<rodarvus> ok, I'm feeling really tired
<rodarvus> I wish I could go on and update the rest of the video drivers tonight, but my batteries are empty. I'1l continue tomorrow morning
<rodarvus> good night, everyone
<rodarvus> another day has started :)
<rodarvus> xserver-xorg-video-glint_1.1.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-input-ur98_1.1.0-0ubuntu1 re-uploaded
<rodarvus> http://people.ubuntu.com/~rodarvus/packages/xorg/status.txt now has up-to-date status on which drivers are uploaded, which ones are already published (including arch)
<rodarvus> xserver-xorg-video-i128_1.2.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-i740_1.1.0-0ubuntu1 uploaded
<rodarvus> fabbione, ping
<rodarvus> I'd appreciate lots if you could guide me on how to rebuild nvidia and ati binary drivers with xorg-server 1.1.1
<rodarvus> last time you updated them yourself in the end, and I didn't learnt about the process :)
<rodarvus> xserver-xorg-input-synaptics appears to be broken due to compilation under gcc-ssp -> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-synaptics/+bug/54357/
<rodarvus> I've just asked about this on #ubuntu-toolchain - issue is under investigation
<rodarvus> xserver-xorg-video-imstt_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-mga_1.4.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-neomagic_1.1.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-newport_0.2.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-nsc_2.8.1-0ubuntu1 uploaded
<fabbione> rodarvus: sorry but i won't have time for it.
<fabbione> rodarvus: look at linux-restricted-modules
<rodarvus> no problem - I just wanted to get your nod for me to go ahead
<rodarvus> fabbione, thanks!
<fabbione> i don't care.. i am not jalous of that package
<rodarvus> yeah, but linux-restricted-modules is on kernel-sphere, so I wanted to make sure it was ok for me to upload a new revision of it, before going ahead
<rodarvus> xserver-xorg-video-rendition_4.1.0-0ubuntu1 uploaded
<rodarvus> lunch time, I'll be back later
<rodarvus> xserver-xorg-video-s3_0.4.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-s3virge_1.9.1-0ubuntu1 uploaded
#ubuntu-x 2006-07-30
<rodarvus> xserver-xorg-video-savage_2.1.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-siliconmotion_1.4.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-sis_0.9.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-sisusb_0.8.1-0ubuntu1
<rodarvus> xserver-xorg-video-tdfx_1.2.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-tga_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-trident_1.2.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-tseng_1.1.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-v4l_0.1.1-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-vmware_10.13.0-0ubuntu1 uploaded
<rodarvus> xserver-xorg-video-voodoo_1.1.0-oubuntu1 uploaded
<rodarvus> all input/video drivers are uploaded or published, by now
<rodarvus> (barring a known bug on -synaptics, and all sparc drivers
<rodarvus> which depend on xorg-server FTBFS on sparc (this will be looked upon tomorrow)
<rodarvus> I'll be back later today, to try to understand well the current fonts situation
<rodarvus> see you all
#ubuntu-x 2007-07-23
<ubotu> New bug: #127650 in xfs (universe) "Please sync xfs 1:1.0.4-2 from Debian (unstable) to Gutsy (universe)" [Undecided,New]  https://launchpad.net/bugs/127650
<ubotu> New bug: #125053 in xorg (main) "I cannot see the mouse." [Undecided,New]  https://launchpad.net/bugs/125053
<ubotu> New bug: #127729 in xorg (main) "xserver crushing several times a day" [Undecided,New]  https://launchpad.net/bugs/127729
<ubotu> New bug: #127728 in xorg (main) "Random black screen" [Undecided,New]  https://launchpad.net/bugs/127728
<ubotu> New bug: #126570 in libxcursor (main) "gnome-system-log crashed with SIGSEGV" [Undecided,New]  https://launchpad.net/bugs/126570
<ubotu> New bug: #127822 in libxinerama (main) "Wine (and GLX) apps crash with Xinerama" [Undecided,New]  https://launchpad.net/bugs/127822
#ubuntu-x 2007-07-24
<ubotu> New bug: #27968 in xorg (main) "Problem with xserver-xorg_6.9.0.dfsg.1-1_i386.deb with ATI Technologies IncM22 [Radeon Mobility M300] " [Unknown,Fix released]  https://launchpad.net/bugs/27968
<ubotu> New bug: #93235 in xorg (main) "Disabled integerated video device selected instead of PCI card" [Undecided,New]  https://launchpad.net/bugs/93235
<ubotu> New bug: #77776 in xorg (main) "Kubuntu black screen xserver not loading on Laptop H5310" [Undecided,Incomplete]  https://launchpad.net/bugs/77776
<jcristau> bryce: is there any particular reason you're modifying debian/copyright in some packages?
<ubotu> New bug: #128072 in xserver-xorg-video-ati (main) "glxinfo crash, driver radeon shows black screen, with ATI Radeon 9550 and Gutsy Tribe 3" [Undecided,New]  https://launchpad.net/bugs/128072
#ubuntu-x 2007-07-25
<ubotu> New bug: #128134 in xterm (main) "xterm menu entry tooltip is not HIG compliant" [Undecided,New]  https://launchpad.net/bugs/128134
<ubotu> New bug: #128136 in xterm (main) "uxterm man page has a typo" [Undecided,New]  https://launchpad.net/bugs/128136
<ubotu> New bug: #128146 in xserver-xorg-video-intel (main) "Font DPI setting way too high using xorg intel driver. (GMA 945)" [Undecided,New]  https://launchpad.net/bugs/128146
<bryce> jcristau: one of the reviewers of my patches suggested it.
<jcristau> bryce: ok
<jcristau> it seemed overkill for adding an epoch, that's why i asked :)
<bryce> probably.  I've since learned about doing -Xbuild1's so have mostly switched to doing that
<bryce> also, another reviewer pointed out that the copyrights are only worth doing where the packaging was done by canonical (i.e. the x-apps)
<jcristau> right
<bryce> jcristau: btw, speaking of epochs, it would be awesome if some time we could get debian and ubuntu on identical epochs.  Save a lot of manual syncing
<jcristau> i did libice the other day after i noticed you had updated it :/
<bryce> I was pretty much able to get all of them done in about 2-3 days, although I'm still waiting on reviewers for uploading them
<jcristau> do you know which ones still need an epoch bump? i've lost track
<bryce> for the next week or so I'm going to focus on getting the bulletproof-x code integrated into xorg, and maybe do syncs for libx11, xorg-server, and xinit
<bryce> jcristau: yeah
<bryce> it's pretty evident scanning down through:  http://people.ubuntu.com/~bryce/Xorg/versions_current.html
<bryce> mostly the lib* section
<jcristau> libxaw libxext libxfontcache libxinerama libxmu libxtrap libxtst libxv libxvmc
<bryce> yup, that sounds like them
<jcristau> i think mostly that's already commited but there was no upload since then
<bryce> ah
<bryce> nite, ttyl
<jcristau> good night
* Starting logfile irclogs/ubuntu-x.log
#ubuntu-x 2008-07-21
<pwnguin> hah
<pwnguin> http://lists.freedesktop.org/archives/xorg/2008-July/037373.html
<pwnguin> I assume by "b59757e468227127b91fff17b523da4deec8b04d" you meant
<pwnguin> 66fb253082ea42179180303393e48846208987fa.
<pwnguin> an amusing and interesting thread
<pwnguin> "Of course, if you want to rename nvidia to nv, then this patch would"
<pwnguin> just magically work when people installed the proprietary driver.  After
<pwnguin> all, having five drivers called nv_drv.so can't be too much worse than
<pwnguin> four called nvidia_drv.so, no?
<Q-FUNK> ahoy! :)
<Q-FUNK> tjaalton: here?
<mario_limonciell> unfortunately fglrx 8-7 /still/ has errors about a missing symbol due to no xorg 1.5 support :(
#ubuntu-x 2008-07-22
<Awsoonn> hi all~ I am interested in what the differance is between 'normal' and 'safe graphics mode' on the liveCD
#ubuntu-x 2008-07-23
<soren> Aha!
<soren> It's all your fault!
<soren> :)
#ubuntu-x 2008-07-24
<mvo> why oh why does ctrl-alt-f1 in failsafe mode not work? 
<jcristau> mvo: it only works if xkb does
<jcristau> any xkb errors in the log?
<mvo> jcristau: aha, good hint, thanks. I haven't checked, it was a unplanned boot into failsafe mode :) I wanted to get out of 800x600 as quickly as possible 
#ubuntu-x 2008-07-25
<pwnguin> http://airlied.livejournal.com/61658.html
<tjaalton> he also has a patch for fdo bug 14441 which I'll test shortly :)
<ubottu> Launchpad bug 14441 in gnome-system-tools "ifup ppp0 does nothing" [High,Fix released] https://launchpad.net/bugs/14441
<tjaalton> u
<tjaalton> h
<tjaalton> fd.o bug 14441
<tjaalton> ok, https://bugs.freedesktop.org/show_bug.cgi?id=14441
<ubottu> Freedesktop bug 14441 in Drivers/DRI/i965 "Compiz shows only black screen on i965" [Normal,Assigned] 
<tjaalton> ..which is the only blocker left for mesa 7.1
<tjaalton> huh, gdm tries to use /usr/X11R6/bin/X now?
<tjaalton> which should work, but still..
<soren> Do any of you guys have a clue about  https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-vmmouse/+bug/251473 ?
<ubottu> Launchpad bug 251473 in xserver-xorg-input-vmmouse "Mouse stuck in lower right corner in Intrepid installs in qemu on hardy (dup-of: 248521)" [Undecided,Confirmed] 
<ubottu> Launchpad bug 248521 in xserver-xorg-input-vmmouse "vmmouse seems to register incorrect x,y values for mouseclick" [Undecided,Confirmed] 
<soren> brb
 * soren 's back
<tjaalton> soren: no idea, but seems like it _should_ be fixed..
<soren> Well... It's not :)
<tjaalton> yeah, so it seems :)
<pwnguin> tseliot: excellente
<tseliot> ï»¿pwnguin: ;)
<pwnguin> i still wish a formal parser was written, but i suppose its enough for me to be vindicated in the end ;)
<tseliot> heh
<pwnguin> as a Computer Scientist, it always frustrates me that people resort to regex and raw string chewing to handle something quite difficult
#ubuntu-x 2008-07-26
<pwnguin> so i just updated my intrepid laptop for the first time in about a month
<pwnguin> what's the deal with nvidia-common?
<pwnguin> isn't there a transitional package system one can use to purge old packages in favor of new naming?
<pwnguin> ok that was wierd
<pwnguin> i installed nvidia-glx-177 and the welcome sound played
<tseliot> ï»¿pwnguin: this problem affects hardy too. I don't know how track it down
<pwnguin> well, it said it removed some modules
<pwnguin> temporarily
<pwnguin> maybe there was some sound queued up that pulse audio blocked?
<pwnguin> seems reasonable if gdm were to start a thread that blocks on a mutex to the soundcard, and then something causes pulse audio to restart
<pwnguin> but this is just wild theory that should be compared against how code actually is written :/
<pwnguin> tseliot: have you asked crimsun about it?
<tseliot> pwnguin: no, I don't know who he is
<pwnguin> if i recall correctly, he helps with ubuntu audio
<tseliot> ok, I'll ask him about this
#ubuntu-x 2009-07-20
<JontheEchidna> Hello guys, would you happen to know off-hand which  portion of the software stack this patch is for? http://bugs.freedesktop.org/attachment.cgi?id=27838
 * JontheEchidna needs to apply it to test an upstream bug
<Ng> looks kernely
<JontheEchidna> meh, thanks
<jbarnes> superm1: just curious, do you guys have anything like the inspiron 1210 but with intel graphics and a nicer keyboard layout?
<jbarnes> the shift, /, uparrow thing really sucks :p
<superm1> jbarnes, 1210. let me see what model this is (I only know codenames generally)
<jbarnes> some kind of mini
<superm1> oh mini 12
<jbarnes> I should say "non-gma500 intel gfx" :)
<superm1> haha
<superm1> i was gonna say..
<superm1> well nothing that's still considered a mini at that size
<jbarnes> I like the form factor
<jbarnes> it's light & slim
<jbarnes> screen is reasonable as is keyboard size
<jbarnes> but gma500.. :(
<superm1> if you are hoping for an atom et'al, your next best bet is the 10v
 * jbarnes looks
<superm1> but that screen is significantly smaller by comparison
<superm1> that's the little sucker I was lugging around at uds
<jbarnes> looks about the same size as the aspireone
<jbarnes> smaller than I was thinking
<superm1> well there are 13" form factor "laptops" too
<jbarnes> ah yeah
<superm1> the studio xps works everything OOTB, but it's not intel gfx.  the inspiron i'd expect is needing a slew of audio quirks and what not still
<jbarnes> ug
<superm1> we ship the inspiron 15 with linux worldwide, but the 13 only gets basic QA
<superm1> eg major BIOS issues get sorted out
<jbarnes> hm 13 looks pretty nice though
<jbarnes> shift is still next to uparrow, but it looks better than the mini 12
<superm1> i'm not sure if it's one of the retail models. you might be able to go check it out at best buy or similar
<jbarnes> cool thanks
<bryce> just got a 10v for my mother in law, just yesterday was teaching her to use it, she's very happy with it
<Ng> my mum loves her mini9 :)
<bryce> she was really worried the keyboard was going to be a bit cramped but she sat down and typed out a document with minimal problems - figuring out where the delete key was, accidentally hitting caps lock, etc.
<bryce> jbarnes, I agree, a mini-12 would be an awesome size/weight for travel
<bryce> jbarnes, btw, I'm about to do a git snapshot update of -intel so we can be sure to have an update of the driver in alpha-3.  I understand 2.8.0 is coming RSN.  Should I hold off a couple more hours, or is 2.8.0 more likely to come tomorrow?
<Sarvatt> sounds like you might want something like an acer timeline jbarnes
<bryce> Sarvatt, today's the last day for merging stuff in for alpha-3.  Any thing you think we need to upload?
<Sarvatt> cant think of anything, there are alot of things you can update but probably better off holding off until after for things like xserver 1.6.2 that might need rebuilds
 * bryce nods
<Sarvatt> xf86-video-ati *still* doesnt build against xserver 1.6.2 yet lol
<bryce> anything I can do to help there?
<Sarvatt> the ati thing? nah they know about it just havent updated it yet, its only an issue with libdrm-radeon1 anyway
<Sarvatt> libdrm would be really nice to update though
<Sarvatt> but its not in debian
<bryce> yeah noticed that earlier and have been thinking about doing it
<Sarvatt> http://cgit.freedesktop.org/mesa/drm/commit/?id=3f3c5be6f908272199ccf53f108b1124bfe0a00e
<Sarvatt> thats an amazing commit :D
<Sarvatt> yeah i take that back, ati is only an issue when libdrm-radeon1 exists with server 1.6.2, the problem is just in dri2 and karmic wont be getting that anytime soon probably since it needs mesa 7.6 for dri2
<Sarvatt> i stuck to using 2.4.12+gitxxxx on edgers because we're using libdrm-radeon1 there and dont want the libdrm overridden by karmics
<jbarnes> bryce: yeah I think cworth will do the 2.8 release today sometime
<jbarnes> but I don't know for sure
<Sarvatt> if you package 2.7.99.902 they'll release 2.8 a few hours later, thats how it works for me :)
<Ng> jbarnes: I don't know what the gfx chipset is exactly but the HP mini Mi has a keyboard that's not particularly hateful :)
<Ng> it's running some weird ubuntu derivative by default, but assuming it's not insane poulsbo nonsense, it should be easy enough to fix that ;)
<bryce> Sarvatt, yeah :-)
<jbarnes> Ng: cool
<Ng> a couple of my teammates take them to conferences/sprints to work from
#ubuntu-x 2009-07-21
<Sarvatt> hmm, autodetection routine for sis in xserver with no xorg.conf seems a little screwy
<bryce> where'd you get sis hw?
<Sarvatt> http://sarvatt.com/downloads/sis.txt
<Sarvatt> creates 2 identical sis devices?
<Sarvatt> dug up an old server :D
<bryce> ah heh
<bryce> yeah that does sound improper
<Sarvatt> maybe thats because theres pci.ids
 * bryce rolls eyes at lp #401107
<ubottu> Launchpad bug 401107 in xorg-server "Software runs as root" [Wishlist,Confirmed] https://launchpad.net/bugs/401107
<Sarvatt> ahh yep it is, deleted the sis.ids and it only added the 1
<Sarvatt> sheesh!
<Sarvatt> wheres the "wont be fixed in the next 3 years" bug status :D
<bryce> no kidding
<bryce> >maybe< running as non-root will come for -intel soonish, but when you think of all the other random drivers that aren't likely to get KMS any time soon...
<Sarvatt> yeah sounds like he read an article on phoronix about moblin which is only targetting intel graphics so they can do it :D
<bryce> sweet http://www.ubuntu.com/news/canonical-open-sources-launchpad
<Sarvatt> nice!
<tjaalton> wow, even soyuz is open
<Ng> ooh, new intel X love
 * Ng does the crack-of-the-day dance
<bryce> :-)
<bryce> sorry, not very much changed, just a handful of bug fixes
<bryce> but at least now we're officially at 2.8.0 in time for alpha-3
<bryce> the mesa 7.5 update should be moderately more interesting
<Ng> bryce: bug fixes is fine, and still worth testing :)
<Company> hey
<Company> 2 questions:
<Company> 1) i updated to the edgers repo and it didn't pull the new kernel
<Company> so i ran with the default jaunty kernel
<Company> and that didn't go very well - read: it quickly hardlocked
<Company> should i file bugs about that or should maybe the intel drivers just pull a newer kernel?
<Company> 2) is there a way to get debug symbols for the edgers ppa?
<Company> i'm hacking on pixman atm, would like to debug its usage inside X and am too lazy to compile it myself but gdb without debug symbols kinda sucks
<jcristau> hacking on it but too lazy to build it yourself?
<jcristau> that kinda doesn't make sense :)
<Company> i'm hacking on pixman, not X :p
<jcristau> ah, ok :)
<tjaalton> 1) not a bug, 2) no idea
<Sarvatt> sudo apt-get install linux-image-2.6.30-10 linux-headers-2.6.30-10-generic linux-headers-2.6.30-10
<Sarvatt> everything with debug symbols in ubuntu has debug symbols in the PPA
<Company> i know how to solve the kernel problem - i just wonder if it should be done by default instead of leaving me with a kinda broken system
<Sarvatt> no it shouldnt
<Sarvatt> its optional
<Company> not really, because it doesn't work
<Sarvatt> you can pastebin your logs from when you locked up and we might be able to help, it doesnt work and it locked up doesnt really say much
<Sarvatt> if you can pastebin them we might be able to help rather
<Company> i'd rather not debug bleeding edge X on outdated kernels
<Company> there's more useful things to do
<Sarvatt> the PPA isnt just for intel, forcing the kernel and breaking jaunty packages that people might be using for everyone just because it makes intel better isnt the best idea
<Company> yeah, but you could make intel depend on the kernel
<Sarvatt> if it was required sure, but it runs fine with 2.6.28 on all of the machines i've tested it on. do you have a /var/log/Xorg.0.log.old showing where it didnt work maybe?
<Company> nope, restarted X a bit too often since then
<Sarvatt> can ya paste a trace of an example of what you need symbols for so I can help ya find which packages you want  to install?
<Sarvatt> libpixman-1-0-dbg xserver-xorg-core-dbg and libgl1-mesa-glx-dbg most likely at least
<Company> oh, -dbg
<Company> i was looking for -dbgsym packages
<Sarvatt> hmm, thinking about putting an updated pixman on xorg-edgers, there was a post asking for testing of the fix for server 1.6 branch that we might be using and i have a feeling people will be wanting to upgrade pixman before karmic release for the arm optimizations
<Sarvatt> jbarnes: any chance the fifo watermark kernel fixes might make it in time for 2.6.31-rc4? :D
<jbarnes> Sarvatt: yeah hopefully
<Sarvatt> is it like, just people with dual channel memory having problems? everyone with flickering i've talked to is running dual channel but its probably just coincidental
<jbarnes> Sarvatt: no the patch that went upstream just has a lot of bugs
<jbarnes> I think it'll affect a lot of people
<apw> jbarnes, that sounds bad, we got a fix we can apply separatly until it gets in?
<apw> bryce, how are we doiing with radeon userspace support?
<apw> (for kms)
<bryce> heya apw
<apw> morning
<jbarnes> apw: yeah there are a couple of patches you can apply until upstream gets the bits
 * jbarnes digs up urls
<bryce> in fact was just chatting with sarvatt about that last night.  Seems it is going to require the radeon-rewrite branches of mesa, et al.  After we get alpha-3 out I think we'll bite the bullet and pull those development trees in.
<jbarnes> http://lists.freedesktop.org/archives/intel-gfx/2009-July/003471.html
<jbarnes> http://lists.freedesktop.org/archives/intel-gfx/2009-July/003472.html
<jbarnes> https://bugs.freedesktop.org/show_bug.cgi?id=19304 - last comment has an untested fix for 845G
<ubottu> Freedesktop bug 19304 in Driver/intel "[845G] FIFO underruns" [Major,Reopened]
<ubott2> Freedesktop bug 19304 in Driver/intel "[845G] FIFO underruns" [Major,Reopened]
<ubottu> Freedesktop bug 19304 in Driver/intel "[845G] FIFO underruns" [Major,Reopened] http://bugzilla.freedesktop.org/show_bug.cgi?id=19304
<ubott2> Freedesktop bug 19304 in Driver/intel "[845G] FIFO underruns" [Major,Reopened] http://bugzilla.freedesktop.org/show_bug.cgi?id=19304
<Sarvatt> funny enough all the people i've come across with the flickering problems are on 945
<Sarvatt> 6 people in #ubuntu+1
<jbarnes> http://lists.freedesktop.org/archives/intel-gfx/2009-July/003471.html is probably the fix for them
<Sarvatt> thanks for the link, there were so many patches flying around i didnt know which to pass along :D
<apw> bryce, sounds like stormy waters ahead
<apw> jbarnes, thanks, will put them on my list to check when we rebase next
<jbarnes> oh those are in drm-intel-next now fwiw
<bryce> apw, :-)
<bryce> apw, actually the ATI guys are pretty conservative about when they pull in new stuff, so it's possible the code's already plenty stable, just not "perfect", so waters may merely be turgid
<apw> heheh lets hope so
<bryce> apw, oh btw, don't know if they've filtered through to you, but as we've been getting -intel bugs resolved upstream with proposed kernel patches, I've been moving them to the kernel queue and marking them xorg-needs-kernel-fix
<apw> ahh no not noticed but th
<apw> that sounds good.  will review those on the next rebase and see which ones are included
<bryce> cool, yeah I suspect a lot can just be closed as already in the kernel
<apw> i see there is a fair lump of fixes in mainline already
<bryce> I think ogasawara mentioned she'd put together a report of these
<apw> but linus' weeks seem to be rather longer than 7 days on average
<bryce> heh, sometimes I feel the same way
<apw> will ask her about it
<apw> yeah i know waht you mean
<MT-> What does xdmx offer?
<MT-> figured it out
<Sarvatt> hmm thats a new one
<Sarvatt> dpkg-shlibdeps: warning: debian/xserver-xorg-core/usr/lib/xorg/modules/libexa.so contains an unresolvable reference to symbol xf86ProcessOptions: it's probably a plugin.
<Sarvatt> dpkg-shlibdeps: warning: 94 other similar warnings have been skipped (use -v to see them all).
<Sarvatt> if anyone else is using arm and wants to test out pixman with neon support -- http://sarvatt.com/downloads/armel/
#ubuntu-x 2009-07-22
<Sarvatt> ugh... found out what my problem was compiling xserver. nasty http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536034
<ubottu> Debian bug 536034 in dpkg-dev "dpkg-dev: dpkg-gensymbols produces broken symbols files" [Serious,Closed]
<Sarvatt> http://groups.google.se/group/linux.debian.bugs.dist/browse_thread/thread/dfcd924e8426179b?fwc=1
<Sarvatt> guess ubuntu hasnt picked that up yet
<Sarvatt> ahh it is there, no clue why i'm still getting the errors
<dfaure> after switching to ati (because fglrx stopped working in jaunty), X starts up but no keyboard and no mouse. Any suggestions?
<Ng> is hald running?
<dfaure> no indeed. I see. Should reboot out of failsafe mode first.
<Ng> (xorg gets its input devices from hal atm)
<dfaure> err now every key sends three letters !?
<dfaure> I type 'd' and I see "ddd"
<dfaure> anyone seen that before?
<Ng> do you have any input devices defined in /etc/X11/xorg.conf? I'm guessing wildly here, I'm just wondering if it's seeing the same event from several different keyboards that are actually the same keyboard defined in several places?
<Ng> seems kinda unlikely though
<dfaure> indeed commenting out the input devices fixes it. Weird though, there was just one of each, not 3.
<dfaure> Ng: thanks for the help. Everything ok now.
<tseliot> Sarvatt: ping
<tseliot> Sarvatt: never mind
<tseliot> ScottK: I have ported my patches for synaptics to Karmic. Have a look at my PPA (and at the bug report)
<ScottK> tseliot: OK.  I'm reinstalling for ISO testing right now.  I'll give it a try in a bit.
<tseliot> ok, thanks
<jbarnes> bryce: so how goes the intel upstreaming?  is it all done?
<jbarnes> bug upstreaming that is
<bryce> jbarnes, I've got 15 or so left to go.  I sort of got inspired/distracted by a comment you made earlier, and have been working on a tool to do upstreaming for me
<jbarnes> nice
<bryce> there also seems to be some confusion as to whether I should set priorities on upstream bugs or leave it unset, so I'm waiting for the higher ups to get that sorted
<bryce> jbarnes, http://people.canonical.com/~bryce//upstream.svg
<jbarnes> that makes it look like only 20% are upstreamed so far?
<jbarnes> bryce: I think it's ok to set prio
<jbarnes> we may drop it down depending on our release schedule, but imo it's fine to set it as an indicator of its importance to you
<jbarnes> the worry on our team was that we're using priorities as our release criteria
<jbarnes> p1 bugs are basically release blockers
<bryce> right, we got a bit over 20% but it fell lately because I pulled in 2.8.0 and closed out the upstreamed bugs that were fixed
<bryce> what that chart doesn't tell is that 180 bugs are incomplete waiting on reporters
<jbarnes> ah that's the discrepancy
<bryce> yeah there's only 15-20 that I need to do something with.  But they're probably mostly just dupes of known issues
<jbarnes> cool
<jcristau> in most cases you don't hear back from people after asking for more information or asking to try a newer version, so the bugs sit there for a while.  at least that's my experience in debian.
<jcristau> and those are not upstreamable
<bryce> many of those incomplete bugs were ones reported with Jaunty's release, which my script asked them to re-test.  Those are all scheduled to expire here this coming week.  So I think we should see a nice jump in the stats within the week
<bryce> jcristau, yep exactly
<jbarnes> bryce: ok consensus is to mark prio according to what prio it is for ubuntu
<jbarnes> like I said, we may bump it down but that can be handled at your regular meetings with yingying if there's disagreement
<bryce> okie doke
<bryce> I put in an openchrome git update in xorg-edgers if anyone's interested
<jcristau> openchrome is in git now?
<bryce> s/git/svn/
<bryce> jcristau, at least I didn't say bzr snapshot ;-)
<jcristau> bryce: heh. you had me hoping they made the switch :)
<Sarvatt> got me too, i thought the same thing :D
#ubuntu-x 2009-07-23
<tjaalton> according to the recent via thread on dri-devel it appears they are going to push openchrome to fd.o within a month
<tjaalton> at least that's how I read it
<Sarvatt> hmm, is there any way to get dbg packages built on a PPA that could point to a standardized location for the source? like /usr/src or something
<Sarvatt> instead of getting this --
<Sarvatt> echo 0x816f9dc | eu-addr2line -e /usr/lib/debug/usr/bin/Xorg 
<Sarvatt> ../../render/glyph.c:260
<bryce> yeah that'd be nice
<Sarvatt> do ddebs do that or something? (never used one of those before)
<bryce> jbarnes, http://people.canonical.com/~bryce//upstreamer-0.png
<jcristau> ooh. looks good.
<tseliot> bryce: something we might want to upload to Karmic after the freeze: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/402863
<ubottu> Ubuntu bug 402863 in xserver-xorg-input-synaptics "Dell mini 10v touchpad is horribly jumpy" [High,In progress]
<bryce> tseliot, yes agreed.  I read your comment earlier
<tseliot> good :-)
<bryce> tseliot, can you remind me again after alpha-4 release?  I'll likely forget
<tseliot> bryce: also I would like to add something for touchpads in the apport hook for X
<tseliot> bryce: sure
<bryce> ok certainly
<tseliot> bryce: that would involve adding a small C program (basically a stripped down and customised version of lsinputs) to the synaptics package
<tseliot> with no external dependencies
<bryce> jcristau, I'm sure I'm putting in more time than it'd take to upstream 100 bugs, but at least it's interesting work...  ;-)
<bryce> tseliot, hmm.  In the xorg package, it is mainly just scripts so having to build a binary might require a lot of package fiddling
<tseliot> bryce: as discussed with pitti, I was thinking of adding the C app to xserver-xorg-input-synaptics (maybe as a patch) which then would be called by the script in x11-common
<bryce> ok that'd be cool
<bryce> just make sure the dependencies for xorg <--> xserver-xorg-input-synaptics are sane
<tseliot> bryce: there will be no additional dependency. This is what my C program uses: http://pastebin.ubuntu.com/226632/
<hyperair> hmmm .31-rc4 panics when booting. =(
<popey> bryce any chance if you get a moment you could look at the video attached to bug 403530 and let me know if there's anything else I need to provide?
<ubottu> Launchpad bug 403530 in xserver-xorg-video-intel "[karmic] Screen goes wild when doing simple 3D work" [Undecided,New] https://launchpad.net/bugs/403530
<jbarnes> bryce: cool
<bryce> popey, thanks looks all the necessary info is there
<popey> bryce: groovy, thanks for looking
<bryce> no prob, thanks for including a video and script to repro the problem, that should make the bug easy to send upstream
<Sarvatt> http://sarvatt.com/downloads/openchrome.patch
<Sarvatt> had to patch it up a little to build against xserver master
<lesshaste> hi all
<Sarvatt> upstreamed it, hope i did it right -- http://openchrome.org/trac/ticket/312
<bryce> Sarvatt, that looks like a good candidate for you to get sponsored
<bryce> Sarvatt, make a debdiff and have me or another core dev sponsor it in
#ubuntu-x 2009-07-24
<richardcavell> Hi all. I'm running Ubuntu 9.04 on a MacBook with Intel GMA950 chipset.  The drivers are pretty buggy.  I hope to fix them by upgrading from the stable release to something more edgy.  I'm thinking kernel 2.6.30 with KMS, and later builds of the intel linux drivers. Can anyone nominate an easy way to do this?
<tjaalton> yeah, upgrade to karmic
<tjaalton> or use the xorg-updates PPA
<crevette> richardcavell, but karmic is still in development so it going to be unstable
<richardcavell> crevette: well my present video system is unstable...
<richardcavell> tjaalton: If I simply upgrade to Karmic will that give me kernel mode setting, and the latest intel drivers?  
<tjaalton> yes
<tjaalton> other things might get broken though, like crevette pointed out
<richardcavell> The latest intel drivers (from intellinuxdrivers.org) are xf86-video-intel-2.8.0
<richardcavell> I tried downloading the source and ./configure but it gives me an error and I don't know enough to fix it
<richardcavell> checking for XORG... configure: error: Package requirements (xorg-server >= 1.6 xproto fontsproto ) were not met:
<richardcavell> No package 'xorg-server' found
<richardcavell> No package 'fontsproto' found
<tjaalton> even if you got it working, it wouldn't be enough
<tjaalton> since you need the new kernel
<richardcavell> tjaalton: I can download binaries for the new kernel
<tjaalton> so build the deb from karmic then?
<richardcavell> tjaalton: but I can't find binaries for Ubuntu for the latest intel drivers.  2.6.3 is the latest stable version
<richardcavell> looking at the changelogs for the intel drivers, it looks like heaps of bugs have been fixed between 2.6.3 and 2.8.0
<tjaalton> yes, but in order to get 2.8.0 working you really need 2.6.31rc
<tjaalton> .30 might work
<richardcavell> I'll upgrade if it will fix my problems, but I'm not sure if it will
<tjaalton> you could also try the xorg-edgers PPA and only pull -intel and it's deps
<tjaalton> and the new kernel
<richardcavell> tjaalton: that's what I'd prefer
<tjaalton> and after installing what you need, disable it
<tjaalton> so that the other crack won't be installed along with other updates
<hyperair> has anyone gotten the rc4 kernel to not panic with intel + modesetting?
<tjaalton> haven't tried it yet
<richardcavell> Okay, I want to upgrade to a more recent set of drivers for my Intel GMA950 on Jaunty.  Here's what I'm planning to do: Install linux kernel 2.6.30-10 and everything in the xorg-edgers PPA.  Does this sound good?
<tjaalton> don't install everything, just the driver and kernel
<tjaalton> gone ->
<RAOF> Look out ninjas.  Preliminary suspend/resume support for g80 (exactly) lands in xorg-edgers/nouveau.
<Guest6103> Hi, guys. I have Jaunty running on a Macbook second-generation, which has an Intel GMA 950.  I was getting poor performance with the standard issue Jaunty drivers.  So I installed everything from the xorg-edgers PPA and now X won't start at all!  Any ideas?
<Guest6103> Okay, can I ask this: I can't get X11 to work, but I can get to a root command line.  What's the metapackage that I need to force install via apt-get to give me the standard Jaunty stable xorg?
<Sarvatt> well heck, I go out of my way to make sure edgers always works and am conservative about updates in it. if people see it that way i might as well just throw xorg 7.5 in there and really break things :)
<Sarvatt> telling people to just install intel and its dependencies is kinda a bad idea, its not like the packaging scripts get all the deps right since its based on the older releases.. and back when xserver 1.6.1.902 was in there it wouldnt even work with the jaunty xserver because of how the dri2 abi was broken.. thats what x-updates is for
<Sarvatt> guess i need to work on the hooks more, the xserver in there requires mesa 7.5 at least because it compiles in setTexBuffer2 support because its available at build time
<Le-Chuck_ITA> Hi all, can someone take a look at bug #402982? Bryce do you have an intel card? Do you have the same bug?
<ubottu> Launchpad bug 402982 in linux "Frequent screen flashing with intel video card (not present with the same packages and kernel 2.6.30)" [Undecided,New] https://launchpad.net/bugs/402982
<Sarvatt> revert back to the 2.6.30-2 kernel
<Sarvatt> err 2.6.31-2
<Sarvatt> hopefully the fix makes it into 2.6.31-5, it didnt make it into 2.6.31-4
<Sarvatt> lots of people are having that problem though
<Sarvatt> started with 2.6.31-rc3 because of this http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7662c8bd6545c12ac7b2b39e4554c3ba34789c50
<jbarnes> tseliot: ping
<tseliot> jbarnes: pong
<jbarnes> tseliot: hi!
<jbarnes> so
<tseliot> hi :-)
<jbarnes> I just upgraded my dell mini 12 to jaunty yesterday
<jbarnes> and found (after some digging) the ubuntu mobile repo with the latest poulsbo drivers
<jbarnes> they seem to work a bit, but they hang a lot and suspend/resume takes forever
<jbarnes> are there any updates in the works or something I can subscribe to for status updates?
<tseliot> yes, that's not what I worked on
<tseliot> I don't think I can share the OEM repositories though
<jbarnes> oh so the mobile repo has old stuff?
<tseliot> I'm not sure, as I don't maintain that
<tseliot> I can ask my boss to see if I can share the repo
<jbarnes> thanks
<jbarnes> or you could point me at someone else... I'd like to get this machine to be a little more stable
<jbarnes> I can also ping some people internally
<tseliot> jbarnes: do you know Michael Frey?
<jbarnes> no I don't think so
<tseliot> jbarnes: ok, let me ask around in our private oem chat room
<jbarnes> thanks, I poked some UMG folks too
<jbarnes> maybe I can get access to the bits we end up sending you guys :)
<tseliot> jbarnes: I did some work so that it works with DKMS, add diversions, etc.
<jbarnes> cool
<jbarnes> so if you're ever able to include it in the jaunty/karmic repos it should be easy right? :)
<tseliot> jbarnes: I don't think I can do that. Maybe I can upload them to a PPA. I'm discussing this with my team manager
<jbarnes> oh right, I'm not sure how you handle the binary only stuff
<tseliot> jbarnes: ok, I can set up a PPA
<jbarnes> yay
 * jbarnes hopes the bits are better than the ones he already has
<tseliot> jbarnes: ok, I'll upload the packages here: https://launchpad.net/~albertomilone/+archive/poulsbo-graphics
<jbarnes> cool
<tseliot> it will take a while though
<jbarnes> np I probably won't get a chance to update until tonight
<bryce> well I've gotten stuck on my upload tool
<jbarnes> tseliot: thanks a lot
<bryce> launchpad doesn't give enough info about attachments unfortunately
<jbarnes> all the poor suffering poulsbo users will be a bit happier now
<tseliot> jbarnes: np ;)
<jbarnes> tseliot: fwiw there are a few forum threads etc where you could announce the ppa
<jbarnes> seems quite a few people are looking for it
<tseliot> jbarnes: I don't want to make too much noise about it
<jbarnes> yeah I suppose attracting attention to poulsbo is a bad thing generally :)
<tseliot> hehe
<ScottK> tseliot: Are you going to build poulsbo for Karmic?
<tseliot> ScottK: I'm not even sure as to whether it builds with the kernels in Karmic
<ScottK> OK.
<tseliot> ScottK: BTW did my synaptics package work well for you?
<ScottK> tseliot: I still didn't get my 10v back to normal after Alpha 3 testing, so I didn't try it yet.
<ScottK> $WORK has been very busy this week.
<tseliot> ok, np
<ScottK> I saw you got some very good feedback on it though.
<tseliot> right. Thanks apw :-)
<apw> tseliot, heh :)  my 10v was a pig to use without that one package with it its not bad
<tseliot> :-)
<apw> i have large finger tips and i could do with the buttons making bigger
<apw> or whatever its doing to stop it going  bonkers
<apw> anyhow ... win over the previous option which was poking ones eyes out everytime you lifted the wrong finger first
<tseliot> apw: have you tried the xinput property?
<tseliot> "Synaptics Area"
 * apw has only added the package
<apw> there is more magic?
<tseliot> apw: that will allow you to create an area outside of which movements, taps, etc. are ignored
<apw> oh nice so i can deaden like the whole bottom or something
<tseliot> apw: yes, exactly
<apw> is that just in the driver, or something the pad does?
<apw> as it would be nice to be able to say the bottom left triangle
<tseliot> apw: I implemented that in the X driver (and it's in upstream now)
<apw> so we could make it any shape in principle
<tseliot> triangle?
<tseliot> it works with rectangles right now
<apw> the area lets me define a rectagle in the middle which is active basically yes?
<apw> for the particular case of the 10v it would be nice to define two square which do not work out of the corners of the pad
<tseliot> yes
<apw> rather then lose all the bottom or all the sides or whatever
<apw> anyhow thats all academic, it sounds like in principle we could do that if we wanted
<apw> as its done in sw we have control over :)
<tseliot> it's doable but it took me a while to get my patch accepted ;)
<apw> heh yeah ...
<tseliot> for now you can try with xinput set-int-prop $YOUR_DEVICE_ID "Synaptics Area" 32 0 0 0 4000
<apw> the main bit i am benfiting from then is just the 'you couldn't get there that fast, i can't hear you' fix
<apw> how does one find out ones DEVICE_ID
<tseliot> note: 0 means that limit = physical edge
 * apw strays out of his nice comfortable kernel cave
<tseliot> xinput list
<tseliot> and see where it says id
<apw> what the heck is a macintosh button emulation when its at home
<apw> tseliot, so why 5 numbers?
<tseliot> 32 bit
<apw> ahh
<apw> stupid interfaces :)
<tseliot> then you have left, right, top, bottom. It's all documented in the man page of synaptics
<apw> so is that 4000, 4000 units from the bottom up or 4000 from the top down
<tseliot> y is inverted, so top < bottom
<apw> so to make the bottom band smaller i'd make it > 4000
<tseliot> apw: right
<tseliot> jbarnes: do things improve if you put this in a file in /etc/modprobe.d/ :
<tseliot> options psb disable_vsync=1 no_fb=1
<tseliot> that should help
<jbarnes> ok cool I'll try that
<tseliot> jbarnes: that should prevent it from hanging or make it hang less frequently at least
<Sarvatt> might be a little easier to use like synclient AreaBottomEdge 4000 instead of figuring out the id
<Sarvatt> oops, I meant synclient AreaButtomEdge=4000 earlier
 * hyperair feels stupid
<hyperair> turns out the panic was because i forgot to add an initrd
 * hyperair watches ccache hits rise and kernel modules go whizzing by
#ubuntu-x 2009-07-25
<Le-Chuck_ITA> Hi there, is there a specific tag for bugs related to kms?
<hyperair> what's up with KMS?
<RAOF> nouveau can haz kms.  And suspend/resume, too.
<RAOF> Possibly.  If you've got a g80 card, and it's exactly the same as darktama's.
<Le-Chuck_ITA> hyperair: it breaks my system :)
<hyperair> and "breaks my system" is supposed to be a very specific description of the problem, yes?
<Le-Chuck_ITA> hyperair: a "what's up" question requires a quick reply :) But in bug 402982 you'll find a bit more, if you could triage that and request additional information that would be really lovely
<ubottu> Launchpad bug 402982 in linux "Kernel mode switching causes frequent screen flashing with intel video card (not present with the same packages and kernel 2.6.30)" [Undecided,New] https://launchpad.net/bugs/402982
<hyperair> huh screen flashing O_o
<Le-Chuck_ITA> my system is unusable with kms on
<hyperair> do you know which intel card you're using?
<hyperair> preferably the lspci -nn line of it
<Le-Chuck_ITA> bryce: do you have the same problem I think you have an intel card?
<hyperair> since there are so many variants
 * hyperair also has an intel card
<hyperair> how often does your screen flash?
<Le-Chuck_ITA> hyperair: almost constantly
<Le-Chuck_ITA> areas of it
<Le-Chuck_ITA> I can't describe the problem better
<hyperair> hmm flickering eh
<hyperair> a video or picture might be good =\
<Le-Chuck_ITA> is it the right term? 
<Le-Chuck_ITA> I can try
<Le-Chuck_ITA> a video, a picture does not look easy :)
<hyperair> hahah
<hyperair> alright
<hyperair> but if you're using a crt monitor, your video's going to end up funny
<Le-Chuck_ITA> btw when I need to find the lspci -nn line I first need lspci, take note of the bus id, and ... is there a simpler way?
<Le-Chuck_ITA> ah no
<Le-Chuck_ITA> sorry
<Le-Chuck_ITA> -nn IS the right way
<Le-Chuck_ITA> I am using my laptop's screen
<Le-Chuck_ITA> but to make a video I need to reboot, later
<hyperair> laptop screen shouldn't be a problem
<Le-Chuck_ITA> I know :) 
<Le-Chuck_ITA> hyperair: thanks for advice, I'll be back later, please take a look to that bug if you have ideas 
 * hyperair doesn't have any idea because KMS is working perfectly for him
<Le-Chuck_ITA> hyperair: I am here to request some triaging and setting priority and all the things that turn a bug into a known bug
<Le-Chuck_ITA> It's a kernel bug anyways, not x
<Le-Chuck_ITA> but I suspect the xorg experts know what information is needed
<Le-Chuck_ITA> thanks anyway I have to go now
<Sarvatt> hmm, i think the g-s-d touchpad stuff is screwing up somewhere, not getting TapButton settings after a reboot anymore since upgrading that even though I have a hal fdi enabling them and tapping is enabled in g-s-d
<Sarvatt> bryce: about the openchrome debdiff, should I fix debian/xsfbs/xsfbs.sh at the same time? ARCHITECTURE="$(dpkg --print-installation-architecture)" needs to be removed from every package with xsfbs because of the new dpkg to get rid of the warnings
<Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=7deebf983f53c505bc25171ab77fdc408f250a6e
<Sarvatt> should we add every package that uses xsfbs that isnt updated to this bug? https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/403316
<ubottu> Ubuntu bug 403316 in xorg-server "dpkg: warning: obsolete option '--print-installation-architecture'" [Low,Triaged]
<Sarvatt> well i'll start adding stuff, got a ton of source packages here that was easy to grep through and dont think it'd hurt to have a list of what needs updating
<Sarvatt> fglrx-installer-8.620/debian/xorg-driver-fglrx.preinst
<Sarvatt> 18:if [ `dpkg --print-installation-architecture` = "amd64" ]; then
<Sarvatt> hmm fglrx-installer might hit trouble when it goes away
<tjaalton> it's just a warning, so not urgent and will be fixed in debian before too long
<Sarvatt> darn, linked all those packages before i realized i couldnt set the priorities lol
<Sarvatt> fglrx-installer is a bit more serious, it uses the --print-installation-architecture output to determine the diversion on amd64
<tjaalton> ah, ok
<Sarvatt> --print-installation-architecture might actually go away in the karmic timeframe
<Sarvatt>   51 When: 1.15.x
<Sarvatt> ok made up a debdiff for xserver-xorg-video-openchrome against the current svn741 in karmic. i used bryce's r758 package, removed all the .svn folders and repackaged the orig.tar.gz, then added 02_xextproto_7_1_compat.patch and removed the print-installation-architecture call in xsfbs.sh -- http://sarvatt.com/downloads/xserver-xorg-video-openchrome_0.2.903%2bsvn758-0ubuntu1.debdiff
<Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/bugs/+sourcepub/682315/+listing-archive-extra
<superm1> Sarvatt, what is it supposed to be replaced with?
<superm1> --print-architecture?
<Sarvatt> yup
<superm1> well i hope it sticks around at least for karmic's life and changes during LL
<Sarvatt> http://git.debian.org/?p=dpkg/dpkg.git;a=blob;f=README.feature-removal-schedule;h=54ec7a7ac1ca0b841156e9385bdd8731943baec1;hb=fd4d99862af837ccf12e83d13da73e8ffb24aa17
<superm1> packaging changes take a long time to show up in AMD's packages
<Sarvatt> ok, so it looks like I should file a bug against xserver-xorg-video-openchrome asking to upgrade it and list all of the changes I have done and link the build on a PPA, then subscribe ubuntu-main-sponsors and attach the debdiff?
<Sarvatt> what the heck is up with all of these warnings the past week or so
<Sarvatt> dpkg-shlibdeps: warning: debian/xserver-xorg-video-openchrome/usr/lib/xorg/modules/drivers/openchrome_drv.so contains an unresolvable reference to symbol DRIDestroyInfoRec: it's probably a plugin.
<Sarvatt> dpkg-shlibdeps: warning: 183 other similar warnings have been skipped (use -v to see them all).
<Sarvatt> hope i did that right -- https://bugs.edge.launchpad.net/bugs/404618
<ubottu> Ubuntu bug 404618 in xserver-xorg-video-openchrome "Please upgrade xserver-xorg-video-openchrome to latest SVN snapshot." [Undecided,New]
<Sarvatt> is there anything special I should do for requesting to join pkg-xorg in alioth besides requesting to join through the web interface? i dont see a pkg-xorg list on lists.alioth.debian.org like some of the other projects have
#ubuntu-x 2009-07-26
<virtuald> sarvatt: have you stopped doing radeon-kms ppa updates?
<Sarvatt> yep, things have moved into xorg-edgers
<virtuald> ok, in short what will i gain from edgers over regular ubuntu packages?
<virtuald> i guess i'll get better support for my rv570xt
<virtuald> i don't mind x breaking if it's fixed in a few days
<Sarvatt> its just adding an extra layer of things that can go wrong supporting the radeon-kms one at the same time as xorg-edgers now that edgers can support radeon KMS directly. the things in radeon-kms were building against karmic's xserver that does not have the updated dri2 stuff but they had the same package names so there were lots of oppurtunities for things to go wrong
<Sarvatt> yeah edgers has all the latest stuff for that
<Sarvatt> i dont think anythings been broken longer than an hour or two in edgers for months
<Sarvatt> i havent put xserver 1.6.99.1 in there so its pretty straight forward, thats when things are going to get ugly because most of the libs need updating too for that :)
<virtuald> :)
<virtuald> you're going to warn before you do that right?
<virtuald> sarvatt: do you know how to boot isos in grub2?
<Sarvatt> yeah i'll put a big old warning on the page a few weeks before i do it virtuald, no worries :D
<virtuald> heh i don't look at the page very often
<Sarvatt> nope i dunno how to boot iso's in grub2 though :(
<virtuald> ok
<virtuald> google does :>
<Sarvatt> hmm, somethings definitely wrong with g-s-d. the touchpad settings in the mouse preferences applet is the old one and is modifying the /desktop/gnome/peripherals/mouse keys, not the new /desktop/gnome/peripherals/touchpad ones
<Sarvatt> its reading the default settings every boot with no way to change it outside of manually adjusting the gconf settings for /desktop/gnome/peripherals/touchpad or using synclient, it overrides the HAL settings even
<Sarvatt> the keys in /desktop/gnome/peripherals/touchpad/ all work as intended, if i enabled tap to click there it enables it right away for instance
<Sarvatt> but the gui to change those settings is broken..
<Sarvatt> ahh we need gnome-control-center to be updated to work with the new touchpad stuff, no wonder
<Sarvatt> http://git.gnome.org/cgit/gnome-control-center/commit/?id=e14a84a718d9882d320de1f359c0547836a9b4e3
<Sarvatt> hmm, whats the deal with the radeon files in firmware-linux from debian?
<Sarvatt> is it built into our kernels with CONFIG_FIRMWARE_IN_KERNEL or something? didnt know they were there
<Sarvatt> ah ok i see how it works in drivers/gpu/drm/radeon/radeon_cp.c
<Sarvatt> https://bugs.edge.launchpad.net/bugs/404428
<Sarvatt> silly silly bugs
<Sarvatt> should be a wishlist if anything, theres 0 chance the mesa r600 dri driver is going to make it into karmic
#ubuntu-x 2010-07-26
<Sarvatt> well no wonder the nvidia blob was fine with firefox and screwed up with everything else with newer cairo - http://hg.mozilla.org/mozilla-central/file/dcddffb3b329/gfx/cairo/disable-server-gradients.patch
<Sarvatt> would be good to update intel-gpu-tools with all of these automated dump reports, http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/?id=2d1ad95423953c60fdc5b336d5dd1298ce2114c7 is nice
<jdub> should i expect problems trying to get an intel G45 running at 2560x1440 on lucid?
<jdub> x has decided that 720x400 should be good enough for me
<jdub> doesn't list 2560x1440 in xrandr (but does list up to 1600x1200)
<jdub> (which works)
<jdub> it's kinda odd, some of the initial mode detection doesn't list 2560x1440 at all
<jdub> but subsequent "printing ddc gathered modelines" shows it as the first choice
<jdub> (II) intel(0): Supported detailed timing:
<jdub> (II) intel(0): clock: 241.5 MHz   Image Size:  597 x 336 mm
<jdub> (II) intel(0): h_active: 2560  h_sync: 2608  h_sync_end 2640 h_blank_end 2720 h_border: 0
<jdub> (II) intel(0): v_active: 1440  v_sync: 1443  v_sync_end 1448 v_blanking: 1481 v_border: 0
<jdub> (II) intel(0): Printing probed modes for output HDMI2
<jdub>  
<jdub> (II) intel(0): Modeline "1600x1200"x60.0  162.00  1600 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
<jdub> (II) intel(0): Modeline "1680x1050"x60.0  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz)
<jdub>  
<jdub> very odd
<jdub> have also tried without kms
<tseliot> jdub: 2560x1440? What kind of screen is that?
<tseliot> jdub: also, the HDMI cable may not support that resolution (it depends on the cable version)
<Duke`> video-intel/mesa (i915) are broken for me since july 22nd
<Sarvatt> hyperair: fixed mesa uploading
#ubuntu-x 2010-07-27
<hyperair> Sarvatt: oh they fixed the bug already? cool!
<Sarvatt> yup http://cgit.freedesktop.org/mesa/mesa/commit/?id=2235b1c72d79ec00a03c99219154e3f9103e692b
<Sarvatt> fixed it here, i dont have to use force_swap_buffers anymore
<hyperair> then i can rmeove my package pin =)
<Sarvatt> hyperair: not sure if its compiz 0.9 specific but i'm seeing some problems still, but at least it works now :)
<Sarvatt> things not refreshing sometimes, like when i switch folders in gmail
<hyperair> hmm
<hyperair> i'm not seeing any problems yet
<hyperair> or maybe i haven't restarted compiz..
 * hyperair attempts to recall whether dpkg finished first or he logged in first.
<hyperair> hmm looks like it works.
#ubuntu-x 2010-07-28
<RAOF> Aaah, plymouth.  Source of endless fun!
 * Sarvatt wonders how long maverick will be broken horribly because of it this time
<Sarvatt> nows about the time where all the brokenness starts if lucid is any indication :)
<RAOF> Me thinks there is a race condition somewhere between X and plymouth on radeon, where drmGetBusId will return ââ if called after a certain point, which obviously breaks X.
<Sarvatt> that happens when X loads the actual kernel module
<Sarvatt> and its fixed by vesafb=sucks
<RAOF> Oh, really?
<RAOF> Well, it doesn't surprise me that killing vesafb works - is that the trigger, though?
<Sarvatt> i think udev sees the video device tagged already because of vesafb and doesn't load radeon before X starts, those errors are the same as when X starts and fails because of the agp crap
<RAOF> The race is that X needs to come up before radeon has got loaded?
<Sarvatt> radeon needs to load before X starts or else the ddx tries to load it with xf86LoadKernelModule() which fails like that
<Sarvatt> its happening on nouveau too
<RAOF> I haven't seen it there on my hardware, but I have seen it on radeon.
<Sarvatt> lemme try to dig up a nouveau one, ricotz and someone else were having it
<Sarvatt> the grub change in mid july started all this
<RAOF> Yeah.
<RAOF> To leave the grub-set vesa mode and hand off to vesafb.
<Sarvatt> dropping gfxpayload=keep or vesafb=sucks fixes it for now at least
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/606244
<ubot4> Launchpad bug 606244 in linux (Ubuntu) "X doesn't find a screen and is not starting due a race condition (affects: 3) (heat: 434)" [High,Confirmed]
<RAOF> Yeah, that's the bug I got them to file.
<Sarvatt> i had problems on intel the first few boots after updating grub but its fine now without any of those for some strange reason
<Sarvatt> with FRAMEBUFFER=Y plymouth was always racy though
<Sarvatt> sometimes i'd get a text splash at native resolution
<Sarvatt> i'm guessing when it actually uses vesafb it'll be screwed and i just havent gotten into those situations where it would use a text splash before
<Sarvatt> i got the text splash because vga16fb was blacklisted
<RAOF> vga16fb should no longer be loading at all now.
<RAOF> Nowâ¦ why is DRI2 killing X on radeon.
<Sarvatt> yeah its not, just saying plymouth would start before inteldrmfb was ready and i'd get a text splash that resized to native res once it was ready sometimes and thats probably whats going to be broken now that its using vesafb
<RAOF> I know the thinking was that vesafb *should* handoff nicely to the drmfb.
<Sarvatt> it does without plymouth
<Sarvatt> plymouth segfaults and things are all screwed up at that point though
<RAOF> Right.
<RAOF> Plymouth also seems to trigger a nice kernel mutex trace.
<Sarvatt> display turns off after intel loads until X starts, if i dont hit escape to switch away from the screwed up plymouth before X starts it just hangs
<RAOF> Hurray for race conditions!
<Sarvatt> vesafb > inteldrmfb handoff > plymouth is fine, vesafb > plymouth > inteldrmfb is screwed
<Dr_Jakob> Sarvatt: so if you get plymouth to load the i915 driver you should be okay?
<Sarvatt> it doesn't like using the framebuffer renderer on a drmfb
<Sarvatt> yeah thats a good idea, will look into that
<RAOF> Do we still have plymouth's drm renderer backend?
<Sarvatt> yeah
<RAOF> What happens if you take that away?
<RAOF> That can't be the nouveau problem, because we don't use it there.
<Sarvatt> it picks which backend to use when it starts though and cant change it
<RAOF> You can't change it by just deleting the .so? :)
<Sarvatt> which would you delete? the framebuffer renderer doesn't work on an inteldrmfb :)
<Sarvatt> getting rid of the drm backend would make seeing if thats whats really happening easier though
<RAOF> As I say, that's clearly not what's happening on nouveau, because we don't use the drm renderer on nouveau.
<Sarvatt> yeah I know, X loading the kernel module doesn't load drm and crap in time for nouveau and radeon, entirely different problem
<RAOF> Hm.  That's a new one - segfault in radeon_drv due to dereferencing a random pointer.
<Sarvatt> can you reproduce the nouveau or radeon problem? i'd be interested in knowing what device is tagged PRIMARY_DEVICE_FOR_DISPLAY when it fails
<Sarvatt> is it on LP?
<RAOF> Sarvatt: I can probably reproduce on radeon.
<RAOF> Sarvatt: It might be on LP, but that's not where I'm looking.
<RAOF> Flicking through screensavers will kill X in radeon_dri2_copy_region.
<RAOF> However, it's not a problem in (the new) mesa, so it's time to get that uploaded.
<RAOF> Then we can move to server 1.9
<Sarvatt> guess i shouldn't have filed that x-x-v-sis sync request if we're about to jump to 1.9 and need to rebuild all the drivers :)
<Sarvatt> i have no clue what this guy was trying to do reversioning ppa-purge to 0+bzr46.1 instead of the 0.2.6 it was at and it's already in the archives.. i need to make some changes and i'm not sure what he wants next
<Sarvatt> guess i'll just do (1) UNRELEASED with all these changes, it needs to be higher than 0.2.6 to even upgrade
<RAOF> Good that it's in the archives, though.
<Sarvatt> RAOF: what gen ati was crashing btw?
<Sarvatt> r300?
<Sarvatt> mesa dri driver gen name I mean
<RAOF> r600
<RAOF> It's an r700 chip, though.
<RAOF> I'll try it against edgers before poking further.
<RAOF> Whoops!  There it goes.
<Sarvatt> crashed with edgers too?
<RAOF> Yup.  This time in dixLookupPrivate because fo all the privates changes in 1.9
<RAOF> Edgers builds from master, right?
<Sarvatt> yeah
<RAOF> Hm.  devPrivates = 0x0.  That's unlikely to work.
<Sarvatt> i dont suppose you use fglrx on that machine ever? :)
 * Sarvatt is packaging up 10.7 and doesn't know if it works
<Sarvatt> eh i'll just do the normal upload and wait for whining on phoronix about it being broken
<RAOF> I can test fglrx if you want.
<Sarvatt> thats weird though, i haven't heard anyone complain about r600 being broken with -ati in edgers, i'm guessing you're getting that right after X starts due to the copyfb stuff?
<Sarvatt> nah thats ok, it should be fine
<Sarvatt> dropped all the patches since its supposed to support 2.6.35 out of the box
<Sarvatt> i'll just do a build test manually
<RAOF> No, not at al.
<RAOF> When quitting a DRI2 client - such as flipping wildly through the scrensavers.
<Sarvatt> ahh ok that narrows it down, i think i saw a bug about that on dri-devel
<RAOF> Hm.  I hadn't noticed one.
<Sarvatt> problem is it had a weird title i'm sure and i can't find it :(
<RAOF> Ok, so at least one part of the problem is that dixLookupDrawable is returning Success, but filling &drawable with random data.
<Sarvatt> prahal: the way to reproduce is to run gnome-screensaver-preferences and switch back and forth on c-waes . After 2 or three attempts I get the segffault and the gdb print shows the dri2 buffer pixmap devPrivates null
<RAOF> Ah, where's that?
<Sarvatt> some more talk of it here - http://www.radeonhd.org/?page=archive_display&c=radeon&m=7&y=2010&d=2010-7-06
<RAOF> Ah, thanks.
<RAOF> Yup, that's what I'm seeing.
<RAOF> Pity there doesn't seem to be a bug reference there.
<Sarvatt> i can't find anything else :(
<Sarvatt> wonder if this helps any - https://bugs.freedesktop.org/attachment.cgi?id=37401
<Sarvatt> + https://bugs.freedesktop.org/attachment.cgi?id=37414
<RAOF> Hm.  I'm not sure.
<alf__> Hi all! Is there a document that describes the current state of input handling in X in ubuntu? eg I want to connect a second keyboard using a different layout and I am a bit confused on how I should go about it.
<kangarooo> Sarvatt: ping
<kangarooo> im now reinstalled 10.10 to test if no xorg crashes.. im actually having now different crash.. all screen freezes and network also. mouse still moves. with raw mode i can open tty6 (still not showing in screen) and making ctrl+alt+del restart.. what dbg i should install? i have nVidia Corporation NV34 [GeForce FX 5500] (rev a1) but restricted driver i removed couse that makes screen respond slow..
<kangarooo> happens when in FF opening YT or http://en.wikipedia.org/wiki/Ubuntu_(operating_system)#cite_note-11 if i open without citenote then it doesnt hang. opening cite note makes screen go to cite note and its marked blue till blue fades out..
<kangarooo> yt flash video i mean.. but not all videos.. but most of them
<kangarooo> what should i install to debug and post report couse i cant get any crash report when crashes happen.
#ubuntu-x 2010-07-29
<Sarvatt> note to self: get x11-xserver-utils merged before feature freeze
<RAOF> What's shiny and new?
<Sarvatt> brightness option in xrandr and a bunch of bugfixes
<Sarvatt> been putting off the merge because i want to upstream the only patch left first
<RAOF> Ok.  I'll leave that to you, then?
<Sarvatt> how should i go about sending someone else's patch to xorg-devel? bryceh: any chance you have your 101_xset_spellfix.patch from x11-xserver-utils git formatted? :)
<Sarvatt> if i use git send-email it'd have me as the author I mean
<RAOF> Sarvatt: Not if you commit it with the --author tag
<Sarvatt> mesa has been going through some really rough spots for the past week after being stable for months, bad timing with feature freeze :(
<RAOF> âIt's getting close to release!  Quick!  Land all the development branches!â
<RAOF> You know it's time to get your gloves when it's getting hard to type because your fingers are too stiff.
<Dr_Jakob> Yeah Kristian decided to open up a whole can of worms with fixing some glx issues.
<kangarooo> Sarvatt: ping
<RAOF> I saw that backtrace; it means, roughly âdamn, the GPU hung and I've got absolutely no idea what to do about itâ
<kangarooo> RAOF: about mine bug?
<apw> do we support nonmodesetting on i915 in maverick any more ?
<tseliot> apw: I think RAOF did something for the 8xx series, I'm not really sure about i915 though
<apw> its becomng hard to use one machine for all testing as you can't do both paths any more it seems
<jcristau> the 2.12 intel X driver doesn't do ums
<jcristau> there's a branch to bring it back, but i don't think it's landed in m
<tseliot> yes, I know it's not easy
<tseliot> fortunately we still have that in radeon
#ubuntu-x 2010-07-30
<RAOF> Argh.  I hate you, git, and the way âgit checkout masterâ doesn't necessarily get you the damn master branch.
<Sarvatt> i didn't realize just how bad this multiple gpu situation has gotten until i just started shopping for a new laptop.. thanks to the new intels pretty much every laptop over $500 has switchable (or optimus) graphics now. optimus is a nightmare :(
<Sarvatt> everything with a newer nvidia discreet gpu and intel cpu having optimus, and not being able to explicitly pick the nvidia gpu and all
<johanbr> Sarvatt, get something with an ATI?
<Sarvatt> yeah trying to find a decent 13.3" with ati hybrid thats not 2k+, it's a shame those nice asus' only have nvidia
<Sarvatt> either that or go back a generation before optimus
<Sarvatt> but i mean it's going to be a horrible linux experience for people with nvidia now
<RAOF> How does that work with the binary drivers?  I mean, apart from the intel GPU not working.
<Sarvatt> it doesnt from what i can see
<RAOF> Joy.
<Sarvatt> you only get the intel
<RAOF> vgaswitcheroo won't work either, will it, because optimus is some sort of crazy abomination where the nvidia GPU renders to the scanout buffer of the intel GPU, right?
<johanbr> apparently it depends on the laptop: http://www.nvnews.net/vbulletin/showthread.php?p=2291702#post2291702
<Sarvatt> too bad the blob and intel cant coexist :)
<Sarvatt> hmm new blobrelease for opengl 4.1
<Sarvatt> http://developer.nvidia.com/object/opengl_driver.html#notes
<Sarvatt> wonder if it snuck in xserver 1.9 support
<RAOF> Gah.  What has decided to eat all my goats?
<RAOF> And by âgoatsâ I of course mean âmemoryâ
<RAOF> Ah, no.  Actually I mean I/O.
<RAOF> The unholy trinity strikes again - ubuntuone-syncdaemon, dpkg, and btrfs.
<RAOF> Who wants to buy me an Apple Magic Trackpad so I can test multitouch? :)
<bryceh> heya
<RAOF> Howdie.
<RAOF> How's the week treated you?
<bryceh> great, been on vacation at the beach the past week
<RAOF> Hah!
<RAOF> Sounds like fun.
<bryceh> the house we were in had wireless but the password they gave didn't work, so yeah
 * RAOF is sitting in front of his fan-forced gas fireplace; the office is too cold!
<bryceh> so instead mostly I played with my son and fiddled with learning how to code cairo animation stuff
<RAOF> Yay!
<bryceh> RAOF, how things going for you?
<RAOF> I spent some of my flight home from Prague working out how to do a proof of concept gobject-introspection-sharp binder.
<RAOF> Looking up, now.
<RAOF> I've not only woken up after the long, long flight, I think I've also beaten the low-grade ubuflu.
<bryceh> oh yeah sounds like that was going around
<RAOF> I don't think I've had it like others have had it.
<bryceh> that's good
<bryceh> being the X guy sucks in that everyone's handing you their germy laptops to fix
<RAOF> I didn't get _too_ many laptops :)
<bryceh> speaking of which... did many people hand you their germy laptops?  :-)
<bryceh> haha, well it's all-hands you have to really watch out for.  uds is pretty intense too sometimes
<RAOF> Heh.
<RAOF> We can tag-team next UDS.
<bryceh> yup
<bryceh> actually I've been doing a lot of thinking about how to restructure things to work better for us
<RAOF> Hm.  Do tell!
<bryceh> did some X strategery thinkin
<bryceh> well, sounds like we're going to have some ample X resources in place for NN, so was thinking maybe this was our chance to really get organized and on top of everything
<bryceh> but to do that we'd need to be more focused in *what* we do
<bryceh> I think in the past there's been so much to do that the work ends up being much more 'reactive'
<RAOF> Right.  There's lots of firefighting.
<bryceh> however there's really no reason it *has* to be that way
<RAOF> Or do you mean more âif we contribute more upstream we get to have more influence on what happens, meaning we get a better ability to planâ?
<bryceh> we just need to narrow down a few points of focus and set some boundaries so we can keep the firefighting at arm's length and focus on some specific projects to make things more solid
<bryceh> well, I don't think it's a matter of *contributing* to upstream so much as *throttling* it
<RAOF> I think collaborating with the DX team we could really get some useful focus.
<bryceh> I think a lot of our bug problems occur because we allow in upstream code that's been heavily changed without sufficient testing
<bryceh> which is something we *could* switch around and do differently
<bryceh> and on a completely other angle
<bryceh> as I've mentioned before I think we get a lot of bug reports that really are more of the type "help me, fix my computer", rather than, "Here is a way to make X better for Ubuntu"
<bryceh> so I think we need to find ways to better distinguish the latter from the former, and focus exclusively on the latter
<bryceh> and another angle...
<bryceh> been thinking about different ways of organizing workloads.  I can think of several schemes:
<RAOF> I know the QA team has a pretty serious collection of hardware which we could potentially harness for the purposes of getting testing.
<bryceh> 1.  One option is to handle things generally, setting priorities on the fly as work comes in
<bryceh> 2.  Divide things by drivers, each of us taking one or two drivers to focus on
<bryceh> 3.  Divide things by work *type*, e.g. packaging vs. bug triage/upstreaming vs. bug fixing vs. special projects
<bryceh> 4.  Divide things by hardware type, e.g. 'tier-one hardware', 'tier-two hardware', ...  
<RAOF> 5. Have a frontend/backend type split, if we've got access to enough people.
<bryceh> yep
<bryceh> anyway, a topic for discussion at next UDS
<RAOF> When we'll 
<RAOF> (hopefull) know the sort of resources we have a available!
<bryceh> or maybe we could have a Ubuntu-X online summit prior to that, just to get organized ahead of time
<bryceh> right
<bryceh> on another angle...  I'd like to push during NN to pull in some more community members into participation.  grow ubuntu-x active members
<bryceh> community members have been key for getting stuff done with ubuntu-x in the past, and will continue to be so
<bryceh> on another angle...  more coordination with debian
<RAOF> I think we're doing reasonably well with that this cycle.
<RAOF> Yay!  I didn't glue my hands to my face with that xserver build!
<bryceh> that's good to hear, I've been pretty piss poor at that 
<RAOF> It may have taken more than one build to get right, though ;)
<bryceh> RAOF, also the launchpad team has some nifty workflow tracking systems that I think would be interesting to try applying to the ubuntu-x team
<bryceh> it's particularly useful for getting the team to focus on *fewer* projects, and to do those well
<RAOF> I'm interested to hear them; jml is the most organised person I know.
<RAOF> (Even moreso than *you*!)
<bryceh> hehe
<bryceh> true
<RAOF> jml talked about âkanbanâ when I breakfasted with him in Prague; that seemed interesting.
<RAOF> Oh, man.  btrfs, I hate you.
<RAOF> Ah, no.  'twas mutter!
<bryceh> right
<bryceh> the kanban the launchpad team's using is good for long-cycle project work
<bryceh> what I've been mulling is something a bit more tightly hooked in with launchpad, so it'll work for the types of shorter-cycle work we tend to do on X
<bryceh> which I think could take the place of some of the various reports and lists I've been generating, and give it a better workflowy feel
<bryceh> easier to show it than explain it :-)
<RAOF> Something like a list we can work through and move things into the âfinishedâ bucket?
<bryceh> of course, I have to code it before that :-)
<bryceh> exactly
<bryceh> actually there'd be multiple buckets
<bryceh> so you'd work on something and then drag it to 'finished', 'upstreamed', 'needs-qa-testing' or so on
<RAOF> Right.
<bryceh> so we avoid just having a list of bugs assigned to ourselves with no context or status
<RAOF> We instead have a couple of lists of bugs, and the list they're in indicates what sort of action we need to take on them.
<bryceh> I also want to make it publically visible so when people come to ask for us to do something we can point them to something that shows exactly how full our plate is and gives them a 'Now Serving #' ticket 
<RAOF> :)
<bryceh> right, one set for triaging, one set for forwarding upstream, one for analyzing/fixing, one for backporting patches, etc.
<RAOF> So we can start on a list that we have an appropriate energy level for.
<bryceh> perhaps also integrate packaging work and blueprint tasks in there, so we can track everything in one tool
<bryceh> perhaps that can also generate our weekly status reports for us ;-)
<RAOF> Moar automation!  Moar!
<bryceh> well, that's getting a bit blue sky...  the dragging stuff into buckets is coded and works, and I think would help in the NN timeframe
<bryceh> well, mostly coded
<RAOF> Heh.
<bryceh> it's cool though, all Cairo graphics stuff, no web browser needed
<RAOF> Sweet.
<RAOF> Cairo is fun.
<bryceh> yep
<bryceh> some of the differences from how inkscape works has required a bit of re-education
<bryceh> waaay better than CSS fiddling though
<bryceh> and no javascript in sight :-)
<RAOF> I found postscript surprisingly fun, to :)
<bryceh> reverse polish notation goodness
<RAOF> Stack based languages FTW!
<bryceh> RAOF, btw do you have some thoughts on how we could improve how we do X maintenance in NN?
<RAOF> I think that one of the things we should do is ask the DX team what they're hitting in mesa & X, and put some work into that.
<RAOF> I think we should have enough resources to be able to spend some time looking at what DX are doing, and what they'd like to work, and making it happen.
 * bryceh nods
<bryceh> that's a good point... internal customer needs
<RAOF> Yeah.  We have them :)
<bryceh> I've thought we could be better tied in with the technical support team as well
<RAOF> And the QA team, I think, too.
<bryceh> yeah, although I don't think we have an X person on the QA team side
<RAOF> For example, did you know that unity has hand-written shaders because the mesa GLSL compiler produces broken shaders for what they wanted to do?
<bryceh> we did do pretty well with Ara for testing though in lucid
<RAOF> Yeah.
<bryceh> ouch
<RAOF> Oh, and unity just doesn't run at all on (at least) r600?
<bryceh> is that just hw acceleration lackage?
<RAOF> I'm not sure.  It should be falling back more gracefully than it is, though.
<bryceh> this gets back to my thinking about setting boundaries... i.e. we support thus and such feature on this and thass hardware
<bryceh> and where there is a discrepancy between what we *think* we support and what we actually deliver, that becomes priority areas for us
<RAOF> Right.  RH basically wants a mesa sufficient to run gnome-shell, and prioritises that; once we've got the X resources, we should do something similar for unity.
<RAOF> I think it might also be nice to be able to push code at the suite of QA machines, wherever they are, before it goes into the main archive.
<bryceh> yep
<bryceh> we've GOT to get something in place for automated testing of the X stack, even if it only has a slight coverage
<RAOF> I wonder if the kernel would be interested in that too, actually.
<bryceh> that's something I've been picking at for years but never really hammered into useful shape
<RAOF> I'm pretty sure that QA *does* have a bunch of automated testing; it's just opaque to me.
<bryceh> true, there's enough overlap here we could probably collaborate on it
<bryceh> yeah I've described to them the types of reports that would be useful to me
<RAOF> At the rally someone was asking about what numbers to look for in the X memory stats to indicate a leak, for example.
<bryceh> like a performance chart run bi-weekly
<RAOF> Yeah.
<Dr_Jakob> If it is suposed to do any good you need to run it continiously...
<Dr_Jakob> A lot of stuff can go into mesa in two weeks.
 * RAOF always gets twice- & bi- confused :)
<bryceh> Dr_Jakob, not a chart of upstream git commits, but rather what is in Ubuntu
<bryceh> we tend not to update mesa quite that frequently, so... ;-)
<bryceh> but daily performance numbers would be lovely
<bryceh> or even more frequently.
<Dr_Jakob> We need something like Linaro but only for graphics.
<bryceh> isn't that what X.org is?  ;-)
<Dr_Jakob> X.org doesn't have any developers.
<bryceh> sure they do
<bryceh> else where would all these bugs be coming from?
<Dr_Jakob> Not hired/given to X.org...
<bryceh> anyway, my point is structurally the organization exists
<bryceh> what's lacking is the business case for putting funding / head-count towards manning it
<bryceh> although a number of companies contribute heads towards development work anyway
<Dr_Jakob> That whats always boggles my mind, the UI is like the most fundamental thing of the OS yet it always gets the short end of the stick.
 * bryceh nods
<bryceh> kernel gets all the luv
<bryceh> most linux-oriented companies have mostly just been focused on server business cases
<bryceh> so X is sort of a nicety for them
<bryceh> not something which drives profitability
<Dr_Jakob> Myeah, tho the feel I get from Ubuntu its that its mostly a desktop outfit, yet your the one contributing the least to X..
<bryceh> how do you count 'contributing'?
<Dr_Jakob> Also I should have probably said "Linaro for 3D" instead of X, the priorities from all the hired devs seems to be Modesetting first 3D last.
<RAOF> Well, Chase has been contributing a bunch of multitouch patches, but I'm not sure how much that's in his own time.  You're right, we don't have a lot of X hackers.
<RAOF> xorg-edgers seems to be quite a useful contribution :)
<Dr_Jakob> Again I probably should have said 3D instead of X, where I spend most of my time.
<RAOF> Damn.  Attaching gdb to mutter caused it to unfreeze :(
<RAOF> Even there, xorg-edgers seems to provide a bunch of testers for the bleeding-edge mesa, some of which appear to file useful bugs/hang on IRC in useful ways.
<RAOF> It's not the same as providing *code* to mesa.
<Dr_Jakob> Yeah, xorg-edgers is nice for bug reports.
<Dr_Jakob> but yeah code is nicer, especially tested code.
<Dr_Jakob> s/tested/debugged/
<RAOF> Hah.
<RAOF> We might be able to direct some people towards contributing code, too, but mesa & X is not particularly amenable to drive-by contributions.
<Dr_Jakob> The problem is you deal with compilers, asyncorness system, network code, virtual memory and non-fault tolerent hardware.
<Dr_Jakob> Graphics code probably has the highest cost per line of code.
<Dr_Jakob> yeah
<bryceh> Dr_Jakob, it's interesting you emphasize _tested_, and goes to my point.  ubuntu-x does a heapload of testing, but since testing does not show up in git changelogs, we earn zero credit for the work
<bryceh> someone contributing half a dozen git commits of untested buggy code gets more credit than any amount of testing/bug fixing/bug forwarding done at our end
<Dr_Jakob> bryceh: I revised it "debugged" that includes fixing the problem :)
<Dr_Jakob> it to*
<bryceh> Dr_Jakob, the one thing you miss is "debugged *and delivered to users*"
<bryceh> fixes do little good to you if they're sitting in some remote git tree
<Dr_Jakob> I'm not saying you haven't done anything, I'm saying we can always need more people doing work on the drivers.
<bryceh> er, you said "you're the one contributing the least to X"
<bryceh> them's fightin' words ;-)
<bryceh> (and a bad yet quite popular meme)
<Dr_Jakob> vs RedHat & Novel yes.
<RAOF> As long as you measure by LoC, certainly.
<Dr_Jakob> Actually I don't really know what Novel does for X, so maybe they are just as bad..
<Dr_Jakob> Does Fedora have bleeding edge as well?
<RAOF> Fedora kindof _is_ bleeding edge, but I'm not aware of anything like xorg-edgers there.
<superm1> RAOF, could you help me to understand what the negative implications are for running a system that supports KMS with fbdev for 2D stuff?  Are there any?
<superm1> eg, lets say it's an intel system, and modesetting is enabled, but we choose to run X with fbdev
<bryceh> superm1, lack of 3D is the main thing
<superm1> bryceh, so for say trying to come up with a more stable installation though, no real negative implications then
<bryceh> superm1, you might also check video, like if Xv is available
<superm1> i'm looking at on recovery media forcing to vesa / fbdev for installation only maybe
<bryceh> that's probably fine
<superm1> especially knowing there is a mess of problems with sugar bay stuff right now that might not necessarily be fixed by the time maverick launches
<superm1> okay cool thanks.  i've added it as a configurable option in ubiquity
<superm1> debconf option is ubiquity/force_failsafe_graphics
 * bryceh nods
<bryceh> we've used fbdev for the failsafe-x stuff
<superm1> the only real problem then is if the HW fails at modesetting, still need to patch initial kernel command line to nomodeset :)
<bryceh> yeah
<superm1> it would be nice if there was actually a way to prod something in sysfs or procfs to turn on and off modesetting
<bryceh> you could check if xrandr can be used from a fbdev session
<bryceh> superm1, you could chat with one of the kernel guys, I'd spoken to them last UDS about making configuration of kms settings easier, and they seemed to already know of some plans afoot
<superm1> oh rlly?  that would certainly be nice
<superm1> looks like you're right, xrandr doesn't work when you are booted with fbdev
<superm1> fortunately that shouldn't be too necessary during install
<bryceh> ok yeah I suspected that
<bryceh> oh, power saving stuff might also not be available with fbdev
<bryceh> or at least screen blanking
<superm1> okay, that shouldn't be too big a deal either then
<bryceh> superm1, specifically we were talking about making it easier to add quirks and to toggle debugging stuff, and they told me about the kernel getting support for having a loadable data nodule where you can set quirks and toggle parameters like the chosen resolution, and then pass that to the kernel 
<bryceh> it was a bit hand wavy, and I didn't follow up so dunno what the status is
<bryceh> however I think it is exactly the sort of thing you guys will find useful for quirking/configuring some of this stuff
<superm1> ah, but that would still be stuff that was passed on the kernel command line then i take it
<superm1> oh wait, but loadable data module, maybe not
<bryceh> I'm not sure what the exact interface is for it, might be sysfs
<superm1> who was it you were chatting with about this?  i should just ping 'em and see
<bryceh> andy mainly, chase and ogasawara were there too. 
<Sarvatt> superm1: as long as we get mesa 7.9 in sugar bay should be fine (famous last words..)
<Sarvatt> then again there's still all kinds of problems with panels using eDP
<Dr_Jakob> Sugar Bay?
<Sarvatt> yeah next intel platform coming out with sandybridge cpu/gpu
<Sarvatt> i6
<Dr_Jakob> Ah
<Sarvatt> new socket yet again :(
<Sarvatt> superm1: i bet you guys at dell are loving the fact that all intel laptops with nvidia GPU's will be unable to use the discreet gpu for a looong time in linux huh?
<superm1> wha?
<superm1> did I miss something?
<Sarvatt> optimus
<superm1> oh, when there are multi nvidia gpu setups
<superm1> you can at least use one of the GPUs still
<Sarvatt> only the intel, its an abomination where the nvidia gpu renders into the intel and i haven't seen any that let you pick one or the other in bios or via acpi yet so you're stuck with only the intel graphics built into the cpu
<superm1> oh yuck, i didn't realize it was that bad
<Sarvatt> the old type of hybrids work somewhat but these optimus ones are nasty
<superm1> none of the platforms that have come by my group have actually had that stuff yet
<Sarvatt> oh looks like alienware m11x is the only laptop with nvidia graphics on dell.com at the moment from a quick glance
<superm1> i know most of the machines that have it, but i haven't kept up on release dates, so i probably shouldn't say much beyond that
<Sarvatt> I'll probably be working with those same machines here soon :)
#ubuntu-x 2010-07-31
<Sarvatt> oh hey there's actually more info on sugar bay now - http://www.electronista.com/articles/10/07/29/intel.to.make.sugar.bay.available.early.january/
<tjaalton> alrighty, let's see how broken maverick on intel is.. upgrading a months worth of packages
<tjaalton> seems to work just fine
<Sarvatt> i'm not going to create orig.tar.gz's for these new nvidia blob packages in x-updates in case the same deal as last time happens again where I can't update it
#ubuntu-x 2010-08-01
<LLStarks> bryceh, what's the diff between raof and glasen's solutions for i8xx?
<LLStarks> err, cwillu's solution
<cwillu> I have a solution?
<cwillu> (my solution was to buy an nvidia, and use nouveau :p)
<LLStarks> i'd do that too, but everything's optimus
<LLStarks> anyway, i meant chris wilson (ickle), not you. <__<
<cwillu> yes, figured there was a missing cw<tab> in here
#ubuntu-x 2011-07-25
<bjsnider> RAOF, do you get into a situation where the screen will go black for an instant with nouveau?
<RAOF> bjsnider: More info required.  That could be VGA polling, but I don't use any VGA outputs.
<afiestas> RAOF: well, I want to start by writting the daemon taht will hadle such things
<afiestas> ut I guess that I can start elsewhere
<afiestas> or, if we agree on the format I can parse it myself like we do in Bluetooth with the pin-database.xml
<afiestas> going to sleep now, send me an email with the status/plans/etc to afiestas@kde.org
<afiestas> good night/morning!
<bjsnider> RAOF, i am using dvi
<RAOF> How frequent are these?  Any triggers?  Do they only occur with 3D?  How long do they last?  etc :)
<bjsnider> i think it may be power related, because i have to stop using it for a little while
<bjsnider> the nouse pointer has a tendency to stutter unde nouveau
<bjsnider> and i lost sound when i upgraded to edgers
<RAOF> Lost *sound*?
<RAOF> That's plenty weird.
<RAOF> I'd guess at kernel fun!
<bjsnider> i needed the 3.0 kernel for nouveau though
<bjsnider> ok, sound works again
<bjsnider> RAOF, how can i have desktop tearing when there's no tearing in mutter?
<bjsnider> i should be tear-free. this is an outrage.
<RAOF> What compositor are you using?  Compiz?
<bjsnider> mutter
<RAOF> But there's no tearing in mutter?  I'm confused as to what the problem is.
<bjsnider> i am using mutter and getting tearing anyway
<RAOF> Ah.  Well, you'd need to turn on vsync if you want that to work :)
<RAOF> That still needs an xorg.conf option IIRC.
<bjsnider> in nouveau?
<bjsnider> why would anyone want to not have vsync?
<RAOF> Because it's as-yet lightly tested.
<bjsnider> well, it was almost stable. i might switch to it in oneiric
<bjsnider> or when wayland is eventually used
<bjsnider> guess i'll have no choice then though
<bjsnider> ricotz, you're using gnome 3 with nvidia right?
<ricotz> bjsnider, yes
<bjsnider> have you noticed the new flash plugin taking down the desktop?
<ricotz> bjsnider, no, i am using 11.0  64bit version
<bjsnider> ricotz, with what browser?
<ricotz> firefox 6.0b2
<bjsnider> do you have chromium installed?
<ricotz> no
<bjsnider> well, anyway, can you go to youtube and play a few videos over the course of a couple of minutes please?
<ricotz> is the xserver crashing or only gnome-shell?
<bjsnider> everything stops except the mouse
<bjsnider> keyboard doesn't work
<ricotz> so it is locked, perhaps in a loop
<ricotz> did you look for running processes while in this state?
<bjsnider> yes but other than flash initiating it i can't tell what the problem is
<bjsnider> could be an nvidia problem, could be gnome-shell, who knows
<ricotz> so you cant switch to tty1?
<bjsnider> it's impossible to do anything except move the mouse
<ricotz> ssh?
<bjsnider> tty1 would require the keyboard to work
<bjsnider> don't have another system to use ssh
<ricotz> mhh, ok
<ricotz> currently i dont want to trigger this here
<ricotz> if it would happen too
<bjsnider> the 64-bit plugin is using vdpau now, so i assume it's somehow interfering with mutter or something
<ricotz> so you are using flashplayer11_b1_install_lin_64_071311?
<bjsnider> yep
<ricotz> ok
<ricotz> and 280.11?
<ricotz> with mutter git and gnome-shell git?
<bjsnider> no, 275.19
<bjsnider> with the packages from the gnome 3 ppa
<ricotz> ok, so on natty?
<bjsnider> yes
<ricotz> i am running oneiric with edgers ppa
<ricotz> bjsnider, there are a lot of fixes since 3.0.2
<ricotz> perhaps you could try 3.1.3+?
<bjsnider> i had a catastrophic sound issue with edgers so i had to purge it
<bjsnider> how, build the packages myself?
<ricotz> sound? are you using hdmi audio?
<bjsnider> no
<ricotz> ppa:ricotz/testing
<bjsnider> the 3.0 kernel was responsible
<ricotz> ok
<ricotz> try to only update mutter and gnome-shell
<ricotz> telepathy and json
<bjsnider> too risky for my taste. i need this thing to work most of the time
<ricotz> bjsnider, does this happen before the gnome3 updates update on the weekend?
<ricotz> ok, np
<bjsnider> happened before that update
<ricotz> ok, good ;)
<ricotz> mhh, so i cant reproduce it here with your configuration, i will test it anyway later
<bjsnider> if it's a flash problem it will happen anyway
<bjsnider> but i can't find a lot of complaints about it in the cloud, so i'm assuming it's somehow unique to my system (lucky me)
<ricotz> bjsnider, btw, the 3.0 kernel is not mandatory using edgers ppa
<bjsnider> i was considering intentionally breaking vdpau by temporarily moving the vdpau driver shared lib somewhere else and then testing it
<bjsnider> ricotz, ah, but it is if you really want to test nouveau
<ricotz> bjsnider, right, but 3.0 is still far behind the nouveau kernel tree ;)
<bjsnider> well, that's the newest kernel i had available to me
<ricotz> ok
<ricotz> bjsnider, i cant confirm any problems here with flash
<highvoltage> hi, anyone know how I can get the amd catalyst control center on natty? old documentation says I need the amdcccle package but that doesn't install any binaries
<bjsnider> ricotz, using firefox only?
<ricotz> bjsnider, yes
#ubuntu-x 2011-07-26
<cnd> bryceh, would you be able to SRU the fix for bug 806256 to 11.04?
<ubot4> Launchpad bug 806256 in xorg-server (Ubuntu) "xf86PostMotionEvent resets cursor to upper left (affects: 2) (heat: 12)" [High,Fix released] https://launchpad.net/bugs/806256
<cnd> it's fixed in oneiric, so it should be easy as far as SRUs go
<RAOF> Bah.  Building xf86-video-intel twice, one with uxa and one with sna is *almost* easy.
<tjaalton> cnd: bryceh might be on paternity leave, but i can sru it next week when i'm back
<RAOF> tjaalton, cnd: Or I could SRU it :)
<tjaalton> that works too :)
<cnd> RAOF, tjaalton: thanks!
<bjsnider> ricotz, i discovered what was happening. i tried flash in firefox since you said it worked. the same crash happened, except instead of the desktop being indefinitely suspended, after about 30 seconds firefox reports flash crashed and then you can move on. chromium doesn't ever give up trying to make the plugin work.
<bjsnider> ricotz, have you got /etc/adobe/mms.cfg on your system?
<ricotz> bjsnider, hi, no, i dont have this file
<bjsnider> yeah so on  your system vdpau probably wasn't enabled and that's why you didn't experience this issue with firefox
<ricotz> bjsnider, mhh, the plugin configuration said the acceleration is enabled
<ricotz> i.e. also mplayer uses it
<bjsnider> ricotz, at once point that file had to be present for hardware accel to work, but that may have changed
<shadeslayer> btw does anyone have a ATi card and when you install the fglrx driver you get a "AMD Unsupported Hardware" watermark at the bottom left?
<ricotz> bjsnider, ok, the flash plugin doesnt seem to use libvdpau while running
<bjsnider> ricotz, i just tested it without that file present and it seems stable now
<ricotz> bjsnider, ok adding the file enables it
<ricotz> bjsnider, ok, i wont do that again :P
<ricotz> xorg get stuck, killing it gets you back to normal
<ricotz> bjsnider, if you wrote something after my last line ("ok adding the file enables it"), i didnt got it
<floppsy> hello. I have a problem with the X server (i think). Booting works fine, but screen stays black. I can change to Terminal, login and so on, but don't see anything. Booting with nomodeset option helps, so I can see, what I type. X does not work. I tried natty first. It did not work. So I tried oneiric, which is not working either. graphic card is radeonhd 2400.
<floppsy> and xorg.0.log ist nopasted at http://paste.ubuntu.com/652520/
<bjsnider> ricotz, why, did the crash happen for you?
<ricotz> bjsnider, it doesnt crash
<ricotz> xorg freezes and stuck
<ricotz> the xorg process
<bjsnider> well, whatever
<bjsnider> so it isn't specifically my system or my flash package that did it
<bjsnider> we'll just have to do without vdpau in flash for the time being
<bjsnider> ricotz, i was only explaining what the issue was, i wasn't insinuating that you should try to make the issue appear on your system
<bjsnider> not until you were ready for it anyway
<bjsnider> something is terribly wrong when flash can take down xorg though
<ricotz> bjsnider, yeah, i was prepared for it, but i messed up saving some logs
<ricotz> if there were any
<bjsnider> if you were using firefox i think the issue would have been cleared up after 30 seconds or so
<ricotz> it is probably nvidias fault here
<ricotz> it happens when i switch to a new video
<ricotz> playing/jumping/fullscreen-toggle/resolution-changing worked for the first one
<bjsnider> yeah, it always happens on a switch to a new video for me
<bjsnider> ricotz, what do you have to do from ssh to resume, or is it just reboot?
<ricotz> bjsnider, as i wrote ;) -- killing xorg and login again
<ricotz> over ssh
<ricotz> bjsnider, more precisely, i looked for the troubled process, killed it and restarted gdm
<bjsnider> ricotz, any idea why xorg freezing would cause the keyboard but not the mouse to be unresponsive?
<ricotz> dont know, the mouse is a bit special with its own buffer
<bjsnider> ricotz, i think at some point soon this should be reported to nvidia
<bjsnider> and you are elected since you can get logs and whatnot via ssh
<ricotz> bjsnider, http://forums.adobe.com/thread/877495
<Sarvatt> ion vdpau has been busted since 270.xx, probably a different bug
<bjsnider> ricotz, the answer to the last guy's question is no doubt by manually adding that file
<ricotz> Sarvatt, perhaps, but could be related
<ricotz> bjsnider, yeah
<ricotz> Sarvatt, any chance you are planning xserver 1.11 for edgers?
<bjsnider> those posts make it sound like adobe is responsible
<dupondje> Somebody has any idea on https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/816588 ?
<ubot4> Launchpad bug 816588 in xorg (Ubuntu) "Changing Caps Lock to Shift Lock does not work (affects: 1) (heat: 6)" [Undecided,New]
<BigWhale> Greetings
<BigWhale> Anyone knows what's the status of fglrx drivers in Oneiric?
<soreau> BigWhale: That's not exactly a pointed question
<soreau> what are you wanting to know specifically?
<BigWhale> Well, mostly if it is working. :) When I tried to use it in Alpha1 I failed.
<soreau> What card model do you have?
<BigWhale> HD6850 which works in Natty and fglrx
<soreau> You might try the open radeon driver as it is the default
<BigWhale> but Oneiric ships with different kernel and at that point fglrx didn't work.
<BigWhale> yeah I am using radeon driver now.
<soreau> So far as fglrx goes, the status is probably the same as it is from the AMD site
<RAOF> AFAIK, fglrx should be working now.
<BigWhale> I have some performance issues in OpenShot and I'd like to rule out the graphics driver.
#ubuntu-x 2011-07-27
<andrease> I am trying to get hdmi audio to work with the radeon driver on 11.10, so fare without any luck
<andrease> How can I figure out if this is a problem with the radeon driver or linux/alsa?
<andrease> I have tried following the guide for debugging sound problems but every thing seems fine, except there is no sound
<andrease> My Xorg log file: http://paste.ubuntu.com/652938/
<jfpowell> Hello, can anyone help me with a mouse related problem?
<jfpowell> I have a logitech mx1000 and I am having very severe problems with ubuntu 11.04 (actually lubuntu 11.04) but the same issues exist in ubuntu 11.04 when I use the livecd
#ubuntu-x 2011-07-28
<horstle> is anybody interested in a reproducable "NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context"?
<horstle> im running NVIDIA 275.19 with a gf 9300 onboard
<RAOF> horstle: nvidia might be; bug reports go to the nvnews forums.
<horstle> well im waiting for response from bjsnider, afaik he is from nvidia
<bjsnider> you're waiting for a response from me?
<bjsnider> this is the first i've heard of it
<bjsnider> and i'm not from nvidia
<bjsnider> i'm from canada
<bjsnider> horstle, http://www.nvnews.net/vbulletin/showthread.php?t=46678
<ripps> well, the lastest xorg-edgers has been causing my i5-2400 igp to hang alot. It loses all 3d/2d acceleration until I reboot after dmesg says I fails from a gpu hang
<RAOF> ripps: Kernel problem, or DDX/mesa?
<BigWhale> Greetings... Where can I find some more info what's going on with intel drivers and 855GM chipset?
<RAOF> BigWhale: There's not much going on.  Hm.  Maybe we should turn them back on; it's apparently possible that they work now.
<RAOF> Upstream is where you want to be, though.
<ripps> RAOF: I don't know. I've gotten these gpu hangs in the recent past, but I could always recover from them. I wouldn't lose my acceleration altogether, I just had to restart compiz.
<RAOF> ripps: Feel like trying an older/newer kernel, then?
<ripps> RAOF: I'm using 3.0.0-7
<BigWhale> I instaled Natty on some old laptop and then enabled intel drivers and the results were poor... windows flickering and disappearing...
<ripps> This is a natty machine with xorg-edgers
<RAOF> ripps: You could try the drm-intel-next mainline build, and/or go back to an older kernel.
<ripps> It's kinda late for me now, I'm going to bed. I'll pastebin my dmesg and any other logs you want the next time it happens, then I'll try out an older kernel
<RAOF> ripps: If you want to help debug, i915_error_state is pretty much mandatory.
<RAOF> BigWhale: I'd want to be sure that you successfully enabled the intel drivers, but I wouldn't expect flickering windows; I'd expect it to hang pretty frequently, though.
<ripps> Just FYI, the hang usually happened when switch mplayer between fullscreen and windowed
<BigWhale> RAOF, I installed this driver https://launchpad.net/~glasen/+archive/intel-driver
<BigWhale> RAOF, enabled modeset and there was a lot of flickering and unity failed to start so it was a fallback to classic desktop. Flickering was take care of by disabling effects.
<BigWhale> 3D support seems to work only partially glxgears will run but there's a game that doesn't work
<Sarvatt> ripps: try again after updating now, I didn't see there was a new update to fix that a few days ago
<kirkland> howdy, I have a video/unity/x issue, thinkpad x201, lspci at http://paste.ubuntu.com/653832/
<kirkland> I can't get 1920x1080 to my external monitor
<kirkland> worked in lucid,maverick, regressed in natty (and I just lived with 1280x800), and I just upgraded to oneiric hoping it might have been fixed
<kirkland> but no dice
<seb128> kirkland, what output do you use?
<kirkland> seb128: okay, so the thinkpad sits in a docking station, connected externally by SVGA to a 24" Samsung monitor
<kirkland> seb128: i want to disable the output on the laptop screen, and only have one output, to the external monitor
<kirkland> seb128: i can only do that up to 1280x800 resolution, which is what the laptop screen maxes out at
<seb128> kirkland, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/729788
<kirkland> seb128: however, the external monitor can certainly do 1920x1080
<ubot4> Launchpad bug 729788 in xserver-xorg-video-intel (Ubuntu) "xrandr reports incorrect max resolution from displayport in laptop dock i915 (affects: 2) (heat: 23)" [Undecided,Confirmed]
<seb128> seems similar
<kirkland> seb128: yeah, definitely
<seb128> kirkland, I don't know the specific, I asked because I know pitti or some others had issue which were happening on the displayport but not on the standard vga output I think
<kirkland> seb128: hmm, okay, maybe i'll poke pitti?
<kirkland> seb128: any known workarounds?
<seb128> kirkland, he's on holidays until end of next week
<seb128> kirkland, did you try the commands from this bug?
<kirkland> seb128: okay
<seb128> I'm looking for the other bugs I read on the topic, wait
<kirkland> seb128: not yet, do you recommend those?  I'm not as familiar with xrandr as I should be ...
<seb128> kirkland, bug #737891 is the one I was thinking about
<ubot4> Launchpad bug 737891 in xserver-xorg-video-intel (Ubuntu Natty) (and 5 other projects) "[Arrandale] gnome-display-properties unable to correctly enable monitors connected to VGA (affects: 15) (dups: 2) (heat: 98)" [Wishlist,Invalid] https://launchpad.net/bugs/737891
<kirkland> seb128: yes, that one I am familiar with
<kirkland> seb128: I'm subscribed, and have commented a few times
<kirkland> seb128: i sort of gave up on that one being solved for Natty
<kirkland> seb128: but really, really hoping it gets solved for Oneiric
<kirkland> as 1280x800 resolution on a 24" monitor looks comical :-)
<kirkland> seb128: i've nominated it for Oneiric
<seb128> kirkland, it shouldn't hurt to try to set the resolution with the second call from the first bug I pointed
<seb128> if that doesn't work wait for some of the x guys to reply
<seb128> they probably know better than me ;-)
<kirkland> seb128: thanks man :-)  will try now
<kirkland> seb128: hmm, hang on a second ...
<kirkland> seb128: in the displays dialog, I have 1920x1080 as an option
<kirkland> seb128: but when I switch to it, I get unity offset from the center, some big black, unusable areas of the screen, and the display is just not coherent
<seb128> kirkland, what happen if you try to use it?
<kirkland> seb128: I can shoot a picture with my phone, one second ...
<seb128> kirkland, that seems a compiz bug, just alt-f2 compiz --replace
<seb128> or alt-f2 unity
<seb128> compiz doesn't like dynamic resizing it seems
<kirkland> seb128: oh?
<kirkland> seb128: that sounds promising
<kirkland> seb128: it certainly looked to me to be a unity/compiz bug from my first guesses, but most of the time when I talk to someone about it, they point me to X, and then to the kernel :-)
<kirkland> seb128: actually, that worked
<kirkland> seb128: so here's what i had to do:
<kirkland> seb128: 1) go to displays, select 1920x1080, apply
<kirkland> seb128: 2) very quickly do the alt-f2 unity <enter>
<kirkland> seb128: 3) very quickly click keep configuration
<kirkland> seb128: not that alt-f2 compiz --replace did NOT work
<kirkland> seb128: and note that it took me a couple of tries to get it right within the 15 seconds before it automatically reverted
<kirkland> seb128: so now I wonder if it persists across reboots ...
#ubuntu-x 2011-07-29
<cwillu_at_work> so, I just added edgers to my embedded build-out script
<cwillu_at_work> I should probably find a different job :p
 * cwillu_at_work counts down to 12.04
#ubuntu-x 2011-07-30
<tjaalton> oh i hate these unity window stacking bugs..
<tjaalton> or the bug
<tjaalton> open firefox with the previous browser session and you don't know where the clicks go
<ach1m> Sarvatt, hi, do you have plans to package xserver-xorg-video-intel driver without SNA enabled in xorg-edgers-ppa?
<RAOF> Sarvatt: If you want to do that, I've got a branch that does that.
<Duke`> since SNA is enabled, I have some random white glitches on windows' title bar, windows' shadows and flash animations (i945 + compiz).
<Duke`> has it been already reported?
<ach1m> Duke`_, yes it has been reported â https://bugs.freedesktop.org/show_bug.cgi?id=38732
<ubot4> Freedesktop bug 38732 in Driver/intel "[sna unity] windows have white borders from time to time." [Normal,New]
<Duke`_> funny, openning this link gave me a white window title for firefox :D
<Duke`_> thank for the link
<cwillu_at_work> tjaalton, I see that under classic with compiz as well
<cwillu_at_work> must be a compiz thing
#ubuntu-x 2011-07-31
<afiestas> RAOF: seems that gnome people already have some xml-based configuration: http://live.gnome.org/RandR#Storage_of_RANDR_configurations
<afiestas> why is that not good enough?
<RAOF> afiestas: It's mostly fine; it just needs a little extending to handle keeping modelines in there.  I thought you were already aware of this, though?
<afiestas> maybe I was, but I forgot xD
<afiestas> I wanted to work on RandR stuff like a year ago so now I'm catching up again
<afiestas> RAOF: are you comming to BDS?
<afiestas> if you do maybe we can have a small meeting with Giovanni (last copyright holder of the gnome code) and add the missing pieces
<RAOF> afiestas: No, I'm not coming to BDS.  I'm happy to do that patching when I get the time to do the rest of the implementation, though.
<afiestas> RAOF: I'm going to send an email to Giovanni asking if he is going to BDS, if he does maybe we can do a skype or something, as you can see I'd like to have the format definition done ASAP
<afiestas> because is probably the best place to start (remember that I'm going to rewrite K*Randr)
<RAOF> Yeah.
<tjaalton> cwillu_at_work: ok, what a relief ;)
#ubuntu-x 2012-07-23
<mlankhorst> morning
<mlankhorst> ricotz: I made geode compile but it's probably broken since I lack the hw to test, still should we upload it? Might be a good way to figure out if anyone actually uses it or not :)
<mlankhorst> I'll try to get my hands on a geode in the meantime
<mlankhorst> but apart from that, xorg 1.13 has the drivers for xserver-xorg-input/video-all ready
<RAOF> mlankhorst: Awesome.
<RAOF> mlankhorst: If you wanted to test that our xserver coredumping patch was working, what would you do?
<jcristau> pkill -SEGV Xorg?
 * RAOF adds that to the set of things to test.
<RAOF> jcristau: The trick, for of course there is a trick, is that the coredumping patch *sometimes* works :)
<jcristau> ick.
<RAOF> Yeah.
<jcristau> could you get rid of the patch and just always pretend you've been passed -core?
<jcristau> (maybe that's what the patch does.  i haven't looked.)
<RAOF> That's actually something I've been thinking aobut.
<RAOF> Although -core would result in everything being killed with SIGABRT, rather than the true cause.
<mlankhorst> RAOF: actually that wouldn't work since the X server checks if it comes from kernel or not
<mlankhorst> Hm maybe why it fails.
<jcristau> oh.  bad X server.
<RAOF> mlankhorst: Really? Where?
<mlankhorst> hm let me check
<mlankhorst> OsSigHandler
<jcristau> it does FatalErorr anyway
<jcristau> Error, even
<jcristau> just changes the ErrorF msg afaict
<RAOF> Oh, yeah. That bit.
<mlankhorst> ah k then
<mlankhorst> my preferred way to kill annoying dialog boxes that don't have a close button is with kill -SEGV :)
<RAOF> I wonder how hard it is to use X's apport hook to teach apport how to extract the right signal from the OsAbort backtrace.
<mlankhorst> RAOF: what's stopping you from simply calling apport hook from there directly? Xorg is toast at that point anyhow
<RAOF> mlankhorst: Nothing. Well, except that you don't *know* what the right signal is at that point.
<jcristau> stuff it in a global :p
<mlankhorst> isn't it already with the rethrow patches?
<mlankhorst> hm guess not, but fatalsignal gets it as argument
<RAOF> It is already with the rethrow patches; I'm hoping to *drop* those patches (given they don't work reliably) in favour of post-processing it in apport.
<mlankhorst> oh ok
<mlankhorst> I guess the default hook will fail due to lack of X at that point?
<mlankhorst> else just stop handling sigabrt/segv w/e
<mlankhorst> yay, freedesktop.org account works :)
<jcristau> congrats
<bryceh> yay, got a mesa provisional MRE
<mlankhorst> oh thanks for reminding me i need to test a srgb fix in mesa. it should fix multisampling in nouveau :)
<mlankhorst> gnight :)
<RAOF> bryceh: Wooo!
<bryceh> RAOF, the regression testing plan was their main concern; all that time spent running piglits paid off :-)
<bryceh> RAOF, so at this point can you just wave the mesa package through, or is anything else needed?
<RAOF> At this point it'll be waved through into -proposed, then build, then we'll want to run some tests on the build from -proposed (because we're paranoid), then it'll get waved through to -updates after the 7 day "does anyone notice if it blows up" phase.
<bryceh> ok, I'm going to be on vacation for a week starting wednesday, so won't be able to do any testing really
<RAOF> Ok.
<bryceh> but I'm set up to do the runs so if no one gets to it before I get back, I can certainly fire the chips up after that.
<RAOF> I'll talk to gema and see if I can get it set up in the QA lab, too.
<bryceh> you might check to see if there's already a WI open to do that.  I had talked to her about piglit running at sessions last UDS.
<bryceh> however, I'm skeptical it's going to be feasible, given that the tests have been hanging for me and so need manual monitoring
<bryceh> but hey, where there's a will there's a way.
<RAOF> Yeah, we also talked about it at UDS: P.
<RAOF> They surely have the tools to handle a hanging testcase. :)
#ubuntu-x 2012-07-24
<bryceh> headlessness was also discussed.  I seem to recall they thought they had a way around that but don't remember the specifics.
<Sarvatt> RAOF: so yeah the SDP's have different pci ids than shipping hardware will and userspace doesnt support it incase you play around with the sdp, need to patch libdrm and mesa to work with 8086:0c16
<RAOF> Sarvatt: Heh. I noticed your patch.
<Sarvatt> thats just the mobile one, libdrm and mesa dont support the desktop version already
<RAOF> I should turn on the IGFX again, see if i915.ko actually binds to the hardware.
<Sarvatt> it didnt before? didnt you have a desktop one?
<Sarvatt> 8086:0c16?
<mlankhorst> RAOF: ohh shiny new libdrm also has the prime calls, I want shiny :D
<mlankhorst> but it can wait a little
<RAOF> mlankhorst: What can we *do* with those prime calls? :)
<mlankhorst> oh for nouveau they just seem to be wrappers, but mostly provides an api around prime.
<mlankhorst> RAOF: do you still want to have fun with r600?
<seb128> bryceh, hey
<bryceh> seb128, hey
<seb128> bryceh, how are you?
<bryceh> seb128, fine, you?
<seb128> bryceh, I'm good thanks
<seb128> bryceh, could you put some lines in https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha3 about what happened in xorg world between a2 and a
<seb128> 3
<bryceh> seb128, certainly
<seb128> bryceh, thanks! ;-)
<bryceh> seb128, under Graphics and Display, or Desktop?
<seb128> bryceh, graphics and display is fine
<seb128> bryceh, hum, wait
<bryceh> oh that's for known issues
<seb128> bryceh, no, under "Ubuntu" 
<bryceh> ok
<seb128> right ;-)
<mlankhorst> and swapped out my wrt54gl for a wndr3800
<mlankhorst> I created a -an (5ghz) network and a 2.4ghz -guest network that should only connect to internet, but is passwordless. You use ssl for everything right?
<bryceh> seb128, ok, think I've got the highlights there.  Poking through changelogs... lots been updated but not much that users would notice.  Think I got the main points.
<mlankhorst> bryceh: I think optimus support will land only properly in 3.7 kernel, so it's going to have to wait for the r-release to be useful. I could probably keep things in a ppa for quantal though
<mlankhorst> a bunch of important things will go in at 3.6 though. intel flushing list removal, deferred fput, some cleanups to the api.
<bryceh> seb128, I didn't mention anything on wayland; robert or raof should probably add a couple sentences on that if it's ready for users
<seb128> bryceh, well, those are a3 notes, so those ppa packages don't really qualify
<bryceh> mlankhorst, *nod* yeah I didn't say anything about hybrid support although I know people will want to know status on that.  Sounds like 12.10 won't be a solution for hybrid users
<mlankhorst> bryceh: actually all the parts except kernel will be in for 12.10 ;-)
<mlankhorst> X 1.13 will support it, libdrm needs a bump but will support it, drivers need some love but adding support is trivial
<mlankhorst> so likely those will be ready in time
<bryceh> mlankhorst, interesting; so what exactly is needed on the kernel side?
<mlankhorst> dma-fence and dmabufmgr
<mlankhorst> and some code to hook it up for i915 and nouveau
<mlankhorst> RAOF called dibs on r600, i might take him up on it soon :)
<bryceh> any of it potentially backportable?
<mlankhorst> probably but I think we would really want to wait until it's upstream first
<mlankhorst> so at least the api is reviewed
<mlankhorst> at first I had a total crap api for fences hardcoded directly into dmabufmgr, but now I dumbed down the dma-fence that was created in response to it and hooked it up to dmabufmgr. So it's actually usable and understandable by others. :-)
#ubuntu-x 2012-07-25
<mlankhorst> morning
<RAOF> Hi, yo.
<mlankhorst> RAOF: did you get anywhere with -core?
<RAOF> mlankhorst: Yup. Pushed a patch to lightdm to add that; we can drop 100_rethrow_signals
<mlankhorst> perfect
<mlankhorst> feel free to upload server-core then, I should probably update intel to 20.1 first and then the rest needd
<mlankhorst> needs xorg-server-core >= 13rc1 for building
<RAOF> mlankhorst: Will do.
<mlankhorst> RAOF: ok intel updated to 2.20.1 :-)
<mlankhorst> want a copy of all the *.orig.tar.gz I have?
<RAOF> Eh.
<RAOF> I'm happy to uscan --download-current-version.
<RAOF> Of course, I'm *also* happy to accept git repositories with pristine-tar branches, so git-buildpackage Just Worksâ¢ ;(
<RAOF> :)
<mlankhorst> optimist :P
<RAOF> Ah.
<mlankhorst> RAOF: but openchrome needs love, there was already a openchrome 0.3.0 in hardy which might have been optimistically numbered like that
<mlankhorst> ok pushed cirrus to 1.5.1, seems a new release was amde in the last time I looked with the build fix
<RAOF> We also need to update the proto first, right? We don't have the necessary proto in quantal or -proposed yet?
<mlankhorst> probably I think some were pushed
<mlankhorst> x11proto-dri2, x11proto-gl, x11proto-randr
<mlankhorst> dri2 needs 2.8
<mlankhorst> gl 1.4.16
<RAOF> Ah, and a bunch of them are in Debian experimental, and can be syncd. But that needs me to manually flick the switch.
<mlankhorst> randr 1.4.0
<RAOF> dri2 hasn't been updated in Debian yet, but that can be done.
<mlankhorst> rest I'm unsure about, those were the ones I encountered at least :-)
<jcristau> i can probably push dri2proto to experimental if that helps
<mlankhorst> sure
<mlankhorst> I bumped all the standards-versions to 3.9.3 too mostly
<RAOF> Oh, *arse*. We've got some ungodly x11proto-randr version from 2010 that claims to be 1.4
<jcristau> that + should have been a ~
<mlankhorst> yeah it's fun
<RAOF> Yup
<mlankhorst> openchrome has the same issue with hardy
<jcristau> i uploaded it as 1.3.99.1 at the time to avoid just this :)
<RAOF> Time for a sourceful upload of Debian syncage!
<jcristau> mlankhorst: hmm?  xserver-xorg-video-openchrome | 1:0.2.901-0ubuntu4 |         hardy | source, amd64, i386
<mlankhorst> jcristau: launchpad refused 0.3.0 though
<mlankhorst> jcristau: https://launchpad.net/ubuntu/hardy/i386/xserver-xorg-video-openchrome/0.3.0-0ubuntu2
<RAOF> Yeah, that's the epoch.
<mlankhorst> so you need to fudge around with that one to make it work
<jcristau> ah, yeah, ok.
<jcristau> just wait for 0.3.1 :p
<jcristau> shouldn't take more than a year
<mlankhorst> or just call it fakesync1 and append that to orig.tar.gz
<mlankhorst> nobody said it would have to be because of debian a fakesync is required >:D
<jcristau> heh
<mlankhorst> but yeah the mess with openchrome was worse in multiple ways. I did get it to switch from git-svn to git though.
<RAOF> jcristau: Pushing dri2proto to experimental *would* help a bit; you still up for it?
<jcristau> RAOF: yeah, looking at it now, see #d-x :)
<ricotz> mlankhorst, hi, is 1.13rc2 suppose to land in quantal this week?
<mlankhorst> think so
<ricotz> i see :)
<ricotz> is there already any news about any compatible nvidia blob?
<mlankhorst> nah it tends to lag behind
<ricotz> i know, aaronp mention 304.x is suppose to get support
<mlankhorst> no prime though :p
<ricotz> but uploading 1.13 will break for quite some people with a new one
<mlankhorst> but maybe those changes will finally force nvidia to coexist with other drivers
<ricotz> *without
<ricotz> maybe
<mlankhorst> yeah you're right, it most likely stays crap :p
<ricotz> but way better than fglrx ;P
<mlankhorst> I don't know if I want to word it like that
<jcristau> ricotz: like that's hard
<mlankhorst> any bets on whether fglrx will have something before the Q release that's compatible?
<mlankhorst> :p
<jcristau> mlankhorst: i thought usually they manage to have something a week before the ubuntu release
<ricotz> hehe
<mlankhorst> but with s3tc package installed I'm getting more luck with r600 nowadays
<mlankhorst> RAOF: how is uploading going?
<RAOF> mlankhorst: It's not really, at the moment :)
<RAOF> mlankhorst: Got as far as the proto stuff, and then had to go to pilates, have dinner, etc ;)
<mlankhorst> ok, I'm just taking a closer look at the precise x server, see if I can fix that issue or if it it's too much work :)
<mlankhorst> just noticed I forgot to kill a patch that was upstream so uploaded that fix
<RAOF> I'll finish off 1.13 uploading tomorrow.
<mlankhorst> wow, first time in all my messing with X that I've seen the failsafe-X screen ;)
<mlankhorst> RAOF: Yeah I just realized I should check if the gimp bug is also in x1.13 before I try to diagnose it further. Might safe me some work if it turns out to be a bug in upstream too.
<mlankhorst> aw unfortunately it works
<mlankhorst> RAOF: hm should I just drop it? The same patches work on x1.12, so likely it's caused by our weird backported input stack
<mlankhorst> and x1.13 with gimp worked fine too
#ubuntu-x 2012-07-26
<mlankhorst> morning
<RAOF> Good morning!
<mlankhorst> I'm looking into nouveau vblank thing, seems the problem is on newer cards we don't get the vblank interrupts yet :o
<mlankhorst> But it's fun, basically invalid card mathods used to generate interrupts, and those interrupts are used to implement software calls.
<mlankhorst> RAOF: oh yeah, the fun of conflicting version names :-)
<mlankhorst> RAOF: shouldn't fakesyncs be named -fakesync1 ?
<RAOF> As far as I'm aware there's no automation on that.
<mlankhorst> shrug, ok :)
<RAOF> mlankhorst: Incidentally, I'm going to be amending the version numbers of all the X stuff to -0ubuntu1 rather than -1; we're not syncing from released Debian packages, and things would go badly if Debian ended up pushing a slightly different -1 ;)
<mlankhorst> sure
<RAOF> Man the DDXen have *so many* compiler warnings :(
<mlankhorst> indeed, it's horrid
<mlankhorst> RAOF: want the patch to make geode compile on new X? I don't think it's in debian version control anywhere so just grab current git and apply the debian tree on top
<RAOF> mlankhorst: I'll build all the drivers I care about first, and check that it minimally works. Then I'll go to drivers noone cares about :)
<mlankhorst> RAOF: well it's part of xorg-video-all so some care
<RAOF> Yeah, we won't be pushing out of -proposed until video-all is installable.
<jcristau> we should trim down video-all.
<RAOF> But I can at least check that ati, intel, and nouveau provide a working server first.
<mlankhorst> it will be installable with the changes, but geode should be gone from video-all and maybe pushed to universe
<jcristau> to like intel+ati+nouveau+modesetting+vesa+fbdev
<mlankhorst> and video-all might need to be renamed to video-base
<mlankhorst> jcristau: udl too
<jcristau> leio was talking about fixing up geode i think
<mlankhorst> ok :)
<mlankhorst> well my patches are on the mailing list
<RAOF> The next -ati release will really, really be 7.0.0, right?
<jcristau> i should certainly think so, given 'drop ums' landed
<mlankhorst> RAOF: yes
<mlankhorst> that's the reason I needed git, to pick up the ums patches
 * RAOF is just hoping to ensure the *next* upload of -ati isn't 6.99.99+is.really.goddamnit.something.else
<mlankhorst> might still happen :P
<mlankhorst> couldn't you just upload it as 6.999~somegit then?
<mlankhorst> :D
<mlankhorst> we shall just append more 9s to make
<mlankhorst> up*
<mlankhorst> RAOF: http://people.canonical.com/~mlankhorst/xf86-video-geode.tar.gz git tree + debian directory inside to build
<mlankhorst> I have only verified it builds, I can pretty much guarantee it's broken until someone fixes exa acceleration
<jcristau> hopefully leio can fix that :)
<Prf_Jakob> RAOF: you are the one working on Wayland in 12.10 right?
<Prf_Jakob> Whats the story there with hardware that doesn't support 3D?
<RAOF> Prf_Jakob: Hardware that doesn't support 3D won't get the system compositor; it'll look exactly as it does today.
<mlankhorst> RAOF: got vblank working on nouveau today, but might have to start over after nouveau changes again ;s
<Prf_Jakob> RAOF: ok
<RAOF> mlankhorst: At least you know what to do now :)
<RAOF> Prf_Jakob: Over time the system compositor path will gain features that the non-composited path doesn't, but as long as the nvidia and fglrx drivers are important the non-composited path isn't going away.
<Prf_Jakob> RAOF: ok
<mlankhorst> RAOF: yeah have to do the prime stuff over as well due to the kernel rework, but i could have expected that
<RAOF> We'll also possibly want a cut-down, software only âcompositorâ at some point; that's entirely possible.
<RAOF> Prf_Jakob: We should be able to do egl+kms on vmwgfx at some point though, right?
<Prf_Jakob> yes
<Prf_Jakob> I think right now, I just haven't tested it.
<RAOF> I should probably test that, shouldn't I :)
<Prf_Jakob> Also 3D might not be enabled.
<RAOF> That would make it a little bit more difficult to test :)
<Prf_Jakob> Well its a VM option.
#ubuntu-x 2012-07-27
<mlankhorst> morning
<tkamppeter> I have some problems with a new Intel HD graphics PC
<mlankhorst> what kind
<tkamppeter> The mobo has only HDMI and DisplayPort output, but xrandr shows also a VGA output which is limited to 1024x768 and fully automatic startup falls aways into 1024x768.
<tkamppeter> How can I makethe login screen 1920x1080?
<mlankhorst> you can change it after login?
<tkamppeter> mlankhorst, yes, after login I can configure my desktop's resolution with the "Displays" part of th system settings.
<tkamppeter> mlankhorst, so principally the resolution is supported. Driver is the intel driver.
<tkamppeter> mlankhorst, xrandr output with the manually configured desktop: http://pastebin.ubuntu.com/1113490/
<mlankhorst> great, VGA-1 connected..
<mlankhorst> xrandr -q --verbose ?
<tkamppeter> mlankhorst, /var/log/Xorg.0.log -> http://pastebin.ubuntu.com/1113491/
<tkamppeter> mlankhorst, this is really strange, the mobo has no VGA connector.
<tkamppeter> mlankhorst, http://pastebin.ubuntu.com/1113495/
<mlankhorst> unsurprisingly no edid data, anything in dmesg?
<tkamppeter> mlankhorst, there is EDID data in theXorg.0.log
<mlankhorst> ok make a bug to xorg so it attaches all relevant logs, and additionally attach a log booting with drm.debug=0xe?
<mlankhorst> you can add a workaround by disabling vga-1 in xorg.conf but you're probably more interested in the proper fix :)
<tkamppeter> mlankhorst, nothing found in dmesg, but I do not really know what to search for.
<tkamppeter> mlankhorst, next problem is that the mouse is not going smoothly.
<mlankhorst>  :s
<tkamppeter> mlankhorst, is thee a workaround for the time being until the problem gets fixed? For example entries in xorg.conf
<jcristau> video=VGA1:d
<jcristau> on the kernel cmdline
<tkamppeter> jcristau, what does this mean exactly? And where do I edit the kernel command line in the GRUB config?
<jcristau> it means disable VGA1, and GRUB_CMDLINE_LINUX in /etc/default/grub
<tkamppeter> jcristau, thank you, will try.
<tkamppeter> jcristau, I havetried it, edited /etc/default/grub as you told and afterwards run "sudo update grub", rebooted and still 1024x768.
<tkamppeter> mlankhorst, bug 1029865
<ubottu> Launchpad bug 1029865 in xorg (Ubuntu) "Intel HD graphics: Starts always with 1024x768 resolution on a 1920x1080 monitor (HDMI and DisplayPort)" [High,New] https://launchpad.net/bugs/1029865
<tkamppeter> mlankhorst, how do I boot with drm.debug=0xe? Is this a kernel CMD line option? Where do I find thelog after the reboot?
<tkamppeter> mlankhorst, how do I disable vga-1 in xorg.conf?
<mlankhorst> tkamppeter: yeah add to grub and collect from syslog or dmesg
<tkamppeter> jcristau, your trick with the kernel command line works. Thank you!
<tkamppeter> jcristau, false alarm, with thekernel cmmad I got the rare case of correct hi-res login screen only once. Now it is rock solid 1024x768 again.
<tkamppeter> mlankhorst, bug report update with syslog with drm.debug info.
<mlankhorst> tkamppeter: oh i asked
<mlankhorst> 13:53 < ickle> mlankhorst: temporary bug early in 3.5 cycle, to accommodate kvm switches we tried to probe the crt and missed that the fallback from that 
<mlankhorst>                would accidentally decide the display was connected
<mlankhorst> so I guess upgrading kernel will fix it
<tkamppeter> mlankhorst, what do you mean with "oh i asked"?
<mlankhorst> on intel-gfx about it
<Azelphur> Anyone know of a way to trick the system into thinking there is a second monitor (in a typical dual screen/twinview setup), when there is in fact no physical monitor present?
<Azelphur> the goal being to do that, then use VNC to connect to the second fake display, and use my android tablet as a second monitor. :)
<Prf_Jakob> RAOF: Sorry, to bother you again, is there a easy way I can try out the system compositor?
#ubuntu-x 2012-07-28
<tjaalton> oh, uds is four days the next time
#ubuntu-x 2012-07-29
<ChaoPeng> Hi, there
<ChaoPeng> I am a new comer
<mlankhorst> hey 
<tjaalton> hi
<RAOF> Prf_Jakob: The system-compositor is installable from ppa:ubuntu-desktop/system-compositor; that PPA is a little old, but I'll get back to refreshing it (and handling some of the problems) after xserver 1.13 has been shepherded in.
<Prf_Jakob> ok
<Prf_Jakob> thanks
#ubuntu-x 2013-07-22
<mlankhorst> morning
<xnox> when i swtich to tty1: vga monitor brightness drops, dvi monitor stays the same. annoying =) how can I fix this?
 * apw is dropping to low-resolution mode, though i can see nothing in the Xorg.0.log to say why, it just quits
<mlankhorst> xnox: probably a monitor thing then :P
<mlankhorst> apw: hm attach debugger? if it's a case of a missing symbol xorg will just quit without reporting anything..
<xnox> mlankhorst: but, but my dual screen monitors are the same: vga->vga goes dim, hdmi->dvi does not. And it's clearly os driven, e.g. focusing on a Virtual Machine KVM on the vga screen makes it go dim, moving that window to dvi screen makes the vga go bright again.
<xnox> it's a desktop, yet the vga screen behaves as if it's a laptop one with battery saving stuff.
<apw> mlankhorst, hmmm i see that is unhelpful
<xnox> mlankhorst: thanks for the hint. the settings on the screens are different depending on the input. Disable "active auto contrast" on the vga and all seems to be fine =)
<apw> mlankhorst, it also seems to be a race of some kind, as it does not occur on all boots
<mlankhorst> apw: fun :/
<apw> mlankhorst, i know
<mlankhorst> I tried putting the nv50 in my computer and was hitting a similar issue, now I'm putting the nv50 in an old computer with a serial port, so that I can bisect it, so that I can use it in my own computer, so that I can bisect the nvc0 locking up on mmiotrace :/
<apw> mlankhorst, nice
<apw> (in a tecno-purv kind of way)
#ubuntu-x 2013-07-26
<bluetiger9> hi
<bluetiger9> I'm using the nVidia 313.30 driver in Ubuntu 13.04. My problem is that I'm getting high CPU usage when OpenGL is used by any application (glmark2, webgl in google-chrome). I graphics are rendered in the GPU but for some reason I'm getting high cpu. Any idea about what causing that?
<bluetiger9> my gpu is nVidia GeForce 8600 GTS
<bluetiger9> OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 8600 GTS/PCIe/SSE2 OpenGL version string: 3.3.0 NVIDIA 313.30 OpenGL shading language version string: 3.30 NVIDIA via Cg compiler
<bluetiger9> anybody here?
#ubuntu-x 2014-07-23
<dupondje> My Xorg crashes regulary with the following message: "Xorg crashed with SIGABRT in __libc_message()"
<dupondje> but can't seem to find an existing bugreport on it? While I did report it with apport 
<dupondje> but it seems like apport sends to whoopsie?
<dupondje> seems to be in /usr/lib/xorg/modules/drivers/intel_drv.so
<dupondje> but no debug symbols installed
<dupondje> ahhh :(
<tjaalton> oh
<tjaalton> huh? wrong channel
#ubuntu-x 2016-07-26
<soee> mamarley: https://developer.nvidia.com/opengl-driver
<mamarley> something something trout
<soee> :(
<mamarley> soee: Fresh crack: https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages
<soee> mamarley: ill test in a few min :)
<mamarley> Yeah, not published yet.
 * mamarley kicks LP.
<ricotz> mamarley, hi, please don't copy that though
<ricotz> btw, Wily can be considered EOL
<mamarley> ricotz: Not planning on it.
<soee> mamarley: installed
<soee> mamarley: driver works fine :) thanks again for packaging it
<mamarley> No problem. :)
<mamarley> There appear to be some changes beyond the new OpenGL support too, because I need to update the Linux 4.7 compatibility patch to get it to apply.
<soee> i would like to see some nice configuration panel from nvidia and nice and easy profile switching instead on those new features :)
#ubuntu-x 2016-07-27
<tjaalton> win 21
<tjaalton> bah
#ubuntu-x 2016-07-29
<punitvara> Hi
<punitvara> My self punit 
<punitvara> I am intereseted to contribute to ubuntu and aiming to become ubuntu member by making some significant contribution
<punitvara> I have contributed to projects like Linux , RTEMS 
<punitvara> Recently I have just purchased XPS 15 laptop 
<punitvara> Can any one suggest me task to contribute ? with bugs or kernel level task 
#ubuntu-x 2017-07-24
<soee__> mamarley: NVIDIA 384.59 Linux Driver Released Along With 375.82 :D
<mamarley> soee__: I will package it once I get home. :)  I was expecting a release this week, but usually they don't come so early in the week.
<soee__> and i can test as always when they are packaged :)
<ricotz> mamarley, thanks for taking care :)
<mamarley> Oh, Yakkety is obsolete now.
<mamarley> soee__: nvidia-384 and nvidia-settings-384 are ready.  nvidia-375 is compiling right now.
<mamarley> My testing indicates that the PowerMizer screen flashing bug from 384.47 has been fixed.
<soee__> will test in a few mins
<soee__> installing
<soee> mamarley: works fine
<soee> will test cs:go on steam
<mamarley> :)
#ubuntu-x 2017-07-25
<mamarley> ricotz: Both of the driver updates from yesterday are uploaded to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.
<ricotz> mamarley, will take a look soon
<soee> i'm using the latest and works fine :)
<ricotz> mamarley, copied :)
<mamarley> Awesome, thanks!
<tseliot> mamarley: I'm going to re-use your tarball then
<tseliot> for 375
<mamarley> OK :)
<tseliot> mamarley: BTW have you done any work on GLVND?
<tseliot> as I am going to push those changes for 17.10
<mamarley> tseliot: No, nothing beyond what I had to do to keep the full functionality of the driver working.
<tseliot> mamarley: ok, I'll let you know guys when the changes are ready
<mamarley> OK
<ricotz> tseliot, did libglvnd got NEWed finally?
<tseliot> tjaalton: ^
<ricotz> https://ftp-master.debian.org/new/libglvnd_0.2.999+git20170201-3.html
<tjaalton> it's been there since may
<tjaalton> so nothing new
<tseliot> tjaalton: BTW nvidia only needs to depend on libglvnd0, right? The rest seems to pull in mesa
<tseliot> or is there any "provide" field that I have to add?
<tjaalton> can't remember offhand :)
<tjaalton> i'll check next week when i'm back (again)
<tjaalton> but could be yeah..
<tjaalton> actually need to provide lib{egl,glx}-vendor
<tseliot> ok
<tseliot> I'll also have to get rid of the alternatives thing, as nothing seems to work right now
<tjaalton> it's not needed anymore with this
<tjaalton> dropped from mesa too
<tjaalton> i mean the ldconfig path hacks
<tseliot> right
<tseliot> I need to test if this breaks hybrid graphics on x11
<tjaalton> it still needs the server side thing from nvidia/ajax to make hybrids work properly, maybe for 1.20 and 18.04
<tjaalton> properly meaning letting both work at the same time
<tjaalton> yeah not sure if there are some hacks still needed
<tseliot> tjaalton: did you also get rid of the glamoregl alternative?
<tseliot> as glamor doesn't play well with nvidia
<tjaalton> tseliot: i don't see that in the current distro package
<tjaalton> so if something like that existed it's long gone
<tseliot> it must be something that's only in nvidia
<tseliot> fair enough
#ubuntu-x 2018-07-23
<mamarley> ricotz: For what it is worth, I have had multiple users emailing me requesting (sometimes rudely) that 396.45 be put in the main PPA. :/
<ricotz> mamarley, ack
<ricotz> I have copied the vulkan specific driver to ppa:gpu/dev
<ricotz> mamarley, bionic/cosmic are not based on the last ppa packages (trusty and xenial seems fine regardless)
<mamarley> ricotz: Were there any changes to those besides the new upstream release?  I didn't think there were/
<mamarley> s///.
<ricotz> mamarley, rebase on cosmic 390 release
<mamarley> ricotz: For both Cosmic and Bionic or just Cosmic?
<ricotz> both
<ricotz> just take the current ppa packages
<mamarley> ricotz: And to be clear, you mean rebase it on the 390.77 from the PPA?
<ricotz> no
<ricotz> just take the current *396* ppa packages as base
<mamarley> Ah, OK. You had said 390 before, that's why I was confused.
<ricotz> (390 got some changes which your 396 misses)
<mamarley> I understand now.  Coming right upâ¦
<ricotz> thanks
<mamarley> ricotz: Done.
#ubuntu-x 2018-07-24
<soee> what is the proper way to install nvidia driver on bionic
<soee> is it still nvidia-xxx or nvidia-driver-xxx ?
#ubuntu-x 2018-07-25
<opuntia> Hi. Any idea when the updated X server (from the testing PPA) that fixes this bug - https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1780664 - will be in the main xenial repos?
<ubottu> Launchpad bug 1780664 in xorg-server (Ubuntu Xenial) "Recent libgl-mesa graphics update prevents drop down list menu appearing in apps like firefox three line/bar menu icon" [Undecided,Triaged]
<soee> mamarley: ping
<tjaalton> opuntia: maybe next week. upload to proposed got rejected because the bug doesn't have the sru information...
<opuntia> thanks for the info, tjaalton 
<mamarley> soee: Oh, sorry, it is "nvidia-driver-xyz"
<soee> mamarley: i tried that on Neon (that is bionic based) and when i tried run nvidia-settings i had and info that nvidia driver is not loaded
<soee> mamarley: any idea what can be wrong with this driver?
<mamarley> No, you haven't given me enough data to draw any conclusions.
#ubuntu-x 2019-07-26
<ricotz> tjaalton, hi, this is the screen freeze issue I mentioned to hit with 5.2 -- https://lkml.org/lkml/2019/6/29/186
<tjaalton> ricotz: he didn't bother to file a bug either, seeing there's no reply ;)
<ricotz> tjaalton, there is a proposed fix staged https://cgit.freedesktop.org/drm-tip/commit/?id=b5ea9c9337007d6e700280c8a60b4e10d070fb53
<ricotz> https://lkml.org/lkml/2019/7/24/1845
<tjaalton> ok, so 5.2.x will get it
<tomreyn> hey, i worked with the person who filed bug 1837945 in #ubuntu yesterday. he had fully updated (and recent) mainboard firmware and were unable to get any graphical output from gdm. the installer worked, but when booting 19.04 he only got a black screen. 
<ubottu> bug 1837945 in xserver-xorg-video-amdgpu (Ubuntu) "AMD RX 570 Black Screen at boot" [Undecided,New] https://launchpad.net/bugs/1837945
<tomreyn> someone else suggested he should downgrade the kernel to 5.1, which he did (the issue was present with the default 19.04 kernel, too), but it didn't help. after searching online i suggested amdgpu.dc=0 which finally helped. he said he tried all of 16.04, 16.04 and 19.04 and all of them gave him a black screen.
<tomreyn> * 16.04, 18.04, 19.04
<tjaalton> tomreyn: should file it upstream then
<tomreyn> tjaalton: would you say upstream is https://bugs.freedesktop.org -> Product: DRI, Compoonent: DRM/AMDgpu ?
<tjaalton> yes
<tomreyn> thanks!
