[00:57] <bryceh> # Classic DRI and Gallium DRI are mixed up together here
[00:57] <bryceh> # Remove the whole tree to avoid false-positives in --list-missing, and
[00:57] <bryceh> # install the right files manually.
[00:57] <bryceh> rm -r debian/tmp/dri/usr/lib/dri
[00:57] <bryceh> dh_install -s --list-missing
[00:57] <bryceh> cp: cannot stat `debian/tmp/dri/usr/lib/egl/st_GLESv1_CM.so': No such file or directory
[00:57] <bryceh> dh_install: cp -a debian/tmp/dri/usr/lib/egl/st_GLESv1_CM.so debian/libgles1-mesa/usr/lib/egl/ returned exit code 1
[00:57] <bryceh> make: *** [binary-arch] Error 2
[00:57] <bryceh> that's after disabling gles overlay and openvg, which krh recommended for mesa to be compatible with wayland
[00:58] <bryceh> RAOF_, would it be wrong of me to drop GLESv1* from mesa's .install's?
[00:58] <bryceh> ( http://launchpadlibrarian.net/59576070/buildlog_ubuntu-maverick-i386.mesa_7.10.0%2Bgit20101118.3dcc3153-0ubuntu1~bryce6_FAILEDTOBUILD.txt.gz )
[00:59] <bryceh> I'm going to comment out  dri/usr/lib/egl/st_GLESv1_CM.so usr/lib/egl  in  libgles1-mesa.install
[01:01] <bryceh> RAOF_, btw, I found that even though the wayland server started working after our changes last night, the clients now fail to launch
[01:02] <bryceh>  
[01:02] <bryceh> errors look like:
[01:02] <bryceh> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
[01:02] <bryceh> Internal error:   Could not resolve keysym SunProps
[01:02] <bryceh> Internal error:   Could not resolve keysym SunFront
[01:02] <bryceh> Internal error:   Could not resolve keysym SunOpen
[01:02] <bryceh> failed to create cairo drm surface
[01:02] <bryceh> libEGL debug: Display 0x87f89f8 is destroyed with resources
[01:02] <bryceh> disconnect from client 0x993db08
[01:02] <bryceh>  
[01:02] <bryceh> I'm wondering about the libtxc_dxtn.so bit - that looks odd
[01:03] <bryceh> however it's the keysym errors that directly precede the termination so I wonder if something's wrong on the input side of things
[01:03] <bryceh> RAOF_, can you confirm that we definitely do want --enable-glx-tls ?
[01:04] <bryceh> It looks like we have that on in xorg-server so presumably we want it in mesa too
[01:12] <RAOF_> I think we do want --enable-glx-tls, yes.
[01:12] <Sarvatt> ...this is just going in the PPA right? you're building cairo-drm? yeah we want --enable-glx-tls, no disabling gles and openvg isn't an option in the archive
[01:14] <RAOF_> Because ARM at least wants GL|ES & OpenVG, and we probably don't want to drop those libraries anyway.
[01:15] <bryceh> Sarvatt, yeah just the PPA for now
[01:15] <bryceh> I'm not building cairo-drm, that's not needed anymore afaik
[01:15] <bryceh> instead doing cairo-gl
[01:15] <bryceh> hm ok
[01:16] <bryceh> wonder why krh suggested disabling them?
[01:17] <RAOF> I don't know.  Except that it'll probably take less build time.
[01:17] <RAOF> I don't see why they would interfere with EGL/GL.
 krh, will --enable-openvg cause troubles if it is on?
 bryceh: it wont wroth with --disable-gallium-egl
 s/wroth/work
 there is --enable-openvg
 Hehe.
 yeah, but I'm pretty sure that require gallium egl
[01:21] <Sarvatt> because he's only made things work on intel with what fedora uses and it gets complicated once you start enabling gallium stuff? :)
[01:21] <RAOF> Right.  But didn't our little expedition into the wonderful world of libudev fix the egl_dri2 problem anyway?
[01:22] <bryceh> RAOF, yes-ish
[01:22] <bryceh> it fixed it for the server, which now launches properly
[01:22] <bryceh> but the clients don't work
[01:22] <Sarvatt> we have things build-depping on our mesa gles/vg dev packages, I think most of it is arm/linaro specific though outside of mesa-utils
[01:23] <bryceh> bryce@lynmouth:~/src/Wayland/wayland$ wsmoke 
[01:23] <bryceh> libEGL warning: failed to create DRM screen
[01:23] <bryceh> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
[01:23] <bryceh> Internal error:   Could not resolve keysym SunProps
[01:23] <bryceh> Internal error:   Could not resolve keysym SunFront
[01:23] <bryceh> Internal error:   Could not resolve keysym SunOpen
[01:23] <bryceh> so I'm poking around for what else needs fixed
[01:23] <Sarvatt> attach gdb and get a backtrace?
[01:23] <RAOF> Does it work if you run as root?
[01:24] <Sarvatt> might just be harmless error spam and its stuck doing something else
[01:24] <RAOF> It could be a simple failure to authenticate the DRM connection.
[01:24] <bryceh> RAOF, nope
[01:24] <RAOF> Sarvatt: I wouldn't think so: “libEGL warning: failed to create DRM screen” looks likely to be fatal :)
[01:25] <Sarvatt> yeah somehow parsed that out and meant the keysym errors :)
[01:25] <bryceh> gdb doesn't help as it's not segfaulting
[01:25] <RAOF> Strace might?
[01:26] <bryceh> strace:  http://pastebin.com/f4qA4nKg
[01:26] <RAOF> And can EGL be a little more verbose? :)
[01:26] <bryceh> yes
[01:26] <Sarvatt> if you attach it should stop the execution until you cont, you can just bt full after attaching?
[01:26] <bryceh> wait no that's all EGL gives
[01:26] <Sarvatt> yeah theres tons of egl debug env vars
[01:27] <bryceh> here's the full run log, showing both server output and client:  http://pastebin.ubuntu.com/536116/
[01:27] <Sarvatt> EGL_LOG_LEVEL=debug
[01:27] <bryceh> this is with:
[01:27] <bryceh> export MESA_DEBUG=1
[01:27] <bryceh> export EGL_LOG_LEVEL=debug eglinfo
[01:29] <Sarvatt> bryceh: do you have X open?
[01:29] <Sarvatt> did you sudo service gdm stop first I mean?
[01:29] <RAOF> Hm.  Looks like it's correctly opening egl_dri2, which is correctly opening i965_dri
[01:29] <bryceh> Sarvatt, I have X open
[01:30] <bryceh> I might have stopped gdm and restarted once since last reboot, I don't remember
[01:30] <Sarvatt> almost positive you can't have X running when you start it?
[01:30] <bryceh> untrue; I've had that working fine
[01:31] <bryceh> in fact I've not yet gotten it running outside X
[01:31] <bryceh> although I've not yet tried very hard
[01:31]  * bryceh tries
[01:32] <bryceh> whoa that's weird
[01:32] <bryceh> screen went tie-died and then wiped to black
[01:32] <RAOF> I suspect the cairo-drm message is the problem
[01:33] <bryceh> libEGL debug: the best driver is DRI2 (score 100)
[01:33] <bryceh> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
[01:33] <bryceh> failed to add socket: Address already in use
[01:33] <bryceh> libEGL debug: Display 0x88999c8 is destroyed with resources
[01:33] <bryceh> same thing whether running as user or root
[01:33] <RAOF> Failed to add socket?
[01:34] <Sarvatt> are you in the video group?
[01:34] <bryceh> video:x:44:bryce
[01:35] <bryceh> RAOF, yeah haven't seen that error before
[01:35] <Sarvatt> you got that error in a paste earlier
[01:35] <Sarvatt> http://pastebin.ubuntu.com/536116/
[01:36] <RAOF> So, I don't particularly think this is a mesa problem; it's loading egl_dri2 properly which is then loading the correct dri driver.
[01:36] <bryceh> oh wait, socket error just meant I had a stray wayland server process
[01:37] <RAOF> And it doesn't work, even without a stray wayland? :)
[01:40] <Sarvatt> tried EGL_PLATFORM=drm EGL_DRIVER=egl_dri2 ./wstart with no X running?
[01:41] <Sarvatt> well your strace says libEGL warning: failed to create DRM screen is from /usr/lib/egl/pipe_i915.so not existing
[01:41] <RAOF> Sarvatt: Yeah, but if you read the strace it then goes on to load egl_dri2 and i965_dri.
[01:41] <bryceh> ok, without a stray wayland it does launch the server, but still no clients
[01:41] <bryceh> actually fairly cool, I can set a background and get a movable mouse cursor
[01:43] <bryceh> Sarvatt, yeah those env vars don't seem to make a difference
[01:43] <bryceh> what generates pipe_i915?
[01:43] <Sarvatt> are your binaries setuid?
[01:44] <Sarvatt> i915g
[01:44] <bryceh> it sounded like from krh that the pipe stuff is used only in certain situations unrelated to this
[01:44] <bryceh> I haven't fiddled with that at all, should I?
[01:44] <Sarvatt> yeah just saying you can ignore that warning it looks like
[01:45] <RAOF> Yeah.  The pipe_* drivers are the gallium hardware drivers; they'd be used if egl_gallium was happening.
[01:45] <bryceh> RAOF, where did you see the cairo-drm bit?
[01:45] <bryceh> afaik that shouldn't make an appearance anywhere
[01:45] <RAOF> write(2, "failed to create cairo drm surfa"..., 35failed to create cairo drm surface
 failed to create cairo drm surface
[01:46] <bryceh> oh right
[01:46] <RAOF> You could play with i915g; I understand that it's not entirely broken, like i965g is :)
[01:46] <bryceh> that's an error message from the client that it gets after trying to create a surface using cairo
[01:46] <bryceh> hrm
[01:47] <bryceh> ok if you guys are out of clue on this too, I'll just shelve it until next week
[01:47] <bryceh> happy to try more idea though if you got 'em
[01:48] <RAOF> I think the interesting question is why cairo's failing to create a drm surface.
[01:49] <Sarvatt> yeah looks like the problems in the way cairo is built to me even though cairo-drm isn't enabled
[01:53] <bryceh> hm ok
[02:00] <bryceh> alright, lastly, gonna try newer wayland in case recent git changes fixed something
[02:00] <bryceh> WHOA
[02:00] <bryceh> that did it
[02:00] <bryceh> sweetness
[02:00] <RAOF> Heh
[02:00] <bryceh> shoulda tried that earlier!
[02:01] <Sarvatt> http://cgit.freedesktop.org/wayland/commit/?id=32ff69017ab003911b754982772d0644b1cd23d4
[02:01] <RAOF> So that sounds like we can use the archive mesa configuration and still have everything work.
[02:01] <Sarvatt> hah was my  next idea
[02:01] <Sarvatt> (are you *sure* the udev rules are getting used?)
[02:02] <bryceh> for the record I still see these warnings when firing up the clients:  http://pastebin.ubuntu.com/536127/
[02:02] <bryceh> Sarvatt, I express certainty on nothing
[02:02] <bryceh> oh
[02:03] <bryceh> on that, I had been forcing install of the udev rules in debian/rules anyway
[02:03] <bryceh> I can probably clean some of that up now
[02:04] <RAOF> Yeah; the dxtn library warning is totally harmless.  I guess unless a wayland client wants to upload DXT-compressed textures :)
[02:04] <bryceh> would be nice to suppress that
[02:05] <bryceh> I've a pet peeve about harmless-but-technobabbly warnings
[02:05] <Sarvatt> you could install it :)
[02:05] <bryceh> actually not sure that I can
[02:06] <RAOF> You know what would be a good fix?  Show that warning when something tries to fiddle with a DXT texture!
[02:06] <Sarvatt> yeah you can I just did on a new install a few days ago
[02:06] <bryceh> bryce@blumonc:~/src/Wayland/wayland/wayland-0.1~git20101124.32ff6901/debian$ apt-cache search dxtn
[02:06] <bryceh> bryce@blumonc:~/src/Wayland/wayland/wayland-0.1~git20101124.32ff6901/debian$ 
[02:06] <bryceh> is it a natty package?
[02:06] <Sarvatt> its patent encumbered, have to do it manually
[02:06] <bryceh> oh, well I don't count that ;-)
[02:07] <bryceh> well, I'd say either quell the warning or add the installation directions to it
[02:07] <bryceh> anyway, task for another day
[02:07] <bryceh> Sarvatt, where do you get the package?
[02:08] <Sarvatt> do you have LIBGL_DEBUG=verbose exported maybe?
[02:10] <Sarvatt> digging around for it now, it was on people.freedesktop.org that got nuked awhile back and had to grab it off bugzilla somewhere
[02:10] <bryceh> no, but I do have MESA_DEBUG=1 exported
[02:10] <Sarvatt> oh thats why ya got it i bet
[02:10] <bryceh> export MESA_DEBUG=1
[02:10] <bryceh> export EGL_DRIVER=egl_dri2
[02:10] <bryceh> export EGL_PLATFORM=drm x11
[02:10] <bryceh> export EGL_LOG_LEVEL=debug eglinfo
[02:11] <Sarvatt> export EGL_LOG_LEVEL=debug eglinfo ?
[02:12] <bryceh> hmm commenting out both MESA_DEBUG and EGL_LOG_LEVEL but still prints it
[02:13] <Sarvatt> http://debian-multimedia.org/pool/main/libt/libtxc-dxtn/libtxc-dxtn.php
[02:13] <Sarvatt> debs!
[02:14] <bryceh> ok thanks
[02:14]  * Sarvatt wonders if he can get away uploading that to xorg-edgers :)
[02:14] <bryceh> if I get around to it I'll isolate where the warning comes from and add that link, if I don't just quell it outright
[02:14] <RAOF> Sarvatt: It's free software, right?
[02:14] <bryceh> is debian-multimedia.org part of Debian?
[02:15] <Sarvatt> heavily patent encumbered and not suitable for debian :)
[02:15] <Sarvatt> its debian's medibuntu
[02:16] <Sarvatt> http://dri.freedesktop.org/wiki/S3TC
[02:18] <ScottK> Sarvatt: only with lower quality packaging.
[02:19] <Sarvatt> lower quality?
[02:19] <ScottK> The debian-multimedia packaging quality is not well thought of in Debian.
[02:19]  * Sarvatt can't even count how many times he's had broken ffmpeg libs screw up his system from medibuntu
[02:20] <bryceh> gotcha
[02:20] <ScottK> AFAIK, most of the people working on medibuntu are actual Ubuntu devs so I think it's similar to Ubuntu package quality wise
[02:20] <ScottK> It's been quite some time since I actually paid attention to medibuntu though.
[02:22] <bryceh> okie dokie guys, get your wayland on:  https://launchpad.net/~xorg-edgers/+archive/wayland
[02:22] <bryceh> IN THEORY, you should be able to just add the ppa, update, install wayland, and then run wayland as described
[02:23] <bryceh> if not, it's something I should fix
[02:23] <Sarvatt> ppa-purge no workie in natty, but at least there aren't many packages involved :)
[02:23] <bryceh> no?  why not?
[02:23] <bryceh> anyway, this is only tested on maverick so far
[02:24] <Sarvatt> sources are stored compressed now, haven't had a chance to make ppa-purge work with that
[02:25] <Sarvatt> /var/lib/apt/lists/ppa.launchpad.net_xorg-edgers_wayland_ubuntu_dists_natty_main_binary-i386_Packages.gz
[02:26] <bryceh> ah
[02:35] <bjsnider> the medibuntu ffmpeg is almost exactly the same as the ubuntu ffmpeg. hard to believe it could have broken anything
[07:52] <tjaalton> bryceh: tried the ppa, but looks like wayland needs to depend on libgles2-mesa
[07:53] <tjaalton> since it can't find libGLESv2.so.2 without it
[07:53] <RAOF> And it's looking for GLESv2?  I thought it was strictly a desktop GL affair.
[07:54] <vish> RAOF: hi, alacarte upstream is unmaintained.. spoke to Amaranth earlier, he said we can just upload the patch in natty.. re: Bug 395692
[07:54] <tjaalton> ah
[07:54] <ubot4`> Launchpad bug 395692 in alacarte (Ubuntu) (and 2 other projects) "Drag-and-Drop behavior in the menu editor is inconsistent and confusing (affects: 3) (heat: 28)" [Low,Triaged] https://launchpad.net/bugs/395692
[07:54] <RAOF> Also, I guess that's a bug in mesa.
[07:54] <tjaalton> RAOF: yeah I'm trying to run it with the hints from the ppa
[07:54] <vish> s/natty/ubuntu
[07:54] <tjaalton> now the compositor runs, but how do I fire up the clients?-)
[07:55] <RAOF> vish: Yeah, I guessed as much.  I was going to go sponsor hunting this evening.
[07:55] <vish> RAOF: neat! thx :)
[08:04] <tjaalton> is there a way to launch wayland without X
[08:04] <tjaalton> ?
[08:04] <bryceh> tjaalton, there may be a /usr/bin/wstart script
[08:05] <tjaalton> bryceh: yeah, it just says "no drm device found"
[08:05] <bryceh> tjaalton, and there are clients named wayland-* you can run if you have the server up
[08:05] <tjaalton> so maybe something else is wrong
[08:05] <bryceh> yeah likely
[08:05] <tjaalton> bryceh: also, it didn't pull libxkbcommon
[08:05] <bryceh> ok
[08:05]  * bryceh makes notes
[08:05] <tjaalton> the ppa description has old client names, btw (wterminal..)
[08:06] <bryceh> oh thanks, yeah just redid the naming today
[08:08] <bryceh> tjaalton, updated
[08:08]  * bryceh -> bed
[08:08] <tjaalton> yeah, night
[21:50] <RAOF> Well, launchpad indicates that mesa doesn't appear to be on fire.  That's nice :)
[22:05] <bryceh> RAOF, should it?
[22:06] <RAOF> No, of course not :)
[22:06] <bryceh> RAOF, oh btw I wanted to ask, you mentioned you'd pulled some of the changes for wayland-enabled mesa into the archive... 
[22:06] <bryceh> RAOF, which changes exactly did you pull, and was that into the main archive or the xorg-edgers archive?
[22:07] <RAOF> I pulled the libudev-dev build-dep into the main archive packages.
[22:07] <RAOF> So egl_dri2 should actually work. :)
[22:08] <RAOF> The reasons why Mesa might have caught fire are the switch to r300g by default and libdricore shared linking.
[22:09] <bryceh> ah gotcha
[22:09] <bryceh> I've been watching all incoming natty bug reports fairly carefully the last couple weeks
[22:09] <bryceh> the sense I get is that very few people are running natty at the moment, cause there's hardly any bug reports coming in
[22:10] <bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
[22:10] <bryceh> there's 1 natty bug against -evdev and one against nvidia-173
[22:39] <RAOF> Ah.  Mesa hasn't caught fire on people's systems because it's failed to build on the buildds.  Thanks, crappy mesa build system!