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