From sedat.dilek at googlemail.com Mon Nov 1 03:28:49 2010 From: sedat.dilek at googlemail.com (Sedat Dilek) Date: Mon, 1 Nov 2010 11:28:49 +0100 Subject: [RESEND] Wayland: swrast-gallium in combination with EGL/pipe_swrast.so? In-Reply-To: References: Message-ID: [RESEND] due to rejects of too big screenshots attachment. (I am sorry about that, now as JPEG + 75% resized, ~100K should be fair now). - Sedat - On Sun, Oct 31, 2010 at 7:34 PM, Sedat Dilek wrote: > Hi, > > I am playing with Wayland this weekend. > > Unfortunately, my RV250 is not r300g-compatible. > > As a workaround I wanted to build and use swrast-gallium for Wayland > (compositor). > > Immediately, when I have "dri" in my autogen line like > "--with-state-trackers=dri,glx,egl" I get also r300_dri.so (r300g) and > EGL/pipe_r300.so auto-built. > > My RV250 has problems to use pipe_r300.so (see below). > I must confirm that "dri" as state-tracker is required to get run > Wayland here (after several builds). > > NOTE: > After several starts of the compositor, I got Wayland running with a > background image (JPG). > But this is very weaky. > > Building mesa with "--with-state-trackers=glx,egl" (no dri set) > results in an unuseable Wayland. > > Next problem is I cannot run Wayland with a mesa compiled with > --disable-gallium. > So Gallium seems to be a must-have as Chia-I Wu confirmed on the > wayland-devel ML. > > In the end - as a more stable solution - I want to use swrastg_dri.so > + EGL/pipe_swrast.so instead. > The mesa build-system is not recognizing this wish of mine. > > Is my workaround idea wrong? > If not, is it a good idea to modify mesa-buildsystem to have *only* > swrastg_dri.so + EGL/pipe_swrast.so built (NO r300* stuff)? > > Thanks in advance. > > > Kind Regards, > - Sedat - > > P.S.: The background shows Walter (a friend of mine) in the > cathedral/dome of Aachen/Germany. > > P.S.S.: > > An autogen line looks like this... > > ./autogen.sh --prefix=/opt/wayland --with-driver=dri > --with-dri-driverdir=/opt/wayland/lib/dri --with-dri-drivers=swrast > --enable-gallium-swrast --with-state-trackers=dri,glx,egl > --disable-glu --disable-glut --disable-glw --enable-egl --enable-gles2 > > ...results in: > > /opt/wayland/lib/dri: > insgesamt 46476 > -rwxr-xr-x 1 sd sd 17052104 31. Okt 18:37 r300_dri.so > -rwxr-xr-x 1 sd sd 14074224 31. Okt 18:37 swrast_dri.so > -rwxr-xr-x 1 sd sd 16456880 31. Okt 18:37 swrastg_dri.so > > /opt/wayland/lib/egl: > insgesamt 22804 > -rwxr-xr-x 1 sd sd ? ?85060 31. Okt 18:37 egl_dri2.so > -rwxr-xr-x 1 sd sd ?1352956 31. Okt 18:37 egl_gallium.so > -rwxr-xr-x 1 sd sd ? ?47832 31. Okt 18:37 egl_glx.so > -rwxr-xr-x 1 sd sd ?3591936 31. Okt 18:37 pipe_r300.so > -rwxr-xr-x 1 sd sd ?3434328 31. Okt 18:37 pipe_swrast.so > -rwxr-xr-x 1 sd sd 14830212 31. Okt 18:37 st_GL.so > > This leads to errors when starting the Wayland compositor: > > sd at tbox:~/src/wayland/wayland/compositor$ LC_ALL=C ./compositor -b > ../../backgrounds/dscn1843.jpg > r300: Warning: Unknown chipset 0x4c66 > radeon: The kernel rejected CS, see dmesg for more information. > > Fact is pipe_r300.so is used: > > # lsof | grep wayland | grep -v bash > firefox-b 4421 ? ? ? ? sd ?mem ? ? ? REG ? ? ? ?8,5 ? 285608 > 260977 /opt/wayland/lib/libEGL.so.1.0 > firefox-b 4421 ? ? ? ? sd ?mem ? ? ? REG ? ? ? ?8,5 ?4416992 > 308578 /opt/wayland/lib/libcairo.so.2.11101.0 > lt-compos 4523 ? ? ? ? sd ?cwd ? ? ? DIR ? ? ? ?8,3 ? ? 4096 > 528742 /home/sd/src/wayland/wayland/compositor > lt-compos 4523 ? ? ? ? sd ?txt ? ? ? REG ? ? ? ?8,3 ? 151648 > 528963 /home/sd/src/wayland/wayland/compositor/.libs/lt-compositor > lt-compos 4523 ? ? ? ? sd ?mem ? ? ? REG ? ? ? ?8,5 14830212 > 260984 /opt/wayland/lib/egl/st_GL.so > lt-compos 4523 ? ? ? ? sd ?mem ? ? ? REG ? ? ? ?8,5 ?3591936 > 260981 /opt/wayland/lib/egl/pipe_r300.so > lt-compos 4523 ? ? ? ? sd ?mem ? ? ? REG ? ? ? ?8,5 ?1352956 > 260983 /opt/wayland/lib/egl/egl_gallium.so > lt-compos 4523 ? ? ? ? sd ?mem ? ? ? REG ? ? ? ?8,5 ? 130800 > 260935 /opt/wayland/lib/libGLESv2.so.2.0.0 > lt-compos 4523 ? ? ? ? sd ?mem ? ? ? REG ? ? ? ?8,5 ? 285608 > 260977 /opt/wayland/lib/libEGL.so.1.0 > lt-compos 4523 ? ? ? ? sd ?mem ? ? ? REG ? ? ? ?8,3 ? ?78296 > 528849 /home/sd/src/wayland/wayland/wayland/.libs/libwayland-server.so.0.0.0 > -------------- next part -------------- A non-text attachment was scrubbed... Name: wayland_compositor_walter_resized.jpg Type: image/jpeg Size: 106209 bytes Desc: not available URL: From sedat.dilek at googlemail.com Mon Nov 1 07:09:34 2010 From: sedat.dilek at googlemail.com (Sedat Dilek) Date: Mon, 1 Nov 2010 15:09:34 +0100 Subject: Radeon tryouts: With and without gallium on RV250 Message-ID: Hi, I have tried some more Wayland-testing on Radeon hardware and wanted to let you know. [1] Disabled-Gallium: NOT working (see attachment) $ LC_ALL=C ; LIBGL_DRIVERS_PATH=/opt/wayland/lib/dri DISPLAY=:0.0 ./compositor -b ../../backgrounds/dscn1843.jpg failed to initialize display Segmentation fault For Intel-GfxCards it is even recommended [1]: "If you're using an intel chipset, it's best to also pass --disable-gallium to ./configure, since otherwise libEGL will try to load the gallium sw rasterizer before loading the Intel DRI driver." [2] With Dirty-Hack to recognize Chip-ID: NOT working (patch attached) Workaround try for the following error-messages: $ LC_ALL=C ; LIBGL_DRIVERS_PATH=/opt/wayland/lib/dri DISPLAY=:0.0 ./compositor r300: Warning: Unknown chipset 0x4c66 radeon: The kernel rejected CS, see dmesg for more information. [ src/gallium/state_trackers/egl/drm/native_drm.c ] ... - name = is_r3xx(chip_id) ? "r300" : "r600"; + name = "r200"; ... Thanks Alex Deucher for pointing me to commit "st/egl: Fix r300/r600 support in KMS backend." (see [2]) and giving help on IRC. [3] Enabled swrast-gallium and Disabled radeon-gallium: NOT working (see attachment) I was wrong in [3], it is possible to have swrast-gallium-only build. ./autogen.sh --prefix=/opt/wayland --with-driver=dri --with-dri-driverdir=/opt/wayland/lib/dri --with-dri-drivers=swrast --disable-gallium-radeon --enable-gallium-swrast --with-state-trackers=dri,glx,egl --enable-egl --enable-gles2 $ LC_ALL=C ; LIBGL_DRIVERS_PATH=/opt/wayland/lib/dri DISPLAY=:0.0 ./compositor -b ../../backgrounds/dscn1843.jpg libEGL warning: failed to create DRM screen failed to initialize display Segmentation fault [4] Conclusion? From bogus@does.not.exist.com Mon Nov 1 06:12:10 2010 From: bogus@does.not.exist.com () Date: Mon, 01 Nov 2010 13:12:10 -0000 Subject: No subject Message-ID: ... [14:22:51] dileks: I dunno. hopefully someone on the wayland list can help [14:23:27] I guess I have wayland-incompatible hardware [14:23:48] thats a hard but fair conclusion [14:24:22] dileks: it's a software problem. I suspect you'd hit similar issues with other radeons. [14:24:39] I don't think anyone has actually tried to use wayland on AMD hw yet [14:27:22] then I am pioneer in testing - I like this conclusion as well :-) User nanonyme gave the hint on #radeon to see problems on r600c (classic-mesa driver). I can't track these problems by my own, in my very first mail to this ML I asked for debugging help [4]. I wrote about some improvements on the "building" website [1], some informations are outdated or wrong. All krh/wayland stuff has moved from his own repos to public ones, for example. New wayland repo is listed here [5]. OLD: git clone git://people.freedesktop.org/~krh/wayland NEW: git://anongit.freedesktop.org/wayland No changes yet, I hope they follow. Kind Regards, - Sedat - [1] http://wayland.freedesktop.org/building.html [2] http://cgit.freedesktop.org/mesa/mesa/commit/?id=1288d5c39234e7c54ae2fbb81dd788c98c62a7b3 [3] http://lists.freedesktop.org/archives/wayland-devel/2010-November/000020.html [4] http://lists.freedesktop.org/archives/wayland-devel/2010-October/000002.html [5] http://cgit.freedesktop.org/wayland/ --20cf30334dc1b6ea460493fe5b32 Content-Type: text/plain; charset=US-ASCII; name="paste_dirty-hack.txt" Content-Disposition: attachment; filename="paste_dirty-hack.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfzf3fkq0 JCBjYXQgLi4vLi4vcGF0Y2hlcy8wMDAxLXN0LWVnbC1SZWR1Y2UtdG8tcjIwMC1zdXBwb3J0LWlu LUtNUy1iYWNrZW5kLnBhdGNoIApGcm9tIDYwNmQxYTFhOTg3ODlkYTRiNmU5NzM0MTdmOWFlZDVh NmYwNGM0N2EgTW9uIFNlcCAxNyAwMDowMDowMCAyMDAxCkZyb206IFNlZGF0IERpbGVrIDxzZWRh dC5kaWxla0BnbWFpbC5jb20+CkRhdGU6IE1vbiwgMSBOb3YgMjAxMCAwNzozNjozOSArMDEwMApT dWJqZWN0OiBbUEFUQ0hdIHN0L2VnbDogUmVkdWNlIHRvIHIyMDAgc3VwcG9ydCBpbiBLTVMgYmFj a2VuZAoKLS0tCiBzcmMvZ2FsbGl1bS9zdGF0ZV90cmFja2Vycy9lZ2wvZHJtL25hdGl2ZV9kcm0u YyB8ICAgIDIgKy0KIDEgZmlsZXMgY2hhbmdlZCwgMSBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9u cygtKQoKZGlmZiAtLWdpdCBhL3NyYy9nYWxsaXVtL3N0YXRlX3RyYWNrZXJzL2VnbC9kcm0vbmF0 aXZlX2RybS5jIGIvc3JjL2dhbGxpdW0vc3RhdGVfdHJhY2tlcnMvZWdsL2RybS9uYXRpdmVfZHJt LmMKaW5kZXggZjZkYzU1OC4uMzVhODJmMyAxMDA2NDQKLS0tIGEvc3JjL2dhbGxpdW0vc3RhdGVf dHJhY2tlcnMvZWdsL2RybS9uYXRpdmVfZHJtLmMKKysrIGIvc3JjL2dhbGxpdW0vc3RhdGVfdHJh Y2tlcnMvZWdsL2RybS9uYXRpdmVfZHJtLmMKQEAgLTE0NSw3ICsxNDUsNyBAQCBnZXRfZHJtX3Nj cmVlbl9uYW1lKGludCBmZCwgZHJtVmVyc2lvblB0ciB2ZXJzaW9uKQogICAgICAgaWYgKGRybUNv bW1hbmRXcml0ZVJlYWQoZmQsIERSTV9SQURFT05fSU5GTywgJmluZm8sIHNpemVvZihpbmZvKSkg IT0gMCkKICAgICAgICAgIHJldHVybiBOVUxMOwogCi0gICAgICBuYW1lID0gaXNfcjN4eChjaGlw X2lkKSA/ICJyMzAwIiA6ICJyNjAwIjsKKyAgICAgIG5hbWUgPSAicjIwMCI7CiAgICB9CiAKICAg IHJldHVybiBuYW1lOwotLSAKMS43LjIuMwoKCnNkQHRib3g6fi9zcmMvd2F5bGFuZC93YXlsYW5k L2NvbXBvc2l0b3IkIExDX0FMTD1DIDsgTElCR0xfRFJJVkVSU19QQVRIPS9vcHQvd2F5bGFuZC9s aWIvZHJpIERJU1BMQVk9OjAuMCAuL2NvbXBvc2l0b3IKbGliRUdMIHdhcm5pbmc6IGZhaWxlZCB0 byBjcmVhdGUgRFJNIHNjcmVlbgpmYWlsZWQgdG8gaW5pdGlhbGl6ZSBkaXNwbGF5ClNlZ21lbnRh dGlvbiBmYXVsdAo= --20cf30334dc1b6ea460493fe5b32 Content-Type: text/plain; charset=US-ASCII; name="paste_disable-gallium.txt" Content-Disposition: attachment; filename="paste_disable-gallium.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfzf3o731 JCBlZ3JlcCAiYXV0b2dlbnxFR0w6fEVHTCBwbGF0Zm9ybXN8RUdMIGRyaXZlcnN8RUdMIEdhbGxp dW0gU1RzfEdhbGxpdW18R2FsbGl1bSBkaXJzfFRhcmdldCBkaXJzfFdpbnN5cyBkaXJzfERyaXZl ciBkaXJzfFRyYWNrZXJzIGRpcnN8Y2hlY2tpbmcgZm9yIFhDQl9EUkkyIiBtZXNhLmxvZworIC4v YXV0b2dlbi5zaCAtLXByZWZpeD0vb3B0L3dheWxhbmQgLS13aXRoLWRyaXZlcj1kcmkgLS13aXRo LWRyaS1kcml2ZXJkaXI9L29wdC93YXlsYW5kL2xpYi9kcmkgLS13aXRoLWRyaS1kcml2ZXJzPXIy MDAscjMwMCxzd3Jhc3QgLS1kaXNhYmxlLWdhbGxpdW0gLS13aXRoLXN0YXRlLXRyYWNrZXJzPWRy aSxnbHgsZWdsIC0tZW5hYmxlLWVnbCAtLWVuYWJsZS1nbGVzMiAtLWRpc2FibGUtZ2x1IC0tZGlz YWJsZS1nbHV0IC0tZGlzYWJsZS1nbHcKY2hlY2tpbmcgZm9yIFhDQl9EUkkyLi4uIHllcwogICAg ICAgIEVHTDogICAgICAgICAgICAgeWVzCiAgICAgICAgRUdMIHBsYXRmb3JtczogICB4MTEgZHJt CiAgICAgICAgRUdMIGRyaXZlcnM6ICAgICBlZ2xfZ2x4IGVnbF9kcmkyCiAgICAgICAgR2FsbGl1 bTogICAgICAgICBubwoKc2RAdGJveDp+L3NyYy93YXlsYW5kL3dheWxhbmQvY29tcG9zaXRvciQg TENfQUxMPUMgOyBMSUJHTF9EUklWRVJTX1BBVEg9L29wdC93YXlsYW5kL2xpYi9kcmkgRElTUExB WT06MC4wIC4vY29tcG9zaXRvciAtYiAuLi8uLi9iYWNrZ3JvdW5kcy9kc2NuMTg0My5qcGcKZmFp bGVkIHRvIGluaXRpYWxpemUgZGlzcGxheQpTZWdtZW50YXRpb24gZmF1bHQKCi9vcHQvd2F5bGFu ZC9saWIvZHJpOgppbnNnZXNhbXQgNDIyMzYKLXJ3eHIteHIteCAxIHNkIHNkIDE1MTAwMTM3ICAx LiBOb3YgMTQ6MTEgcjIwMF9kcmkuc28KLXJ3eHIteHIteCAxIHNkIHNkIDE1MzY4MzI1ICAxLiBO b3YgMTQ6MTEgcjMwMF9kcmkuc28KLXJ3eHIteHIteCAxIHNkIHNkIDEyNzcxMzMzICAxLiBOb3Yg MTQ6MTEgc3dyYXN0X2RyaS5zbwoKL29wdC93YXlsYW5kL2xpYi9lZ2w6Cmluc2dlc2FtdCAxMjAK LXJ3eHIteHIteCAxIHNkIHNkIDc1NDk1ICAxLiBOb3YgMTQ6MTEgZWdsX2RyaTIuc28KLXJ3eHIt eHIteCAxIHNkIHNkIDQyNzAyICAxLiBOb3YgMTQ6MTEgZWdsX2dseC5zbwoK --20cf30334dc1b6ea460493fe5b32 Content-Type: text/plain; charset=US-ASCII; name="paste_swrast-gallium-only_1.txt" Content-Disposition: attachment; filename="paste_swrast-gallium-only_1.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfzf3tew2 JCBlZ3JlcCAnYXV0b2dlbnxFR0wgZHJpdmVyc3xFR0wgR2FsbGl1bSBTVHN8R2FsbGl1bXxUYXJn ZXQgZGlyc3xUcmFja2VycyBkaXJzfGNoZWNraW5nIGZvciBYQ0JfRFJJMicgbWVzYS5sb2cgCisg Li9hdXRvZ2VuLnNoIC0tcHJlZml4PS9vcHQvd2F5bGFuZCAtLXdpdGgtZHJpdmVyPWRyaSAtLXdp dGgtZHJpLWRyaXZlcmRpcj0vb3B0L3dheWxhbmQvbGliL2RyaSAtLXdpdGgtZHJpLWRyaXZlcnM9 c3dyYXN0IC0tZGlzYWJsZS1nYWxsaXVtLXJhZGVvbiAtLWVuYWJsZS1nYWxsaXVtLXN3cmFzdCAt LXdpdGgtc3RhdGUtdHJhY2tlcnM9ZHJpLGdseCxlZ2wgLS1lbmFibGUtZWdsIC0tZW5hYmxlLWds ZXMyCmNoZWNraW5nIGZvciBYQ0JfRFJJMi4uLiB5ZXMKICAgICAgICBFR0wgZHJpdmVyczogICAg IGVnbF9nbHggZWdsX2RyaTIgZWdsX2dhbGxpdW0KICAgICAgICBFR0wgR2FsbGl1bSBTVHM6ICQo R0xfTElCKQogICAgICAgIEdhbGxpdW06ICAgICAgICAgeWVzCiAgICAgICAgR2FsbGl1bSBkaXJz OiAgICBhdXhpbGlhcnkgZHJpdmVycyBzdGF0ZV90cmFja2VycwogICAgICAgIFRhcmdldCBkaXJz OiAgICAgIGVnbCBkcmktc3dyYXN0CiAgICAgICAgVHJhY2tlcnMgZGlyczogICBkcmkgZ2x4IGVn bA== --20cf30334dc1b6ea460493fe5b32 Content-Type: text/plain; charset=US-ASCII; name="paste_swrast-gallium-only_2.txt" Content-Disposition: attachment; filename="paste_swrast-gallium-only_2.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfzf40ud3 c2RAdGJveDp+L3NyYy93YXlsYW5kL3dheWxhbmQvY29tcG9zaXRvciQgTENfQUxMPUMgOyBMSUJH TF9EUklWRVJTX1BBVEg9L29wdC93YXlsYW5kL2xpYi9kcmkgRElTUExBWT06MC4wIC4vY29tcG9z aXRvciAtYiAuLi8uLi9iYWNrZ3JvdW5kcy9kc2NuMTg0My5qcGcKbGliRUdMIHdhcm5pbmc6IGZh aWxlZCB0byBjcmVhdGUgRFJNIHNjcmVlbgpmYWlsZWQgdG8gaW5pdGlhbGl6ZSBkaXNwbGF5ClNl Z21lbnRhdGlvbiBmYXVsdAoKL29wdC93YXlsYW5kL2xpYjoKaW5zZ2VzYW10IDEwNTg0CmRyd3hy LXhyLXggMiBzZCBzZCAgICA0MDk2ICAxLiBOb3YgMTM6MDAgY2Fpcm8KZHJ3eHIteHIteCAyIHNk IHNkICAgIDQwOTYgIDEuIE5vdiAxMjo1NiBkcmkKZHJ3eHIteHIteCAyIHNkIHNkICAgIDQwOTYg IDEuIE5vdiAxMjo1NiBlZ2wKLXJ3eHIteHIteCAxIHNkIHNkICAgIDEyMzYgIDEuIE5vdiAxMzow MCBsaWJjYWlyby1nb2JqZWN0LmxhCmxyd3hyd3hyd3ggMSBzZCBzZCAgICAgIDI5ICAxLiBOb3Yg MTM6MDAgbGliY2Fpcm8tZ29iamVjdC5zbyAtPiBsaWJjYWlyby1nb2JqZWN0LnNvLjIuMTExMDEu MApscnd4cnd4cnd4IDEgc2Qgc2QgICAgICAyOSAgMS4gTm92IDEzOjAwIGxpYmNhaXJvLWdvYmpl Y3Quc28uMiAtPiBsaWJjYWlyby1nb2JqZWN0LnNvLjIuMTExMDEuMAotcnd4ci14ci14IDEgc2Qg c2QgICA1MDgwMCAgMS4gTm92IDEzOjAwIGxpYmNhaXJvLWdvYmplY3Quc28uMi4xMTEwMS4wCi1y d3hyLXhyLXggMSBzZCBzZCAgICAxMDY3ICAxLiBOb3YgMTM6MDAgbGliY2Fpcm8ubGEKLXJ3eHIt eHIteCAxIHNkIHNkICAgIDEyMTAgIDEuIE5vdiAxMzowMCBsaWJjYWlyby1zY3JpcHQtaW50ZXJw cmV0ZXIubGEKbHJ3eHJ3eHJ3eCAxIHNkIHNkICAgICAgNDAgIDEuIE5vdiAxMzowMCBsaWJjYWly by1zY3JpcHQtaW50ZXJwcmV0ZXIuc28gLT4gbGliY2Fpcm8tc2NyaXB0LWludGVycHJldGVyLnNv LjIuMTExMDEuMApscnd4cnd4cnd4IDEgc2Qgc2QgICAgICA0MCAgMS4gTm92IDEzOjAwIGxpYmNh aXJvLXNjcmlwdC1pbnRlcnByZXRlci5zby4yIC0+IGxpYmNhaXJvLXNjcmlwdC1pbnRlcnByZXRl ci5zby4yLjExMTAxLjAKLXJ3eHIteHIteCAxIHNkIHNkICAzODYxMjkgIDEuIE5vdiAxMzowMCBs aWJjYWlyby1zY3JpcHQtaW50ZXJwcmV0ZXIuc28uMi4xMTEwMS4wCmxyd3hyd3hyd3ggMSBzZCBz ZCAgICAgIDIxICAxLiBOb3YgMTM6MDAgbGliY2Fpcm8uc28gLT4gbGliY2Fpcm8uc28uMi4xMTEw MS4wCmxyd3hyd3hyd3ggMSBzZCBzZCAgICAgIDIxICAxLiBOb3YgMTM6MDAgbGliY2Fpcm8uc28u MiAtPiBsaWJjYWlyby5zby4yLjExMTAxLjAKLXJ3eHIteHIteCAxIHNkIHNkIDM2MjUxMjAgIDEu IE5vdiAxMzowMCBsaWJjYWlyby5zby4yLjExMTAxLjAKbHJ3eHJ3eHJ3eCAxIHNkIHNkICAgICAg MTEgIDEuIE5vdiAxMjo1NiBsaWJFR0wuc28gLT4gbGliRUdMLnNvLjEKbHJ3eHJ3eHJ3eCAxIHNk IHNkICAgICAgMTMgIDEuIE5vdiAxMjo1NiBsaWJFR0wuc28uMSAtPiBsaWJFR0wuc28uMS4wCi1y d3hyLXhyLXggMSBzZCBzZCAgMjQ3NjEyICAxLiBOb3YgMTI6NTYgbGliRUdMLnNvLjEuMApscnd4 cnd4cnd4IDEgc2Qgc2QgICAgICAxNyAgMS4gTm92IDEyOjU2IGxpYkdMRVN2MV9DTS5zbyAtPiBs aWJHTEVTdjFfQ00uc28uMQpscnd4cnd4cnd4IDEgc2Qgc2QgICAgICAyMSAgMS4gTm92IDEyOjU2 IGxpYkdMRVN2MV9DTS5zby4xIC0+IGxpYkdMRVN2MV9DTS5zby4xLjEuMAotcnd4ci14ci14IDEg c2Qgc2QgIDEzMTc2MyAgMS4gTm92IDEyOjU2IGxpYkdMRVN2MV9DTS5zby4xLjEuMApscnd4cnd4 cnd4IDEgc2Qgc2QgICAgICAxNCAgMS4gTm92IDEyOjU2IGxpYkdMRVN2Mi5zbyAtPiBsaWJHTEVT djIuc28uMgpscnd4cnd4cnd4IDEgc2Qgc2QgICAgICAxOCAgMS4gTm92IDEyOjU2IGxpYkdMRVN2 Mi5zby4yIC0+IGxpYkdMRVN2Mi5zby4yLjAuMAotcnd4ci14ci14IDEgc2Qgc2QgIDEyODAxNiAg MS4gTm92IDEyOjU2IGxpYkdMRVN2Mi5zby4yLjAuMApscnd4cnd4cnd4IDEgc2Qgc2QgICAgICAx MCAgMS4gTm92IDEyOjU2IGxpYkdMLnNvIC0+IGxpYkdMLnNvLjEKbHJ3eHJ3eHJ3eCAxIHNkIHNk ICAgICAgMTIgIDEuIE5vdiAxMjo1NiBsaWJHTC5zby4xIC0+IGxpYkdMLnNvLjEuMgotcnd4ci14 ci14IDEgc2Qgc2QgMTg0NjcyMyAgMS4gTm92IDEyOjU2IGxpYkdMLnNvLjEuMgpscnd4cnd4cnd4 IDEgc2Qgc2QgICAgICAxMSAgMS4gTm92IDEyOjU2IGxpYkdMVS5zbyAtPiBsaWJHTFUuc28uMQps cnd4cnd4cnd4IDEgc2Qgc2QgICAgICAyMCAgMS4gTm92IDEyOjU2IGxpYkdMVS5zby4xIC0+IGxp YkdMVS5zby4xLjMuMDcxMDAwCi1yd3hyLXhyLXggMSBzZCBzZCAxNjM0ODgxICAxLiBOb3YgMTI6 NTYgbGliR0xVLnNvLjEuMy4wNzEwMDAKbHJ3eHJ3eHJ3eCAxIHNkIHNkICAgICAgMTIgIDEuIE5v diAxMjo1NiBsaWJnbHV0LnNvIC0+IGxpYmdsdXQuc28uMwpscnd4cnd4cnd4IDEgc2Qgc2QgICAg ICAxNiAgMS4gTm92IDEyOjU2IGxpYmdsdXQuc28uMyAtPiBsaWJnbHV0LnNvLjMuNy4xCi1yd3hy LXhyLXggMSBzZCBzZCAgNjUxMjY4ICAxLiBOb3YgMTI6NTYgbGliZ2x1dC5zby4zLjcuMQpscnd4 cnd4cnd4IDEgc2Qgc2QgICAgICAxMSAgMS4gTm92IDEyOjU2IGxpYkdMdy5zbyAtPiBsaWJHTHcu c28uMQpscnd4cnd4cnd4IDEgc2Qgc2QgICAgICAxNSAgMS4gTm92IDEyOjU2IGxpYkdMdy5zby4x IC0+IGxpYkdMdy5zby4xLjAuMAotcnd4ci14ci14IDEgc2Qgc2QgICAzNzA0OCAgMS4gTm92IDEy OjU2IGxpYkdMdy5zby4xLjAuMAotcnctci0tci0tIDEgc2Qgc2QgICA3NjgwOCAgMS4gTm92IDEz OjAxIGxpYndheWxhbmQtY2xpZW50LmEKLXJ3eHIteHIteCAxIHNkIHNkICAgIDEwMTQgIDEuIE5v diAxMzowMSBsaWJ3YXlsYW5kLWNsaWVudC5sYQpscnd4cnd4cnd4IDEgc2Qgc2QgICAgICAyNiAg MS4gTm92IDEzOjAxIGxpYndheWxhbmQtY2xpZW50LnNvIC0+IGxpYndheWxhbmQtY2xpZW50LnNv LjAuMC4wCmxyd3hyd3hyd3ggMSBzZCBzZCAgICAgIDI2ICAxLiBOb3YgMTM6MDEgbGlid2F5bGFu ZC1jbGllbnQuc28uMCAtPiBsaWJ3YXlsYW5kLWNsaWVudC5zby4wLjAuMAotcnd4ci14ci14IDEg c2Qgc2QgICA2MDc5NyAgMS4gTm92IDEzOjAxIGxpYndheWxhbmQtY2xpZW50LnNvLjAuMC4wCi1y dy1yLS1yLS0gMSBzZCBzZCAgIDkyODUwICAxLiBOb3YgMTM6MDEgbGlid2F5bGFuZC1zZXJ2ZXIu YQotcnd4ci14ci14IDEgc2Qgc2QgICAgMTAxNCAgMS4gTm92IDEzOjAxIGxpYndheWxhbmQtc2Vy dmVyLmxhCmxyd3hyd3hyd3ggMSBzZCBzZCAgICAgIDI2ICAxLiBOb3YgMTM6MDEgbGlid2F5bGFu ZC1zZXJ2ZXIuc28gLT4gbGlid2F5bGFuZC1zZXJ2ZXIuc28uMC4wLjAKbHJ3eHJ3eHJ3eCAxIHNk IHNkICAgICAgMjYgIDEuIE5vdiAxMzowMSBsaWJ3YXlsYW5kLXNlcnZlci5zby4wIC0+IGxpYndh eWxhbmQtc2VydmVyLnNvLjAuMC4wCi1yd3hyLXhyLXggMSBzZCBzZCAgIDczNjEyICAxLiBOb3Yg MTM6MDEgbGlid2F5bGFuZC1zZXJ2ZXIuc28uMC4wLjAKLXJ3LXItLXItLSAxIHNkIHNkIDEwMjI1 MzYgIDEuIE5vdiAxMjo1NyBsaWJ4a2Jjb21tb24uYQotcnd4ci14ci14IDEgc2Qgc2QgICAgIDk3 MyAgMS4gTm92IDEyOjU3IGxpYnhrYmNvbW1vbi5sYQpscnd4cnd4cnd4IDEgc2Qgc2QgICAgICAy MSAgMS4gTm92IDEyOjU3IGxpYnhrYmNvbW1vbi5zbyAtPiBsaWJ4a2Jjb21tb24uc28uMC4wLjAK bHJ3eHJ3eHJ3eCAxIHNkIHNkICAgICAgMjEgIDEuIE5vdiAxMjo1NyBsaWJ4a2Jjb21tb24uc28u MCAtPiBsaWJ4a2Jjb21tb24uc28uMC4wLjAKLXJ3eHIteHIteCAxIHNkIHNkICA2OTUyODUgIDEu IE5vdiAxMjo1NyBsaWJ4a2Jjb21tb24uc28uMC4wLjAKZHJ3eHIteHIteCAyIHNkIHNkICAgIDQw OTYgIDEuIE5vdiAxMzowMCBwa2djb25maWcKCi9vcHQvd2F5bGFuZC9saWIvY2Fpcm86Cmluc2dl c2FtdCAyMzIKLXJ3eHIteHIteCAxIHNkIHNkICAgMTAwMCAgMS4gTm92IDEzOjAwIGxpYmNhaXJv LXRyYWNlLmxhCmxyd3hyd3hyd3ggMSBzZCBzZCAgICAgMjMgIDEuIE5vdiAxMzowMCBsaWJjYWly by10cmFjZS5zbyAtPiBsaWJjYWlyby10cmFjZS5zby4wLjAuMApscnd4cnd4cnd4IDEgc2Qgc2Qg ICAgIDIzICAxLiBOb3YgMTM6MDAgbGliY2Fpcm8tdHJhY2Uuc28uMCAtPiBsaWJjYWlyby10cmFj ZS5zby4wLjAuMAotcnd4ci14ci14IDEgc2Qgc2QgMjMwMzkyICAxLiBOb3YgMTM6MDAgbGliY2Fp cm8tdHJhY2Uuc28uMC4wLjAKCi9vcHQvd2F5bGFuZC9saWIvZHJpOgppbnNnZXNhbXQgMjcxMzYK LXJ3eHIteHIteCAxIHNkIHNkIDEyNzcxMjgxICAxLiBOb3YgMTI6NTYgc3dyYXN0X2RyaS5zbwot cnd4ci14ci14IDEgc2Qgc2QgMTUwMTIxODEgIDEuIE5vdiAxMjo1NiBzd3Jhc3RnX2RyaS5zbwoK L29wdC93YXlsYW5kL2xpYi9lZ2w6Cmluc2dlc2FtdCAxNzQyOAotcnd4ci14ci14IDEgc2Qgc2Qg ICAgNzU0OTUgIDEuIE5vdiAxMjo1NiBlZ2xfZHJpMi5zbwotcnd4ci14ci14IDEgc2Qgc2QgIDEx NzQ2ODMgIDEuIE5vdiAxMjo1NiBlZ2xfZ2FsbGl1bS5zbwotcnd4ci14ci14IDEgc2Qgc2QgICAg NDI3MDIgIDEuIE5vdiAxMjo1NiBlZ2xfZ2x4LnNvCi1yd3hyLXhyLXggMSBzZCBzZCAgMjk2MDQx MiAgMS4gTm92IDEyOjU2IHBpcGVfc3dyYXN0LnNvCi1yd3hyLXhyLXggMSBzZCBzZCAxMzU4MjM2 MCAgMS4gTm92IDEyOjU2IHN0X0dMLnNv --20cf30334dc1b6ea460493fe5b32-- From olvaffe at gmail.com Mon Nov 1 07:36:41 2010 From: olvaffe at gmail.com (Chia-I Wu) Date: Mon, 1 Nov 2010 22:36:41 +0800 Subject: Radeon tryouts: With and without gallium on RV250 In-Reply-To: References: Message-ID: On Mon, Nov 1, 2010 at 10:09 PM, Sedat Dilek wrote: > Hi, > > I have tried some more Wayland-testing on Radeon hardware and wanted > to let you know. > > [1] Disabled-Gallium: NOT working (see attachment) > > $ LC_ALL=C ; LIBGL_DRIVERS_PATH=/opt/wayland/lib/dri DISPLAY=:0.0 > ./compositor -b ../../backgrounds/dscn1843.jpg > failed to initialize display > Segmentation fault > > For Intel-GfxCards it is even recommended [1]: > > "If you're using an intel chipset, it's best to also pass > --disable-gallium to ./configure, since otherwise libEGL will try to > load the gallium sw rasterizer before loading the Intel DRI driver." > > > [2] With Dirty-Hack to recognize Chip-ID: NOT working (patch attached) > > Workaround try for the following error-messages: > > $ LC_ALL=C ; LIBGL_DRIVERS_PATH=/opt/wayland/lib/dri DISPLAY=:0.0 ./compositor > r300: Warning: Unknown chipset 0x4c66 > radeon: The kernel rejected CS, see dmesg for more information. > > > [ src/gallium/state_trackers/egl/drm/native_drm.c ] > ... > - ? ? ?name = is_r3xx(chip_id) ? "r300" : "r600"; > + ? ? ?name = "r200"; > ... > > Thanks Alex Deucher for pointing me to commit "st/egl: Fix r300/r600 > support in KMS backend." (see [2]) and giving help on IRC. > > [3] Enabled swrast-gallium and Disabled radeon-gallium: NOT working > (see attachment) > > I was wrong in [3], it is possible to have swrast-gallium-only build. > > ./autogen.sh --prefix=/opt/wayland --with-driver=dri > --with-dri-driverdir=/opt/wayland/lib/dri --with-dri-drivers=swrast > --disable-gallium-radeon --enable-gallium-swrast > --with-state-trackers=dri,glx,egl --enable-egl --enable-gles2 > > $ LC_ALL=C ; LIBGL_DRIVERS_PATH=/opt/wayland/lib/dri DISPLAY=:0.0 > ./compositor -b ../../backgrounds/dscn1843.jpg > libEGL warning: failed to create DRM screen > failed to initialize display > Segmentation fault > > [4] Conclusion? > > From #radeon/freenode (01-Nov-2010, German Local-Time UTC+1): > ... > [14:22:51] dileks: I dunno. ?hopefully someone on the wayland > list can help > [14:23:27] I guess I have wayland-incompatible hardware > [14:23:48] thats a hard but fair conclusion > [14:24:22] dileks: it's a software problem. ?I suspect you'd > hit similar issues with other radeons. > [14:24:39] I don't think anyone has actually tried to use > wayland on AMD hw yet > [14:27:22] then I am pioneer in testing - I like this > conclusion as well :-) > > User nanonyme gave the hint on #radeon to see problems on r600c > (classic-mesa driver). > > I can't track these problems by my own, in my very first mail to this > ML I asked for debugging help [4]. > > I wrote about some improvements on the "building" website [1], some > informations are outdated or wrong. > All krh/wayland stuff has moved from his own repos to public ones, for example. > New wayland repo is listed here [5]. > OLD: git clone git://people.freedesktop.org/~krh/wayland > NEW: git://anongit.freedesktop.org/wayland > > No changes yet, I hope they follow. For r200c to work, as mentioned on Wayland list, you need to make sure you can enable API_OPENGLES2 bit, and support for __DRI_IMAGE extension should be added. As for swrast, it requires more changes to work. First, egl_dri2 needs to support loading swrast DRI modules. Then Wayland clients should be modified to use shm_buffer interface instead of drm_buffer interface. There could be some more that I am missing. > > Kind Regards, > - Sedat - > > > [1] http://wayland.freedesktop.org/building.html > [2] http://cgit.freedesktop.org/mesa/mesa/commit/?id=1288d5c39234e7c54ae2fbb81dd788c98c62a7b3 > [3] http://lists.freedesktop.org/archives/wayland-devel/2010-November/000020.html > [4] http://lists.freedesktop.org/archives/wayland-devel/2010-October/000002.html > [5] http://cgit.freedesktop.org/wayland/ > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > -- olv at LunarG.com From clurado1980 at gmail.com Mon Nov 1 12:49:57 2010 From: clurado1980 at gmail.com (Clurado cl) Date: Mon, 1 Nov 2010 23:19:57 +0330 Subject: Failed to create Context Message-ID: Hi , i compiled latest libdrm mesa ( --with-dri-drivers=i915 --with-egl-platforms=drm,x11 --with-state-trackers=egl --enable-gles2 --enable-gles-overlay --enable-gallium-intel --disable-gallium-radeon --disable-gallium-svga ) libxkbcommon -> ~krh cairo ( --enable-gl=yes ) copy udev rules and run trigger command export EGL_LOG_LEVEL=debug export EGL_DRIVER=/usr/lib/egl/egl_dri2.so export EGL_PLATFORM=drm all installed in /usr/lib and there isnt any other compiled wayland -- when i run the compositor under X i got the following messages ./compositor -b 1.jpg libEGL dlopen(/usr/lib/egl/egl_dri2.so) libEGL pci id for 5: 8086:3582, driver i915 libEGL DRI2 dlopen(/usr/lib/dri/i915_dri.so) libEGL DRI2 forund extension DRI_CORE libEGL DRI2 forund extension DRI_CORE version 1 libEGL DRI2 forund extension DRI_DRI2 libEGL DRI2 forund extension DRI_DRI2 version 2 libEGL DRI2 forund extension DRI_ReadDrawable libEGL DRI2 forund extension DRI_texBuffer libEGL DRI2 forund extension DRI_texBuffer version 2 libEGL DRI2 forund extension DRI2_Flush libEGL DRI2 forund extension DRI2_Flush version 3 libEGL DRI2 forund extension DRI_IMAGE libEGL DRI2 forund extension DRI_IMAGE version 4 libEGL DRI2 forund extension DRI_CONFIG_QUERY libEGL the best driver is DRI2 ( score 100 ) failed to create context than i see a blank window without crusor libEGL DRI2 forund extension DRI_CORE --- so whats wrong guys ?! is that anything i forgot ?! i able to run xegl demos from mesa but i am not able to run others . when i stopping x and run wayland outside the x i see those messages plus : failed to initialize egl failed to create compositor i am confused ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From clurado1980 at gmail.com Mon Nov 1 13:48:38 2010 From: clurado1980 at gmail.com (Clurado cl) Date: Tue, 2 Nov 2010 00:18:38 +0330 Subject: Failed to create Context Message-ID: these are the errors : linux-fqw5:/d/driogl/wayland/wayland-master/compositor # ./compositor -b 1.jpg libEGL debug: added /usr/local/lib/egl/egl_dri2.so to module array libEGL debug: added /usr/local/lib/egl/egl_gallium.so to module array libEGL debug: added /usr/local/lib/egl/egl_glx.so to module array libEGL debug: dlopen(/usr/local/lib/egl/egl_dri2.so) libEGL debug: pci id for 5: 8086:3582, driver i915 libEGL debug: DRI2: dlopen(/usr/local/lib/dri//i915_dri.so) libEGL debug: DRI2: found extension `DRI_Core' libEGL info: DRI2: found extension DRI_Core version 1 libEGL debug: DRI2: found extension `DRI_DRI2' libEGL info: DRI2: found extension DRI_DRI2 version 2 libEGL debug: DRI2: found extension `DRI_ReadDrawable' libEGL debug: DRI2: found extension `DRI_TexBuffer' libEGL info: DRI2: found extension DRI_TexBuffer version 2 libEGL debug: DRI2: found extension `DRI2_Flush' libEGL info: DRI2: found extension DRI2_Flush version 3 libEGL debug: DRI2: found extension `DRI_IMAGE' libEGL info: DRI2: found extension DRI_IMAGE version 1 libEGL debug: DRI2: found extension `DRI_CONFIG_QUERY' libEGL debug: the best driver is DRI2 (score 100) failed to create context disconnect from client 0x8069210 disconnect from client 0x8069210 disconnect from client 0x8069210 -------------- next part -------------- An HTML attachment was scrubbed... URL: From krh at bitplanet.net Tue Nov 2 06:36:33 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Tue, 2 Nov 2010 09:36:33 -0400 Subject: Failed to create Context In-Reply-To: References: Message-ID: On Mon, Nov 1, 2010 at 4:48 PM, Clurado cl wrote: > these are the errors : > > ?linux-fqw5:/d/driogl/wayland/wayland-master/compositor # ./compositor -b > 1.jpg [snip] We talked about this in irc and you're trying to run wayland on a Intel 855, which isn't going to work. The example wayland compositor uses GLES2 which is all shader based, so 855 wont be able to run this. Kristian From bluescreen_avenger at verizon.net Wed Nov 3 19:14:16 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Wed, 03 Nov 2010 22:14:16 -0400 Subject: Please Don't Use Cleint Side Window Decorations Message-ID: <201011032214.17126.bluescreen_avenger@verizon.net> Seeing how the old mailing list is going to soon be shut down, I wanted to continue this discussion here. The latest information that I know about if Client Side Decorations will actually be used, is that it still has to be decided. I hope that you choose to not use Client Side window decorations, and here are a few reasons why: First, there is a good list here why client side window decorations should not be used: http://www.google.com/url?sa=D&q=http://blog.martin- graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window- decorations/&usg=AFQjCNHGkwQHTa1YkBLEVn3P_PF53KhEdA As I understand, you lose lots of customisation, such as special buttons to put on the windows (like window shade), changing the order of the buttons, or the appearance on the titlebars because now you are relying on the apps to provide them (and could result in different titlebars between QT/GTK apps). Not only that, but I think even window movement could be inconsistant, (such as edge resistance) because you are relying on the app to provide window movement. Could multple virtual desktops even be supported? What will manage effects like window wobbliness? These features are what many Linux/Unix users are now spoiled by, and IMHO make window managment better then Windows, Client side window decorations also leave windowing "exposed" to glitchy apps or other problems. From what I can tell in Windows (that has client side window decorations) when an app freezes, its windows will be unable to move, unless a workaround is implanted (which you can see in Windows), and in Windows a modal window (like a progress window) prevents its parent window from moving. Lastly, with server side window managment, I think thats how XPRA http://en.wikipedia.org/wiki/Xpra is able to export apps windows, rootless on a remote display. In the other mailing list, someone suggested that this type of approach could be used to support something similar to ssh -X with wayland. seeing that XPRA relies on its own virual window manager, I don't know if this would be doable if it was cleint side. Sorry for the length. I don't mean to be overly critical with this, I just wanted to bring these issues into consideration, before its too late. From mostawesomedude at gmail.com Thu Nov 4 01:39:12 2010 From: mostawesomedude at gmail.com (Corbin Simpson) Date: Thu, 4 Nov 2010 01:39:12 -0700 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: <201011032214.17126.bluescreen_avenger@verizon.net> References: <201011032214.17126.bluescreen_avenger@verizon.net> Message-ID: On Wed, Nov 3, 2010 at 7:14 PM, nerdopolis wrote: > Seeing how the old mailing list is going to soon be shut down, I > wanted to continue this discussion here. > > The latest information that I know about if Client Side > Decorations will actually be used, is that it still has to be > decided. > > I hope that you choose to not use Client Side window decorations, and here are > a few reasons why: > > First, there is a good list here why client side window decorations should not > be used: http://www.google.com/url?sa=D&q=http://blog.martin- > graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window- > decorations/&usg=AFQjCNHGkwQHTa1YkBLEVn3P_PF53KhEdA > > As I understand, you lose lots of customisation, such as special buttons to > put on the windows (like window shade), changing the order of the buttons, or > the appearance on the titlebars because now you are relying on the apps to > provide them (and could result in different titlebars between QT/GTK apps). > > Not only that, but I think even window movement could be inconsistant, (such > as edge resistance) because you are relying on the app to provide window > movement. Could multple virtual desktops even be supported? What will manage > effects like window wobbliness? > > These features are what many Linux/Unix users are now spoiled by, and IMHO > make window managment better then Windows, > > Client side window decorations also leave windowing "exposed" to glitchy apps > or other problems. From what I can tell in Windows (that has client side > window decorations) when an app freezes, its windows will be unable to move, > unless a workaround is implanted (which you can see in Windows), and in > Windows a modal window (like a progress window) prevents its parent window > from moving. > > Lastly, with server side window managment, I think thats how XPRA > http://en.wikipedia.org/wiki/Xpra is able to export apps windows, rootless on > a remote display. In the other mailing list, someone suggested that this type > of approach could be used to support something similar to ssh -X with wayland. > seeing that XPRA relies on its own virual window manager, I don't know if this > would be doable if it was cleint side. > > Sorry for the length. I don't mean to be overly critical with this, I just > wanted to bring these issues into consideration, before its too late. I think that you don't really get the point of Wayland. As I said before, one could definitely build a Wayland-based compositor that draws its own decorations instead of having its clients do it. There's no reason that it must be one way or the other. Additionally, Wayland doesn't have remote rendering because that would defeat the entire purpose of being direct-rendered. If you want network transparency, keep using X -- it's not like X is being abandoned or deprecated. One can also run X *inside* of Wayland. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson From justinlee5455 at gmail.com Thu Nov 4 04:22:37 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Thu, 4 Nov 2010 19:22:37 +0800 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: <201011032214.17126.bluescreen_avenger@verizon.net> References: <201011032214.17126.bluescreen_avenger@verizon.net> Message-ID: 2010/11/4 nerdopolis : > I hope that you choose to not use Client Side window decorations, and here are > a few reasons why: > > As I understand, you lose lots of customisation, such as special buttons to > put on the windows (like window shade), changing the order of the buttons, or > the appearance on the titlebars because now you are relying on the apps to > provide them (and could result in different titlebars between QT/GTK apps). In considering consistent look and feel issue of window decorations due to client-side window decoration, maybe we shouldn't let the toolkit (Qt/GTK) render decorations nor let the app render its decoration directly. Rather, there should be a separate, independent library (may be called libWinDeco) dedicated to render window decorations. Whenever an app needs to render its decoration, it calls libWinDeco to help the job. Then this becomes a programming convention/protocol to each Wayland app that Wayland app should use libWinDeco to render decoration by default (unless the app want to be maverick, it can disregard the convention and render its decoration by itself directly). If all Wayland apps follow the convention, they will have consistent look and feel of window decorations as all the decorations are rendered by the same code, i.e. libWinDeco. By this way, highly customizable window appearances are still possible if libWinDeco is designed to be configurable. Where 'configurable' means behaviors of libWinDeco are controlled by a single, universal, system-wide config file (which specifies button attributes, title bar appearances etc.). > Client side window decorations also leave windowing "exposed" to glitchy apps > or other problems. From what I can tell in Windows (that has client side > window decorations) when an app freezes, its windows will be unable to move, > unless a workaround is implanted (which you can see in Windows), and in > Windows a modal window (like a progress window) prevents its parent window > from moving. libWinDeco should be designed to be easy to use in order to make programmers willing to follow the convention therefore glitchy apps become rare. According to "Open Letter: The issues with client-side-window-decorations" (http://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window-decorations/): > Closing hung applications: Currently there is an easy way to close a hung application. > You click the close button in the decoration and the window manager will notice that > the application does not response any more and will offer to forcefully close the > window. With client-side window decoration this is impossible. The close button is > part of the hung application > and so the click event cannot be recognized. I do not expect users to know shortcuts > like ctrl+alt+esc to forcefully close a window and so they will be stuck with an > unresponsive application. In case the application is caught in an endless loop this > would render the system unusable and an unexperienced user has only one choice: > force the system to reboot by the power switch. With client-side window decoration and libWinDeco, I think it's possible. Because libWinDeco as a library can do almost anything, including forking processes and creating threads. libWinDeco can create an UI thread which is only responsible for handling UI events such as closing window, moving window etc. and user's code should be run in another worker thread. So even if user's code hangs, the UI thread is still running and able to handle closing event then forcibly terminate the app. From lallenlowe at gmail.com Thu Nov 4 14:31:54 2010 From: lallenlowe at gmail.com (Allen Lowe) Date: Thu, 04 Nov 2010 15:31:54 -0600 Subject: Mark's announcement Message-ID: <1288906314.30555.1.camel@allen-work-desktop> I am so stoked, this is what I have been dreaming of! http://www.markshuttleworth.com/archives/551 Allen Lowe -- Sent from Ubuntu -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mostawesomedude at gmail.com Thu Nov 4 15:50:46 2010 From: mostawesomedude at gmail.com (Corbin Simpson) Date: Thu, 4 Nov 2010 15:50:46 -0700 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: <201011041847.08482.bluescreen_avenger@verizon.net> References: <201011032214.17126.bluescreen_avenger@verizon.net> <201011041847.08482.bluescreen_avenger@verizon.net> Message-ID: On Thu, Nov 4, 2010 at 3:47 PM, nerdopolis wrote: > XPRA AFAIK is not remotely rendering the apps. I think they are rendered > locally, and then the window is exported to a remote display. I know X can > still run as a Wayland client, but what if someone needs to run an app that > runs on Wayland remotely? > You can't. Run it in X instead. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson From bluescreen_avenger at verizon.net Thu Nov 4 15:47:08 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Thu, 04 Nov 2010 18:47:08 -0400 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: References: <201011032214.17126.bluescreen_avenger@verizon.net> Message-ID: <201011041847.08482.bluescreen_avenger@verizon.net> On Thursday, November 04, 2010 04:39:12 am Corbin Simpson wrote: > On Wed, Nov 3, 2010 at 7:14 PM, nerdopolis > > wrote: > > Seeing how the old mailing list is going to soon be shut down, I > > wanted to continue this discussion here. > > > > The latest information that I know about if Client Side > > Decorations will actually be used, is that it still has to be > > decided. > > > > I hope that you choose to not use Client Side window decorations, and > > here are a few reasons why: > > > > First, there is a good list here why client side window decorations > > should not be used: http://www.google.com/url?sa=D&q=http://blog.martin- > > graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window > > - decorations/&usg=AFQjCNHGkwQHTa1YkBLEVn3P_PF53KhEdA > > > > As I understand, you lose lots of customisation, such as special buttons > > to put on the windows (like window shade), changing the order of the > > buttons, or the appearance on the titlebars because now you are relying > > on the apps to provide them (and could result in different titlebars > > between QT/GTK apps). > > > > Not only that, but I think even window movement could be inconsistant, > > (such as edge resistance) because you are relying on the app to provide > > window movement. Could multple virtual desktops even be supported? What > > will manage effects like window wobbliness? > > > > These features are what many Linux/Unix users are now spoiled by, and > > IMHO make window managment better then Windows, > > > > Client side window decorations also leave windowing "exposed" to glitchy > > apps or other problems. From what I can tell in Windows (that has client > > side window decorations) when an app freezes, its windows will be unable > > to move, unless a workaround is implanted (which you can see in > > Windows), and in Windows a modal window (like a progress window) > > prevents its parent window from moving. > > > > Lastly, with server side window managment, I think thats how XPRA > > http://en.wikipedia.org/wiki/Xpra is able to export apps windows, > > rootless on a remote display. In the other mailing list, someone > > suggested that this type of approach could be used to support something > > similar to ssh -X with wayland. seeing that XPRA relies on its own > > virual window manager, I don't know if this would be doable if it was > > cleint side. > > > > Sorry for the length. I don't mean to be overly critical with this, I > > just wanted to bring these issues into consideration, before its too > > late. > > I think that you don't really get the point of Wayland. As I said > before, one could definitely build a Wayland-based compositor that > draws its own decorations instead of having its clients do it. There's > no reason that it must be one way or the other. > But if the apps are programmed to draw their window decoration on one Wayland compositor, how will they "know" to not draw them with compositors that are already drawing server side ones? > Additionally, Wayland doesn't have remote rendering because that would > defeat the entire purpose of being direct-rendered. If you want > network transparency, keep using X -- it's not like X is being > abandoned or deprecated. One can also run X *inside* of Wayland. XPRA AFAIK is not remotely rendering the apps. I think they are rendered locally, and then the window is exported to a remote display. I know X can still run as a Wayland client, but what if someone needs to run an app that runs on Wayland remotely? From justinlee5455 at gmail.com Thu Nov 4 17:47:30 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Fri, 5 Nov 2010 08:47:30 +0800 Subject: Mark's announcement In-Reply-To: <1288906314.30555.1.camel@allen-work-desktop> References: <1288906314.30555.1.camel@allen-work-desktop> Message-ID: Great news! Also noticed someone has updated the Wayland article in Wikipedia. 2010/11/5 Allen Lowe : > I am so stoked, this is what I have been dreaming of! > > http://www.markshuttleworth.com/archives/551 > > Allen Lowe > -- > Sent from Ubuntu > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > From xiaoxiaomuyusajiangtian at gmail.com Fri Nov 5 01:22:28 2010 From: xiaoxiaomuyusajiangtian at gmail.com (Arthur Zhu) Date: Fri, 5 Nov 2010 16:22:28 +0800 Subject: How to debug wayland? Message-ID: Hi, everyone: configure.ac have -g option for GCC_CFLAGS, but it seems to do nothing. Cheers, Arthur -------------- next part -------------- An HTML attachment was scrubbed... URL: From luke.hutch at mit.edu Fri Nov 5 11:07:53 2010 From: luke.hutch at mit.edu (Luke Hutchison) Date: Fri, 5 Nov 2010 14:07:53 -0400 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: References: <201011032214.17126.bluescreen_avenger@verizon.net> <201011041847.08482.bluescreen_avenger@verizon.net> Message-ID: On Thu, Nov 4, 2010 at 6:50 PM, Corbin Simpson wrote: > On Thu, Nov 4, 2010 at 3:47 PM, nerdopolis? wrote: > > I know X can?still run as a Wayland client, but what if someone > >?needs to run an app that?runs on Wayland remotely? > > You can't. Run it in X instead. Based on the architectural overview on the new Wayland website, it seems that VNC/NX/SPICE could be made to work with Wayland. Are there technical reasons why this would be difficult? From krh at bitplanet.net Fri Nov 5 12:21:48 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Fri, 5 Nov 2010 15:21:48 -0400 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: References: <201011032214.17126.bluescreen_avenger@verizon.net> <201011041847.08482.bluescreen_avenger@verizon.net> Message-ID: On Fri, Nov 5, 2010 at 2:07 PM, Luke Hutchison wrote: > On Thu, Nov 4, 2010 at 6:50 PM, Corbin Simpson > wrote: >> On Thu, Nov 4, 2010 at 3:47 PM, nerdopolis? wrote: >> > I know X can?still run as a Wayland client, but what if someone >> >?needs to run an app that?runs on Wayland remotely? >> >> You can't. Run it in X instead. > > Based on the architectural overview on the new Wayland website, it > seems that VNC/NX/SPICE could be made to work with Wayland. ?Are there > technical reasons why this would be difficult? No, you're right, that's an option, just not a priority right now. Kristian From mars at montik.net Fri Nov 5 12:16:09 2010 From: mars at montik.net (Martin Sivak) Date: Fri, 5 Nov 2010 20:16:09 +0100 Subject: Remote apps idea (without changing the underlying concept) Message-ID: <6C242A93-CFA7-40A0-A567-74EC56EE7F72@montik.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, If I understood the discussions correctly, there will be no underlying X or the "window manager". Instead the compositor process (linked against common wayland library) will be doing all client and window management and work with hardware directly through kernel. The clients will then render directly to provided/created buffer and exchange damage and input events with the compositor. I hope I got this right, there is a lot of confusing info around. Now to my idea: So the equivalent of ssh -X, which people are asking for, should be possible using the following approach. And it would only require that any wayland app can be pointed to different local compositor (like we do in X world with -display or $DISPLAY). Anyone would then be able to write "network compositor client" which would act as a compositor, but use only in-memory buffers (and probably stores the opengl commands). It would then be able to compress (maybe) the bitmap from the application and sent it over network using any suitable protocol and it would of course return all received input events back to the application. On the remote side would be a "network compositor daemon" which would present itself as a regular client app to the compositor running on the remote machine. It would claim ownership of all windows of all apps running through it (and allocate all the necessary buffers) and forward all buffer changes to compositor and input events back over network to the client. Basicly, it would be "VNC" with different buffer for each remote app. It would require a pair of relatively simple daemons to do the bitmap and event transfer (much like NX does) and would be completely transparent to the wayland approach and IMHO goals too. But of course only if I got the idea right. What lot of people are afraid of it that when Ubuntu adopts Wayland as a main display system and wayland-only apps start appearing, we would lose the ability to run apps remotely, because nobody will be maintaining non-wayland toolkit variants anymore. If the approach I described is possible, it would be great and actually make things much simplier (even writing xlib replacement which renders localy and acts as a wayland client). - -- Martin Sivak mars at montik.net -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) iEYEARECAAYFAkzUV/0ACgkQLtuY88yhq1x5rACeMfe4s29/WggT7+bIeMr/RslF LCcAniM8p2QVaIe9KGv3OnZxOZXv9dIR =eQ6V -----END PGP SIGNATURE----- From krh at bitplanet.net Fri Nov 5 12:58:16 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Fri, 5 Nov 2010 15:58:16 -0400 Subject: Remote apps idea (without changing the underlying concept) In-Reply-To: <6C242A93-CFA7-40A0-A567-74EC56EE7F72@montik.net> References: <6C242A93-CFA7-40A0-A567-74EC56EE7F72@montik.net> Message-ID: On Fri, Nov 5, 2010 at 3:16 PM, Martin Sivak wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > If I understood the discussions correctly, there will be no underlying X ?or the "window manager". Instead the compositor process (linked against common wayland library) will be doing all client and window management and work with hardware directly through kernel. > > The clients will then render directly to provided/created buffer and exchange damage and input events with the compositor. > > I hope I got this right, there is a lot of confusing info around. > > Now to my idea: > > So the equivalent of ssh -X, which people are asking for, should be possible using the following approach. And it would only require that any wayland app can be pointed to different local compositor (like we do in X world with -display or $DISPLAY). > > Anyone would then be able to write "network compositor client" which would act as a compositor, but use only in-memory buffers (and probably stores the opengl commands). It would then be able to compress (maybe) the bitmap from the application and sent it over network using any suitable protocol and it would of course return all received input events back to the application. > > On the remote side would be a "network compositor daemon" which would present itself as a regular client app to the compositor running on the remote machine. It would claim ownership of all windows of all apps running through it (and allocate all the necessary buffers) and forward all buffer changes to compositor and input events back over network to the client. > > Basicly, it would be "VNC" with different buffer for each remote app. It would require a pair of relatively simple daemons to do the bitmap and event transfer (much like NX does) and would be completely transparent to the wayland approach and IMHO goals too. > > But of course only if I got the idea right. Yeah, that's the general idea. RDP Seamless in particular lets your forward individual windows as far as I know. You could do it as a separate "network compositor" or you could build it into the regular desktop compositor, which would let you select an existing window and forward it over rdp. Kristian From krh at bitplanet.net Fri Nov 5 13:00:46 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Fri, 5 Nov 2010 16:00:46 -0400 Subject: How to debug wayland? In-Reply-To: References: Message-ID: On Fri, Nov 5, 2010 at 4:22 AM, Arthur Zhu wrote: > Hi, everyone: > > configure.ac have -g option for GCC_CFLAGS, but it seems to do nothing. What's the problem? gdb works fine for me, but since the change to automake, you'll need to run it with libtool: $ libtool --mode=execute gdb compositor The X compositor is easy to debug, but if you're trying to track down a problem in the kms compositor, you'll probably need two laptops. Kristian From bluescreen_avenger at verizon.net Fri Nov 5 20:57:15 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Fri, 05 Nov 2010 23:57:15 -0400 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: References: <201011032214.17126.bluescreen_avenger@verizon.net> Message-ID: <201011052357.16589.bluescreen_avenger@verizon.net> On Friday, November 05, 2010 03:21:48 pm Kristian H?gsberg wrote: > On Fri, Nov 5, 2010 at 2:07 PM, Luke Hutchison wrote: > > On Thu, Nov 4, 2010 at 6:50 PM, Corbin Simpson > > > > wrote: > >> On Thu, Nov 4, 2010 at 3:47 PM, nerdopolis wrote: > >> > I know X can still run as a Wayland client, but what if someone > >> > > >> > needs to run an app that runs on Wayland remotely? > >> > >> You can't. Run it in X instead. > > > > Based on the architectural overview on the new Wayland website, it > > seems that VNC/NX/SPICE could be made to work with Wayland. Are there > > technical reasons why this would be difficult? > > No, you're right, that's an option, just not a priority right now. > > Kristian OK. Thats a releif that remote apps are possible with Wayland! I have one more question: How do you plan to handle titlebars, and window placement, and stuff like that? is it done by the apps, or is it done by the display server? From justinlee5455 at gmail.com Sat Nov 6 01:12:09 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Sat, 6 Nov 2010 16:12:09 +0800 Subject: Fw: Is this list dead now? Message-ID: Kristian H?gsberg wrote: >> Since wayland development has moved to freedesktop? > > Yes the list is dead and I'll shut down the google group in a week. > Kristian Hopefully, Wayland group is still viewable to after it's shut down. As far as I know group stuff has not been moved to freedesktop.org, but there are many external links in Wikipedia refer to the group. Besides, the discussions in the group more or less reflect the history of Wayland and there are many valuable ideas to me in it. From justinlee5455 at gmail.com Sat Nov 6 02:03:36 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Sat, 6 Nov 2010 17:03:36 +0800 Subject: Remote apps idea (without changing the underlying concept) In-Reply-To: References: <6C242A93-CFA7-40A0-A567-74EC56EE7F72@montik.net> Message-ID: 2010/11/6 Kristian H?gsberg : > On Fri, Nov 5, 2010 at 3:16 PM, Martin Sivak wrote: > Yeah, that's the general idea. ?RDP Seamless in particular lets your > forward individual windows as far as I know. ?You could do it as a > separate "network compositor" or you could build it into the regular > desktop compositor, which would let you select an existing window and > forward it over rdp. microsoft's Remote Desktop Protocol performs Bitmap Caching while forwarding desktop. Which reduces network traffic and speeds up the transfer a lot over a slow connection. Wayland may benefit by this kind of optimizations if it adopts RDP. (don't know if X protocol has such kind of caching) From someuniquename at gmail.com Sat Nov 6 02:20:23 2010 From: someuniquename at gmail.com (Roman Evstifeev) Date: Sat, 6 Nov 2010 12:20:23 +0300 Subject: Remote apps idea (without changing the underlying concept) In-Reply-To: References: <6C242A93-CFA7-40A0-A567-74EC56EE7F72@montik.net> Message-ID: 2010/11/6 Justin Lee : > 2010/11/6 Kristian H?gsberg : >> On Fri, Nov 5, 2010 at 3:16 PM, Martin Sivak wrote: >> Yeah, that's the general idea. ?RDP Seamless in particular lets your >> forward individual windows as far as I know. ?You could do it as a >> separate "network compositor" or you could build it into the regular >> desktop compositor, which would let you select an existing window and >> forward it over rdp. > > microsoft's Remote Desktop Protocol performs Bitmap Caching > > while forwarding desktop. Which reduces network traffic and speeds up > the transfer a lot over a slow connection. Wayland may benefit by this > kind of optimizations if it adopts RDP. (don't know if X protocol has > such kind of caching) http://www.microsoft.com/about/legal/en/us/IntellectualProperty/IPLicensing/Programs/RemoteDesktopProtocol.aspx?pf=true "Microsoft offers a patent license for the RDP protocol set." I have a feeling, that once wayland hit mobile market (or something in microsoft's interest) those patents will join the threat pool. > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From justinlee5455 at gmail.com Sat Nov 6 02:36:22 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Sat, 6 Nov 2010 17:36:22 +0800 Subject: Remote apps idea (without changing the underlying concept) In-Reply-To: References: <6C242A93-CFA7-40A0-A567-74EC56EE7F72@montik.net> Message-ID: 2010/11/6 Roman Evstifeev : > 2010/11/6 Justin Lee : >> 2010/11/6 Kristian H?gsberg : >>> On Fri, Nov 5, 2010 at 3:16 PM, Martin Sivak wrote: >>> Yeah, that's the general idea. ?RDP Seamless in particular lets your >>> forward individual windows as far as I know. ?You could do it as a >>> separate "network compositor" or you could build it into the regular >>> desktop compositor, which would let you select an existing window and >>> forward it over rdp. >> >> microsoft's Remote Desktop Protocol performs Bitmap Caching >> >> while forwarding desktop. Which reduces network traffic and speeds up >> the transfer a lot over a slow connection. Wayland may benefit by this >> kind of optimizations if it adopts RDP. (don't know if X protocol has >> such kind of caching) > > http://www.microsoft.com/about/legal/en/us/IntellectualProperty/IPLicensing/Programs/RemoteDesktopProtocol.aspx?pf=true > "Microsoft offers a patent license for the RDP protocol set." > I have a feeling, that once wayland hit mobile market (or something in > microsoft's interest) those patents will join the threat pool. > >> _______________________________________________ >> wayland-devel mailing list >> wayland-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > sounds bad we should find other comparable solutions and don't even give MS a chance From canbaby at 21cn.com Sat Nov 6 03:47:00 2010 From: canbaby at 21cn.com (canbaby) Date: Sat, 06 Nov 2010 18:47:00 +0800 Subject: wayland build failed Message-ID: <4CD53224.2080604@21cn.com> Hi: I'm new to wayland, I do git clone from repo, and configure and build, I got these error message: == make all-recursive make[1]: Entering directory `/media/sda6/softrepo/freedesktop/wayland' Making all in wayland make[2]: Entering directory `/media/sda6/softrepo/freedesktop/wayland/wayland' make all-am make[3]: Entering directory `/media/sda6/softrepo/freedesktop/wayland/wayland' CC wayland-server.lo wayland-server.c:343: error: variable ?display_interface? has initializer but incomplete type wayland-server.c:344: warning: excess elements in struct initializer wayland-server.c:344: warning: (near initialization for ?display_interface?) wayland-server.c:346: warning: excess elements in struct initializer wayland-server.c:346: warning: (near initialization for ?display_interface?) make[3]: *** [wayland-server.lo] Error 1 make[3]: Leaving directory `/media/sda6/softrepo/freedesktop/wayland/wayland' make[2]: *** [all] Error 2 make[2]: Leaving directory `/media/sda6/softrepo/freedesktop/wayland/wayland' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/media/sda6/softrepo/freedesktop/wayland' make: *** [all] Error 2 == I think the reason is in wayland/wayland-server-protocol.h, extern const struct wl_interface wl_display_interface; and struct wl_display_interface {...} Which had double define wl_display_interface, one as var and one as type, which confuse my gcc(verson 4.4.5), should there be a option to let gcc distinction them? Or something else wrong, or the scanner? Best Regards! -- wucan From airlied at gmail.com Sat Nov 6 08:02:49 2010 From: airlied at gmail.com (Dave Airlie) Date: Sun, 7 Nov 2010 01:02:49 +1000 Subject: jhbuild scripts Message-ID: Just some jhbuild scripts I hacked up locally to build wayland on Fedora 14, The moduleset is fairly small, it builds kbproto libxkbcommon libdrm mesa cairo wayland. Dave. -------------- next part -------------- A non-text attachment was scrubbed... Name: wayland.modules Type: application/octet-stream Size: 2116 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wayland.jhbuildrc Type: application/octet-stream Size: 1050 bytes Desc: not available URL: From jjardon at gnome.org Sat Nov 6 10:11:29 2010 From: jjardon at gnome.org (=?UTF-8?Q?Javier_Jard=C3=B3n?=) Date: Sat, 6 Nov 2010 18:11:29 +0100 Subject: [patch] Update autotools configuration Message-ID: Hello, Here a little patch to use the new libtool syntax and cleaning the code a bit Regards, -- Javier Jard?n Cabezas -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-autotools-configuration.patch Type: application/octet-stream Size: 1897 bytes Desc: not available URL: From Darxus at chaosreigns.com Sat Nov 6 11:48:10 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sat, 6 Nov 2010 14:48:10 -0400 Subject: configure failed on Ubuntu Maverick Message-ID: <20101106184810.GJ13517@chaosreigns.com> Mesa building instructions are wrong, it uses autogen.sh, not configure. While building wayland with shtool in the path: configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.." (I fixed it with a simlink, but that should be fixed properly.) And then building wayland failed: darxus at dancer:~/wayland$ git clone git://people.freedesktop.org/~krh/wayland (works) darxus at dancer:~/wayland$ cd wayland/ darxus at dancer:~/wayland/wayland$ ls autogen.sh clients compositor configure.ac data m4 Makefile.am protocol README spec TODO wayland darxus at dancer:~/wayland/wayland$ aclocal; autoconf; ./configure --prefix=$HOME/install checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /bin/bash: /home/darxus/wayland/missing: No such file or directory configure: WARNING: `missing' script is too old or missing checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... none configure: error: cannot run /bin/bash ./../config.sub -- "You will need: a big heavy rock, something with a bit of a swing to it... perhaps Mars" - http://ned.ucam.org/~sdh31/misc/destroy.html http://www.ChaosReigns.com From Darxus at chaosreigns.com Sat Nov 6 11:51:26 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sat, 6 Nov 2010 14:51:26 -0400 Subject: configure failed on Ubuntu Maverick In-Reply-To: <20101106184810.GJ13517@chaosreigns.com> References: <20101106184810.GJ13517@chaosreigns.com> Message-ID: <20101106185126.GK13517@chaosreigns.com> "automake --add-missing" got me past that. On 11/06, Darxus at chaosreigns.com wrote: > darxus at dancer:~/wayland/wayland$ aclocal; autoconf; ./configure --prefix=$HOME/install > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > /bin/bash: /home/darxus/wayland/missing: No such file or directory > configure: WARNING: `missing' script is too old or missing -- "He who dies with the most toys... still dies." - No Fear http://www.ChaosReigns.com From Darxus at chaosreigns.com Sat Nov 6 12:07:15 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sat, 6 Nov 2010 15:07:15 -0400 Subject: configure failed on Ubuntu Maverick In-Reply-To: <20101106185126.GK13517@chaosreigns.com> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> Message-ID: <20101106190715.GL13517@chaosreigns.com> On 11/06, Darxus at chaosreigns.com wrote: > "automake --add-missing" got me past that. When I run that I get: $ aclocal; autoconf; ./configure --prefix=$HOME/install ... /bin/bash: /home/darxus/wayland/missing: No such file or directory configure: WARNING: `missing' script is too old or missing ... configure: error: cannot run /bin/bash ./../config.sub $ automake --add-missing configure.ac:4: installing `./config.guess' configure.ac:4: installing `./config.sub' configure.ac:2: installing `./install-sh' configure.ac:4: required file `./ltmain.sh' not found configure.ac:2: installing `./missing' clients/Makefile.am: installing `./depcomp' configure.ac:6: required file `config.h.in' not found And then when I rerun the configure: $ aclocal; autoconf; ./configure --prefix=$HOME/install ... config.status: error: cannot find input file: `Makefile.in' -- "We will be dead soon. Is this how we want to live?" http://www.ChaosReigns.com From Darxus at chaosreigns.com Sat Nov 6 12:26:08 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sat, 6 Nov 2010 15:26:08 -0400 Subject: Ubuntu build tips In-Reply-To: <20101106190715.GL13517@chaosreigns.com> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> Message-ID: <20101106192608.GM13517@chaosreigns.com> A couple tips I think it would be nice to include in the build instructions for use with Ubuntu: When the build complains about a package named "example" not being found, you can find it with: $ sudo aptitude install apt-file && sudo apt-file update && apt-file search /example.pc (.pc stands for package config) To use the stuff built and installed into $HOME/install you need to do: $ export PKG_CONFIG_PATH=/home/darxus/install/lib/pkgconfig/ (or similar for non-bash shells) Ubuntu Maverick packages that I've installed to resolve build dependencies (so far): libgl1-mesa-dev xutils-dev libtalloc-dev libdrm-dev autoconf x11proto-kb-dev libegl1-mesa-dev libgles2-mesa-dev libgdk-pixbuf2.0-dev libudev-dev libxcb-dri2-0-dev libxcb-xfixes0-dev shtool libffi-dev libpoppler-glib-dev libgtk2.0-dev Maverick's x11proto-kb-dev is not new enough (for libxkbcommon from git), but Natty's is, and you can download it from http://packages.ubuntu.com/natty/x11proto-kb-dev And install it via "dpkg -i x11proto-kb-dev". -- "Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action." - George Washington http://www.ChaosReigns.com From Darxus at chaosreigns.com Sat Nov 6 17:45:07 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sat, 6 Nov 2010 20:45:07 -0400 Subject: Ubuntu PPA Re: Ubuntu build tips In-Reply-To: <20101106212842.GA1223@bryceharrington.org> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101106192608.GM13517@chaosreigns.com> <20101106212842.GA1223@bryceharrington.org> Message-ID: <20101107004507.GN13517@chaosreigns.com> On 11/06, Bryce Harrington wrote: > Also can be obtained from xorg-edgers, or at: > > https://launchpad.net/~xorg-edgers/+archive/wayland/+packages I don't know why this was off list. A PPA is a Personal Package Archive. This is great because it makes it much easier to install stuff under Ubuntu. Just do: sudo add-apt-repository ppa:xorg-edgers/wayland aptitude update && aptitude install cairo libxkbcommon x11proto-kbd The wayland and mesa packages haven't been completed yet. What's in there that isn't broken, per release: Maverick: cairo libxkbcommon x11proto-kbd Lucid: cairo, pixman Don't what pixman is. -- "One armed student or teacher could have stopped the killer, but all died obeying the rules." - http://www.olegvolk.net/gallery/technology/arms/yourkid0181.jpg.html http://www.ChaosReigns.com From bryce at canonical.com Sat Nov 6 21:35:21 2010 From: bryce at canonical.com (Bryce Harrington) Date: Sat, 6 Nov 2010 21:35:21 -0700 Subject: Ubuntu PPA Re: Ubuntu build tips In-Reply-To: <20101107004507.GN13517@chaosreigns.com> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101106192608.GM13517@chaosreigns.com> <20101106212842.GA1223@bryceharrington.org> <20101107004507.GN13517@chaosreigns.com> Message-ID: <20101107043521.GB1223@bryceharrington.org> On Sat, Nov 06, 2010 at 08:45:07PM -0400, Darxus at chaosreigns.com wrote: > On 11/06, Bryce Harrington wrote: > > Also can be obtained from xorg-edgers, or at: > > > > https://launchpad.net/~xorg-edgers/+archive/wayland/+packages > > I don't know why this was off list. Wasn't going to mention it until there was actually something worth mentioning. > A PPA is a Personal Package Archive. This is great because it makes it > much easier to install stuff under Ubuntu. Just do: > > sudo add-apt-repository ppa:xorg-edgers/wayland > aptitude update && aptitude install cairo libxkbcommon x11proto-kbd > > The wayland and mesa packages haven't been completed yet. The build directions recommend disabling gallium in order to get intel working properly. However I've not gotten a successful build with --disable-gallium added. Unless someone has a suggestion, I'm going to try a mesa without --disable-gallium. Maybe there's a better solution anyway. We will need gallium enabled in mesa for Radeon and Nouveau, so hopefully there's a better way to solve this for intel. > What's in there that isn't broken, per release: > > Maverick: cairo This is the stock ubuntu cairo package with gl enabled. Untested. > libxkbcommon Brand new package for this component. Also untested. > x11proto-kbd Cribbed from xorg-edgers out of laziness. Natty has 1.0.5 already packaged now, I may pull that in instead. Should work fine. > Lucid: cairo, pixman > > Don't what pixman is. Those are just cruft leftovers from a packaging of wayland I did a year ago. Ignore them. Bryce From Darxus at chaosreigns.com Sat Nov 6 21:51:08 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sun, 7 Nov 2010 00:51:08 -0400 Subject: DRI2: failed to authenticate Re: configure failed on Ubuntu Maverick In-Reply-To: <20101106190715.GL13517@chaosreigns.com> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> Message-ID: <20101107045108.GO13517@chaosreigns.com> I got the build to run cleanly, but like a couple others, I got no wayland-system-compositor installed as mentioned in the build instructions. And running running from the build directory: $ ./compositor DRI2: failed to authenticateSegmentation fault I do have: $ echo $DISPLAY :0.0 I followed these instructions from csj: http://grep.tw/blog/?p=1061 Except I used --prefix=$HOME/install Which required: export PKG_CONFIG_PATH=$HOME/install/lib/pkgconfig/:$HOME/install/share/pkgconfig/ export ACLOCAL="aclocal -I $HOME/install/share/aclocal" It's working for csj, running wayland as an X client. I'm running nvidia with the blob. He's running intel. When he switched to an nvidia with nouveau he got: 12:34AM < csj> DRI2: could not open (No such file or directory)Segmentation fault I wrote a bash script which should get you to where I am, wayland building without errors but not creating wayland-system-compositor (again, under Ubuntu Maverick). I'm using 'export MAKEFLAGS="-j 8"' to build with multiple cpu cores. Also might want to take out "--disable-gallium". Script (downloads git repos to current directory): set -u # exit script if anything fails mkdir $HOME/install mkdir -p $HOME/install/share/aclocal export PKG_CONFIG_PATH=$HOME/install/lib/pkgconfig/:$HOME/install/share/pkgconfig/ export ACLOCAL="aclocal -I $HOME/install/share/aclocal" sudo aptitude remove --purge libegl1-mesa-drivers sudo aptitude build-dep libglu1-mesa sudo aptitude build-dep libcairo2 sudo aptitude install libtool libxi-dev libxmu-dev libxt-dev bison flex libgl1-mesa-dev xutils-dev libtalloc-dev libdrm-dev autoconf x11proto-kb-dev libegl1-mesa-dev libgles2-mesa-dev libgdk-pixbuf2.0-dev libudev-dev libxcb-dri2-0-dev libxcb-xfixes0-dev shtool libffi-dev libpoppler-glib-dev libgtk2.0-dev git clone git://anongit.freedesktop.org/mesa/mesa cd mesa/ ./autogen.sh --prefix=$HOME/install --enable-egl --enable-gles2 --disable-gallium --with-egl-platforms="drm" #./autogen.sh --prefix=$HOME/install --enable-egl --enable-gles2 --with-egl-platforms="drm" make make install cd .. git clone git://anongit.freedesktop.org/xorg/proto/xproto cd xproto ./autogen.sh --prefix=$HOME/install make install cd .. git clone git://anongit.freedesktop.org/xorg/proto/kbproto cd kbproto/ ./autogen.sh --prefix=$HOME/install make install cd .. git clone git://anongit.freedesktop.org/xorg/util/macros cd macros ./autogen.sh --prefix=$HOME/install make install cd .. git clone git://anongit.freedesktop.org/xorg/lib/libX11 cd libX11 ./autogen.sh --prefix=$HOME/install make install cd .. git clone git://people.freedesktop.org/xorg/lib/libxkbcommon.git cd libxkbcommon/ ./autogen.sh --prefix=$HOME/install make make install cd .. git clone git://anongit.freedesktop.org/cairo cd cairo ./autogen.sh --prefix=$HOME/install --enable-gl --enable-xcb make make install cd .. git clone git://people.freedesktop.org/~krh/wayland cd wayland/ ./autogen.sh --prefix=$HOME/install make make install sudo cp -a compositor/70-wayland.rules /etc/udev/rules.d/ sudo udevadm trigger --subsystem-match=drm --subsystem-match=input From xiaoxiaomuyusajiangtian at gmail.com Sat Nov 6 22:26:33 2010 From: xiaoxiaomuyusajiangtian at gmail.com (Arthur Zhu) Date: Sun, 7 Nov 2010 13:26:33 +0800 Subject: Delivery Status Notification (Failure) In-Reply-To: <0016e647101e8e531c04946fae78@google.com> References: <0016e647101e8e531c04946fae78@google.com> Message-ID: The build directions recommend disabling gallium in order to get intel working properly. However I've not gotten a successful build with --disable-gallium added. Unless someone has a suggestion, I'm going to try a mesa without --disable-gallium. Maybe there's a better solution anyway. We will need gallium enabled in mesa for Radeon and Nouveau, so hopefully there's a better way to solve this for intel. --enable-gallium-i915 while compositor would have been failed, I'm debugging it right now that Could there someone else to let compositor framebuffer running in another term in the same computer? $./compositor Mesa: Mesa 7.9 DEBUG build Nov 5 2010 15:59:41 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa 7.9 implementation error: Incomplete OpenGL ES 2.0 support. Please report at bugzilla.freedesktop.org i915_state_derived.c:72:calculate_vertex_layout: Assertion `unit < 8' failed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From canbaby at 21cn.com Sun Nov 7 01:58:03 2010 From: canbaby at 21cn.com (canbaby) Date: Sun, 07 Nov 2010 16:58:03 +0800 Subject: Delivery Status Notification (Failure) In-Reply-To: References: <0016e647101e8e531c04946fae78@google.com> Message-ID: <4CD66A1B.4050506@21cn.com> On 11/07/2010 01:26 PM, Arthur Zhu wrote: > The build directions recommend disabling gallium in order to get intel > working properly. However I've not gotten a successful build with > --disable-gallium added. no "--disable-agallium" in wayland. Current I had no Intel chip, else I could try. > Unless someone has a suggestion, I'm going to > try a mesa without --disable-gallium. Maybe there's a better solution > anyway. We will need gallium enabled in mesa for Radeon and Nouveau, so > hopefully there's a better way to solve this for intel. > > > --enable-gallium-i915 while compositor would have been failed, I'm > debugging it right now that Could there someone else to let compositor > framebuffer running in another term in the same computer? > > $./compositor > Mesa: Mesa 7.9 DEBUG build Nov 5 2010 15:59:41 > Mesa warning: couldn't open libtxc_dxtn.so, software DXTn > compression/decompression unavailable > Mesa 7.9 implementation error: Incomplete OpenGL ES 2.0 support. > Please report at bugzilla.freedesktop.org > > i915_state_derived.c:72:calculate_vertex_layout: Assertion `unit < 8' > failed. > > > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- wucan -------------- next part -------------- An HTML attachment was scrubbed... URL: From canbaby at 21cn.com Sun Nov 7 03:33:11 2010 From: canbaby at 21cn.com (canbaby) Date: Sun, 07 Nov 2010 19:33:11 +0800 Subject: DRI2: failed to authenticate Re: configure failed on Ubuntu Maverick In-Reply-To: <20101107045108.GO13517@chaosreigns.com> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101107045108.GO13517@chaosreigns.com> Message-ID: <4CD68E77.6050302@21cn.com> On 11/07/2010 12:51 PM, Darxus at chaosreigns.com wrote: > I got the build to run cleanly, but like a couple others, I got no > wayland-system-compositor installed as mentioned in the build instructions. > > And running running from the build directory: > > $ ./compositor > DRI2: failed to authenticateSegmentation fault > > I do have: > > $ echo $DISPLAY > :0.0 > > I followed these instructions from csj: > > http://grep.tw/blog/?p=1061 > > Except I used --prefix=$HOME/install > > Which required: > > export PKG_CONFIG_PATH=$HOME/install/lib/pkgconfig/:$HOME/install/share/pkgconfig/ > export ACLOCAL="aclocal -I $HOME/install/share/aclocal" > > > It's working for csj, running wayland as an X client. I'm running nvidia > with the blob. He's running intel. When he switched to an nvidia with > nouveau he got: > > 12:34AM< csj> DRI2: could not open (No such file or directory)Segmentation fault > > I wrote a bash script which should get you to where I am, wayland building > without errors but not creating wayland-system-compositor (again, under > Ubuntu Maverick). I'm using 'export MAKEFLAGS="-j 8"' to build with > multiple cpu cores. Also might want to take out "--disable-gallium". > > Script (downloads git repos to current directory): > > > set -u # exit script if anything fails > > mkdir $HOME/install > mkdir -p $HOME/install/share/aclocal > export PKG_CONFIG_PATH=$HOME/install/lib/pkgconfig/:$HOME/install/share/pkgconfig/ > export ACLOCAL="aclocal -I $HOME/install/share/aclocal" > > sudo aptitude remove --purge libegl1-mesa-drivers > sudo aptitude build-dep libglu1-mesa > sudo aptitude build-dep libcairo2 > sudo aptitude install libtool libxi-dev libxmu-dev libxt-dev bison flex libgl1-mesa-dev xutils-dev libtalloc-dev libdrm-dev autoconf x11proto-kb-dev libegl1-mesa-dev libgles2-mesa-dev libgdk-pixbuf2.0-dev libudev-dev libxcb-dri2-0-dev libxcb-xfixes0-dev shtool libffi-dev libpoppler-glib-dev libgtk2.0-dev > > git clone git://anongit.freedesktop.org/mesa/mesa > cd mesa/ > ../autogen.sh --prefix=$HOME/install --enable-egl --enable-gles2 --disable-gallium --with-egl-platforms="drm" believe me, --enable-gallium and you'll make wayland running. I'm use nouveau driver for my nvidia chip, why not you try it instead? > #./autogen.sh --prefix=$HOME/install --enable-egl --enable-gles2 --with-egl-platforms="drm" > make > make install > cd .. > > git clone git://anongit.freedesktop.org/xorg/proto/xproto > cd xproto > ../autogen.sh --prefix=$HOME/install > make install > cd .. > > git clone git://anongit.freedesktop.org/xorg/proto/kbproto > cd kbproto/ > ../autogen.sh --prefix=$HOME/install > make install > cd .. > > git clone git://anongit.freedesktop.org/xorg/util/macros > cd macros > ../autogen.sh --prefix=$HOME/install > make install > cd .. > > git clone git://anongit.freedesktop.org/xorg/lib/libX11 > cd libX11 > ../autogen.sh --prefix=$HOME/install > make install > cd .. > > git clone git://people.freedesktop.org/xorg/lib/libxkbcommon.git > cd libxkbcommon/ > ../autogen.sh --prefix=$HOME/install > make > make install > cd .. > > git clone git://anongit.freedesktop.org/cairo > cd cairo > ../autogen.sh --prefix=$HOME/install --enable-gl --enable-xcb > make > make install > cd .. > > git clone git://people.freedesktop.org/~krh/wayland > cd wayland/ > ../autogen.sh --prefix=$HOME/install > make > make install > sudo cp -a compositor/70-wayland.rules /etc/udev/rules.d/ > sudo udevadm trigger --subsystem-match=drm --subsystem-match=input > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- wucan From Darxus at chaosreigns.com Sun Nov 7 11:06:24 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sun, 7 Nov 2010 14:06:24 -0500 Subject: DRI2: failed to authenticate Re: configure failed on Ubuntu Maverick In-Reply-To: <4CD68E77.6050302@21cn.com> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101107045108.GO13517@chaosreigns.com> <4CD68E77.6050302@21cn.com> Message-ID: <20101107190624.GP13517@chaosreigns.com> On 11/07, canbaby wrote: > believe me, --enable-gallium and you'll make wayland running. I'm > use nouveau driver for my nvidia chip, why not you try it instead? Nope, doesn't work. Last night somebody switched from --prefix=$HOME/install to --prefix=/usr and it started working. I'm not willing to do that. -- "Democracy is the theory that the common people know what they want, and deserve to get it good and hard." - H. L. Mencken http://www.ChaosReigns.com From jonsmirl at gmail.com Sun Nov 7 12:02:54 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Sun, 7 Nov 2010 15:02:54 -0500 Subject: Keyboard support in Wayland Message-ID: A repost now that I found the Wayland discussion list... Who is doing the libxkbcommon work? Please add them to the thread. --------------------------------------------------------- Wayland presents and opportunity to ditch xkeys. What do you think about having Wayland apps use the kernel keysyms and drop the whole legacy xkey world? Of course we would keep that library around for legacy purposes. The goal is to build a key mapping system usable by all apps/windowing systems, not just X. We have a opportunity here to redesign the keymap system for direct Wayland apps and not repeat the legacy problems from X. Clearly there is more to this than just using scan codes out of the kernel. I'm no expert on keymapping but I'll try and get the discussion started. There's some discussion here about the deficiencies in X keyboard handling... http://www.freedesktop.org/wiki/Software/LibXklavier ---------------------------- Another thought on this would be to move the kernel definitions of multimedia keys to a private space in Unicode. Currently they are defined on top of existing characters in Unicode. Doing this will remove the need to remap them. The Unicode people have been asked to directly support multimedia keys in Unicode and they have declined to do so since there are too many variations. -- Jon Smirl jonsmirl at gmail.com From canbaby at 21cn.com Sun Nov 7 17:03:27 2010 From: canbaby at 21cn.com (canbaby) Date: Mon, 08 Nov 2010 09:03:27 +0800 Subject: DRI2: failed to authenticate Re: configure failed on UbuntuMaverick In-Reply-To: <20101107190624.GP13517@chaosreigns.com> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101107045108.GO13517@chaosreigns.com> <4CD68E77.6050302@21cn.com> <20101107190624.GP13517@chaosreigns.com> Message-ID: <4CD74C5F.2070405@21cn.com> On 11/08/2010 03:06 AM, Darxus at chaosreigns.com wrote: > On 11/07, canbaby wrote: >> believe me, --enable-gallium and you'll make wayland running. I'm >> use nouveau driver for my nvidia chip, why not you try it instead? > Nope, doesn't work. What's wrong here? > Last night somebody switched from --prefix=$HOME/install to > --prefix=/usr and it started working. I'm not willing to do that. > -- wucan From Darxus at chaosreigns.com Sun Nov 7 17:33:58 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sun, 7 Nov 2010 20:33:58 -0500 Subject: DRI2: failed to authenticate Re: configure failed on UbuntuMaverick In-Reply-To: <4CD74C5F.2070405@21cn.com> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101107045108.GO13517@chaosreigns.com> <4CD68E77.6050302@21cn.com> <20101107190624.GP13517@chaosreigns.com> <4CD74C5F.2070405@21cn.com> Message-ID: <20101108013358.GQ13517@chaosreigns.com> On 11/08, canbaby wrote: > On 11/08/2010 03:06 AM, Darxus at chaosreigns.com wrote: > >On 11/07, canbaby wrote: > >>believe me, --enable-gallium and you'll make wayland running. I'm > >>use nouveau driver for my nvidia chip, why not you try it instead? > >Nope, doesn't work. > What's wrong here? Same. $ ./compositor -b my-image.jpg DRI2: failed to authenticateSegmentation fault (When you reply to me and the list, I'm getting two copies.) -- "It is the first responsibility of every citizen to question authority." - Benjamin Franklin http://www.ChaosReigns.com From canbaby at 21cn.com Sun Nov 7 18:28:54 2010 From: canbaby at 21cn.com (canbaby) Date: Mon, 08 Nov 2010 10:28:54 +0800 Subject: DRI2: failed to authenticate Re: configure failed onUbuntuMaverick In-Reply-To: <20101108013358.GQ13517@chaosreigns.com> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101107045108.GO13517@chaosreigns.com> <4CD68E77.6050302@21cn.com> <20101107190624.GP13517@chaosreigns.com> <4CD74C5F.2070405@21cn.com> <20101108013358.GQ13517@chaosreigns.com> Message-ID: <4CD76066.7060204@21cn.com> On 11/08/2010 09:34 AM, Darxus at chaosreigns.com wrote: > On 11/08, canbaby wrote: >> On 11/08/2010 03:06 AM, Darxus at chaosreigns.com wrote: >>> On 11/07, canbaby wrote: >>>> believe me, --enable-gallium and you'll make wayland running. I'm >>>> use nouveau driver for my nvidia chip, why not you try it instead? >>> Nope, doesn't work. >> What's wrong here? > Same. > > $ ./compositor -b my-image.jpg > DRI2: failed to authenticateSegmentation fault I mean what's wrong with your not working of nouveau and gallium? > > (When you reply to me and the list, I'm getting two copies.) > oh, sorry for the noise, I just hit "response all". -- wucan From Darxus at chaosreigns.com Sun Nov 7 20:48:47 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sun, 7 Nov 2010 23:48:47 -0500 Subject: DRI2: failed to authenticate Re: configure failed onUbuntuMaverick In-Reply-To: <4CD76066.7060204@21cn.com> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101107045108.GO13517@chaosreigns.com> <4CD68E77.6050302@21cn.com> <20101107190624.GP13517@chaosreigns.com> <4CD74C5F.2070405@21cn.com> <20101108013358.GQ13517@chaosreigns.com> <4CD76066.7060204@21cn.com> Message-ID: <20101108044847.GS13517@chaosreigns.com> On 11/08, canbaby wrote: > I mean what's wrong with your not working of nouveau and gallium? I don't understand the question. I have never tried to use nouveau (I'm using the blob). I don't even have any idea what gallium is. I believe I should be able to use wayland as an X client without involving video drivers? -- "I'd rather be happy than right any day." - Slartiblartfast, The Hitchhiker's Guide to the Galaxy http://www.ChaosReigns.com From canbaby at 21cn.com Sun Nov 7 23:01:04 2010 From: canbaby at 21cn.com (canbaby) Date: Mon, 08 Nov 2010 15:01:04 +0800 Subject: DRI2: failed to authenticate Re: configure failed onUbuntuMaverick In-Reply-To: <20101108044847.GS13517@chaosreigns.com> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101107045108.GO13517@chaosreigns.com> <4CD68E77.6050302@21cn.com> <20101107190624.GP13517@chaosreigns.com> <4CD74C5F.2070405@21cn.com> <20101108013358.GQ13517@chaosreigns.com> <4CD76066.7060204@21cn.com> <20101108044847.GS13517@chaosreigns.com> Message-ID: <4CD7A030.4050207@21cn.com> On 11/08/2010 12:49 PM, Darxus at chaosreigns.com wrote: > On 11/08, canbaby wrote: >> I mean what's wrong with your not working of nouveau and gallium? > I don't understand the question. I have never tried to use nouveau (I'm > using the blob). I don't even have any idea what gallium is. > > I believe I should be able to use wayland as an X client without involving > video drivers? > Sure or not, since the dri2 backend egl had failed initialized in my machine. Sorry for the confuse, I should dig more deep... -- wucan From spbnick at gmail.com Mon Nov 8 01:59:53 2010 From: spbnick at gmail.com (Nikolai Kondrashov) Date: Mon, 8 Nov 2010 12:59:53 +0300 Subject: [PATCH] Fix Wayland build instructions Message-ID: <1289210393-3003-1-git-send-email-spbnick@gmail.com> Replace aclocal; autoconf invocation in Wayland build instructions with an up-to-date ./autogen.sh invocation. Signed-off-by: Nikolai Kondrashov --- README | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/README b/README index 5b168d4..dad2d85 100644 --- a/README +++ b/README @@ -96,7 +96,7 @@ compositor) cairo-gl, glib-2.0, gdk-2.0 (for poppler) and poppler-glib: $ git clone git://people.freedesktop.org/~krh/wayland - $ aclocal; autoconf; ./configure --prefix=$HOME/install + $ ./autogen.sh --prefix=$HOME/install $ make && make install Installing into a non-/usr prefix is fine, but the 70-wayland.rules -- 1.7.2.3 From halsmit at t-online.de Mon Nov 8 01:50:36 2010 From: halsmit at t-online.de (Dirk Wallenstein) Date: Mon, 8 Nov 2010 10:50:36 +0100 Subject: jhbuild scripts In-Reply-To: References: Message-ID: <20101108095036.GA13650@zap> Hi, I made a few modifications to wayland.modules to work better with xjh. The diff does not show dependency differences currently as I thought that would clutter the output with bigger modulesets like the gnome ones. However, mentioning dependency differences on the header line for each module would probably be a good thing... -- Greetings, Dirk -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: diff-xjh-wayland.png Type: image/png Size: 24480 bytes Desc: not available URL: From krh at bitplanet.net Mon Nov 8 05:04:46 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 8 Nov 2010 08:04:46 -0500 Subject: Wayland web repo Message-ID: Hi all, I put the website in git and put it up over here: http://cgit.freedesktop.org/~krh/wayland-web/ so if you find bugs, out-dated build instructions you can now send patches to the web module and I'll pick it up. Kristian From krh at bitplanet.net Mon Nov 8 06:02:01 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 8 Nov 2010 09:02:01 -0500 Subject: Ubuntu PPA Re: Ubuntu build tips In-Reply-To: <20101107043521.GB1223@bryceharrington.org> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101106192608.GM13517@chaosreigns.com> <20101106212842.GA1223@bryceharrington.org> <20101107004507.GN13517@chaosreigns.com> <20101107043521.GB1223@bryceharrington.org> Message-ID: On Sun, Nov 7, 2010 at 12:35 AM, Bryce Harrington wrote: > On Sat, Nov 06, 2010 at 08:45:07PM -0400, Darxus at chaosreigns.com wrote: >> On 11/06, Bryce Harrington wrote: >> > Also can be obtained from xorg-edgers, or at: >> > >> > https://launchpad.net/~xorg-edgers/+archive/wayland/+packages >> >> I don't know why this was off list. > > Wasn't going to mention it until there was actually something worth > mentioning. > >> A PPA is a Personal Package Archive. ?This is great because it makes it >> much easier to install stuff under Ubuntu. ?Just do: >> >> sudo add-apt-repository ppa:xorg-edgers/wayland >> aptitude update && aptitude install cairo libxkbcommon x11proto-kbd >> >> The wayland and mesa packages haven't been completed yet. > > The build directions recommend disabling gallium in order to get intel > working properly. ?However I've not gotten a successful build with > --disable-gallium added. ?Unless someone has a suggestion, I'm going to > try a mesa without --disable-gallium. ?Maybe there's a better solution > anyway. ?We will need gallium enabled in mesa for Radeon and Nouveau, so > hopefully there's a better way to solve this for intel. Yea, this is something we need to fix in mesa. The problem is that the EGL loader prefers gallium drivers, even to the point where it will load the gallim swrast over the intel DRI driver. A better work around may be to not compile the gallium swrast driver, but eventually we need to make upstream mesa just get the load order right. >> What's in there that isn't broken, per release: >> >> Maverick: cairo > > This is the stock ubuntu cairo package with gl enabled. ?Untested. > >> libxkbcommon > > Brand new package for this component. ?Also untested. Also, not API or ABI stable at this point. I hope we can get it there for xserver 1.10. Kristian From rjshaw at netspace.net.au Mon Nov 8 07:52:04 2010 From: rjshaw at netspace.net.au (Russell Shaw) Date: Tue, 09 Nov 2010 02:52:04 +1100 Subject: Dri2 buffer format Message-ID: <4CD81CA4.40009@netspace.net.au> Hi, How should the "format" of a DRI2 buffer be determined? http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt DRI2ATTACH_FORMAT { attachment: CARD32 format: CARD32 } The DRI2ATTACH_FORMAT describes an attachment and the associated format. 'attachment' describes the attachment point for the buffer, 'format' describes an opaque, device-dependent format for the buffer. xorg-server-1.7.7/hw/xfree86/dri2/dri2ext.c From spbnick at gmail.com Mon Nov 8 08:38:40 2010 From: spbnick at gmail.com (Nikolai Kondrashov) Date: Mon, 8 Nov 2010 19:38:40 +0300 Subject: [PATCH] Clean up .gitignore files Message-ID: <1289234320-5758-1-git-send-email-spbnick@gmail.com> Sort the contents and update .gitignore files to hide generated files from git status output. Signed-off-by: Nikolai Kondrashov --- .gitignore | 32 ++++++++++++++++++++++++-------- clients/.gitignore | 8 ++++++-- compositor/.gitignore | 3 +++ m4/.gitignore | 5 +++++ wayland/.gitignore | 4 ++++ 5 files changed, 42 insertions(+), 10 deletions(-) create mode 100644 compositor/.gitignore create mode 100644 wayland/.gitignore diff --git a/.gitignore b/.gitignore index 435df93..7c5bfe5 100644 --- a/.gitignore +++ b/.gitignore @@ -1,12 +1,28 @@ *.deps +*.jpg +*.la +*.lo *.o -*.so *.pc -*.jpg +*.so +*.swp *~ -aclocal.m4 -autom4te.cache/ -config.log -config.status -configure -config.mk +.libs +/aclocal.m4 +/autom4te.cache +/config.guess +/config.h +/config.h.in +/config.log +/config.mk +/config.status +/config.sub +/configure +/depcomp +/install-sh +/libtool +/ltmain.sh +/missing +/stamp-h1 +Makefile +Makefile.in diff --git a/clients/.gitignore b/clients/.gitignore index 14a78c6..2401358 100644 --- a/clients/.gitignore +++ b/clients/.gitignore @@ -1,6 +1,10 @@ -gears +dnd flower +gears +image +screenshooter-client-protocol.h +screenshooter-protocol.c screenshot +smoke terminal -image view diff --git a/compositor/.gitignore b/compositor/.gitignore new file mode 100644 index 0000000..dc926c1 --- /dev/null +++ b/compositor/.gitignore @@ -0,0 +1,3 @@ +compositor +screenshooter-protocol.c +screenshooter-server-protocol.h diff --git a/m4/.gitignore b/m4/.gitignore index e69de29..38066dd 100644 --- a/m4/.gitignore +++ b/m4/.gitignore @@ -0,0 +1,5 @@ +libtool.m4 +ltoptions.m4 +ltsugar.m4 +ltversion.m4 +lt~obsolete.m4 diff --git a/wayland/.gitignore b/wayland/.gitignore new file mode 100644 index 0000000..0d28ba5 --- /dev/null +++ b/wayland/.gitignore @@ -0,0 +1,4 @@ +scanner +wayland-client-protocol.h +wayland-protocol.c +wayland-server-protocol.h -- 1.7.2.3 From jonsmirl at gmail.com Mon Nov 8 08:57:25 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Mon, 8 Nov 2010 11:57:25 -0500 Subject: Fwd: Revoke and multiple user ids In-Reply-To: References: Message-ID: --------- Forwarded message ---------- From: jonsmirl at gmail.com Date: Sun, Nov 7, 2010 at 10:08 AM Subject: Revoke and multiple user ids To: linux-input at vger.kernel.org There was some discussion at plumbers about how to handle input when the input device is shared between multiple user ids and you want to make sure that one of those users doesn't insert a key logger. Since Linux doesn't have a revoke system call there isn't a good way to implement this. A random idea for handling this would be to implement a pseudo revoke inside the input subsystem. You could do this by creating a set of evdev device nodes in a subdirectory of the /dev tree for each logged in user. ?Policy kit (or whatever handles user switching) would ask for a set of these device nodes to be created whenever someone logs in. The appropriate privs would be set on them. They get deleted when the user logs out. One set of nodes for each logged in user. When policy kit (which has root privs) hands the system over to a different user it would use and ioctl to tell the input core to move the evdev events over to another set of evdev nodes. The evdev events only appear on the device nodes of the logged in user. 1) each logged in user has a set of evdev nodes with ownership and permission set to only them 2) users can't look at each other's evdev nodes because they don't have permission to open them 3) the privileged task that swaps users tells the kernel to move the events 4) tasks can insert key loggers and keep the device nodes open, because now it doesn't matter. This can probably be built as a small module that load on top of the existing evdev system. The base evdev nodes would always be root owned. I forgot who was asking me how to do this, it was someone working on X to make it run as non-root. -- Jon Smirl jonsmirl at gmail.com -- Jon Smirl jonsmirl at gmail.com From j.glisse at gmail.com Mon Nov 8 09:53:56 2010 From: j.glisse at gmail.com (Jerome Glisse) Date: Mon, 8 Nov 2010 12:53:56 -0500 Subject: Dri2 buffer format In-Reply-To: <4CD81CA4.40009@netspace.net.au> References: <4CD81CA4.40009@netspace.net.au> Message-ID: On Mon, Nov 8, 2010 at 10:52 AM, Russell Shaw wrote: > Hi, > How should the "format" of a DRI2 buffer be determined? > > > http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt > > DRI2ATTACH_FORMAT { attachment: CARD32 > ? ? ? ? ? ?format: ? ? CARD32 } > > ? ?The DRI2ATTACH_FORMAT describes an attachment and the associated > ? ?format. ?'attachment' describes the attachment point for the buffer, > ? ?'format' describes an opaque, device-dependent format for the buffer. > > As the spec says, it's opaque and only the driver understand it, intel, radeon, nouveau all use different things i think. DRI2 is meant to be use btw different driver of same hw which should all understand each others. Jerome From krh at bitplanet.net Mon Nov 8 12:17:34 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 8 Nov 2010 15:17:34 -0500 Subject: Fw: Is this list dead now? In-Reply-To: References: Message-ID: On Sat, Nov 6, 2010 at 4:12 AM, Justin Lee wrote: > Kristian H?gsberg wrote: > >>> Since wayland development has moved to freedesktop? >> >> Yes the list is dead and I'll shut down the google group in a week. >> Kristian > > Hopefully, Wayland group is still viewable to after it's shut down. > > As far as I know group stuff has not been moved to freedesktop.org, > but there are many external links in Wikipedia refer to the group. > > Besides, the discussions in the group more or less reflect the history > of Wayland and there are many valuable ideas to me in it. Yup, I just set the 'archive' bit for the group, new postings are rejected, but the current mails and files will stay around. Kristian From justinlee5455 at gmail.com Mon Nov 8 15:27:19 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Tue, 9 Nov 2010 07:27:19 +0800 Subject: Fw: Is this list dead now? In-Reply-To: References: Message-ID: Thanks for your kindness to 'archive' it :) 2010/11/9 Kristian H?gsberg : > On Sat, Nov 6, 2010 at 4:12 AM, Justin Lee wrote: >> Kristian H?gsberg wrote: >> >>>> Since wayland development has moved to freedesktop? >>> >>> Yes the list is dead and I'll shut down the google group in a week. >>> Kristian >> >> Hopefully, Wayland group is still viewable to after it's shut down. >> >> As far as I know group stuff has not been moved to freedesktop.org, >> but there are many external links in Wikipedia refer to the group. >> >> Besides, the discussions in the group more or less reflect the history >> of Wayland and there are many valuable ideas to me in it. > > Yup, I just set the 'archive' bit for the group, new postings are > rejected, but the current mails and files will stay around. > > Kristian > From rjshaw at netspace.net.au Mon Nov 8 15:55:22 2010 From: rjshaw at netspace.net.au (Russell Shaw) Date: Tue, 09 Nov 2010 10:55:22 +1100 Subject: Dri2 buffer format In-Reply-To: References: <4CD81CA4.40009@netspace.net.au> Message-ID: <4CD88DEA.5030205@netspace.net.au> On 09/11/10 04:53, Jerome Glisse wrote: > On Mon, Nov 8, 2010 at 10:52 AM, Russell Shaw wrote: >> Hi, >> How should the "format" of a DRI2 buffer be determined? >> >> >> http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt >> >> DRI2ATTACH_FORMAT { attachment: CARD32 >> format: CARD32 } >> >> The DRI2ATTACH_FORMAT describes an attachment and the associated >> format. 'attachment' describes the attachment point for the buffer, >> 'format' describes an opaque, device-dependent format for the buffer. >> >> > > As the spec says, it's opaque and only the driver understand it, intel, > radeon, nouveau all use different things i think. DRI2 is meant to be > use btw different driver of same hw which should all understand each > others. If it's opaque, how does one know what bytes are red/green/blue so that you can draw a line in the right colour? From jonsmirl at gmail.com Mon Nov 8 20:03:22 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Mon, 8 Nov 2010 23:03:22 -0500 Subject: Network transparency argument Message-ID: One way to deal with the network transparency issue is to turn it on it's head. Network transparency is changing. The web is a giant network transparent app. HTML5 allows much better UIs to be built. Maybe the question should be, why are you using gtk/qt instead of HTML5 to build your GUI? -- Jon Smirl jonsmirl at gmail.com From pbx009 at gmail.com Mon Nov 8 21:12:06 2010 From: pbx009 at gmail.com (aj) Date: Tue, 9 Nov 2010 10:42:06 +0530 Subject: Wayland on vmware ? Message-ID: I tried to compile and run wayland on vmware machine. While running compositor , I got the following message DRI2: failed to authenticate Segmentation fault does wayland runs on vmware machine ? Any help on this would be appreciated. Thanks Rajeev -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.hutterer at who-t.net Mon Nov 8 22:31:30 2010 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Tue, 9 Nov 2010 16:31:30 +1000 Subject: [PATCH] README: fix a few typos Message-ID: <20101109063125.GA17588@salty.local> And one in the main.tex spec document. Signed-off-by: Peter Hutterer --- README | 6 +++--- spec/main.tex | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/README b/README index 5b168d4..a23345c 100644 --- a/README +++ b/README @@ -4,7 +4,7 @@ Wayland is a project to define a protocol for a compositor to talk to its clients as well as a library implementation of the protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X applications, or a wayland -client itself. The clients can be traditional appliactions, X servers +client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers. The wayland protocol is essentially only about input handling and @@ -64,7 +64,7 @@ libxkbcommon Wayland needs libxkbcommon for translating evdev keycodes to keysyms. There's a couple of repos around, and we're trying to consolidate the -development, but for wayland you'll need the repo from my get +development, but for wayland you'll need the repo from my git repository. For this you'll need development packages for xproto, kbproto and libX11. @@ -76,7 +76,7 @@ kbproto and libX11. cairo-gl -The Waland clients render using cairo-gl, which is an experimental +The Wayland clients render using cairo-gl, which is an experimental cairo backend. It has been available since cairo 1.10. Unless your distribution ships cairo with the gl backend enabled, you'll need to compile your own version of cairo: diff --git a/spec/main.tex b/spec/main.tex index 41e0367..8c512be 100644 --- a/spec/main.tex +++ b/spec/main.tex @@ -68,7 +68,7 @@ languages, but that hasn't been done at this point. The server sends back events to the client, each event is emitted from an object. Events can be error conditions. The event includes the object id and the event opcode, from which the client can determine -the type of event. Events are generated both in repsonse to a request +the type of event. Events are generated both in response to a request (in which case the request and the event constitutes a round trip) or spontanously when the server state changes. -- 1.7.2.3 From markc at renta.net Mon Nov 8 22:49:01 2010 From: markc at renta.net (Mark Constable) Date: Tue, 9 Nov 2010 16:49:01 +1000 Subject: Network transparency argument In-Reply-To: References: Message-ID: <201011091649.01941.markc@renta.net> On 2010-11-09, jonsmirl at gmail.com wrote: > Network transparency is changing. The web is a giant > network transparent app. HTML5 allows much better UIs > to be built. Maybe the question should be, why are you > using gtk/qt instead of HTML5 to build your GUI? Good point. The network aspect of X was built-in way before the web existed in the days when the very concept of a HTTP browser did not yet exist. I don't understand why folks "demand" that Wayland emulate the networking features of X when a) it's not even functioning as a viable windowing system yet and b) do you really want the extra code bloat when X can run on top of Wayland and provide network transparency indirectly. Give Wayland a chance to become usable and stabilise and I am confident that there will be 1/2 dozen different ways to provide networking features directly to Wayland, for those that want it, and in a way that does not hog development time for those who do not want it. To me, Wayland represents the best chance I know of to have an efficient tear-free and flicker-free desktop. Just get that right first and worry about ad-ons later. --markc From kazade at gmail.com Tue Nov 9 01:28:40 2010 From: kazade at gmail.com (Luke Benstead) Date: Tue, 9 Nov 2010 09:28:40 +0000 Subject: Making Wayland Game-friendly Message-ID: Hi all, This is my first post to this list, and I fear it may be a lengthy one, so bear with me :) Firstly, I may be totally off base with this. I'm working under the assumption that once complete Wayland will take care of resolution changes instead of xrandr (as xrandr is obviously an X extension). If someone could point me to any information on resolution switching in Wayland I'd appreciate it. So, the rest of this email is based on the assumption that Wayland has, or will have, an API for switching resolution. If I'm wrong, just disregard :) The reason I'm emailing is there is a minor issue in the way xrandr behaves that causes issues to games, or other fullscreen, non-native resolution apps (e.g. media player visualizations), and I'm hoping that Wayland doesn't inherit it. Basically, xrandr is designed under the assumption that a resolution change is permanent, or at least semi-permanent (e.g. until reboot or manual switch back) and system wide. The problem is that games (as an example) require a temporary resolution change that is associated with a single window. What I mean by this is that when a game initializes it sets the resolution (through SDL, X, Win32 on Wine etc.) and this is frequently a resolution below native normally for performance reasons (e.g. your PC may not like running Alien Arena at full HD, but it will run perfectly well at 1024x768). Ideally, if that game then crashed, or someone ALT+TAB'd to a different window, the native resolution would be restored. If the user then switched back to the window, then the game's resolution would be restored. On Windows, it's possible to pass a temporary flag to the Win32 ChangeDisplaySettings()* function for this behaviour. At the moment, if a game crashes (either native, or run via Wine) on X you are left with a low resolution and have to find your way to the Monitor control panel to set it back. Which is obviously not ideal. So, basically I'm hoping that Wayland can fix this issue by allowing a resolution change to be associated with a single window. Thoughts? Luke. http://msdn.microsoft.com/en-us/library/dd183411%28VS.85%29.aspx (see CDS_FULLSCREEN) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce at canonical.com Tue Nov 9 01:39:47 2010 From: bryce at canonical.com (Bryce Harrington) Date: Tue, 9 Nov 2010 01:39:47 -0800 Subject: Making Wayland Game-friendly In-Reply-To: References: Message-ID: <20101109093947.GF9521@bryceharrington.org> On Tue, Nov 09, 2010 at 09:28:40AM +0000, Luke Benstead wrote: > The reason I'm emailing is there is a minor issue in the way xrandr behaves > that causes issues to games, or other fullscreen, non-native resolution apps > (e.g. media player visualizations), and I'm hoping that Wayland doesn't > inherit it. I've noticed this as well. > Basically, xrandr is designed under the assumption that a resolution change > is permanent, or at least semi-permanent (e.g. until reboot or manual switch > back) and system wide. The problem is that games (as an example) require a > temporary resolution change that is associated with a single window. What I > mean by this is that when a game initializes it sets the resolution (through > SDL, X, Win32 on Wine etc.) and this is frequently a resolution below native > normally for performance reasons (e.g. your PC may not like running Alien > Arena at full HD, but it will run perfectly well at 1024x768). > > Ideally, if that game then crashed, or someone ALT+TAB'd to a different > window, the native resolution would be restored. If the user then switched > back to the window, then the game's resolution would be restored. On > Windows, it's possible to pass a temporary flag to the Win32 > ChangeDisplaySettings()* function for this behaviour. Could you elaborate on how Windows handles this? > At the moment, if a game crashes (either native, or run via Wine) on X you > are left with a low resolution and have to find your way to the Monitor > control panel to set it back. Which is obviously not ideal. > > So, basically I'm hoping that Wayland can fix this issue by allowing a > resolution change to be associated with a single window. Could you expound on how you think Wayland should behave in this situation? Bryce From kazade at gmail.com Tue Nov 9 01:54:24 2010 From: kazade at gmail.com (Luke Benstead) Date: Tue, 9 Nov 2010 09:54:24 +0000 Subject: Making Wayland Game-friendly In-Reply-To: <20101109093947.GF9521@bryceharrington.org> References: <20101109093947.GF9521@bryceharrington.org> Message-ID: > > Basically, xrandr is designed under the assumption that a resolution > change > > is permanent, or at least semi-permanent (e.g. until reboot or manual > switch > > back) and system wide. The problem is that games (as an example) require > a > > temporary resolution change that is associated with a single window. What > I > > mean by this is that when a game initializes it sets the resolution > (through > > SDL, X, Win32 on Wine etc.) and this is frequently a resolution below > native > > normally for performance reasons (e.g. your PC may not like running Alien > > Arena at full HD, but it will run perfectly well at 1024x768). > > > > Ideally, if that game then crashed, or someone ALT+TAB'd to a different > > window, the native resolution would be restored. If the user then > switched > > back to the window, then the game's resolution would be restored. On > > Windows, it's possible to pass a temporary flag to the Win32 > > ChangeDisplaySettings()* function for this behaviour. > > Could you elaborate on how Windows handles this? > I don't know much about what it does under the hood, but there is a little more information here: http://blogs.msdn.com/b/oldnewthing/archive/2008/01/04/6973747.aspx The general idea is that it: 1. Restores the native resolution when the application exits 2. Restores the native resolution when the application window loses focus 3. Goes back to the non-native resolution when the window gains focus 4. Doesn't reorganize the desktop etc. (e.g other applications don't get a WM_DISPLAYCHANGED message - http://msdn.microsoft.com/en-us/library/dd145210%28v=VS.85%29.aspx) 5. If the window loses focus, it is minimized automatically. > > > At the moment, if a game crashes (either native, or run via Wine) on X > you > > are left with a low resolution and have to find your way to the Monitor > > control panel to set it back. Which is obviously not ideal. > > > > So, basically I'm hoping that Wayland can fix this issue by allowing a > > resolution change to be associated with a single window. > > Could you expound on how you think Wayland should behave in this > situation? > > Bryce > I think basically, similar to windows. So, in the API call that sets the resolution, allow an optional parameter which takes the ID of the window. If the window does not have focus (or ceases to exist), restore the previous resolution. I don't really know how Wayland works so I can't really suggest much more than that. I do have another idea, but whether it would work in practice I'm not sure, so I'll just throw this out there. What if, instead of changing the native resolution, Wayland allocated an off-screen buffer of the requested resolution. As far as the app is concerned it's rendering to a fullscreen window at the requested res, but then Wayland scales the offscreen buffer and blits it to the screen. If the window loses focus then it's minimized. (I know we are sort of stumbling onto WM territory here, I'm not really sure how to handle that. Perhaps it doesn't need to be minimized just displayed non-fullscreen). Sorry if I'm talking rubbish, I only have basically knowledge of how this stuff works. Luke. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spbnick at gmail.com Tue Nov 9 02:01:13 2010 From: spbnick at gmail.com (Nikolai Kondrashov) Date: Tue, 09 Nov 2010 13:01:13 +0300 Subject: Making Wayland Game-friendly In-Reply-To: References: <20101109093947.GF9521@bryceharrington.org> Message-ID: <4CD91BE9.60207@gmail.com> On 11/09/2010 12:54 PM, Luke Benstead wrote: > I do have another idea, but whether it would work in practice I'm not > sure, so I'll just throw this out there. What if, instead of changing > the native resolution, Wayland allocated an off-screen buffer of the > requested resolution. As far as the app is concerned it's rendering to a > fullscreen window at the requested res, but then Wayland scales the > offscreen buffer and blits it to the screen. If the window loses focus > then it's minimized. (I know we are sort of stumbling onto WM territory > here, I'm not really sure how to handle that. Perhaps it doesn't need to > be minimized just displayed non-fullscreen). For this to work properly Wayland would need to sometimes apply aspect ratio transformation, because the application might expect the aspect ratio different from the one of the current resolution. This would be great if Wayland could handle it. It would also be great if Wayland didn't force minimize the window as Windows does. Sincerely, Nick From kamilion at gmail.com Tue Nov 9 02:06:34 2010 From: kamilion at gmail.com (Graham Cantin) Date: Tue, 9 Nov 2010 02:06:34 -0800 Subject: Making Wayland Game-friendly In-Reply-To: References: <20101109093947.GF9521@bryceharrington.org> Message-ID: On Tue, Nov 9, 2010 at 1:54 AM, Luke Benstead wrote: >> > So, basically I'm hoping that Wayland can fix this issue by allowing a >> > resolution change to be associated with a single window. >> >> Could you expound on how you think Wayland should behave in this >> situation? >> >> Bryce > > I think basically, similar to windows. So, in the API call that sets the resolution, allow an optional parameter which takes the ID of the window. If the window does not have focus (or ceases to exist), restore the previous resolution. I don't really know how Wayland works so I can't really suggest much more than that. > > I do have another idea, but whether it would work in practice I'm not sure, so I'll just throw this out there. What if, instead of changing the native resolution, Wayland allocated an off-screen buffer of the requested resolution. As far as the app is concerned it's rendering to a fullscreen window at the requested res, but then Wayland scales the offscreen buffer and blits it to the screen. If the window loses focus then it's minimized. (I know we are sort of stumbling onto WM territory here, I'm not really sure how to handle that. Perhaps it doesn't need to be minimized just displayed non-fullscreen). > > Sorry if I'm talking rubbish, I only have basically knowledge of how this stuff works. > > Luke. I second that blitting to fit behavior: LCDs like being driven in their native resolution; and we can do much much nicer stretches with shaders than the hardware scaler in some displays can. Please consider this as an *upgrade* to windows' behavior. IIRC, on win7, either modern nvidia or modern ati drivers (forget which) have something similar to this; always keeping native resolution output to the display and shader-scaling the framebuffer resolution up. -- [? ?? Graham Cantin? ? ? ] | (408) 890-7463 - Google Voice FindME "Never feel stupid for asking questions, feel stupid for ignoring answers." [? System Administrator? ] | (XXX) XXX-XXXX xXXX - IT & Office PBX "You're arrogant for thinking you can, ignorant for thinking you cannot." [ RFSpot Mobile Services ] | (XXX) XXX-XXXX - Main Office Direct "Asking questions is important, because that's when intuition gets converted into inspiration." [?? NASA Ames Research?? ] | Building 19, Moffett Field, CA "As living spies we must recruit men who are intelligent?but appear to be stupid; who seem to be dull but are strong in heart;?men who are agile, vigorous, hardy, and brave; well-versed in lowly matters?and able to endure hunger, cold, filth, and humiliation." - Tu Mu (803-825) From spbnick at gmail.com Tue Nov 9 02:14:22 2010 From: spbnick at gmail.com (Nikolai Kondrashov) Date: Tue, 09 Nov 2010 13:14:22 +0300 Subject: Making Wayland Game-friendly In-Reply-To: References: <20101109093947.GF9521@bryceharrington.org> Message-ID: <4CD91EFE.1010401@gmail.com> On 11/09/2010 12:54 PM, Luke Benstead wrote: > I do have another idea, but whether it would work in practice I'm not > sure, so I'll just throw this out there. What if, instead of changing > the native resolution, Wayland allocated an off-screen buffer of the > requested resolution. As far as the app is concerned it's rendering to a > fullscreen window at the requested res, but then Wayland scales the > offscreen buffer and blits it to the screen. If the window loses focus > then it's minimized. (I know we are sort of stumbling onto WM territory > here, I'm not really sure how to handle that. Perhaps it doesn't need to > be minimized just displayed non-fullscreen). Sorry, I misinterpreted your idea. I thought you were talking about switching resolutions transparently for the application. However, the idea of keeping the native LCD resolution seems to be very nice, yet supporting real resolution switching might be needed anyway. Sincerely, Nick From kazade at gmail.com Tue Nov 9 02:16:24 2010 From: kazade at gmail.com (Luke Benstead) Date: Tue, 9 Nov 2010 10:16:24 +0000 Subject: Making Wayland Game-friendly In-Reply-To: <4CD91EFE.1010401@gmail.com> References: <20101109093947.GF9521@bryceharrington.org> <4CD91EFE.1010401@gmail.com> Message-ID: On 9 November 2010 10:14, Nikolai Kondrashov wrote: > On 11/09/2010 12:54 PM, Luke Benstead wrote: > >> I do have another idea, but whether it would work in practice I'm not >> sure, so I'll just throw this out there. What if, instead of changing >> the native resolution, Wayland allocated an off-screen buffer of the >> requested resolution. As far as the app is concerned it's rendering to a >> fullscreen window at the requested res, but then Wayland scales the >> offscreen buffer and blits it to the screen. If the window loses focus >> then it's minimized. (I know we are sort of stumbling onto WM territory >> here, I'm not really sure how to handle that. Perhaps it doesn't need to >> be minimized just displayed non-fullscreen). >> > Sorry, I misinterpreted your idea. I thought you were talking about > switching resolutions transparently for the application. However, the idea > of keeping the native LCD resolution seems to be very nice, yet supporting > real resolution switching might be needed anyway. > > Sincerely, > Nick > Yeah, of course. I don't doubt that native resolutions switches will be required. But if temporary switches can be handled by rendering offscreen, and full resolutions switches happen in a similar style to xrandr, that at least removes the problems with the common cases. Luke. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamilion at gmail.com Tue Nov 9 02:34:56 2010 From: kamilion at gmail.com (Graham Cantin) Date: Tue, 9 Nov 2010 02:34:56 -0800 Subject: Making Wayland Game-friendly In-Reply-To: References: <20101109093947.GF9521@bryceharrington.org> <4CD91EFE.1010401@gmail.com> Message-ID: On Tue, Nov 9, 2010 at 2:16 AM, Luke Benstead wrote: > On 9 November 2010 10:14, Nikolai Kondrashov wrote: >> On 11/09/2010 12:54 PM, Luke Benstead wrote: >>> I do have another idea, but whether it would work in practice I'm not >>> sure, so I'll just throw this out there. What if, instead of changing >>> the native resolution, Wayland allocated an off-screen buffer of the >>> requested resolution. As far as the app is concerned it's rendering to a >>> fullscreen window at the requested res, but then Wayland scales the >>> offscreen buffer and blits it to the screen. If the window loses focus >>> then it's minimized. (I know we are sort of stumbling onto WM territory >>> here, I'm not really sure how to handle that. Perhaps it doesn't need to >>> be minimized just displayed non-fullscreen). >> >> Sorry, I misinterpreted your idea. I thought you were talking about >> switching resolutions transparently for the application. However, the idea >> of keeping the native LCD resolution seems to be very nice, yet supporting >> real resolution switching might be needed anyway. >> >> Sincerely, >> Nick > > Yeah, of course. I don't doubt that native resolutions switches will be > required. But if temporary switches can be handled by rendering offscreen, > and full resolutions switches happen in a similar style to xrandr, that at > least removes the problems with the common cases. > > Luke. Hm, I picked up my droid to play a little NES river city ransom a second ago, when it hit me. Modern emulators have LEGENDARY 2d shaders. http://en.wikipedia.org/wiki/Pixel_art_scaling_algorithms#Super_2.C3.97SaI_and_Super_Eagle http://vogons.zetafleet.com/files/setting_scalers_in_dbgl.png Have a look at the dosbox source tree for a whole mess of GPL implementations. http://dosbox.svn.sourceforge.net/viewvc/dosbox/dosbox/trunk/src/gui/ render_* http://dosbox.svn.sourceforge.net/viewvc/dosbox/dosbox/trunk/src/gui/render_scalers.cpp?revision=3653&view=markup I know there's some shader versions as well, I'll try and dig some up; if anyone shows interest in getting high quality scalers directly in wayland (which sounds like a *REALLY* good idea to me.) 2xSaI or Super Eagle scaling of any window to fullscreen would be pure love for Ten-Foot-Interfaces on wayland. Wayland backend for MythTV? :D Suggested aspect ratio should also be passed; in case the user *asks* to override it (Eg, yes, I really *do* want to scale that 4:3 to widescreen. *click click... click... click click* Ahhh.) -- [? ?? Graham Cantin? ? ? ] | (408) 890-7463 - Google Voice FindME "Never feel stupid for asking questions, feel stupid for ignoring answers." [? System Administrator? ] | (XXX) XXX-XXXX xXXX - IT & Office PBX "You're arrogant for thinking you can, ignorant for thinking you cannot." [ RFSpot Mobile Services ] | (XXX) XXX-XXXX - Main Office Direct "Asking questions is important, because that's when intuition gets converted into inspiration." [?? NASA Ames Research?? ] | Building 19, Moffett Field, CA "As living spies we must recruit men who are intelligent?but appear to be stupid; who seem to be dull but are strong in heart;?men who are agile, vigorous, hardy, and brave; well-versed in lowly matters?and able to endure hunger, cold, filth, and humiliation." - Tu Mu (803-825) From kazade at gmail.com Tue Nov 9 02:38:02 2010 From: kazade at gmail.com (Luke Benstead) Date: Tue, 9 Nov 2010 10:38:02 +0000 Subject: Making Wayland Game-friendly In-Reply-To: References: <20101109093947.GF9521@bryceharrington.org> <4CD91EFE.1010401@gmail.com> Message-ID: > Suggested aspect ratio should also be passed; in case the user *asks* > to override it (Eg, yes, I really *do* want to scale that 4:3 to > widescreen. *click click... click... click click* Ahhh.) > Yeah, conversely, automatic black-barring if adjust_aspect=false or something would be awesome. :) Luke. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bluescreen_avenger at verizon.net Tue Nov 9 05:53:31 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Tue, 09 Nov 2010 08:53:31 -0500 Subject: Wayland and GPU hotswapping Message-ID: <201011090853.32509.bluescreen_avenger@verizon.net> A feature that seems to be in some laptops, and is being worked into the Linux kernel. Would Wayland ever be able to handle this, when the feature comes into Linux, or would the display server always need to be reset? From olvaffe at gmail.com Tue Nov 9 10:08:57 2010 From: olvaffe at gmail.com (Chia-I Wu) Date: Wed, 10 Nov 2010 02:08:57 +0800 Subject: Wayland on vmware ? In-Reply-To: References: Message-ID: On Tue, Nov 9, 2010 at 1:12 PM, aj wrote: > I tried to compile and run wayland on vmware machine. > > While running? compositor , I got the following message > > DRI2: failed to authenticate Segmentation fault > > does wayland runs on vmware machine ? It should, but I am not sure if anyone ever tries it. So there is a good chance it does not. Before you try, make sure you enable 3D acceleration and your xserver uses the Gallium xorg driver and dri driver. > Any help on this would be appreciated. > > Thanks > Rajeev > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > -- olv at LunarG.com From olvaffe at gmail.com Tue Nov 9 10:30:34 2010 From: olvaffe at gmail.com (Chia-I Wu) Date: Wed, 10 Nov 2010 02:30:34 +0800 Subject: Ubuntu PPA Re: Ubuntu build tips In-Reply-To: References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101106192608.GM13517@chaosreigns.com> <20101106212842.GA1223@bryceharrington.org> <20101107004507.GN13517@chaosreigns.com> <20101107043521.GB1223@bryceharrington.org> Message-ID: 2010/11/8 Kristian H?gsberg : > On Sun, Nov 7, 2010 at 12:35 AM, Bryce Harrington wrote: >> On Sat, Nov 06, 2010 at 08:45:07PM -0400, Darxus at chaosreigns.com wrote: >>> On 11/06, Bryce Harrington wrote: >>> > Also can be obtained from xorg-edgers, or at: >>> > >>> > https://launchpad.net/~xorg-edgers/+archive/wayland/+packages >>> >>> I don't know why this was off list. >> >> Wasn't going to mention it until there was actually something worth >> mentioning. >> >>> A PPA is a Personal Package Archive. ?This is great because it makes it >>> much easier to install stuff under Ubuntu. ?Just do: >>> >>> sudo add-apt-repository ppa:xorg-edgers/wayland >>> aptitude update && aptitude install cairo libxkbcommon x11proto-kbd >>> >>> The wayland and mesa packages haven't been completed yet. >> >> The build directions recommend disabling gallium in order to get intel >> working properly. ?However I've not gotten a successful build with >> --disable-gallium added. ?Unless someone has a suggestion, I'm going to >> try a mesa without --disable-gallium. ?Maybe there's a better solution >> anyway. ?We will need gallium enabled in mesa for Radeon and Nouveau, so >> hopefully there's a better way to solve this for intel. > > Yea, this is something we need to fix in mesa. ?The problem is that > the EGL loader prefers gallium drivers, even to the point where it > will load the gallim swrast over the intel DRI driver. ?A better work > around may be to not compile the gallium swrast driver, but eventually > we need to make upstream mesa just get the load order right. Mesa can be configured to build gallium-based DRI drivers but not gallium-based EGL driver. But it is not clearly documented. I've added a new option, --disable-gallium-egl, to Mesa to easily disable the gallium-based EGL driver. What do you think? For a normal desktop which has DRI drivers, egl_dri2 should be the way to go. So along the way, I've also fixed a bug in gallium-based DRI drivers to support surfaceless current contexts. I've only tested with nouveau, but r300g/r600g should hopefully work too. A patch to add the PCI IDs of cards supported by nouveau to egl_dri2 is still required though. > >>> What's in there that isn't broken, per release: >>> >>> Maverick: cairo >> >> This is the stock ubuntu cairo package with gl enabled. ?Untested. >> >>> libxkbcommon >> >> Brand new package for this component. ?Also untested. > > Also, not API or ABI stable at this point. ?I hope we can get it there > for xserver 1.10. > > Kristian > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- olv at LunarG.com From Darxus at chaosreigns.com Tue Nov 9 10:48:25 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Tue, 9 Nov 2010 13:48:25 -0500 Subject: Network transparency argument In-Reply-To: <201011091649.01941.markc@renta.net> References: <201011091649.01941.markc@renta.net> Message-ID: <20101109184825.GD13517@chaosreigns.com> I was hoping that this subject just wouldn't get any replies. The "network transparency argument" is pointless because network transparency via the X protocol will never go away. I think people who are concerned about this must not be aware that X clients already run seamlessly with Windows or Mac OS as the native graphical environment. Windows and Mac OS use the same X server as Linux (Xorg) running rootless ("multi-window mode"). It's bundled with Mac OS as part of X11.app. That means each application gets its own window, decorated by the native environment (Windows, Mac OS, Wayland) and you can't even tell the difference between native apps and apps which are connected via X. It is ridiculous to assume this will not be wonderfully supported under Linux. (I expect an X server dynamically loaded only when an X client tries to connect.) So basically, everything will work exactly the way it currently does, and you won't even notice the difference. Except less overhead and smoother graphics with applications using Wayland directly. I expect the major graphics libraries (GTK and Qt) to add Wayland support as a run time option, so applications using them will not lose the ability to connect directly to an X server over a network. I'm not in a position of authority to dictate these things, it's just obvious how it will work. I'm sure anyone who has been concerned about this came from Mark Shuttleworth's Ubuntu announcement, and somehow failed to notice that he made it very clear that X compatibility will be maintained. There are screenshots of Xorg under Windows here: http://x.cygwin.com/ Xorg for Mac OS is called XQuartz: http://xquartz.macosforge.org/trac/wiki And requiring people to use HTML5 to get network transparency is incredibly dumb. -- "The future masters of technology will have to be lighthearted and intelligent. The machine easily masters the grim and the dumb." - Marshall McLuhan, 1969 http://www.ChaosReigns.com From deisner at gmail.com Tue Nov 9 11:51:41 2010 From: deisner at gmail.com (David Eisner) Date: Tue, 9 Nov 2010 14:51:41 -0500 Subject: Network transparency argument In-Reply-To: <20101109184825.GD13517@chaosreigns.com> References: <201011091649.01941.markc@renta.net> <20101109184825.GD13517@chaosreigns.com> Message-ID: On Tue, Nov 9, 2010 at 1:48 PM, wrote: > The "network transparency argument" is pointless because network > transparency via the X protocol will never go away. > > I think people who are concerned about this must not be aware that X > clients already run seamlessly with Windows or Mac OS as the native > graphical environment. Such ignorance may account for some concern. But even those who know that Wayland will support an X Server Wayland Client might be worried for the following reason: Should Wayland become ubiquitous on the Free desktop, it may come to pass that most (non-browser-hosted) apps will be written as native Wayland clients. Let's say you really need to run AppFoo on a remote system. If AppFoo isn't an X client, you're out of luck. Now that's not necessarily a show-stopper -- VNC or SPICE might be good enough. And if the app is built using a suitable toolkit (e.g. Qt) then it should be possible to compile it as an X client or a Wayland app, if it is written carefully. The compromises necessary to build network transparency into Wayland may not be worth the trouble (I don't know enough to say whether this is so). But it's not necessarily the case that those raising the issue aren't aware that they'll be able to run X apps on Wayland. -David -- David Eisner? ?? http://cradle.brokenglass.com From Darxus at chaosreigns.com Tue Nov 9 12:02:04 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Tue, 9 Nov 2010 15:02:04 -0500 Subject: Network transparency argument In-Reply-To: References: <201011091649.01941.markc@renta.net> <20101109184825.GD13517@chaosreigns.com> Message-ID: <20101109200204.GE13517@chaosreigns.com> On 11/09, David Eisner wrote: > good enough. And if the app is built using a suitable toolkit (e.g. > Qt) then it should be possible to compile it as an X client or a > Wayland app, if it is written carefully. As I already said: On 11/09, Darxus at chaosreigns.com wrote: > I expect the major graphics libraries (GTK and Qt) to add Wayland > support as a run time option, so applications using them will not lose > the ability to connect directly to an X server over a network. There's no reason to expect most apps won't be able to connect to both Wayland and X without a recompile. Ever. -- "Some people will tell you that slow is good - and it may be, on some days - but I am here to tell you that fast is better.... That is why God made fast motorcycles...." - Hunter S. Thompson http://www.ChaosReigns.com From jonsmirl at gmail.com Tue Nov 9 12:07:29 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Tue, 9 Nov 2010 15:07:29 -0500 Subject: Network transparency argument In-Reply-To: <20101109184825.GD13517@chaosreigns.com> References: <201011091649.01941.markc@renta.net> <20101109184825.GD13517@chaosreigns.com> Message-ID: On Tue, Nov 9, 2010 at 1:48 PM, wrote: > I was hoping that this subject just wouldn't get any replies. > > The "network transparency argument" is pointless because network > transparency via the X protocol will never go away. I'd like to see X declared to be a legacy API. Look at what HTML5 (on GL) does and compare it to the X protocol. Don't think of HTML5 as just an Internet protocol; they are both client server protocols for implementing GUIs. You can run the client and the server on the same box just like you do with the Xserver. Tell me which protocol is better. I wonder if Ubuntu will go all the way and turn Unity into an HTML5 app. -- Jon Smirl jonsmirl at gmail.com From mostawesomedude at gmail.com Tue Nov 9 11:59:46 2010 From: mostawesomedude at gmail.com (Corbin Simpson) Date: Tue, 9 Nov 2010 11:59:46 -0800 Subject: Network transparency argument In-Reply-To: References: <201011091649.01941.markc@renta.net> <20101109184825.GD13517@chaosreigns.com> Message-ID: Indeed. What's really amazing to me is that people are not realizing that one of the founding principles of Wayland is no uniform rendering API. This precludes remote apps because the only way to render is directly, without Wayland's help. The other path just leads back to X. Sending from a mobile, pardon the brevity. ~ C. On Nov 9, 2010 11:52 AM, "David Eisner" wrote: > On Tue, Nov 9, 2010 at 1:48 PM, wrote: >> The "network transparency argument" is pointless because network >> transparency via the X protocol will never go away. >> >> I think people who are concerned about this must not be aware that X >> clients already run seamlessly with Windows or Mac OS as the native >> graphical environment. > > Such ignorance may account for some concern. But even those who know > that Wayland will support an X Server Wayland Client might be worried > for the following reason: Should Wayland become ubiquitous on the Free > desktop, it may come to pass that most (non-browser-hosted) apps will > be written as native Wayland clients. Let's say you really need to run > AppFoo on a remote system. If AppFoo isn't an X client, you're out of > luck. > > Now that's not necessarily a show-stopper -- VNC or SPICE might be > good enough. And if the app is built using a suitable toolkit (e.g. > Qt) then it should be possible to compile it as an X client or a > Wayland app, if it is written carefully. > > The compromises necessary to build network transparency into Wayland > may not be worth the trouble (I don't know enough to say whether this > is so). But it's not necessarily the case that those raising the > issue aren't aware that they'll be able to run X apps on Wayland. > > -David > > -- > David Eisner http://cradle.brokenglass.com > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From krh at bitplanet.net Tue Nov 9 12:22:17 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Tue, 9 Nov 2010 15:22:17 -0500 Subject: Network transparency argument In-Reply-To: References: <201011091649.01941.markc@renta.net> <20101109184825.GD13517@chaosreigns.com> Message-ID: On Tue, Nov 9, 2010 at 2:51 PM, David Eisner wrote: > On Tue, Nov 9, 2010 at 1:48 PM, ? wrote: >> The "network transparency argument" is pointless because network >> transparency via the X protocol will never go away. >> >> I think people who are concerned about this must not be aware that X >> clients already run seamlessly with Windows or Mac OS as the native >> graphical environment. > > Such ignorance may account for some concern. ?But even those who know > that Wayland will support an X Server Wayland Client might be worried > for the following reason: Should Wayland become ubiquitous on the Free > desktop, it may come to pass that most (non-browser-hosted) apps will > be written as native Wayland clients. Let's say you really need to run > AppFoo on a remote system. ?If AppFoo isn't an X client, you're out of > luck. You're right, using X for remote applications is not a full answer. I do think HTML5 is a better answer than most people acknowledge, but at the same time I agree that there may be a need to run native wayland applications across the network. Wayland isn't a remote rendering API like X, but that doesn't exclude network transparency. Clients render into a shared buffer and then have to tell the compositor the what they changed. The compositor can then send the new pixels in that region out over the network. The wayland protocol is already violently asynchronous, so it should be able to handle a bit of network lag gracefully. Remote fullscreen video viewing or gaming isn't going to work well, I don't know any other display system that handles that well and transparently. Kristian From jonsmirl at gmail.com Tue Nov 9 12:43:58 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Tue, 9 Nov 2010 15:43:58 -0500 Subject: Network transparency argument In-Reply-To: References: <201011091649.01941.markc@renta.net> <20101109184825.GD13517@chaosreigns.com> Message-ID: 2010/11/9 Kristian H?gsberg : > On Tue, Nov 9, 2010 at 2:51 PM, David Eisner wrote: >> On Tue, Nov 9, 2010 at 1:48 PM, ? wrote: >>> The "network transparency argument" is pointless because network >>> transparency via the X protocol will never go away. >>> >>> I think people who are concerned about this must not be aware that X >>> clients already run seamlessly with Windows or Mac OS as the native >>> graphical environment. >> >> Such ignorance may account for some concern. ?But even those who know >> that Wayland will support an X Server Wayland Client might be worried >> for the following reason: Should Wayland become ubiquitous on the Free >> desktop, it may come to pass that most (non-browser-hosted) apps will >> be written as native Wayland clients. Let's say you really need to run >> AppFoo on a remote system. ?If AppFoo isn't an X client, you're out of >> luck. > > You're right, using X for remote applications is not a full answer. ?I > do think HTML5 is a better answer than most people acknowledge, but at People are definitely underestimating HTML5's capabilities, you can even play Quake in it: http://techcrunch.com/2010/04/01/google-html5-quake/ > the same time I agree that there may be a need to run native wayland > applications across the network. ?Wayland isn't a remote rendering API > like X, but that doesn't exclude network transparency. ?Clients render > into a shared buffer and then have to tell the compositor the what > they changed. ?The compositor can then send the new pixels in that > region out over the network. ?The wayland protocol is already > violently asynchronous, so it should be able to handle a bit of > network lag gracefully. ?Remote fullscreen video viewing or gaming > isn't going to work well, I don't know any other display system that > handles that well and transparently. > > Kristian > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jon Smirl jonsmirl at gmail.com From j.glisse at gmail.com Tue Nov 9 14:28:13 2010 From: j.glisse at gmail.com (Jerome Glisse) Date: Tue, 9 Nov 2010 17:28:13 -0500 Subject: Dri2 buffer format In-Reply-To: <4CD88DEA.5030205@netspace.net.au> References: <4CD81CA4.40009@netspace.net.au> <4CD88DEA.5030205@netspace.net.au> Message-ID: On Mon, Nov 8, 2010 at 6:55 PM, Russell Shaw wrote: > On 09/11/10 04:53, Jerome Glisse wrote: >> >> On Mon, Nov 8, 2010 at 10:52 AM, Russell Shaw >> ?wrote: >>> >>> Hi, >>> How should the "format" of a DRI2 buffer be determined? >>> >>> >>> http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt >>> >>> DRI2ATTACH_FORMAT { attachment: CARD32 >>> ? ? ? ? ? ?format: ? ? CARD32 } >>> >>> ? ?The DRI2ATTACH_FORMAT describes an attachment and the associated >>> ? ?format. ?'attachment' describes the attachment point for the buffer, >>> ? ?'format' describes an opaque, device-dependent format for the buffer. >>> >>> >> >> As the spec says, it's opaque and only the driver understand it, intel, >> radeon, nouveau all use different things i think. DRI2 is meant to be >> use btw different driver of same hw which should all understand each >> others. > > If it's opaque, how does one know what bytes are red/green/blue so that > you can draw a line in the right colour? This format is intend to be exchanged btw Xorg DDX driver for a given hw for instance the nouveau ddx and with the mesa or other dri2 driver like for instance the nouveau gallium driver. Both of this component understand each others. DRI2 is not mean to be use by end user application, it's only use by Xorg to comunicate with library such as opengl that want to provide direct rendering to X pixmap/window. Cheers, Jerome From j.glisse at gmail.com Tue Nov 9 14:34:21 2010 From: j.glisse at gmail.com (Jerome Glisse) Date: Tue, 9 Nov 2010 17:34:21 -0500 Subject: Wayland and GPU hotswapping In-Reply-To: <201011090853.32509.bluescreen_avenger@verizon.net> References: <201011090853.32509.bluescreen_avenger@verizon.net> Message-ID: On Tue, Nov 9, 2010 at 8:53 AM, nerdopolis wrote: > A feature that seems to be in some laptops, and is being worked into the Linux > kernel. > > Would Wayland ever be able to handle this, when the feature comes into Linux, > or would the display server always need to be reset? Outcome of discussion between Dave, Kristian, Jesse and me while ridding a bus is that we should add a way for wayland to ask its client to redraw their surface using a another EGL driver and that wayland server should be able to handle client reporting failure doing so. Maybe i did get this wrong, feel free to correct me :) I think to cover all use case Dave presented we should have somethings like this: -wayland provide a list of EGL driver it can texture from (optimus case where we can migrate texture from nvidia to intel) -wayland can ask to it's client to switch GL driver and report if they can switch or not (i think this should happen in 2 step first ask and gather answer from all client if one client says it can't then forbid the switch, otherwise ask to all client to redraw with new driver) All this wouldn't need restart from wayland. Cheers, Jerome From jbarnes at virtuousgeek.org Tue Nov 9 14:42:16 2010 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Tue, 9 Nov 2010 14:42:16 -0800 Subject: Wayland and GPU hotswapping In-Reply-To: References: <201011090853.32509.bluescreen_avenger@verizon.net> Message-ID: <20101109144216.6f48bcbf@jbarnes-desktop> On Tue, 9 Nov 2010 17:34:21 -0500 Jerome Glisse wrote: > On Tue, Nov 9, 2010 at 8:53 AM, nerdopolis > wrote: > > A feature that seems to be in some laptops, and is being worked into the Linux > > kernel. > > > > Would Wayland ever be able to handle this, when the feature comes into Linux, > > or would the display server always need to be reset? > > Outcome of discussion between Dave, Kristian, Jesse and me while ridding a bus > is that we should add a way for wayland to ask its client to redraw > their surface > using a another EGL driver and that wayland server should be able to handle > client reporting failure doing so. Maybe i did get this wrong, feel > free to correct me :) > > I think to cover all use case Dave presented we should have somethings > like this: > -wayland provide a list of EGL driver it can texture from (optimus case where we > can migrate texture from nvidia to intel) > -wayland can ask to it's client to switch GL driver and report if they > can switch or > not (i think this should happen in 2 step first ask and gather answer > from all client > if one client says it can't then forbid the switch, otherwise ask to > all client to redraw > with new driver) > > All this wouldn't need restart from wayland. Yeah, the big advantage of this approach is that it would allow apps to create a new context, check for extensions, etc when they receive a "hey time to switch" request. The alternative (shimming all the GL calls through a wrapper and advertising the intersection of the driver feature sets) is way more work and you end up with something that hurts performance and functionality. -- Jesse Barnes, Intel Open Source Technology Center From tiago.vignatti at nokia.com Tue Nov 9 16:42:35 2010 From: tiago.vignatti at nokia.com (Tiago Vignatti) Date: Wed, 10 Nov 2010 02:42:35 +0200 Subject: [PATCH] compositor: add safety check when EGL fails to initialize Message-ID: <1289349755-23478-1-git-send-email-tiago.vignatti@nokia.com> offending message: Program received signal SIGSEGV, Segmentation fault. create_pointer_images (ec=0x619f10) at compositor.c:240 240 glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, Signed-off-by: Tiago Vignatti --- Hello, This trivial patch is to celebrate and earn the amount of time I spent to make this all work on my system. So: nouveau + gallium + egl + wayland under xorg = victory \o/ compositor/compositor-x11.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/compositor/compositor-x11.c b/compositor/compositor-x11.c index f55b30e..5178873 100644 --- a/compositor/compositor-x11.c +++ b/compositor/compositor-x11.c @@ -659,7 +659,8 @@ x11_compositor_create(struct wl_display *display, int width, int height) x11_compositor_get_resources(c); c->base.wl_display = display; - x11_compositor_init_egl(c); + if (x11_compositor_init_egl(c) < 0) + return NULL; /* Can't init base class until we have a current egl context */ if (wlsc_compositor_init(&c->base, display) < 0) -- 1.7.0.4 From rjshaw at netspace.net.au Tue Nov 9 17:30:11 2010 From: rjshaw at netspace.net.au (Russell Shaw) Date: Wed, 10 Nov 2010 12:30:11 +1100 Subject: Dri2 buffer format In-Reply-To: References: <4CD81CA4.40009@netspace.net.au> <4CD88DEA.5030205@netspace.net.au> Message-ID: <4CD9F5A3.1020101@netspace.net.au> On 10/11/10 09:28, Jerome Glisse wrote: > On Mon, Nov 8, 2010 at 6:55 PM, Russell Shaw wrote: >> On 09/11/10 04:53, Jerome Glisse wrote: >>> >>> On Mon, Nov 8, 2010 at 10:52 AM, Russell Shaw >>> wrote: >>>> >>>> Hi, >>>> How should the "format" of a DRI2 buffer be determined? >>>> >>>> >>>> http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt >>>> >>>> DRI2ATTACH_FORMAT { attachment: CARD32 >>>> format: CARD32 } >>>> >>>> The DRI2ATTACH_FORMAT describes an attachment and the associated >>>> format. 'attachment' describes the attachment point for the buffer, >>>> 'format' describes an opaque, device-dependent format for the buffer. >>>> >>>> >>> >>> As the spec says, it's opaque and only the driver understand it, intel, >>> radeon, nouveau all use different things i think. DRI2 is meant to be >>> use btw different driver of same hw which should all understand each >>> others. >> >> If it's opaque, how does one know what bytes are red/green/blue so that >> you can draw a line in the right colour? > > This format is intend to be exchanged btw Xorg DDX driver for a given > hw for instance the nouveau ddx and with the mesa or other dri2 driver > like for instance the nouveau gallium driver. Both of this component > understand each others. > > DRI2 is not mean to be use by end user application, it's only use by > Xorg to comunicate with library such as opengl that want to provide > direct rendering to X pixmap/window. Ok. How do i plot a pixel in Wayland? I'm not using gtk/qt/OpenGL/OpenVG etc. From jbarnes at virtuousgeek.org Tue Nov 9 17:32:47 2010 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Tue, 9 Nov 2010 17:32:47 -0800 Subject: Dri2 buffer format In-Reply-To: <4CD9F5A3.1020101@netspace.net.au> References: <4CD81CA4.40009@netspace.net.au> <4CD88DEA.5030205@netspace.net.au> <4CD9F5A3.1020101@netspace.net.au> Message-ID: <20101109173247.348d29ac@jbarnes-desktop> On Wed, 10 Nov 2010 12:30:11 +1100 Russell Shaw wrote: > On 10/11/10 09:28, Jerome Glisse wrote: > > On Mon, Nov 8, 2010 at 6:55 PM, Russell Shaw wrote: > >> On 09/11/10 04:53, Jerome Glisse wrote: > >>> > >>> On Mon, Nov 8, 2010 at 10:52 AM, Russell Shaw > >>> wrote: > >>>> > >>>> Hi, > >>>> How should the "format" of a DRI2 buffer be determined? > >>>> > >>>> > >>>> http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt > >>>> > >>>> DRI2ATTACH_FORMAT { attachment: CARD32 > >>>> format: CARD32 } > >>>> > >>>> The DRI2ATTACH_FORMAT describes an attachment and the associated > >>>> format. 'attachment' describes the attachment point for the buffer, > >>>> 'format' describes an opaque, device-dependent format for the buffer. > >>>> > >>>> > >>> > >>> As the spec says, it's opaque and only the driver understand it, intel, > >>> radeon, nouveau all use different things i think. DRI2 is meant to be > >>> use btw different driver of same hw which should all understand each > >>> others. > >> > >> If it's opaque, how does one know what bytes are red/green/blue so that > >> you can draw a line in the right colour? > > > > This format is intend to be exchanged btw Xorg DDX driver for a given > > hw for instance the nouveau ddx and with the mesa or other dri2 driver > > like for instance the nouveau gallium driver. Both of this component > > understand each others. > > > > DRI2 is not mean to be use by end user application, it's only use by > > Xorg to comunicate with library such as opengl that want to provide > > direct rendering to X pixmap/window. > > Ok. How do i plot a pixel in Wayland? I'm not using gtk/qt/OpenGL/OpenVG etc. Allocate an shm buffer based on an mmap you've done in your client. Then you can draw to it and notify wayland of the damage. -- Jesse Barnes, Intel Open Source Technology Center From rjshaw at netspace.net.au Tue Nov 9 17:43:56 2010 From: rjshaw at netspace.net.au (Russell Shaw) Date: Wed, 10 Nov 2010 12:43:56 +1100 Subject: Dri2 buffer format In-Reply-To: <20101109173247.348d29ac@jbarnes-desktop> References: <4CD81CA4.40009@netspace.net.au> <4CD88DEA.5030205@netspace.net.au> <4CD9F5A3.1020101@netspace.net.au> <20101109173247.348d29ac@jbarnes-desktop> Message-ID: <4CD9F8DC.50904@netspace.net.au> On 10/11/10 12:32, Jesse Barnes wrote: > On Wed, 10 Nov 2010 12:30:11 +1100 > Russell Shaw wrote: > >> On 10/11/10 09:28, Jerome Glisse wrote: >>> On Mon, Nov 8, 2010 at 6:55 PM, Russell Shaw wrote: >>>> On 09/11/10 04:53, Jerome Glisse wrote: >>>>> >>>>> On Mon, Nov 8, 2010 at 10:52 AM, Russell Shaw >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> How should the "format" of a DRI2 buffer be determined? >>>>>> >>>>>> >>>>>> http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt >>>>>> >>>>>> DRI2ATTACH_FORMAT { attachment: CARD32 >>>>>> format: CARD32 } >>>>>> >>>>>> The DRI2ATTACH_FORMAT describes an attachment and the associated >>>>>> format. 'attachment' describes the attachment point for the buffer, >>>>>> 'format' describes an opaque, device-dependent format for the buffer. >>>>>> >>>>>> >>>>> >>>>> As the spec says, it's opaque and only the driver understand it, intel, >>>>> radeon, nouveau all use different things i think. DRI2 is meant to be >>>>> use btw different driver of same hw which should all understand each >>>>> others. >>>> >>>> If it's opaque, how does one know what bytes are red/green/blue so that >>>> you can draw a line in the right colour? >>> >>> This format is intend to be exchanged btw Xorg DDX driver for a given >>> hw for instance the nouveau ddx and with the mesa or other dri2 driver >>> like for instance the nouveau gallium driver. Both of this component >>> understand each others. >>> >>> DRI2 is not mean to be use by end user application, it's only use by >>> Xorg to comunicate with library such as opengl that want to provide >>> direct rendering to X pixmap/window. >> >> Ok. How do i plot a pixel in Wayland? I'm not using gtk/qt/OpenGL/OpenVG etc. > > Allocate an shm buffer based on an mmap you've done in your client. > Then you can draw to it and notify wayland of the damage. Ok. I'm already using shm buffers in X. Is there example code in wayland of getting the shm pixel format? (i couldn't see one last time i looked) From krh at bitplanet.net Tue Nov 9 17:47:10 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Tue, 9 Nov 2010 20:47:10 -0500 Subject: Dri2 buffer format In-Reply-To: <4CD9F8DC.50904@netspace.net.au> References: <4CD81CA4.40009@netspace.net.au> <4CD88DEA.5030205@netspace.net.au> <4CD9F5A3.1020101@netspace.net.au> <20101109173247.348d29ac@jbarnes-desktop> <4CD9F8DC.50904@netspace.net.au> Message-ID: On Tue, Nov 9, 2010 at 8:43 PM, Russell Shaw wrote: > On 10/11/10 12:32, Jesse Barnes wrote: >> >> On Wed, 10 Nov 2010 12:30:11 +1100 >> Russell Shaw ?wrote: >> >>> On 10/11/10 09:28, Jerome Glisse wrote: >>>> >>>> On Mon, Nov 8, 2010 at 6:55 PM, Russell Shaw >>>> wrote: >>>>> >>>>> On 09/11/10 04:53, Jerome Glisse wrote: >>>>>> >>>>>> On Mon, Nov 8, 2010 at 10:52 AM, Russell Shaw >>>>>> ? wrote: >>>>>>> >>>>>>> Hi, >>>>>>> How should the "format" of a DRI2 buffer be determined? >>>>>>> >>>>>>> >>>>>>> http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt >>>>>>> >>>>>>> DRI2ATTACH_FORMAT { attachment: CARD32 >>>>>>> ? ? ? ? ? ? format: ? ? CARD32 } >>>>>>> >>>>>>> ? ? The DRI2ATTACH_FORMAT describes an attachment and the associated >>>>>>> ? ? format. ?'attachment' describes the attachment point for the >>>>>>> buffer, >>>>>>> ? ? 'format' describes an opaque, device-dependent format for the >>>>>>> buffer. >>>>>>> >>>>>>> >>>>>> >>>>>> As the spec says, it's opaque and only the driver understand it, >>>>>> intel, >>>>>> radeon, nouveau all use different things i think. DRI2 is meant to be >>>>>> use btw different driver of same hw which should all understand each >>>>>> others. >>>>> >>>>> If it's opaque, how does one know what bytes are red/green/blue so that >>>>> you can draw a line in the right colour? >>>> >>>> This format is intend to be exchanged btw Xorg DDX driver for a given >>>> hw for instance the nouveau ddx and with the mesa or other dri2 driver >>>> like for instance the nouveau gallium driver. Both of this component >>>> understand each others. >>>> >>>> DRI2 is not mean to be use by end user application, it's only use by >>>> Xorg to comunicate with library such as opengl that want to provide >>>> direct rendering to X pixmap/window. >>> >>> Ok. How do i plot a pixel in Wayland? I'm not using gtk/qt/OpenGL/OpenVG >>> etc. >> >> Allocate an shm buffer based on an mmap you've done in your client. >> Then you can draw to it and notify wayland of the damage. > > Ok. I'm already using shm buffers in X. Is there example code in wayland > of getting the shm pixel format? (i couldn't see one last time i looked) Look at the smoke.c example. Kristian From krh at bitplanet.net Tue Nov 9 17:48:53 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Tue, 9 Nov 2010 20:48:53 -0500 Subject: [PATCH] compositor: add safety check when EGL fails to initialize In-Reply-To: <1289349755-23478-1-git-send-email-tiago.vignatti@nokia.com> References: <1289349755-23478-1-git-send-email-tiago.vignatti@nokia.com> Message-ID: On Tue, Nov 9, 2010 at 7:42 PM, Tiago Vignatti wrote: > offending message: > > ? ?Program received signal SIGSEGV, Segmentation fault. > ? ?create_pointer_images (ec=0x619f10) at compositor.c:240 > ? ?240 ? ? ? ? glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, > > Signed-off-by: Tiago Vignatti > --- > Hello, > > This trivial patch is to celebrate and earn the amount of time I spent to make > this all work on my system. So: nouveau + gallium + egl + wayland under xorg = > victory \o/ Very nice, patch applied. Kristian > ?compositor/compositor-x11.c | ? ?3 ++- > ?1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/compositor/compositor-x11.c b/compositor/compositor-x11.c > index f55b30e..5178873 100644 > --- a/compositor/compositor-x11.c > +++ b/compositor/compositor-x11.c > @@ -659,7 +659,8 @@ x11_compositor_create(struct wl_display *display, int width, int height) > ? ? ? ?x11_compositor_get_resources(c); > > ? ? ? ?c->base.wl_display = display; > - ? ? ? x11_compositor_init_egl(c); > + ? ? ? if (x11_compositor_init_egl(c) < 0) > + ? ? ? ?return NULL; > > ? ? ? ?/* Can't init base class until we have a current egl context */ > ? ? ? ?if (wlsc_compositor_init(&c->base, display) < 0) > -- > 1.7.0.4 > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From rjshaw at netspace.net.au Tue Nov 9 18:11:44 2010 From: rjshaw at netspace.net.au (Russell Shaw) Date: Wed, 10 Nov 2010 13:11:44 +1100 Subject: Dri2 buffer format In-Reply-To: References: <4CD81CA4.40009@netspace.net.au> <4CD88DEA.5030205@netspace.net.au> <4CD9F5A3.1020101@netspace.net.au> <20101109173247.348d29ac@jbarnes-desktop> <4CD9F8DC.50904@netspace.net.au> Message-ID: <4CD9FF60.70106@netspace.net.au> On 10/11/10 12:47, Kristian H?gsberg wrote: > On Tue, Nov 9, 2010 at 8:43 PM, Russell Shaw wrote: >> On 10/11/10 12:32, Jesse Barnes wrote: ... >>>>> DRI2 is not mean to be use by end user application, it's only use by >>>>> Xorg to comunicate with library such as opengl that want to provide >>>>> direct rendering to X pixmap/window. >>>> >>>> Ok. How do i plot a pixel in Wayland? I'm not using gtk/qt/OpenGL/OpenVG >>>> etc. >>> >>> Allocate an shm buffer based on an mmap you've done in your client. >>> Then you can draw to it and notify wayland of the damage. >> >> Ok. I'm already using shm buffers in X. Is there example code in wayland >> of getting the shm pixel format? (i couldn't see one last time i looked) > > Look at the smoke.c example. Hi, smoke.c uses cairo http://cairographics.org/ I don't want cairo. Please could i have that one bit of code for the pixel format?:) From olvaffe at gmail.com Tue Nov 9 21:37:28 2010 From: olvaffe at gmail.com (Chia-I Wu) Date: Wed, 10 Nov 2010 13:37:28 +0800 Subject: which library should OpenGL ES clients link to? Message-ID: Hi list, I am curious which library should, say, gears links to when it is ported to OpenGL ES 2.0. libGL.so or libGLESv2.so? I'd like to say libGLESv2, but cairo links to libGL and there is going to be a conflict: both libraries export _glapi_tls_Dispatch for current dispatch table. It is not possible to tell which _glapi_tls_Dispatch eglMakeCurrent will update and which one glDrawArrays will use. -- olv at LunarG.com From krh at bitplanet.net Wed Nov 10 05:44:27 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Wed, 10 Nov 2010 08:44:27 -0500 Subject: [PATCH] README: fix a few typos In-Reply-To: <20101109063125.GA17588@salty.local> References: <20101109063125.GA17588@salty.local> Message-ID: On Tue, Nov 9, 2010 at 1:31 AM, Peter Hutterer wrote: > And one in the main.tex spec document. Thanks, applied Kristian > Signed-off-by: Peter Hutterer > --- > ?README ? ? ? ?| ? ?6 +++--- > ?spec/main.tex | ? ?2 +- > ?2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/README b/README > index 5b168d4..a23345c 100644 > --- a/README > +++ b/README > @@ -4,7 +4,7 @@ Wayland is a project to define a protocol for a compositor to talk to > ?its clients as well as a library implementation of the protocol. ?The > ?compositor can be a standalone display server running on Linux kernel > ?modesetting and evdev input devices, an X applications, or a wayland > -client itself. ?The clients can be traditional appliactions, X servers > +client itself. ?The clients can be traditional applications, X servers > ?(rootless or fullscreen) or other display servers. > > ?The wayland protocol is essentially only about input handling and > @@ -64,7 +64,7 @@ libxkbcommon > > ?Wayland needs libxkbcommon for translating evdev keycodes to keysyms. > ?There's a couple of repos around, and we're trying to consolidate the > -development, but for wayland you'll need the repo from my get > +development, but for wayland you'll need the repo from my git > ?repository. ?For this you'll need development packages for xproto, > ?kbproto and libX11. > > @@ -76,7 +76,7 @@ kbproto and libX11. > > ?cairo-gl > > -The Waland clients render using cairo-gl, which is an experimental > +The Wayland clients render using cairo-gl, which is an experimental > ?cairo backend. ?It has been available since cairo 1.10. ?Unless your > ?distribution ships cairo with the gl backend enabled, you'll need to > ?compile your own version of cairo: > diff --git a/spec/main.tex b/spec/main.tex > index 41e0367..8c512be 100644 > --- a/spec/main.tex > +++ b/spec/main.tex > @@ -68,7 +68,7 @@ languages, but that hasn't been done at this point. > ?The server sends back events to the client, each event is emitted from > ?an object. ?Events can be error conditions. ?The event includes the > ?object id and the event opcode, from which the client can determine > -the type of event. ?Events are generated both in repsonse to a request > +the type of event. ?Events are generated both in response to a request > ?(in which case the request and the event constitutes a round trip) or > ?spontanously when the server state changes. > > -- > 1.7.2.3 > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From krh at bitplanet.net Wed Nov 10 06:02:04 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Wed, 10 Nov 2010 09:02:04 -0500 Subject: which library should OpenGL ES clients link to? In-Reply-To: References: Message-ID: On Wed, Nov 10, 2010 at 12:37 AM, Chia-I Wu wrote: > Hi list, > > I am curious which library should, say, gears links to when it is > ported to OpenGL ES 2.0. ?libGL.so or libGLESv2.so? ?I'd like to say > libGLESv2, but cairo links to libGL and there is going to be a > conflict: both libraries export _glapi_tls_Dispatch for current > dispatch table. ?It is not possible to tell which _glapi_tls_Dispatch > eglMakeCurrent will update and which one glDrawArrays will use. Yup, that is a problem. Ideally cairo-gl should support GL and GLES2, maybe even dlopen libGL.so or libGLESv2.so at runtime so we could support both in one cairo build. As it is now, it's just hardcoded full GL support. cairo-gl isn't a core dependency for wayland though, just for the demo clients. Qt, for example, lets you select GL, GLES1 or GLES2 at compile time, which is then used for the entire stack. Cairo gl uses glew for looking up extensions, but I think it would make sense to just use a cairo-specific function table that would hold the required core functions as well as the extension functions needed by cairo. That way you can specify the GL dialect at runtime and cairo-gl will open the right .so and lookup the necessary extension functions for that dialect. For the demo clients, it may be nice to move the cairo dependency out of the toytoolkit, but even then, the toy toolkit still has to use libGL, since otherwise it won't work with cairo-gl. Kristian From j.glisse at gmail.com Wed Nov 10 06:22:42 2010 From: j.glisse at gmail.com (Jerome Glisse) Date: Wed, 10 Nov 2010 09:22:42 -0500 Subject: Dri2 buffer format In-Reply-To: <4CD9FF60.70106@netspace.net.au> References: <4CD81CA4.40009@netspace.net.au> <4CD88DEA.5030205@netspace.net.au> <4CD9F5A3.1020101@netspace.net.au> <20101109173247.348d29ac@jbarnes-desktop> <4CD9F8DC.50904@netspace.net.au> <4CD9FF60.70106@netspace.net.au> Message-ID: On Tue, Nov 9, 2010 at 9:11 PM, Russell Shaw wrote: > On 10/11/10 12:47, Kristian H?gsberg wrote: >> >> On Tue, Nov 9, 2010 at 8:43 PM, Russell Shaw >> ?wrote: >>> >>> On 10/11/10 12:32, Jesse Barnes wrote: > > ... > >>>>>> DRI2 is not mean to be use by end user application, it's only use by >>>>>> Xorg to comunicate with library such as opengl that want to provide >>>>>> direct rendering to X pixmap/window. >>>>> >>>>> Ok. How do i plot a pixel in Wayland? I'm not using >>>>> gtk/qt/OpenGL/OpenVG >>>>> etc. >>>> >>>> Allocate an shm buffer based on an mmap you've done in your client. >>>> Then you can draw to it and notify wayland of the damage. >>> >>> Ok. I'm already using shm buffers in X. Is there example code in wayland >>> of getting the shm pixel format? (i couldn't see one last time i looked) >> >> Look at the smoke.c example. > > Hi, > smoke.c uses cairo http://cairographics.org/ > I don't want cairo. > > Please could i have that one bit of code for the pixel format?:) Wayland is not intended to work that way, GPU might pack pixel in strange format (especialy newer GPU where sometimes you can only use tiled buffer). The format of the buffer that GPU can understand would thus vary from one GPU to another, making any application which try to directly access pixel non portable at all. The format of the underlying buffer should thus only be understable by the associated GPU driver (wayland use EGL driver and in your app you can use another api as long as it has a driver for the GPU but i could only encourage anyone to stick to api such as EGL or cairo GL as this have proper driver for all 3 big GPU amd,intel &nividia) Cheers, Jerome From olvaffe at gmail.com Wed Nov 10 06:36:45 2010 From: olvaffe at gmail.com (Chia-I Wu) Date: Wed, 10 Nov 2010 22:36:45 +0800 Subject: which library should OpenGL ES clients link to? In-Reply-To: References: Message-ID: 2010/11/10 Kristian H?gsberg : > On Wed, Nov 10, 2010 at 12:37 AM, Chia-I Wu wrote: >> Hi list, >> >> I am curious which library should, say, gears links to when it is >> ported to OpenGL ES 2.0. ?libGL.so or libGLESv2.so? ?I'd like to say >> libGLESv2, but cairo links to libGL and there is going to be a >> conflict: both libraries export _glapi_tls_Dispatch for current >> dispatch table. ?It is not possible to tell which _glapi_tls_Dispatch >> eglMakeCurrent will update and which one glDrawArrays will use. > > Yup, that is a problem. ?Ideally cairo-gl should support GL and GLES2, > maybe even dlopen libGL.so or libGLESv2.so at runtime so we could > support both in one cairo build. ?As it is now, it's just hardcoded > full GL support. ?cairo-gl isn't a core dependency for wayland though, > just for the demo clients. ?Qt, for example, lets you select GL, GLES1 > or GLES2 at compile time, which is then used for the entire stack. > > Cairo gl uses glew for looking up extensions, but I think it would > make sense to just use a cairo-specific function table that would hold > the required core functions as well as the extension functions needed > by cairo. ?That way you can specify the GL dialect at runtime and > cairo-gl will open the right .so and lookup the necessary extension > functions for that dialect. > > For the demo clients, it may be nice to move the cairo dependency out > of the toytoolkit, but even then, the toy toolkit still has to use > libGL, since otherwise it won't work with cairo-gl. Yeah. Even cairo-gl supports both GL and GLES2 and load libGL.so or libGLESv2.so at runtime, it might still not be robust. What cairo-gl loads and what an app links to can still differ. The idea I have is to _not_ distribute libGLESv1_CM.so and libGLESv2.so at all on systems with libGL.so. An app or a library that uses GLES2 should always link to libGL.so and use eglGetProcAddress to find the addresses of the GLES2 functions. -- olv at LunarG.com From j.glisse at gmail.com Wed Nov 10 06:39:04 2010 From: j.glisse at gmail.com (Jerome Glisse) Date: Wed, 10 Nov 2010 09:39:04 -0500 Subject: which library should OpenGL ES clients link to? In-Reply-To: References: Message-ID: 2010/11/10 Kristian H?gsberg : > On Wed, Nov 10, 2010 at 12:37 AM, Chia-I Wu wrote: >> Hi list, >> >> I am curious which library should, say, gears links to when it is >> ported to OpenGL ES 2.0. ?libGL.so or libGLESv2.so? ?I'd like to say >> libGLESv2, but cairo links to libGL and there is going to be a >> conflict: both libraries export _glapi_tls_Dispatch for current >> dispatch table. ?It is not possible to tell which _glapi_tls_Dispatch >> eglMakeCurrent will update and which one glDrawArrays will use. > > Yup, that is a problem. ?Ideally cairo-gl should support GL and GLES2, > maybe even dlopen libGL.so or libGLESv2.so at runtime so we could > support both in one cairo build. ?As it is now, it's just hardcoded > full GL support. ?cairo-gl isn't a core dependency for wayland though, > just for the demo clients. ?Qt, for example, lets you select GL, GLES1 > or GLES2 at compile time, which is then used for the entire stack. > > Cairo gl uses glew for looking up extensions, but I think it would > make sense to just use a cairo-specific function table that would hold > the required core functions as well as the extension functions needed > by cairo. ?That way you can specify the GL dialect at runtime and > cairo-gl will open the right .so and lookup the necessary extension > functions for that dialect. > > For the demo clients, it may be nice to move the cairo dependency out > of the toytoolkit, but even then, the toy toolkit still has to use > libGL, since otherwise it won't work with cairo-gl. > > Kristian Side question to this how to pick which GPU to use at runtime ? (i haven't looked at how EGL create it's context and how we pick which driver to use inside EGL but i guess there is some mecanism and i think we should worry about this early as this is an important feature for multi-GPU support). Cheers, Jerome From rjshaw at netspace.net.au Wed Nov 10 06:39:36 2010 From: rjshaw at netspace.net.au (Russell Shaw) Date: Thu, 11 Nov 2010 01:39:36 +1100 Subject: Dri2 buffer format In-Reply-To: References: <4CD81CA4.40009@netspace.net.au> <4CD88DEA.5030205@netspace.net.au> <4CD9F5A3.1020101@netspace.net.au> <20101109173247.348d29ac@jbarnes-desktop> <4CD9F8DC.50904@netspace.net.au> <4CD9FF60.70106@netspace.net.au> Message-ID: <4CDAAEA8.9020205@netspace.net.au> On 11/11/10 01:22, Jerome Glisse wrote: > On Tue, Nov 9, 2010 at 9:11 PM, Russell Shaw wrote: >> On 10/11/10 12:47, Kristian H?gsberg wrote: >>> >>> On Tue, Nov 9, 2010 at 8:43 PM, Russell Shaw >>> wrote: >>>> >>>> On 10/11/10 12:32, Jesse Barnes wrote: >> >> ... >> >>>>>>> DRI2 is not mean to be use by end user application, it's only use by >>>>>>> Xorg to comunicate with library such as opengl that want to provide >>>>>>> direct rendering to X pixmap/window. >>>>>> >>>>>> Ok. How do i plot a pixel in Wayland? I'm not using >>>>>> gtk/qt/OpenGL/OpenVG >>>>>> etc. >>>>> >>>>> Allocate an shm buffer based on an mmap you've done in your client. >>>>> Then you can draw to it and notify wayland of the damage. >>>> >>>> Ok. I'm already using shm buffers in X. Is there example code in wayland >>>> of getting the shm pixel format? (i couldn't see one last time i looked) >>> >>> Look at the smoke.c example. >> >> Hi, >> smoke.c uses cairo http://cairographics.org/ >> I don't want cairo. >> >> Please could i have that one bit of code for the pixel format?:) > > Wayland is not intended to work that way, GPU might pack pixel in strange > format (especialy newer GPU where sometimes you can only use tiled > buffer). The format of the buffer that GPU can understand would thus vary > from one GPU to another, making any application which try to directly > access pixel non portable at all. > > The format of the underlying buffer should thus only be understable > by the associated GPU driver (wayland use EGL driver and in your > app you can use another api as long as it has a driver for the GPU > but i could only encourage anyone to stick to api such as EGL or > cairo GL as this have proper driver for all 3 big GPU amd,intel&nividia) Hi, I figured that out today. I'll adapt to that way. From olvaffe at gmail.com Wed Nov 10 06:49:11 2010 From: olvaffe at gmail.com (Chia-I Wu) Date: Wed, 10 Nov 2010 22:49:11 +0800 Subject: Dri2 buffer format In-Reply-To: References: <4CD81CA4.40009@netspace.net.au> <4CD88DEA.5030205@netspace.net.au> <4CD9F5A3.1020101@netspace.net.au> <20101109173247.348d29ac@jbarnes-desktop> <4CD9F8DC.50904@netspace.net.au> <4CD9FF60.70106@netspace.net.au> Message-ID: On Wed, Nov 10, 2010 at 10:22 PM, Jerome Glisse wrote: > On Tue, Nov 9, 2010 at 9:11 PM, Russell Shaw wrote: >> On 10/11/10 12:47, Kristian H?gsberg wrote: >>> >>> On Tue, Nov 9, 2010 at 8:43 PM, Russell Shaw >>> ?wrote: >>>> >>>> On 10/11/10 12:32, Jesse Barnes wrote: >> >> ... >> >>>>>>> DRI2 is not mean to be use by end user application, it's only use by >>>>>>> Xorg to comunicate with library such as opengl that want to provide >>>>>>> direct rendering to X pixmap/window. >>>>>> >>>>>> Ok. How do i plot a pixel in Wayland? I'm not using >>>>>> gtk/qt/OpenGL/OpenVG >>>>>> etc. >>>>> >>>>> Allocate an shm buffer based on an mmap you've done in your client. >>>>> Then you can draw to it and notify wayland of the damage. >>>> >>>> Ok. I'm already using shm buffers in X. Is there example code in wayland >>>> of getting the shm pixel format? (i couldn't see one last time i looked) >>> >>> Look at the smoke.c example. >> >> Hi, >> smoke.c uses cairo http://cairographics.org/ >> I don't want cairo. >> >> Please could i have that one bit of code for the pixel format?:) > > Wayland is not intended to work that way, GPU might pack pixel in strange > format (especialy newer GPU where sometimes you can only use tiled > buffer). The format of the buffer that GPU can understand would thus vary > from one GPU to another, making any application which try to directly > access pixel non portable at all. > > The format of the underlying buffer should thus only be understable > by the associated GPU driver (wayland use EGL driver and in your > app you can use another api as long as it has a driver for the GPU > but i could only encourage anyone to stick to api such as EGL or > cairo GL as this have proper driver for all 3 big GPU amd,intel &nividia) Though I think it is a good idea to be able to lock/unlock a buffer for CPU access. It is what libkms does. But in light of EGL_MESA_drm_image, it could be EGL_MESA_drm_image_cpu: eglLockDRMImageMESA - maps an image for CPU access eglUnlockDRMImageMESA - unmap and flush changes > Cheers, > Jerome > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- olv at LunarG.com From krh at bitplanet.net Wed Nov 10 07:05:24 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Wed, 10 Nov 2010 10:05:24 -0500 Subject: Making Wayland Game-friendly In-Reply-To: References: Message-ID: On Tue, Nov 9, 2010 at 4:28 AM, Luke Benstead wrote: > Hi all, > > This is my first post to this list, and I fear it may be a lengthy one, so > bear with me :) > > Firstly, I may be totally off base with this. I'm working under the > assumption that once complete Wayland will take care of resolution changes > instead of xrandr (as xrandr is obviously an X extension). If someone could > point me to any information on resolution switching in Wayland I'd > appreciate it. > > So, the rest of this email is based on the assumption that Wayland has, or > will have, an API for switching resolution. If I'm wrong, just disregard :) Nope, you're spot on and I agree. Carsten Haitzler recently posted a good writeup on the good and bad things games do under X: http://lists.x.org/archives/xorg/2010-September/051152.html and at the end of the email he's proposing something similar to what you describe. I even think we shouldn't expose the full modesetting API to regular applications, just enough that they know the screen sizes and layout. Either the compositor can run a special client with access to the modesetting interface or changing the resolution and/or screen layout could just be part of the compositor. Either way, a native resolution fullscreen mode is definitely planned. Both scaling (with or without aspect ratio/black bars) and native modes (we can page flip directly to the applications buffer) make sense, but I think that will be policy/configuration options in the compositor. What will be in the protocol will be a way to request to be fullscreen, which the compositor will honor when the application has focus, but it will always be possible to alt-tab away (or press the "home button" or similar). So the compositor is in control, it will change the resolution, scale and draw black bars, or maybe even just center the application window and fade out the rest of the desktop around it. This also ties in with capturing the mouse pointer and relative events (which Carsten also talks about in his mail). Typically games also want to make sure the pointer stays inside the window and they want relative events. It's no good if you're trying to turn around in quake and the pointer leaves the window or hits the screen edge. X applications solve this by grabbing the mouse, confining it to the window and continuously warping the cursor into the center to simulate relative events. This is obviously a hack, and wayland isn't going to support open-ended pointer or keyboard grabs, nor warping the pointer. Instead, we provide relative events when the device generates them, and in fullscreen mode, all the events go to the fullscreen application, so no need to confine the pointer. Possibly, an application can request "application pointer", where the compositor hides the pointer when the fullscreen application receives focus, doesn't update its location and only sends relative events. This is a pointer mode that may be useful to allow when an application has a button grab as well (that is, grabbing the pointer for the duration of a button click). Anyway, this is all kinda half-baked, but it is the general direction I see this going. Kristian From krh at bitplanet.net Wed Nov 10 07:06:57 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Wed, 10 Nov 2010 10:06:57 -0500 Subject: which library should OpenGL ES clients link to? In-Reply-To: References: Message-ID: 2010/11/10 Jerome Glisse : > 2010/11/10 Kristian H?gsberg : >> On Wed, Nov 10, 2010 at 12:37 AM, Chia-I Wu wrote: >>> Hi list, >>> >>> I am curious which library should, say, gears links to when it is >>> ported to OpenGL ES 2.0. ?libGL.so or libGLESv2.so? ?I'd like to say >>> libGLESv2, but cairo links to libGL and there is going to be a >>> conflict: both libraries export _glapi_tls_Dispatch for current >>> dispatch table. ?It is not possible to tell which _glapi_tls_Dispatch >>> eglMakeCurrent will update and which one glDrawArrays will use. >> >> Yup, that is a problem. ?Ideally cairo-gl should support GL and GLES2, >> maybe even dlopen libGL.so or libGLESv2.so at runtime so we could >> support both in one cairo build. ?As it is now, it's just hardcoded >> full GL support. ?cairo-gl isn't a core dependency for wayland though, >> just for the demo clients. ?Qt, for example, lets you select GL, GLES1 >> or GLES2 at compile time, which is then used for the entire stack. >> >> Cairo gl uses glew for looking up extensions, but I think it would >> make sense to just use a cairo-specific function table that would hold >> the required core functions as well as the extension functions needed >> by cairo. ?That way you can specify the GL dialect at runtime and >> cairo-gl will open the right .so and lookup the necessary extension >> functions for that dialect. >> >> For the demo clients, it may be nice to move the cairo dependency out >> of the toytoolkit, but even then, the toy toolkit still has to use >> libGL, since otherwise it won't work with cairo-gl. >> >> Kristian > > Side question to this how to pick which GPU to use at runtime ? (i > haven't looked at how EGL create it's context and how we pick which > driver to use inside EGL but i guess there is some mecanism and i > think we should worry about this early as this is an important feature > for multi-GPU support). The drm interface in the wayland protocol will send out an event to tell you which dri device file to open. Kristian From kazade at gmail.com Wed Nov 10 07:16:05 2010 From: kazade at gmail.com (Luke Benstead) Date: Wed, 10 Nov 2010 15:16:05 +0000 Subject: Making Wayland Game-friendly In-Reply-To: References: Message-ID: 2010/11/10 Kristian H?gsberg > > Either way, a native resolution fullscreen mode is definitely planned. > Both scaling (with or without aspect ratio/black bars) and native > modes (we can page flip directly to the applications buffer) make > sense, but I think that will be policy/configuration options in the > compositor. What will be in the protocol will be a way to request to > be fullscreen, which the compositor will honor when the application > has focus, but it will always be possible to alt-tab away (or press > the "home button" or similar). So the compositor is in control, it > will change the resolution, scale and draw black bars, or maybe even > just center the application window and fade out the rest of the > desktop around it. > > Excellent! I can't wait for that! > This also ties in with capturing the mouse pointer and relative events > (which Carsten also talks about in his mail). Typically games also > want to make sure the pointer stays inside the window and they want > relative events. It's no good if you're trying to turn around in > quake and the pointer leaves the window or hits the screen edge. X > applications solve this by grabbing the mouse, confining it to the > window and continuously warping the cursor into the center to simulate > relative events. This is obviously a hack, and wayland isn't going to > support open-ended pointer or keyboard grabs, nor warping the pointer. > Instead, we provide relative events when the device generates them, > and in fullscreen mode, all the events go to the fullscreen > application, so no need to confine the pointer. > Brilliant, the Wine project will love you guys - they've had a nightmare with the lack of relative mouse info from X (until recently) - that is of course if/when they write a Wayland driver. > > Anyway, this is all kinda half-baked, but it is the general direction > I see this going. > > Kristian > Thanks Kristian! -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.glisse at gmail.com Wed Nov 10 08:09:32 2010 From: j.glisse at gmail.com (Jerome Glisse) Date: Wed, 10 Nov 2010 11:09:32 -0500 Subject: Dri2 buffer format In-Reply-To: References: <4CD81CA4.40009@netspace.net.au> <4CD88DEA.5030205@netspace.net.au> <4CD9F5A3.1020101@netspace.net.au> <20101109173247.348d29ac@jbarnes-desktop> <4CD9F8DC.50904@netspace.net.au> <4CD9FF60.70106@netspace.net.au> Message-ID: On Wed, Nov 10, 2010 at 9:49 AM, Chia-I Wu wrote: > On Wed, Nov 10, 2010 at 10:22 PM, Jerome Glisse wrote: >> On Tue, Nov 9, 2010 at 9:11 PM, Russell Shaw wrote: >>> On 10/11/10 12:47, Kristian H?gsberg wrote: >>>> >>>> On Tue, Nov 9, 2010 at 8:43 PM, Russell Shaw >>>> ?wrote: >>>>> >>>>> On 10/11/10 12:32, Jesse Barnes wrote: >>> >>> ... >>> >>>>>>>> DRI2 is not mean to be use by end user application, it's only use by >>>>>>>> Xorg to comunicate with library such as opengl that want to provide >>>>>>>> direct rendering to X pixmap/window. >>>>>>> >>>>>>> Ok. How do i plot a pixel in Wayland? I'm not using >>>>>>> gtk/qt/OpenGL/OpenVG >>>>>>> etc. >>>>>> >>>>>> Allocate an shm buffer based on an mmap you've done in your client. >>>>>> Then you can draw to it and notify wayland of the damage. >>>>> >>>>> Ok. I'm already using shm buffers in X. Is there example code in wayland >>>>> of getting the shm pixel format? (i couldn't see one last time i looked) >>>> >>>> Look at the smoke.c example. >>> >>> Hi, >>> smoke.c uses cairo http://cairographics.org/ >>> I don't want cairo. >>> >>> Please could i have that one bit of code for the pixel format?:) >> >> Wayland is not intended to work that way, GPU might pack pixel in strange >> format (especialy newer GPU where sometimes you can only use tiled >> buffer). The format of the buffer that GPU can understand would thus vary >> from one GPU to another, making any application which try to directly >> access pixel non portable at all. >> >> The format of the underlying buffer should thus only be understable >> by the associated GPU driver (wayland use EGL driver and in your >> app you can use another api as long as it has a driver for the GPU >> but i could only encourage anyone to stick to api such as EGL or >> cairo GL as this have proper driver for all 3 big GPU amd,intel &nividia) > Though I think it is a good idea to be able to lock/unlock a buffer > for CPU access. ?It is what libkms does. ?But in light of > EGL_MESA_drm_image, it could be EGL_MESA_drm_image_cpu: > > ?eglLockDRMImageMESA - maps an image for CPU access > ?eglUnlockDRMImageMESA - unmap and flush changes >> Cheers, >> Jerome My point was that in some GPU we might never have linear pixel packing, it might always be tiled. Thought i expect here is a way to until them using the GPU and retile them. Also the stride|pitch might not be evident. Of course we can hide that in EGL driver and driver might allocate temporary memory that will be easily accessible from CPU (linear and maybe return the pitch) and on unlock will update the GPU copy properly. That would still mean that app need to start an EGL context and allocate their buffer using EGL even thought they don't want to use EGL. But i am fine with that :) Cheers, Jerome From Darxus at chaosreigns.com Wed Nov 10 15:13:23 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Wed, 10 Nov 2010 18:13:23 -0500 Subject: Ubuntu Maverack nouveau (nvidia) build script for Wayland Message-ID: <20101110231323.GB24875@chaosreigns.com> http://www.chaosreigns.com/wayland/wayland_build.sh Run it in a temp directory (I use ~/wayland ). Installs everything into $HOME/install If you have an X server running using the nouveau (open source nvidia) drivers with DRI enabled, under Ubuntu Maverick, this will download and build everything, and then run wayland and a few clients. All you need to do to switch to nouveau with DRI is sudo aptitude install libgl1-mesa-dri-experimental usermod -a -G video darxus # where "darxus" is your username That package is in the official Maverick Universe repository. But it's still experimental, upstream is not even accepting bug reports, and may ignite your computer. Then disable the proprietary driver in System / Administration / Additional Drivers, and reboot. Verify DRI is working: $ glxinfo | grep direct direct rendering: Yes Then just run that script. Takes about 4 minutes on a quad core Pentium 4 2.40GHz, not including downloads. You'll probably want something like 'export MAKEFLAGS="-j 8"' to use multiple CPU cores while compiling. I don't recommend putting that LD_LIBRARY_PATH in your ~/.bashrc. When I had it in my /etc/ld.so.conf and rebooted, X didn't start, which isn't surprising. Stuff it rebuilds (all from git) (in order): drm mesa xproto kbproto macros libX11 libxkbcommon cairo wayland This is largely based on instructions from csj for use with an Intel video card: http://grep.tw/blog/?p=1061 Running the wayland compositor outside of X just gives me a screen full of garbage. -- "It is the first responsibility of every citizen to question authority." - Benjamin Franklin http://www.ChaosReigns.com From bluescreen_avenger at verizon.net Wed Nov 10 08:37:01 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Wed, 10 Nov 2010 11:37:01 -0500 Subject: Please Don't Use Cleint Side Window Decorations [RESEND] In-Reply-To: References: <201011032214.17126.bluescreen_avenger@verizon.net> Message-ID: <201011101137.01872.bluescreen_avenger@verizon.net> On Friday, November 05, 2010 03:21:48 pm Kristian H?gsberg wrote: > On Fri, Nov 5, 2010 at 2:07 PM, Luke Hutchison wrote: > > On Thu, Nov 4, 2010 at 6:50 PM, Corbin Simpson > > > > wrote: > >> On Thu, Nov 4, 2010 at 3:47 PM, nerdopolis wrote: > >> > I know X can still run as a Wayland client, but what if someone > >> > > >> > needs to run an app that runs on Wayland remotely? > >> > >> You can't. Run it in X instead. > > > > Based on the architectural overview on the new Wayland website, it > > seems that VNC/NX/SPICE could be made to work with Wayland. Are there > > technical reasons why this would be difficult? > > No, you're right, that's an option, just not a priority right now. > > Kristian Sorry, I forgot to hit "reply all"... As far as the Client side window decorations are concerned I read elseware http://smspillaz.wordpress.com/2010/11/07/compiz-in-a-strange-new- land/#comment-5018 that a custom compositor can draw its own decorations instead of the clients. If this is true, my question is how would clients know to not draw decorations on these compositors, to not get double titlebars? would it be a property flag that they can retrived? From bluescreen_avenger at verizon.net Wed Nov 10 08:38:34 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Wed, 10 Nov 2010 11:38:34 -0500 Subject: Wayland and GPU hotswapping [RESEND] In-Reply-To: <20101109144216.6f48bcbf@jbarnes-desktop> References: <201011090853.32509.bluescreen_avenger@verizon.net> <20101109144216.6f48bcbf@jbarnes-desktop> Message-ID: <201011101138.35139.bluescreen_avenger@verizon.net> On Tuesday, November 09, 2010 05:42:16 pm Jesse Barnes wrote: > On Tue, 9 Nov 2010 17:34:21 -0500 > > Jerome Glisse wrote: > > On Tue, Nov 9, 2010 at 8:53 AM, nerdopolis > > > > wrote: > > > A feature that seems to be in some laptops, and is being worked into > > > the Linux kernel. > > > > > > Would Wayland ever be able to handle this, when the feature comes into > > > Linux, or would the display server always need to be reset? > > > > Outcome of discussion between Dave, Kristian, Jesse and me while ridding > > a bus is that we should add a way for wayland to ask its client to > > redraw their surface > > using a another EGL driver and that wayland server should be able to > > handle client reporting failure doing so. Maybe i did get this wrong, > > feel free to correct me :) > > > > I think to cover all use case Dave presented we should have somethings > > like this: > > -wayland provide a list of EGL driver it can texture from (optimus case > > where we can migrate texture from nvidia to intel) > > -wayland can ask to it's client to switch GL driver and report if they > > can switch or > > not (i think this should happen in 2 step first ask and gather answer > > from all client > > if one client says it can't then forbid the switch, otherwise ask to > > all client to redraw > > with new driver) > > > > All this wouldn't need restart from wayland. > > Yeah, the big advantage of this approach is that it would allow apps to > create a new context, check for extensions, etc when they receive a > "hey time to switch" request. The alternative (shimming all the GL > calls through a wrapper and advertising the intersection of the > driver feature sets) is way more work and you end up with something > that hurts performance and functionality. Sorry, I forgot to hit "Reply to All"... Thats pretty slick... What about multiple GPU's and graphics cards? Would Wayland be able to spread across screens connected to different graphics cards? Would Wayland be able to load balance across multple GPU's? Like rendering one client on one GPU, and another client on another GPU before drawing it on the display? I know some computers have multiple GPUs that do this... From j.glisse at gmail.com Wed Nov 10 17:42:38 2010 From: j.glisse at gmail.com (Jerome Glisse) Date: Wed, 10 Nov 2010 20:42:38 -0500 Subject: Wayland and GPU hotswapping [RESEND] In-Reply-To: <201011101138.35139.bluescreen_avenger@verizon.net> References: <201011090853.32509.bluescreen_avenger@verizon.net> <20101109144216.6f48bcbf@jbarnes-desktop> <201011101138.35139.bluescreen_avenger@verizon.net> Message-ID: The design described here allow such things to happen modulo the restriction there is from the wayland server point of view (wayland need to be able to texture from the buffer of all GPU involved). Thought there is no policy in what we describe and i think it's better to stay out of this. For instance toolkit can add a properties that allow user to asign each app to a different gpu, toolkit can then even define some standard way of doing this. Cheers, Jerome Glisse On 11/10/10, nerdopolis wrote: > On Tuesday, November 09, 2010 05:42:16 pm Jesse Barnes wrote: >> On Tue, 9 Nov 2010 17:34:21 -0500 >> >> Jerome Glisse wrote: >> > On Tue, Nov 9, 2010 at 8:53 AM, nerdopolis >> > >> > wrote: >> > > A feature that seems to be in some laptops, and is being worked into >> > > the Linux kernel. >> > > >> > > Would Wayland ever be able to handle this, when the feature comes into >> > > Linux, or would the display server always need to be reset? >> > >> > Outcome of discussion between Dave, Kristian, Jesse and me while ridding >> > a bus is that we should add a way for wayland to ask its client to >> > redraw their surface >> > using a another EGL driver and that wayland server should be able to >> > handle client reporting failure doing so. Maybe i did get this wrong, >> > feel free to correct me :) >> > >> > I think to cover all use case Dave presented we should have somethings >> > like this: >> > -wayland provide a list of EGL driver it can texture from (optimus case >> > where we can migrate texture from nvidia to intel) >> > -wayland can ask to it's client to switch GL driver and report if they >> > can switch or >> > not (i think this should happen in 2 step first ask and gather answer >> > from all client >> > if one client says it can't then forbid the switch, otherwise ask to >> > all client to redraw >> > with new driver) >> > >> > All this wouldn't need restart from wayland. >> >> Yeah, the big advantage of this approach is that it would allow apps to >> create a new context, check for extensions, etc when they receive a >> "hey time to switch" request. The alternative (shimming all the GL >> calls through a wrapper and advertising the intersection of the >> driver feature sets) is way more work and you end up with something >> that hurts performance and functionality. > > Sorry, I forgot to hit "Reply to All"... > > Thats pretty slick... > > > What about multiple GPU's and graphics cards? > > Would Wayland be able to spread across screens connected to different > graphics > cards? > > Would Wayland be able to load balance across multple GPU's? Like rendering > one > client on one GPU, and another client on another GPU before drawing it on > the > display? I know some computers have multiple GPUs that do this... > From xinyunliu at gmail.com Thu Nov 11 00:32:17 2010 From: xinyunliu at gmail.com (Liu, Xinyun) Date: Thu, 11 Nov 2010 16:32:17 +0800 Subject: Run wayland on MeeGo with a netbook Message-ID: I can run the wayland in MeeGo successfully on an Aser netbook this afternoon. Here is video that shows wayland without X. http://www.youtube.com/watch?v=LAPwHYq-v6k I build it with a MeeGo 1.1 test image, that Pixman 1.9.4, cairo is 1.10.0 with GL support. And I replaced the following with specified version. cairo 7237eb62be34370b34e0ba31504b5ae2708e44e5 drm 877b2ce15b80975b4dac42657bdfb0a3da833e1c kbproto 6080b1839d556899ad456e60c46a925fcc285cb5 libX11 8cbca8a10761d1ea75a75bafa647632d6c0dac71 libxkbcommon f94a64cc08b47cdbfdfea5b5756340246fc391ed macros 04030cbca37c04c48161debc0cade6db00cb347b mesa dc524adee2cfd0f115800cd4ec3f8384010f154e wayland b97b28c339a94223119e122ab899f500d7a4bd9e xproto d441b9b0230b57159fa8522b80f18a0b87f5aac5 -- Best Regards, Liu, Xinyun From justinlee5455 at gmail.com Thu Nov 11 01:08:02 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Thu, 11 Nov 2010 17:08:02 +0800 Subject: Benchmark of Wayland Message-ID: Chris Wilson has been playing around with direct-rendered cairo (cairo-drm) http://cworth.org/talks/lca_2009/html/lca-2009-024.html http://linuxplumbersconf.org/ocw/proposals/29 and notice very promising results: * Gradients are 100x - 120x faster * Some painting operations are 50x faster * Text is 4x faster If I didn't get it wrong, Wayland apps are also direct-rendered. I'm not sure if Wayland runs on my video chip SiS 661 (I think it doesn't), but it seems there have been some successful builds and executions of Wayland as I can see in Wayland group and this list. It will be good if similar benchmark could be observed in Wayland. I expect Wayland will have the same order of performance as cairo-drm although it depends on hardware and driver. From chris at chris-wilson.co.uk Thu Nov 11 01:44:44 2010 From: chris at chris-wilson.co.uk (Chris Wilson) Date: Thu, 11 Nov 2010 09:44:44 +0000 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: On Thu, 11 Nov 2010 17:08:02 +0800, Justin Lee wrote: > It will be good if similar benchmark could be observed in Wayland. I > expect Wayland will have the same order of performance as cairo-drm > although it depends on hardware and driver. Yes Wayland will be as fast as a well written DDX. -Chris -- Chris Wilson, Intel Open Source Technology Centre From microcai at fedoraproject.org Thu Nov 11 03:37:42 2010 From: microcai at fedoraproject.org (microcai) Date: Thu, 11 Nov 2010 19:37:42 +0800 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: Wayland start a new age, when every one can write X server. We can't forget who bring us the new age, the EGL. Yes, if you can get GLcontext on raw framebuffer, then why can't we write X. So, next generation X should be fully hardware independent. X only depends on EGL and some basic system libs. X will no longer have driver as module of built-in, because it is the EGL and kernel that should manage the graphic hardware... EGL and DRM makes it possible that X is only a GL program ...... so , I just hope NVIDIA and AMD can provide there hardware's EGL library so that we can start using Wayland right away .... currently we just have Mesa's EGL.. too bad ..... Hope ubuntu's decision can make some difference ...... 2010/11/11 Chris Wilson > On Thu, 11 Nov 2010 17:08:02 +0800, Justin Lee > wrote: > > It will be good if similar benchmark could be observed in Wayland. I > > expect Wayland will have the same order of performance as cairo-drm > > although it depends on hardware and driver. > > Yes Wayland will be as fast as a well written DDX. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From microcai at fedoraproject.org Thu Nov 11 03:47:49 2010 From: microcai at fedoraproject.org (microcai) Date: Thu, 11 Nov 2010 19:47:49 +0800 Subject: which library should OpenGL ES clients link to? In-Reply-To: References: Message-ID: maybe better just just use symbolic to switch between EGL and XGL 2010/11/10 Kristian H?gsberg > On Wed, Nov 10, 2010 at 12:37 AM, Chia-I Wu wrote: > > Hi list, > > > > I am curious which library should, say, gears links to when it is > > ported to OpenGL ES 2.0. libGL.so or libGLESv2.so? I'd like to say > > libGLESv2, but cairo links to libGL and there is going to be a > > conflict: both libraries export _glapi_tls_Dispatch for current > > dispatch table. It is not possible to tell which _glapi_tls_Dispatch > > eglMakeCurrent will update and which one glDrawArrays will use. > > Yup, that is a problem. Ideally cairo-gl should support GL and GLES2, > maybe even dlopen libGL.so or libGLESv2.so at runtime so we could > support both in one cairo build. As it is now, it's just hardcoded > full GL support. cairo-gl isn't a core dependency for wayland though, > just for the demo clients. Qt, for example, lets you select GL, GLES1 > or GLES2 at compile time, which is then used for the entire stack. > > Cairo gl uses glew for looking up extensions, but I think it would > make sense to just use a cairo-specific function table that would hold > the required core functions as well as the extension functions needed > by cairo. That way you can specify the GL dialect at runtime and > cairo-gl will open the right .so and lookup the necessary extension > functions for that dialect. > > For the demo clients, it may be nice to move the cairo dependency out > of the toytoolkit, but even then, the toy toolkit still has to use > libGL, since otherwise it won't work with cairo-gl. > > Kristian > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krh at bitplanet.net Thu Nov 11 05:42:39 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Thu, 11 Nov 2010 08:42:39 -0500 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: On Thu, Nov 11, 2010 at 4:08 AM, Justin Lee wrote: > Chris Wilson has been playing around with direct-rendered cairo (cairo-drm) > > http://cworth.org/talks/lca_2009/html/lca-2009-024.html > http://linuxplumbersconf.org/ocw/proposals/29 > > and notice very promising results: > * Gradients are 100x - 120x faster > * Some painting operations are 50x faster > * Text is 4x faster > > If I didn't get it wrong, Wayland apps are also direct-rendered. I'm > not sure if Wayland runs on my video chip SiS 661 (I think it > doesn't), but it seems there have been some successful builds and > executions of Wayland as I can see in Wayland group and this list. > > It will be good if similar benchmark could be observed in Wayland. I > expect Wayland will have the same order of performance as cairo-drm > although it depends on hardware and driver. cairo-drm works as well under wayland as it does under X. But it's not a way forward in either case. It's a proof of concept to show how fast cairo can go, and the challenge is to get cairo-gl and the gl drivers to match that. GLES2 is a fine interface for what cairo needs, and there's no reason we shouldn't be able to make that fast. It's not going to work on the SiS 661, unfortunately. Kristian From krh at bitplanet.net Thu Nov 11 17:27:14 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Thu, 11 Nov 2010 20:27:14 -0500 Subject: [PATCH] Clean up .gitignore files In-Reply-To: <1289234320-5758-1-git-send-email-spbnick@gmail.com> References: <1289234320-5758-1-git-send-email-spbnick@gmail.com> Message-ID: On Mon, Nov 8, 2010 at 11:38 AM, Nikolai Kondrashov wrote: > Sort the contents and update .gitignore files to hide generated files from > git status output. Thanks, applied. Kristian > Signed-off-by: Nikolai Kondrashov > --- > ?.gitignore ? ? ? ? ? ?| ? 32 ++++++++++++++++++++++++-------- > ?clients/.gitignore ? ?| ? ?8 ++++++-- > ?compositor/.gitignore | ? ?3 +++ > ?m4/.gitignore ? ? ? ? | ? ?5 +++++ > ?wayland/.gitignore ? ?| ? ?4 ++++ > ?5 files changed, 42 insertions(+), 10 deletions(-) > ?create mode 100644 compositor/.gitignore > ?create mode 100644 wayland/.gitignore > > diff --git a/.gitignore b/.gitignore > index 435df93..7c5bfe5 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -1,12 +1,28 @@ > ?*.deps > +*.jpg > +*.la > +*.lo > ?*.o > -*.so > ?*.pc > -*.jpg > +*.so > +*.swp > ?*~ > -aclocal.m4 > -autom4te.cache/ > -config.log > -config.status > -configure > -config.mk > +.libs > +/aclocal.m4 > +/autom4te.cache > +/config.guess > +/config.h > +/config.h.in > +/config.log > +/config.mk > +/config.status > +/config.sub > +/configure > +/depcomp > +/install-sh > +/libtool > +/ltmain.sh > +/missing > +/stamp-h1 > +Makefile > +Makefile.in > diff --git a/clients/.gitignore b/clients/.gitignore > index 14a78c6..2401358 100644 > --- a/clients/.gitignore > +++ b/clients/.gitignore > @@ -1,6 +1,10 @@ > -gears > +dnd > ?flower > +gears > +image > +screenshooter-client-protocol.h > +screenshooter-protocol.c > ?screenshot > +smoke > ?terminal > -image > ?view > diff --git a/compositor/.gitignore b/compositor/.gitignore > new file mode 100644 > index 0000000..dc926c1 > --- /dev/null > +++ b/compositor/.gitignore > @@ -0,0 +1,3 @@ > +compositor > +screenshooter-protocol.c > +screenshooter-server-protocol.h > diff --git a/m4/.gitignore b/m4/.gitignore > index e69de29..38066dd 100644 > --- a/m4/.gitignore > +++ b/m4/.gitignore > @@ -0,0 +1,5 @@ > +libtool.m4 > +ltoptions.m4 > +ltsugar.m4 > +ltversion.m4 > +lt~obsolete.m4 > diff --git a/wayland/.gitignore b/wayland/.gitignore > new file mode 100644 > index 0000000..0d28ba5 > --- /dev/null > +++ b/wayland/.gitignore > @@ -0,0 +1,4 @@ > +scanner > +wayland-client-protocol.h > +wayland-protocol.c > +wayland-server-protocol.h > -- > 1.7.2.3 > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From spbnick at gmail.com Fri Nov 12 01:43:37 2010 From: spbnick at gmail.com (Nikolai Kondrashov) Date: Fri, 12 Nov 2010 12:43:37 +0300 Subject: Inline documentation format Message-ID: <4CDD0C49.1030600@gmail.com> Hi everybody, Wouldn't it be great to adopt an inline documentation format for Wayland and start writing some documentation? For example doxygen or maybe even kernel-doc? Sincerely, Nick From arete74 at gmail.com Thu Nov 11 22:23:39 2010 From: arete74 at gmail.com (Gerardo Di Iorio) Date: Fri, 12 Nov 2010 07:23:39 +0100 Subject: gtk+ on wayland Message-ID: hi, is possibiple run gtk+ on wailand? If yes, was are the step for build gtk for wayland. regards -- http://www.gerardodiiorio.com From krh at bitplanet.net Fri Nov 12 05:45:40 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Fri, 12 Nov 2010 08:45:40 -0500 Subject: gtk+ on wayland In-Reply-To: References: Message-ID: On Fri, Nov 12, 2010 at 1:23 AM, Gerardo Di Iorio wrote: > hi, > is possibiple run gtk+ on wailand? > If yes, was are the step for build gtk for wayland. Yes, it's possible, I have a branch here: http://cgit.freedesktop.org/~krh/gtk/log/?h=wayland-4 It's an old branch and much have changed (for the better, from a wayland point-of-view) in upstream GTK+. It's also not a complete port. You have to pass --with-gdktarget=wayland and possibly --disable-introspection to build it. I plan to revive the branch at some point, but for now I'm waiting for two things to happen in GTK+: merge GdkDrawable into GtkWindow and the client-side-decoration branch to land. I may end up doing some of that work myself, but if anybody wants to give it a try, I started the GdkDrawable merging here: http://cgit.freedesktop.org/~krh/gtk/log/?h=rendering-cleanup Kristian From spbnick at gmail.com Fri Nov 12 07:36:18 2010 From: spbnick at gmail.com (Nikolai Kondrashov) Date: Fri, 12 Nov 2010 18:36:18 +0300 Subject: Inline documentation format In-Reply-To: <4CDD0C49.1030600@gmail.com> References: <4CDD0C49.1030600@gmail.com> Message-ID: <4CDD5EF2.1020706@gmail.com> On 11/12/2010 12:43 PM, Nikolai Kondrashov wrote: > Wouldn't it be great to adopt an inline documentation format for Wayland > and start writing some documentation? Just a clarification: I'm not suggesting that someone should write the documentation, but rather I'm asking for a format to write comments in as I go along the Wayland code and try to understand it :) Sincerely, Nick From boulabiar at gmail.com Fri Nov 12 08:04:45 2010 From: boulabiar at gmail.com (Mohamed Ikbel Boulabiar) Date: Fri, 12 Nov 2010 17:04:45 +0100 Subject: Inline documentation format In-Reply-To: <4CDD5EF2.1020706@gmail.com> References: <4CDD0C49.1030600@gmail.com> <4CDD5EF2.1020706@gmail.com> Message-ID: The most used one is doxygen. And I verified it can generate any other type of common documents format (Latex, html, pdf, etc..) Some tools exist to generate docbook documents, so with the current process of putting all X documentation in one place with that format, we can have similar thing with Wayland. Nikolai, if you have some time, send some patches for doxygen and I think Kristian will apply them. Thanks, i From tiago.vignatti at nokia.com Fri Nov 12 10:15:45 2010 From: tiago.vignatti at nokia.com (Tiago Vignatti) Date: Fri, 12 Nov 2010 20:15:45 +0200 Subject: [PATCH] terminal: fix crashing when terminal size is < 0 Message-ID: <1289585745-3033-1-git-send-email-tiago.vignatti@nokia.com> Just skip drawing when width or height is less than zero. Signed-off-by: Tiago Vignatti --- haven't tested actually whether child windows still okay. clients/terminal.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/clients/terminal.c b/clients/terminal.c index c841ef2..4d8474c 100644 --- a/clients/terminal.c +++ b/clients/terminal.c @@ -203,6 +203,10 @@ terminal_draw(struct terminal *terminal) (int32_t) terminal->extents.max_x_advance; height = (rectangle.height - 2 * terminal->margin) / (int32_t) terminal->extents.height; + + if (width < 0 || height < 0) + return; + terminal_resize(terminal, width, height); if (!terminal->fullscreen) { -- 1.7.0.4 From spbnick at gmail.com Fri Nov 12 09:48:52 2010 From: spbnick at gmail.com (Nikolai Kondrashov) Date: Fri, 12 Nov 2010 20:48:52 +0300 Subject: Inline documentation format In-Reply-To: References: <4CDD0C49.1030600@gmail.com> <4CDD5EF2.1020706@gmail.com> Message-ID: <4CDD7E04.5030102@gmail.com> On 11/12/2010 07:04 PM, Mohamed Ikbel Boulabiar wrote: > The most used one is doxygen. > And I verified it can generate any other type of common documents > format (Latex, html, pdf, etc..) Sure, and I prefer doxygen myself. However, some may consider it bloated. > Some tools exist to generate docbook documents, so with the current > process of putting all X documentation in one place with that format, > we can have similar thing with Wayland. Yeah, good idea. > Nikolai, if you have some time, send some patches for doxygen and I > think Kristian will apply them. Do you mean the patches to add the document generation? I was rather thinking on the way of inline documentation first, HTML/DocBook/etc. later. Because this is most useful to current and potential developers. Once there is at least some documentation then generating some document will be worthwile. But I can add a slightly modified default Doxyfile, of course - this is the only thing needed to generate a documentation. Sincerely, Nick From markc at renta.net Fri Nov 12 15:45:39 2010 From: markc at renta.net (Mark Constable) Date: Sat, 13 Nov 2010 09:45:39 +1000 Subject: Inline documentation format In-Reply-To: <4CDD7E04.5030102@gmail.com> References: <4CDD0C49.1030600@gmail.com> <4CDD7E04.5030102@gmail.com> Message-ID: <201011130945.39444.markc@renta.net> > > The most used one is doxygen. > > And I verified it can generate any other type of > > common documents format (Latex, html, pdf, etc..) > > Sure, and I prefer doxygen myself. However, some may > consider it bloated. Just a super simple suggestion that is probably not appropriate but FWIW. I use this format with a mildly preprocessed Markdown (ie; showdown.js + node or gromjs) script that simply adds ^4 spaces between the ***/ /*** sections then removes the /*** and ***/ lines then passes it to regular Mardown code which turns it into HTML with the code sections within 
...
. Advantages are it's super simple and lightweight, allows for free form documentation, leaves /** ... */ jsdoc-like comments in place for further processing, and once the result is in HTML format there are a number of other utilities to turn it into other formats like PDF. I don't rate *nix man pages as useful enough to bother but there are probably tools to do that conversion as well (from HTML). /*** # Heading ## Sub-heading * list item 1 * list item 2 This is a paragraph, etc ***/ program ... code /*** * Author: etc * Version: etc * Copyright: etc ***/ --markc From canbaby at 21cn.com Fri Nov 12 17:18:04 2010 From: canbaby at 21cn.com (wucan) Date: Sat, 13 Nov 2010 09:18:04 +0800 Subject: [PATCH] client: don't call drag_offer_handler if it not hooked Message-ID: <4CDDE74C.8030301@21cn.com> When play with dnd and terminal, if you drag any item in dnd to terminal,terminal segvment fault. It's because terminal not setup drag_offer_handler, but when a item draged on it's window, display_handle_global() trigger the handler. --- clients/window.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/clients/window.c b/clients/window.c index 9dfd355..5f69561 100644 --- a/clients/window.c +++ b/clients/window.c @@ -1329,7 +1329,9 @@ display_handle_global(struct wl_display *display, uint32_t id, d->shm = wl_shm_create(display, id); } else if (strcmp(interface, "drag_offer") == 0) { offer = wl_drag_offer_create(display, id); - d->drag_offer_handler(offer, d); + if (d->drag_offer_handler) { + d->drag_offer_handler(offer, d); + } } } -- 1.6.4.GIT -- wucan From justinlee5455 at gmail.com Fri Nov 12 20:20:29 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Sat, 13 Nov 2010 12:20:29 +0800 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: Yep, I guess cairo-gl used by Wayland should get similar performance boosts as cairo-drm if it's also direct-rendered (by mesa-dri?). It seems that mixing 2D drawings with 3D drawings makes problems, therefore we want to draw everything by OpenGL even if for 2D graphics. Maybe that's the purpose of cairo-gl i.e. being a wrapper library which use OpenGL to draw 2D graphics. I am interested in comparing benchmarks of cairo-drm and Wayland, because Wayland is still uses client-server architecture like X. Although Wayland integrates together the X server and the compositing window manager to form a single-process, see the 2nd diagram in Wayland Architecture http://wayland.freedesktop.org/architecture.html which eliminates many overheads. But Wayland client and Wayland server are still in separate processes. As far as I know, X Window suffers from overheads due to its client-server architecture, such as 1. Round-trip delay time between client and server for synchronized request. 2. Context switch overhead. IPC overhead. (Unix domain socket?) 3. X protocol overhead. (package and buffer commands) as we can see in http://en.wikipedia.org/wiki/X_Window_System#Client.E2.80.93server_separation http://en.wikipedia.org/wiki/MicroXwin#Background hence I guess the overheads above also exist in Wayland. I expect the benchmark comparison will show how much performance drop are made by Wayland's client-server architecture. Yet another related stuff, according to page 29 of "Why X Is Not Our Ideal Window System" , it states: "The X protocol?s network-transparent client-server model is less efficient than a direct-procedure-call window system, such as SunView or Microsoft Windows." sounds like we should make everything direct-procedure-called as much as possible in order to maximum our system's performance. Therefore I guess we could further improve Wayland's performance (don't know how much will improve and if it's worth though) by turning all things Wayland server/compositor does into direct-procedure calls (that is without any context switch ...well it sounds like talking rubbish as I don't aware of any technical/logical issues). 2010/11/11 Kristian H?gsberg : > On Thu, Nov 11, 2010 at 4:08 AM, Justin Lee wrote: >> Chris Wilson has been playing around with direct-rendered cairo (cairo-drm) >> >> http://cworth.org/talks/lca_2009/html/lca-2009-024.html >> http://linuxplumbersconf.org/ocw/proposals/29 >> >> and notice very promising results: >> * Gradients are 100x - 120x faster >> * Some painting operations are 50x faster >> * Text is 4x faster >> >> If I didn't get it wrong, Wayland apps are also direct-rendered. I'm >> not sure if Wayland runs on my video chip SiS 661 (I think it >> doesn't), but it seems there have been some successful builds and >> executions of Wayland as I can see in Wayland group and this list. >> >> It will be good if similar benchmark could be observed in Wayland. I >> expect Wayland will have the same order of performance as cairo-drm >> although it depends on hardware and driver. > > cairo-drm works as well under wayland as it does under X. ?But it's > not a way forward in either case. ?It's a proof of concept to show how > fast cairo can go, and the challenge is to get cairo-gl and the gl > drivers to match that. ?GLES2 is a fine interface for what cairo > needs, and there's no reason we shouldn't be able to make that fast. > It's not going to work on the SiS 661, unfortunately. > > Kristian > From canbaby at 21cn.com Fri Nov 12 20:57:21 2010 From: canbaby at 21cn.com (wucan) Date: Sat, 13 Nov 2010 12:57:21 +0800 Subject: [PATCH v2] client: don't call drag_offer_handler if it not hooked Message-ID: <4CDE1AB1.3090006@21cn.com> When play with dnd and terminal, if you drag any item in dnd to terminal,terminal segvment fault. It's because terminal not setup drag_offer_handler, but when a item dragged on it's window, display_handle_global() trigger the handler. --- clients/window.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) Don't create "offer" too, sorry. diff --git a/clients/window.c b/clients/window.c index 9dfd355..9ee4212 100644 --- a/clients/window.c +++ b/clients/window.c @@ -1328,8 +1328,10 @@ display_handle_global(struct wl_display *display, uint32_t id, } else if (strcmp(interface, "shm") == 0) { d->shm = wl_shm_create(display, id); } else if (strcmp(interface, "drag_offer") == 0) { - offer = wl_drag_offer_create(display, id); - d->drag_offer_handler(offer, d); + if (d->drag_offer_handler) { + offer = wl_drag_offer_create(display, id); + d->drag_offer_handler(offer, d); + } } } -- 1.6.4.GIT -- wucan From christoph.frieben at googlemail.com Fri Nov 12 21:55:42 2010 From: christoph.frieben at googlemail.com (Christoph Frieben) Date: Sat, 13 Nov 2010 06:55:42 +0100 Subject: Garbled screen for KMS and ATI Radeon X800 Message-ID: After building wayland, mesa, cairo-gl, and libxkbcommon (git version of 2010-11-12), compositor and clients runs nicely in a window on top of a GNOME desktop under Fedora 14 (kernel-2.6.35.8-55.fc14.x86_64). However, when started in a VT, the screen shows a garbled pattern. Moving the mouse has no effect. It is possible though to abort the compositor and to get dropped to the shell. Issue occurs for an ATI Radeon X800 (Chipset: "ATI Radeon X800 SE (R430) (PCIE)" (ChipID = 0x554e)). glxinfo reports OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on R430 OpenGL version string: 2.1 Mesa 7.10-devel OpenGL shading language version string: 1.20 Any clues how to get wayland up and running in KMS? From chris at chris-wilson.co.uk Sat Nov 13 01:23:04 2010 From: chris at chris-wilson.co.uk (Chris Wilson) Date: Sat, 13 Nov 2010 09:23:04 +0000 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: Take a step back. It's time to review the system architecture once more. Wayland is a input/output [de-]multiplexer. It does no rendering on the behalf of the client, only compositing the many clients onto the scanouts. The clients must prepare for themselves the shared memory buffers that they pass to Wayland for compositing. (Under GEM those shared memory buffers are merely GEM objects and therefore can also be used with hardware accelerated rendering.) On Sat, 13 Nov 2010 12:20:29 +0800, Justin Lee wrote: > Yep, I guess cairo-gl used by Wayland should get similar performance > boosts as cairo-drm if it's also direct-rendered (by mesa-dri?). It > seems that mixing 2D drawings with 3D drawings makes problems, > therefore we want to draw everything by OpenGL even if for 2D > graphics. Maybe that's the purpose of cairo-gl i.e. being a wrapper > library which use OpenGL to draw 2D graphics. The difference between theory and practice... To put it bluntly, cairo-gl on my fastest boxes [g45, ironlake] is still slower than cairo-xlib on one of my slowest boxes [q35, for pnv it's close but the Atom is just no match for the CPUs in the desktop boxes]. This is all due to driver quality and the fact that RENDER is much easier to accelerate than a full GL implementation. This also implies that there is less opportunity for acceleration of RENDER because so much information is thrown away upfront. (Having said that cairo-xlib on g45/ilk is atrocious and much slower than cairo-gl on the same platforms, again due to driver quality.) The promise of GL is that we only need to write one good driver per chipset... The promise of Wayland is that every pixel is perfect. It takes the architecture that X has organically developed over the last 25 years and aims to implement that in a small footprint, low latency system. One of the killer ideas of Wayland is that it is self-hosting. -Chris -- Chris Wilson, Intel Open Source Technology Centre From tiago.vignatti at nokia.com Sat Nov 13 07:20:21 2010 From: tiago.vignatti at nokia.com (Tiago Vignatti) Date: Sat, 13 Nov 2010 17:20:21 +0200 Subject: [PATCH v2] client: don't call drag_offer_handler if it not hooked In-Reply-To: <4CDE1AB1.3090006@21cn.com> References: <4CDE1AB1.3090006@21cn.com> Message-ID: <20101113152021.GA749@cachaca> On Sat, Nov 13, 2010 at 12:57:21PM +0800, ext wucan wrote: > When play with dnd and terminal, if you drag any item in dnd to > terminal,terminal segvment fault. It's because terminal not setup > drag_offer_handler, but when a item dragged on it's window, > display_handle_global() trigger the handler. > --- > clients/window.c | 6 ++++-- > 1 files changed, 4 insertions(+), 2 deletions(-) > > Don't create "offer" too, sorry. > > diff --git a/clients/window.c b/clients/window.c > index 9dfd355..9ee4212 100644 > --- a/clients/window.c > +++ b/clients/window.c > @@ -1328,8 +1328,10 @@ display_handle_global(struct wl_display > *display, uint32_t id, > } else if (strcmp(interface, "shm") == 0) { > d->shm = wl_shm_create(display, id); > } else if (strcmp(interface, "drag_offer") == 0) { > - offer = wl_drag_offer_create(display, id); > - d->drag_offer_handler(offer, d); > + if (d->drag_offer_handler) { > + offer = wl_drag_offer_create(display, id); > + d->drag_offer_handler(offer, d); > + } > } > } The other way to fix it would be creating a stub function for the drag handler and initiate it with display_set_drag_offer_handler. But we should protect anyway those clients not initialize it, so: Reviewed-by: Tiago Vignatti Tiago From tiago.vignatti at nokia.com Sat Nov 13 08:15:45 2010 From: tiago.vignatti at nokia.com (Tiago Vignatti) Date: Sat, 13 Nov 2010 18:15:45 +0200 Subject: Run wayland on MeeGo with a netbook In-Reply-To: References: Message-ID: <20101113161545.GA1307@cachaca> On Thu, Nov 11, 2010 at 04:32:17PM +0800, ext Liu, Xinyun wrote: > I can run the wayland in MeeGo successfully on an Aser netbook this > afternoon. it sounds you could run the whole MeeGo sw platform, with qt and all infrastructure, on the top of Wayland. It wasn't the case though. So watch out to not distort the information ;) Tiago From alexdeucher at gmail.com Sat Nov 13 13:29:08 2010 From: alexdeucher at gmail.com (Alex Deucher) Date: Sat, 13 Nov 2010 16:29:08 -0500 Subject: Garbled screen for KMS and ATI Radeon X800 In-Reply-To: References: Message-ID: On Sat, Nov 13, 2010 at 12:55 AM, Christoph Frieben wrote: > After building wayland, mesa, cairo-gl, and libxkbcommon (git version > of 2010-11-12), compositor and clients runs nicely in a window on top > of a GNOME desktop under Fedora 14 (kernel-2.6.35.8-55.fc14.x86_64). > However, when started in a VT, the screen shows a garbled pattern. > Moving the mouse has no effect. It is possible though to abort the > compositor and to get dropped to the shell. Issue occurs for an ATI > Radeon X800 (Chipset: "ATI Radeon X800 SE (R430) (PCIE)" (ChipID = > 0x554e)). glxinfo reports > > OpenGL vendor string: X.Org R300 Project > OpenGL renderer string: Gallium 0.4 on R430 > OpenGL version string: 2.1 Mesa 7.10-devel > OpenGL shading language version string: 1.20 > > Any clues how to get wayland up and running in KMS? Try the r300 calssic mesa 3D driver. I suspect the r300g driver probably needs something similar to this: http://cgit.freedesktop.org/mesa/mesa/commit/?id=46c19700676e17bfaa0a88346d512449fbeede79 Alex From nobled at dreamwidth.org Sat Nov 13 19:24:18 2010 From: nobled at dreamwidth.org (nobled) Date: Sat, 13 Nov 2010 22:24:18 -0500 Subject: [PATCH] Return something when creating a surface Message-ID: --- clients/window.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/clients/window.c b/clients/window.c index 24ec5b0..ea1d6f6 100644 --- a/clients/window.c +++ b/clients/window.c @@ -433,9 +433,9 @@ display_create_surface(struct display *display, struct rectangle *rectangle) { #ifdef HAVE_CAIRO_GL - display_create_drm_surface(display, rectangle); + return display_create_drm_surface(display, rectangle); #else - display_create_shm_surface(display, rectangle); + return display_create_shm_surface(display, rectangle); #endif } @@ -445,9 +445,9 @@ display_create_surface_from_file(struct display *display, struct rectangle *rectangle) { #ifdef HAVE_CAIRO_GL - display_create_drm_surface_from_file(display, filename, rectangle); + return display_create_drm_surface_from_file(display, filename, rectangle); #else - display_create_shm_surface_from_file(display, filename, rectangle); + return display_create_shm_surface_from_file(display, filename, rectangle); #endif } -- 1.7.0.4 From canbaby at 21cn.com Sat Nov 13 20:32:21 2010 From: canbaby at 21cn.com (wucan) Date: Sun, 14 Nov 2010 12:32:21 +0800 Subject: [PATCH v2] client: don't call drag_offer_handler if it not hooked In-Reply-To: <20101113152021.GA749@cachaca> References: <4CDE1AB1.3090006@21cn.com> <20101113152021.GA749@cachaca> Message-ID: <4CDF6655.6070702@21cn.com> On 11/13/2010 11:20 PM, Tiago Vignatti wrote: > On Sat, Nov 13, 2010 at 12:57:21PM +0800, ext wucan wrote: >> When play with dnd and terminal, if you drag any item in dnd to >> terminal,terminal segvment fault. It's because terminal not setup >> drag_offer_handler, but when a item dragged on it's window, >> display_handle_global() trigger the handler. >> --- >> clients/window.c | 6 ++++-- >> 1 files changed, 4 insertions(+), 2 deletions(-) >> >> Don't create "offer" too, sorry. >> >> diff --git a/clients/window.c b/clients/window.c >> index 9dfd355..9ee4212 100644 >> --- a/clients/window.c >> +++ b/clients/window.c >> @@ -1328,8 +1328,10 @@ display_handle_global(struct wl_display >> *display, uint32_t id, >> } else if (strcmp(interface, "shm") == 0) { >> d->shm = wl_shm_create(display, id); >> } else if (strcmp(interface, "drag_offer") == 0) { >> - offer = wl_drag_offer_create(display, id); >> - d->drag_offer_handler(offer, d); >> + if (d->drag_offer_handler) { >> + offer = wl_drag_offer_create(display, id); >> + d->drag_offer_handler(offer, d); >> + } >> } >> } > > The other way to fix it would be creating a stub function for the drag handler > and initiate it with display_set_drag_offer_handler. But we should protect > anyway those clients not initialize it, so: > yes, stub function seems a better solution for all these handler stuff. > Reviewed-by: Tiago Vignatti thanks > > Tiago > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- wucan From flyser42 at gmx.de Sun Nov 14 04:25:29 2010 From: flyser42 at gmx.de (Fabian Henze) Date: Sun, 14 Nov 2010 13:25:29 +0100 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: Message-ID: <201011141325.31009.flyser42@gmx.de> Hi all, I am rather new to all this and I don't know all the facts, so please forgive me, if my concerns are stupid or not valid at all. On Thu 04 Nov 2010 04:22:37-PDT, Justin Lee wrote: > In considering consistent look and feel issue of window decorations > due to client-side window decoration, maybe we shouldn't let the > toolkit (Qt/GTK) render decorations nor let the app render its > decoration directly. Rather, there should be a separate, independent > library (may be called libWinDeco) dedicated to render window > decorations. Whenever an app needs to render its decoration, it calls > libWinDeco to help the job. Then this becomes a programming > convention/protocol to each Wayland app that Wayland app should use > libWinDeco to render decoration by default (unless the app want to be > maverick, it can disregard the convention and render its decoration by > itself directly). If all Wayland apps follow the convention, they will > have consistent look and feel of window decorations as all the > decorations are rendered by the same code, i.e. libWinDeco. > > By this way, highly customizable window appearances are still possible > if libWinDeco is designed to be configurable. Where 'configurable' > means behaviors of libWinDeco are controlled by a single, universal, > system-wide config file (which specifies button attributes, title bar > appearances etc.). [..] > libWinDeco should be designed to be easy to use in order to make > programmers willing to follow the convention therefore glitchy apps > become rare. This seems like a much more complicated and error-prone solution compared to server-side window decorations (sswd ;)). I am wondering what you gain compared to sswd? In other words: How is this an improvement over the current design of X.org? Todays X applications can already hide their window decorations and do their own stuff, but this technique is not used very often (at least for full-blown application windows) at the moment, so why make it the default? -- regards, Fabian Henze -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.frieben at googlemail.com Sun Nov 14 04:38:47 2010 From: christoph.frieben at googlemail.com (Christoph Frieben) Date: Sun, 14 Nov 2010 13:38:47 +0100 Subject: Garbled screen for KMS and ATI Radeon X800 In-Reply-To: References: Message-ID: 2010/11/13 Alex Deucher: > Try the r300 classic mesa 3D driver. No luck after adding "--disable-gallium" of the build options of mesa: $ ./compositor failed to create context failed to create compositor -Christoph From smspillaz at gmail.com Sun Nov 14 04:53:40 2010 From: smspillaz at gmail.com (Sam Spilsbury) Date: Sun, 14 Nov 2010 20:53:40 +0800 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: <201011141325.31009.flyser42@gmx.de> References: <201011141325.31009.flyser42@gmx.de> Message-ID: On Sun, Nov 14, 2010 at 8:25 PM, Fabian Henze wrote: > Hi all, > > I am rather new to all this and I don't know all the facts, so please > forgive me, if my concerns are stupid or not valid at all. > > On Thu 04 Nov 2010 04:22:37-PDT, Justin Lee wrote: > >> In considering consistent look and feel issue of window decorations > >> due to client-side window decoration, maybe we shouldn't let the > >> toolkit (Qt/GTK) render decorations nor let the app render its > >> decoration directly. Rather, there should be a separate, independent > >> library (may be called libWinDeco) dedicated to render window > >> decorations. Whenever an app needs to render its decoration, it calls > >> libWinDeco to help the job. Then this becomes a programming > >> convention/protocol to each Wayland app that Wayland app should use > >> libWinDeco to render decoration by default (unless the app want to be > >> maverick, it can disregard the convention and render its decoration by > >> itself directly). If all Wayland apps follow the convention, they will > >> have consistent look and feel of window decorations as all the > >> decorations are rendered by the same code, i.e. libWinDeco. > >> > >> By this way, highly customizable window appearances are still possible > >> if libWinDeco is designed to be configurable. Where 'configurable' > >> means behaviors of libWinDeco are controlled by a single, universal, > >> system-wide config file (which specifies button attributes, title bar > >> appearances etc.). > > [..] > >> libWinDeco should be designed to be easy to use in order to make > >> programmers willing to follow the convention therefore glitchy apps > >> become rare. > > This seems like a much more complicated and error-prone solution compared to > server-side window decorations (sswd ;)). I am wondering what you gain > compared to sswd? In other words: How is this an improvement over the > current design of X.org? > > Todays X applications can already hide their window decorations and do their > own stuff, but this technique is not used very often (at least for > full-blown application windows) at the moment, so why make it the default? > Since we don't need to re-parent windows, any compositor (for example a mutter based or compiz based libwayland-server) would be able to draw the window decorations and get their input just fine. The clients don't need to worry about their own decorations. These servers can also handle drawing the background of the window to (so the buffers that are passed to us are actually ARGB buffers with an 100% transparent background). Regards, Sam > -- > > regards, > > Fabian Henze > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > -- Sam Spilsbury From benjaminfranzke at googlemail.com Sun Nov 14 05:12:11 2010 From: benjaminfranzke at googlemail.com (Benjamin Franzke) Date: Sun, 14 Nov 2010 14:12:11 +0100 Subject: Garbled screen for KMS and ATI Radeon X800 In-Reply-To: References: Message-ID: Using the classic driver wont work... It doesnt implement initialization for opengl es2, and some of the new extensions needed for wayland (EGL_MESA_drm_image and surfaceless opengl). So your chances to get wayland running on drm are better with the r300g driver.. Btw the function, thats implemented by the patch Alex linked, exists already in r300g. What you might need are the page-flip patches Alex posted on the dri-devel mailing list: http://lists.freedesktop.org/archives/dri-devel/2010-October/005043.html http://lists.freedesktop.org/archives/dri-devel/2010-October/005044.html But that doesnt mean it works then: With the patches on r300g i can see some parts of wayland, but the wayland image starts at about 5/6 vertically and in the middle horizontally. It looks like the image is read from a wrong buffer.. 2010/11/14 Christoph Frieben : > 2010/11/13 Alex Deucher: >> Try the r300 classic mesa 3D driver. > > No luck after adding "--disable-gallium" of the build options of mesa: > > $ ./compositor > failed to create context > failed to create compositor > > -Christoph > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From bluescreen_avenger at verizon.net Sun Nov 14 07:55:20 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Sun, 14 Nov 2010 10:55:20 -0500 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: References: <201011141325.31009.flyser42@gmx.de> Message-ID: <201011141055.20550.bluescreen_avenger@verizon.net> On Sunday, November 14, 2010 07:53:40 am Sam Spilsbury wrote: > On Sun, Nov 14, 2010 at 8:25 PM, Fabian Henze wrote: > > Hi all, > > > > I am rather new to all this and I don't know all the facts, so please > > forgive me, if my concerns are stupid or not valid at all. > > > > On Thu 04 Nov 2010 04:22:37-PDT, Justin Lee wrote: > >> In considering consistent look and feel issue of window decorations > >> > >> due to client-side window decoration, maybe we shouldn't let the > >> > >> toolkit (Qt/GTK) render decorations nor let the app render its > >> > >> decoration directly. Rather, there should be a separate, independent > >> > >> library (may be called libWinDeco) dedicated to render window > >> > >> decorations. Whenever an app needs to render its decoration, it calls > >> > >> libWinDeco to help the job. Then this becomes a programming > >> > >> convention/protocol to each Wayland app that Wayland app should use > >> > >> libWinDeco to render decoration by default (unless the app want to be > >> > >> maverick, it can disregard the convention and render its decoration by > >> > >> itself directly). If all Wayland apps follow the convention, they will > >> > >> have consistent look and feel of window decorations as all the > >> > >> decorations are rendered by the same code, i.e. libWinDeco. > >> > >> > >> > >> By this way, highly customizable window appearances are still possible > >> > >> if libWinDeco is designed to be configurable. Where 'configurable' > >> > >> means behaviors of libWinDeco are controlled by a single, universal, > >> > >> system-wide config file (which specifies button attributes, title bar > >> > >> appearances etc.). > > > > [..] > > > >> libWinDeco should be designed to be easy to use in order to make > >> > >> programmers willing to follow the convention therefore glitchy apps > >> > >> become rare. > > > > This seems like a much more complicated and error-prone solution compared > > to server-side window decorations (sswd ;)). I am wondering what you > > gain compared to sswd? In other words: How is this an improvement over > > the current design of X.org? > > > > Todays X applications can already hide their window decorations and do > > their own stuff, but this technique is not used very often (at least for > > full-blown application windows) at the moment, so why make it the > > default? > > Since we don't need to re-parent windows, any compositor (for example > a mutter based or compiz based libwayland-server) would be able to > draw the window decorations and get their input just fine. The clients > don't need to worry about their own decorations. These servers can > also handle drawing the background of the window to (so the buffers > that are passed to us are actually ARGB buffers with an 100% > transparent background). > > Regards, > > Sam > > > -- > > > > regards, > > > > Fabian Henze > > > > _______________________________________________ > > wayland-devel mailing list > > wayland-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel That definantly sounds better... I already had the Terminal cleint freeze up, and become unmovable over a whole bunch of windows... But how can it insure that we won't get two titlebars? If the client is drawing its titlebar, and if the sever is drawing its titlebar? And how will the server know to not put a titlebar on windows like popup menus? Some interface probably would need to be put into the protocol in order for this to work I think. Am I right? From flyser42 at gmx.de Sun Nov 14 09:08:11 2010 From: flyser42 at gmx.de (Fabian Henze) Date: Sun, 14 Nov 2010 18:08:11 +0100 Subject: A few questions and a suggestion for dnd Message-ID: <201011141808.27580.flyser42@gmx.de> Hello list, I read the wayland documentation in the specs folder of the git repository and while I am impressed of the simplicity and elegance of waylands design, a few questions came to my mind. I hope they are not too specific for a display server in such an early state :-) 1. If the design of the pointer is controlled by the client, how will this be consistent among applications? Especially, if the user wants to change the system-wide pointer theme? How will clients decide what e.g. the "hand" or text-selection pointer looks like? If I understood the document correctly, the pointer image is not reset, if the pointer leaves a surface. If so: 2. Will all clients have to reset the pointer once they receive motion events? Isn't this ineffective? Will the "root surface" (is that what it's called?) also have to do this? 3. What are the minimum requirements to run wayland? Does the system have to have a 3D capable GPU? what about virtual GPUs? e.g. cirrus for qemu or whatever other emulators use? And finally an idea for the drag and drop mechanism: Would it be possible (and desirable) to modify dnd in the following way: When the drag starts, the initiator surface creates a new surface, which contains just an image of the drag content and is positioned relative to the pointer. After the target surface accepted the drag, it gains access to the surface and can do whatever animation with it. This would make drag and drop visually more appealing. I hope you understand what I mean and how this would be useful. If you don't, I can try to create a quick mockup using gimp :-). P.S.: I found two typos in the documentation: The first one is on page 5, where "drag.offer(mime-type1" misses a brace and the second one is on page 8 in 3.1, where "fromt" should be "from". Do you care for a patch or do you quickly fix this yourself? From alexdeucher at gmail.com Sun Nov 14 09:46:04 2010 From: alexdeucher at gmail.com (Alex Deucher) Date: Sun, 14 Nov 2010 12:46:04 -0500 Subject: Garbled screen for KMS and ATI Radeon X800 In-Reply-To: References: Message-ID: On Sun, Nov 14, 2010 at 8:12 AM, Benjamin Franzke wrote: > Using the classic driver wont work... > It doesnt implement initialization for opengl es2, and some of the new > extensions needed for wayland (EGL_MESA_drm_image and surfaceless > opengl). > > So your chances to get wayland running on drm are better with the r300g driver.. > Btw the function, thats implemented by the patch Alex linked, exists > already in r300g. > > What you might need are the page-flip patches Alex posted on the > dri-devel mailing list: > ?http://lists.freedesktop.org/archives/dri-devel/2010-October/005043.html > ?http://lists.freedesktop.org/archives/dri-devel/2010-October/005044.html Those patches are old and buggy, please try the latest patches here: http://people.freedesktop.org/~agd5f/pflip/ > But that doesnt mean it works then: > With the patches on r300g i can see some parts of wayland, but the > wayland image starts at about 5/6 vertically and in the middle > horizontally. > It looks like the image is read from a wrong buffer.. The gallium drivers may need a fix similar to this one to make sure the flushing happens at the right time: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d8eef5196fcd6f51e443d4dfa0fda8aadc668f9f Alex > > 2010/11/14 Christoph Frieben : >> 2010/11/13 Alex Deucher: >>> Try the r300 classic mesa 3D driver. >> >> No luck after adding "--disable-gallium" of the build options of mesa: >> >> $ ./compositor >> failed to create context >> failed to create compositor >> >> -Christoph >> _______________________________________________ >> wayland-devel mailing list >> wayland-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From Darxus at chaosreigns.com Sun Nov 14 11:21:12 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sun, 14 Nov 2010 14:21:12 -0500 Subject: More ubuntu build instructions Message-ID: <20101114192112.GF30262@chaosreigns.com> http://www.chaosreigns.com/wayland/ubuntu.html http://www.chaosreigns.com/wayland/wayland-build-ubuntu-intel.sh http://www.chaosreigns.com/wayland/wayland-build-ubuntu-not-intel.sh I think this should cover all builds under Ubuntu Maverick. I'd like it to end up on the wayland web site. Let me know if you have suggestions for improvement, or it doesn't work for you. As the web page mentions, this is likely to be useful on other platforms as long as you install the build dependencies first. -- "I'd rather be happy than right any day." - Slartiblartfast, The Hitchhiker's Guide to the Galaxy http://www.ChaosReigns.com From krh at bitplanet.net Sun Nov 14 14:42:23 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Sun, 14 Nov 2010 17:42:23 -0500 Subject: A few questions and a suggestion for dnd In-Reply-To: <201011141808.27580.flyser42@gmx.de> References: <201011141808.27580.flyser42@gmx.de> Message-ID: On Sun, Nov 14, 2010 at 12:08 PM, Fabian Henze wrote: > Hello list, > I read the wayland documentation in the specs folder of the git repository and > while I am impressed of the simplicity and elegance of waylands design, a few > questions came to my mind. I hope they are not too specific for a display > server in such an early state :-) No, I appreciate the input. In fact, at this point, the most useful feedback is on highlevel architecture issues like what you bring up, not so much whether or not the demo clients segfault occasionally ;-) > 1. If the design of the pointer is controlled by the client, how will this be > consistent among applications? Especially, if the user wants to change the > system-wide pointer theme? How will clients decide what e.g. the "hand" or > text-selection pointer looks like? There has to be a out-of-band theme mechanism that lets applications agree on a icon/font/cursor/color theme. In X we have the xsettings protocol, which provides this, but that's really a workaround for the fact that applications can't agree on one configuration system. > If I understood the document correctly, the pointer image is not reset, if the > pointer leaves a surface. Yup. > If so: > 2. Will all clients have to reset the pointer once they receive motion events? > Isn't this ineffective? Will the "root surface" (is that what it's called?) > also have to do this? Yes, clients have to set the cursor, and no, it's not inefficient. Wayland doesn't have sub-surfaces that would let you set a pointer per surface, so clients have to track motion within their surface and update the cursor accordingly. For example, if the cursor moves into a textfield, the client has to set the I-beam cursor etc. The consequence of this design is that the server can't know what cursor to set. Maybe the last cursor set for a surface was the I-beam cursor, then the pointer exits and enters from a different edge, where it enters a menu. The menu needs the arrow cursor so if the server was to set the I-beam cursor and the app was slow, we would just see a brief flash of I-beam, before the app sets it back to the pointer. A tiny delay before setting the right cursor is better than setting the wrong cursor briefly. And typically, there wont be any noticable delay. The root surface is handle by the compositor and the compositor will set the default cursor when the pointer enters the root surface (where default cursor is up to the compositor). > 3. What are the minimum requirements to run wayland? Does the system have to > have a 3D capable GPU? what about virtual GPUs? e.g. cirrus for qemu or > whatever other emulators use? All wayland needs is a way to share surfaces. And there's a shm mechanisms that uses fd passing,which works on any graphics cards. So you could implement wayland with client side all sw rendering (cairo image backend, for example) and do software compositing on the server side. The only requirement in that case is that you can do modesetting in the compositor. Wayland could run on /dev/fb, in other words. > And finally an idea for the drag and drop mechanism: > Would it be possible (and desirable) to modify dnd in the following way: > When the drag starts, the initiator surface creates a new surface, which > contains just an image of the drag content and is positioned relative to the > pointer. After the target surface accepted the drag, it gains access to the > surface and can do whatever animation with it. This would make drag and drop > visually more appealing. > I hope you understand what I mean and how this would be useful. If you don't, > I can try to create a quick mockup using gimp :-). I think that it may be useful to split the cursor image from the image being dragged. The use case I have in mind is where you want to do a "snap back" animation in case the drop is declined, that is, the dragged icon slides back to the origin if the source rejects the drop. The compositor will have to implement that (it's the only place where we know where the drag was started and where it was rejected), but in the current scheme, the compositor doesn't have the dragged icon without the cursor composited on top. My concern was that I don't want lag between the cursor and the drag icon, but the compositor can ensure that even if the two are not in the same texture, so I think we can do this. I'm not sure about passing the image to the drop target though. It's easy enough to let the client pass an ID for the buffer that holds the icon image, and I guess I don't see a problem with that. I'll have to try to implement it and see how it works. Kristian > P.S.: I found two typos in the documentation: The first one is on page 5, where > "drag.offer(mime-type1" misses a brace and the second one is on page 8 in 3.1, > where "fromt" should be "from". Do you care for a patch or do you quickly fix > this yourself? > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From flyser42 at gmx.de Mon Nov 15 01:27:49 2010 From: flyser42 at gmx.de (Fabian Henze) Date: Mon, 15 Nov 2010 10:27:49 +0100 Subject: A few questions and a suggestion for dnd In-Reply-To: References: <201011141808.27580.flyser42@gmx.de> Message-ID: <201011151028.06593.flyser42@gmx.de> On Sunday, 14 Nov 2010, 22:42-UTC, Kristian H?gsberg wrote: > On Sun, Nov 14, 2010 at 12:08 PM, Fabian Henze wrote: > > 1. If the design of the pointer is controlled by the client, how will > > this be consistent among applications? Especially, if the user wants to > > change the system-wide pointer theme? How will clients decide what e.g. > > the "hand" or text-selection pointer looks like? > > There has to be a out-of-band theme mechanism that lets applications > agree on a icon/font/cursor/color theme. In X we have the xsettings > protocol, which provides this, but that's really a workaround for the > fact that applications can't agree on one configuration system. Why do you intend it to be out-of-band? Broadcasting the theming information after a client connects, sounds like a sane solution to me. I fear that toolkits or (much worse) application developers won't agree on a single mechanism to handle this and that this will take years of fdo work to correct. Especially, if some distribution adopts wayland, before a sane mechanism is ready. > > If so: > > 2. Will all clients have to reset the pointer once they receive motion > > events? Isn't this ineffective? Will the "root surface" (is that what > > it's called?) also have to do this? > > Yes, clients have to set the cursor, and no, it's not inefficient. > Wayland doesn't have sub-surfaces that would let you set a pointer per > surface, so clients have to track motion within their surface and > update the cursor accordingly. For example, if the cursor moves into > a textfield, the client has to set the I-beam cursor etc. The > consequence of this design is that the server can't know what cursor > to set. Maybe the last cursor set for a surface was the I-beam > cursor, then the pointer exits and enters from a different edge, where > it enters a menu. The menu needs the arrow cursor so if the server > was to set the I-beam cursor and the app was slow, we would just see a > brief flash of I-beam, before the app sets it back to the pointer. A > tiny delay before setting the right cursor is better than setting the > wrong cursor briefly. And typically, there wont be any noticable > delay. > > The root surface is handle by the compositor and the compositor will > set the default cursor when the pointer enters the root surface (where > default cursor is up to the compositor). Sounds good :) > > 3. What are the minimum requirements to run wayland? Does the system have > > to have a 3D capable GPU? what about virtual GPUs? e.g. cirrus for qemu > > or whatever other emulators use? > > All wayland needs is a way to share surfaces. And there's a shm > mechanisms that uses fd passing,which works on any graphics cards. So > you could implement wayland with client side all sw rendering (cairo > image backend, for example) and do software compositing on the server > side. The only requirement in that case is that you can do > modesetting in the compositor. Wayland could run on /dev/fb, in other > words. I am glad to hear that :) Is the code for /dev/fb-based wayland already there or is it just a possibility for the future? > > And finally an idea for the drag and drop mechanism: > > Would it be possible (and desirable) to modify dnd in the following way: > > When the drag starts, the initiator surface creates a new surface, which > > contains just an image of the drag content and is positioned relative to > > the pointer. After the target surface accepted the drag, it gains access > > to the surface and can do whatever animation with it. This would make > > drag and drop visually more appealing. > > I hope you understand what I mean and how this would be useful. If you > > don't, I can try to create a quick mockup using gimp :-). > > I think that it may be useful to split the cursor image from the image > being dragged. The use case I have in mind is where you want to do a > "snap back" animation in case the drop is declined, that is, the > dragged icon slides back to the origin if the source rejects the drop. > The compositor will have to implement that (it's the only place where > we know where the drag was started and where it was rejected), but in > the current scheme, the compositor doesn't have the dragged icon > without the cursor composited on top. My concern was that I don't > want lag between the cursor and the drag icon, but the compositor can > ensure that even if the two are not in the same texture, so I think we > can do this. > > I'm not sure about passing the image to the drop target though. It's > easy enough to let the client pass an ID for the buffer that holds the > icon image, and I guess I don't see a problem with that. I'll have to > try to implement it and see how it works. While the compositor knows where the drag has started, it doesn't know where it will affect the target surface in case the dnd is successful. The only place with that knowledge is the target client and imo it should be able to make use of this knowledge by smoothly integrating the icon surface in the target surface. Otherwise the "dnd failed" case is nicely animated, while the "dnd successful" is not. Oh and one more question popped to my mind: Just out of curiosity, does wayland use hwcursor? I heard there were plans (or musing) in the X world to remove hwcursor support for some reason. And last but not least, I tried to build and run wayland in a chroot on my Ironlake notebook. It works fine, but only after I patched the pci ids of my graphics card into the mesa source (src/egl/drivers/dri2/egl_dri2.c). Do you care to sync this list with the rest of mesa? Or is it intentional that Ironlake is not supported? -- regards, Fabian Henze From bluescreen_avenger at verizon.net Mon Nov 15 16:47:40 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Mon, 15 Nov 2010 19:47:40 -0500 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: References: <201011141055.20550.bluescreen_avenger@verizon.net> Message-ID: <201011151947.41580.bluescreen_avenger@verizon.net> On Sunday, November 14, 2010 07:06:51 pm you wrote: > On Sun, Nov 14, 2010 at 11:55 PM, nerdopolis > > wrote: > > On Sunday, November 14, 2010 07:53:40 am Sam Spilsbury wrote: > >> On Sun, Nov 14, 2010 at 8:25 PM, Fabian Henze wrote: > >> > Hi all, > >> > > >> > I am rather new to all this and I don't know all the facts, so please > >> > forgive me, if my concerns are stupid or not valid at all. > >> > > >> > On Thu 04 Nov 2010 04:22:37-PDT, Justin Lee wrote: > >> >> In considering consistent look and feel issue of window decorations > >> >> > >> >> due to client-side window decoration, maybe we shouldn't let the > >> >> > >> >> toolkit (Qt/GTK) render decorations nor let the app render its > >> >> > >> >> decoration directly. Rather, there should be a separate, independent > >> >> > >> >> library (may be called libWinDeco) dedicated to render window > >> >> > >> >> decorations. Whenever an app needs to render its decoration, it calls > >> >> > >> >> libWinDeco to help the job. Then this becomes a programming > >> >> > >> >> convention/protocol to each Wayland app that Wayland app should use > >> >> > >> >> libWinDeco to render decoration by default (unless the app want to be > >> >> > >> >> maverick, it can disregard the convention and render its decoration > >> >> by > >> >> > >> >> itself directly). If all Wayland apps follow the convention, they > >> >> will > >> >> > >> >> have consistent look and feel of window decorations as all the > >> >> > >> >> decorations are rendered by the same code, i.e. libWinDeco. > >> >> > >> >> > >> >> > >> >> By this way, highly customizable window appearances are still > >> >> possible > >> >> > >> >> if libWinDeco is designed to be configurable. Where 'configurable' > >> >> > >> >> means behaviors of libWinDeco are controlled by a single, universal, > >> >> > >> >> system-wide config file (which specifies button attributes, title bar > >> >> > >> >> appearances etc.). > >> > > >> > [..] > >> > > >> >> libWinDeco should be designed to be easy to use in order to make > >> >> > >> >> programmers willing to follow the convention therefore glitchy apps > >> >> > >> >> become rare. > >> > > >> > This seems like a much more complicated and error-prone solution > >> > compared to server-side window decorations (sswd ;)). I am wondering > >> > what you gain compared to sswd? In other words: How is this an > >> > improvement over the current design of X.org? > >> > > >> > Todays X applications can already hide their window decorations and do > >> > their own stuff, but this technique is not used very often (at least > >> > for full-blown application windows) at the moment, so why make it the > >> > default? > >> > >> Since we don't need to re-parent windows, any compositor (for example > >> a mutter based or compiz based libwayland-server) would be able to > >> draw the window decorations and get their input just fine. The clients > >> don't need to worry about their own decorations. These servers can > >> also handle drawing the background of the window to (so the buffers > >> that are passed to us are actually ARGB buffers with an 100% > >> transparent background). > >> > >> Regards, > >> > >> Sam > >> > >> > -- > >> > > >> > regards, > >> > > >> > Fabian Henze > >> > > >> > _______________________________________________ > >> > wayland-devel mailing list > >> > wayland-devel at lists.freedesktop.org > >> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > That definantly sounds better... I already had the Terminal cleint freeze > > up, and become unmovable over a whole bunch of windows... > > > > But how can it insure that we won't get two titlebars? If the client is > > drawing its titlebar, and if the sever is drawing its titlebar? > > We will install a hint to tell the client not to draw decorations. > > > And how will the server know to not put a titlebar on windows like popup > > menus? > > I would imagine there'd be something similar to EWMH's window types - > however for wayland this isn't really relevant as the menus would be > part of the application's buffer space anyways. > > > Some interface probably would need to be put into the protocol in order > > for this to work I think. Am I right? > > I would imagine there would need to be some kind of specification, but > this can be worked out once we have compositing managers and toolkits > ported. Awesome! With this, and the proposed NX style remote app fowarding ability, it seems we won't lose many X features... From dana at orodu.net Mon Nov 15 17:22:42 2010 From: dana at orodu.net (Dana Jansens) Date: Mon, 15 Nov 2010 20:22:42 -0500 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: <201011151947.41580.bluescreen_avenger@verizon.net> References: <201011141055.20550.bluescreen_avenger@verizon.net> <201011151947.41580.bluescreen_avenger@verizon.net> Message-ID: On Mon, Nov 15, 2010 at 7:47 PM, nerdopolis wrote: > On Sunday, November 14, 2010 07:06:51 pm you wrote: >> On Sun, Nov 14, 2010 at 11:55 PM, nerdopolis >> >> wrote: >> > On Sunday, November 14, 2010 07:53:40 am Sam Spilsbury wrote: >> >> On Sun, Nov 14, 2010 at 8:25 PM, Fabian Henze wrote: >> >> > Hi all, >> >> > >> >> > I am rather new to all this and I don't know all the facts, so please >> >> > forgive me, if my concerns are stupid or not valid at all. >> >> > >> >> > On Thu 04 Nov 2010 04:22:37-PDT, Justin Lee wrote: >> >> >> In considering consistent look and feel issue of window decorations >> >> >> >> >> >> due to client-side window decoration, maybe we shouldn't let the >> >> >> >> >> >> toolkit (Qt/GTK) render decorations nor let the app render its >> >> >> >> >> >> decoration directly. Rather, there should be a separate, independent >> >> >> >> >> >> library (may be called libWinDeco) dedicated to render window >> >> >> >> >> >> decorations. Whenever an app needs to render its decoration, it calls >> >> >> >> >> >> libWinDeco to help the job. Then this becomes a programming >> >> >> >> >> >> convention/protocol to each Wayland app that Wayland app should use >> >> >> >> >> >> libWinDeco to render decoration by default (unless the app want to be >> >> >> >> >> >> maverick, it can disregard the convention and render its decoration >> >> >> by >> >> >> >> >> >> itself directly). If all Wayland apps follow the convention, they >> >> >> will >> >> >> >> >> >> have consistent look and feel of window decorations as all the >> >> >> >> >> >> decorations are rendered by the same code, i.e. libWinDeco. >> >> >> >> >> >> >> >> >> >> >> >> By this way, highly customizable window appearances are still >> >> >> possible >> >> >> >> >> >> if libWinDeco is designed to be configurable. Where 'configurable' >> >> >> >> >> >> means behaviors of libWinDeco are controlled by a single, universal, >> >> >> >> >> >> system-wide config file (which specifies button attributes, title bar >> >> >> >> >> >> appearances etc.). >> >> > >> >> > [..] >> >> > >> >> >> libWinDeco should be designed to be easy to use in order to make >> >> >> >> >> >> programmers willing to follow the convention therefore glitchy apps >> >> >> >> >> >> become rare. >> >> > >> >> > This seems like a much more complicated and error-prone solution >> >> > compared to server-side window decorations (sswd ;)). I am wondering >> >> > what you gain compared to sswd? In other words: How is this an >> >> > improvement over the current design of X.org? >> >> > >> >> > Todays X applications can already hide their window decorations and do >> >> > their own stuff, but this technique is not used very often (at least >> >> > for full-blown application windows) at the moment, so why make it the >> >> > default? >> >> >> >> Since we don't need to re-parent windows, any compositor (for example >> >> a mutter based or compiz based libwayland-server) would be able to >> >> draw the window decorations and get their input just fine. The clients >> >> don't need to worry about their own decorations. These servers can >> >> also handle drawing the background of the window to (so the buffers >> >> that are passed to us are actually ARGB buffers with an 100% >> >> transparent background). >> >> >> >> Regards, >> >> >> >> Sam >> >> >> >> > -- >> >> > >> >> > regards, >> >> > >> >> > Fabian Henze >> >> > >> >> > _______________________________________________ >> >> > wayland-devel mailing list >> >> > wayland-devel at lists.freedesktop.org >> >> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > >> > That definantly sounds better... I already had the Terminal cleint freeze >> > up, and become unmovable over a whole bunch of windows... >> > >> > But how can it insure that we won't get two titlebars? If the client is >> > drawing its titlebar, and if the sever is drawing its titlebar? >> >> We will install a hint to tell the client not to draw decorations. >> >> > And how will the server know to not put a titlebar on windows like popup >> > menus? >> >> I would imagine there'd be something similar to EWMH's window types - >> however for wayland this isn't really relevant as the menus would be >> part of the application's buffer space anyways. >> >> > Some interface probably would need to be put into the protocol in order >> > for this to work I think. Am I right? >> >> I would imagine there would need to be some kind of specification, but >> this can be worked out once we have compositing managers and toolkits >> ported. > > Awesome! > With this, and the proposed NX style remote app fowarding ability, it seems we > won't lose many X features... Hello, I think it is important to point out that this conversation has been predicated entirely on the idea that window decorations and window managers are the same thing. Window management is - at its core - a filter for focus and window manipulation requests. It does not require that the WM also draw the window decorations. A window can initiate an move/resize just as well as the WM itself can, via a request to the WM. I think it would be a big step to make this separation clear from the start, and have window decorations separate from the WM functionality, wherever they end up. Personally, I think toolkits could do a better job of rendering decorations than the compositor could. Secondly, there seems to be a belief that people would write wayland applications without any toolkit - that wayland would be a toolkit in essence, like Xlib is. Also, similar to the demo apps that are currently given. But from what I see of the project, it would be expected that applications would be developed using a reasonable toolkit such as Qt or GTK, and thus those toolkits can provide all the functionality clients are concerned about - such as threading for window interaction and so on. I don't see any reason to try push any of that onto the compositor/WM. Cheers, Dana -- http://openbox.org/ From bluescreen_avenger at verizon.net Mon Nov 15 20:20:16 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Mon, 15 Nov 2010 23:20:16 -0500 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: References: <201011151947.41580.bluescreen_avenger@verizon.net> Message-ID: <201011152320.17460.bluescreen_avenger@verizon.net> On Monday, November 15, 2010 08:22:42 pm Dana Jansens wrote: > On Mon, Nov 15, 2010 at 7:47 PM, nerdopolis > > wrote: > > On Sunday, November 14, 2010 07:06:51 pm you wrote: > >> On Sun, Nov 14, 2010 at 11:55 PM, nerdopolis > >> > >> wrote: > >> > On Sunday, November 14, 2010 07:53:40 am Sam Spilsbury wrote: > >> >> On Sun, Nov 14, 2010 at 8:25 PM, Fabian Henze wrote: > >> >> > Hi all, > >> >> > > >> >> > I am rather new to all this and I don't know all the facts, so > >> >> > please forgive me, if my concerns are stupid or not valid at all. > >> >> > > >> >> > On Thu 04 Nov 2010 04:22:37-PDT, Justin Lee wrote: > >> >> >> In considering consistent look and feel issue of window > >> >> >> decorations > >> >> >> > >> >> >> due to client-side window decoration, maybe we shouldn't let the > >> >> >> > >> >> >> toolkit (Qt/GTK) render decorations nor let the app render its > >> >> >> > >> >> >> decoration directly. Rather, there should be a separate, > >> >> >> independent > >> >> >> > >> >> >> library (may be called libWinDeco) dedicated to render window > >> >> >> > >> >> >> decorations. Whenever an app needs to render its decoration, it > >> >> >> calls > >> >> >> > >> >> >> libWinDeco to help the job. Then this becomes a programming > >> >> >> > >> >> >> convention/protocol to each Wayland app that Wayland app should > >> >> >> use > >> >> >> > >> >> >> libWinDeco to render decoration by default (unless the app want to > >> >> >> be > >> >> >> > >> >> >> maverick, it can disregard the convention and render its > >> >> >> decoration by > >> >> >> > >> >> >> itself directly). If all Wayland apps follow the convention, they > >> >> >> will > >> >> >> > >> >> >> have consistent look and feel of window decorations as all the > >> >> >> > >> >> >> decorations are rendered by the same code, i.e. libWinDeco. > >> >> >> > >> >> >> > >> >> >> > >> >> >> By this way, highly customizable window appearances are still > >> >> >> possible > >> >> >> > >> >> >> if libWinDeco is designed to be configurable. Where 'configurable' > >> >> >> > >> >> >> means behaviors of libWinDeco are controlled by a single, > >> >> >> universal, > >> >> >> > >> >> >> system-wide config file (which specifies button attributes, title > >> >> >> bar > >> >> >> > >> >> >> appearances etc.). > >> >> > > >> >> > [..] > >> >> > > >> >> >> libWinDeco should be designed to be easy to use in order to make > >> >> >> > >> >> >> programmers willing to follow the convention therefore glitchy > >> >> >> apps > >> >> >> > >> >> >> become rare. > >> >> > > >> >> > This seems like a much more complicated and error-prone solution > >> >> > compared to server-side window decorations (sswd ;)). I am > >> >> > wondering what you gain compared to sswd? In other words: How is > >> >> > this an improvement over the current design of X.org? > >> >> > > >> >> > Todays X applications can already hide their window decorations and > >> >> > do their own stuff, but this technique is not used very often (at > >> >> > least for full-blown application windows) at the moment, so why > >> >> > make it the default? > >> >> > >> >> Since we don't need to re-parent windows, any compositor (for example > >> >> a mutter based or compiz based libwayland-server) would be able to > >> >> draw the window decorations and get their input just fine. The > >> >> clients don't need to worry about their own decorations. These > >> >> servers can also handle drawing the background of the window to (so > >> >> the buffers that are passed to us are actually ARGB buffers with an > >> >> 100% transparent background). > >> >> > >> >> Regards, > >> >> > >> >> Sam > >> >> > >> >> > -- > >> >> > > >> >> > regards, > >> >> > > >> >> > Fabian Henze > >> >> > > >> >> > _______________________________________________ > >> >> > wayland-devel mailing list > >> >> > wayland-devel at lists.freedesktop.org > >> >> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > >> > > >> > That definantly sounds better... I already had the Terminal cleint > >> > freeze up, and become unmovable over a whole bunch of windows... > >> > > >> > But how can it insure that we won't get two titlebars? If the client > >> > is drawing its titlebar, and if the sever is drawing its titlebar? > >> > >> We will install a hint to tell the client not to draw decorations. > >> > >> > And how will the server know to not put a titlebar on windows like > >> > popup menus? > >> > >> I would imagine there'd be something similar to EWMH's window types - > >> however for wayland this isn't really relevant as the menus would be > >> part of the application's buffer space anyways. > >> > >> > Some interface probably would need to be put into the protocol in > >> > order for this to work I think. Am I right? > >> > >> I would imagine there would need to be some kind of specification, but > >> this can be worked out once we have compositing managers and toolkits > >> ported. > > > > Awesome! > > With this, and the proposed NX style remote app fowarding ability, it > > seems we won't lose many X features... > > Hello, > > I think it is important to point out that this conversation has been > predicated entirely on the idea that window decorations and window > managers are the same thing. > > Window management is - at its core - a filter for focus and window > manipulation requests. It does not require that the WM also draw the > window decorations. A window can initiate an move/resize just as well > as the WM itself can, via a request to the WM. I think it would be a > big step to make this separation clear from the start, and have window > decorations separate from the WM functionality, wherever they end up. > > Personally, I think toolkits could do a better job of rendering > decorations than the compositor could. > > Secondly, there seems to be a belief that people would write wayland > applications without any toolkit - that wayland would be a toolkit in > essence, like Xlib is. Also, similar to the demo apps that are > currently given. But from what I see of the project, it would be > expected that applications would be developed using a reasonable > toolkit such as Qt or GTK, and thus those toolkits can provide all the > functionality clients are concerned about - such as threading for > window interaction and so on. I don't see any reason to try push any > of that onto the compositor/WM. > > Cheers, > Dana Hmm... I guess threading provided by a toolkit library would save users from a hung window because of a bug in the app that causes it to hang, but I guess the window can still hang if the entire procesess is suspended... ...Or if the app is rouge or something, and it does not use a toolkit and is written to hang a window on the screen... but, by the looks of it, we will be able to chose cleint side or server side decorations which I guess is neat! From kamilion at gmail.com Tue Nov 16 00:31:20 2010 From: kamilion at gmail.com (Graham Cantin) Date: Tue, 16 Nov 2010 00:31:20 -0800 Subject: More ubuntu build instructions In-Reply-To: <20101114192112.GF30262@chaosreigns.com> References: <20101114192112.GF30262@chaosreigns.com> Message-ID: On Sun, Nov 14, 2010 at 11:21 AM, wrote: > > http://www.chaosreigns.com/wayland/ubuntu.html > http://www.chaosreigns.com/wayland/wayland-build-ubuntu-intel.sh > http://www.chaosreigns.com/wayland/wayland-build-ubuntu-not-intel.sh > > I think this should cover all builds under Ubuntu Maverick. ?I'd like it to > end up on the wayland web site. > > Let me know if you have suggestions for improvement, or it doesn't work for > you. > > As the web page mentions, this is likely to be useful on other platforms as > long as you install the build dependencies first. > Think I've got a 7600 hanging around somewhere... I'll dig it up and give this a shot. What's the status on accelerated 3D drivers in virtual machines? Wasn't there some VMGL thing going on 2007ish they were trumpeting? I know VirtualBox and VMWare have some sort of GL acceleration; and I remember some interesting patches floating around for KVM... Is there something fundamental missing? OpenGL 1.x only? I prefer Ubuntu, and it'd be nice to be able to mess with Wayland on VMWare Player or something without much in the way of host video hardware restrictions. Got a bunch of AMD 780Gs with maverick; love to see them running wayland early. At least if not a VM; support for the cheap $300 AMD rigs would probably draw in some more folks. -- [? ?? Graham Cantin? ? ? ] | (408) 890-7463 - Google Voice FindME "Never feel stupid for asking questions, feel stupid for ignoring answers." [? System Administrator? ] | (XXX) XXX-XXXX xXXX - IT & Office PBX "You're arrogant for thinking you can, ignorant for thinking you cannot." [ RFSpot Mobile Services ] | (XXX) XXX-XXXX - Main Office Direct "Asking questions is important, because that's when intuition gets converted into inspiration." [?? NASA Ames Research?? ] | Building 19, Moffett Field, CA "As living spies we must recruit men who are intelligent?but appear to be stupid; who seem to be dull but are strong in heart;?men who are agile, vigorous, hardy, and brave; well-versed in lowly matters?and able to endure hunger, cold, filth, and humiliation." - Tu Mu (803-825) From flyser42 at gmx.de Tue Nov 16 00:55:34 2010 From: flyser42 at gmx.de (Fabian Henze) Date: Tue, 16 Nov 2010 09:55:34 +0100 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: References: <201011151947.41580.bluescreen_avenger@verizon.net> Message-ID: <201011160955.38142.flyser42@gmx.de> Hello, On Tuesday, 16 Nov 2010, 01:22:42-UTC, Dana Jansens wrote: > I think it is important to point out that this conversation has been > predicated entirely on the idea that window decorations and window > managers are the same thing. > > Window management is - at its core - a filter for focus and window > manipulation requests. It does not require that the WM also draw the > window decorations. A window can initiate an move/resize just as well > as the WM itself can, via a request to the WM. Could you elaborate, why this makes such a big difference? While I am aware of this distinction, I don't think it changes the situation at all. > I think it would be a > big step to make this separation clear from the start, and have window > decorations separate from the WM functionality, wherever they end up. The thing I don't understand about this whole discussion is: How would this be a big step? Why would you want to put this kind of logic in the client? I see numerous issues (please correct me if they are actually non-issues): 1. advanced WM features won't work, like: disallow fullscreen for certain windows, always maximize a certain window, resize and move using user-defined hotkeys, snap to window borders. 2. I just don't believe that GTK, Qt and all the minor toolkits will agree on standards for window decoration and behaviour. That would make the linux desktop even more inconsistent than it is now. 3. Freezing clients, remote clients with a hung connection, stopped clients (CTRL-Z) may cause unmovable windows. 4. code and bug (!) duplication in every toolkit. 5. Malware, adware or scareware easily have way too much control about the graphical environment. To sum it up: I am concerned, that most features that make X11 window managers absolutely rock compared to Windows or OSX will be gone. > > Personally, I think toolkits could do a better job of rendering > decorations than the compositor could. Why? and in which way? > Secondly, there seems to be a belief that people would write wayland > applications without any toolkit - that wayland would be a toolkit in > essence, like Xlib is. Also, similar to the demo apps that are > currently given. But from what I see of the project, it would be > expected that applications would be developed using a reasonable > toolkit such as Qt or GTK, and thus those toolkits can provide all the > functionality clients are concerned about - such as threading for > window interaction and so on. I don't see any reason to try push any > of that onto the compositor/WM. While I generally agree, I would like to point out that some applications might not require a toolkit. The most prominent example would be 3d games, but I think there are also other special purpose applications, that might not want to use a toolkit (like proprietary ports of windows software). btw. Has anyone ever asked the developers of the major desktop environments, windows managers and toolkits what they want? -- regards, Fabian Henze From espen at opera.com Tue Nov 16 01:52:42 2010 From: espen at opera.com (Espen Sand) Date: Tue, 16 Nov 2010 10:52:42 +0100 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: <201011160955.38142.flyser42@gmx.de> References: <201011151947.41580.bluescreen_avenger@verizon.net> <201011160955.38142.flyser42@gmx.de> Message-ID: On Tue, 16 Nov 2010 09:55:34 +0100, Fabian Henze wrote: > Hello, > > 2. I just don't believe that GTK, Qt and all the minor toolkits will > agree on standards for window decoration and behaviour. That would make > the linux > desktop even more inconsistent than it is now. I have been lurking around for a while and I am sure I do not understand all the concepts yet, but if one aim to replace functionality that, among other things, serves to decorate windows in a uniform manner, the replacement can not be any inferior in that respect. The toolkits (and applications may for other reasons depend on a special version of a toolkit) will never agree and/or be in sync all the time. I have no big problems to allow an application to have better control over the decorations (if one take security considerations into mind) but it has to happen through a common layer, perhaps a library, or a separate program as today, which all programs must use. One issue with a library approach is that an application using one toolkit may suddenly have to depend on anther as well because of the dependencies of the decoration library itself. I do not think anyone want a future where programs depend both Qt and GTK. Or perhaps depend one of them just because of required toolkit decorations (if no toolkit is otherwise needed by the application). -- Espen Sand From dana at orodu.net Tue Nov 16 08:27:22 2010 From: dana at orodu.net (Dana Jansens) Date: Tue, 16 Nov 2010 11:27:22 -0500 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: <201011160955.38142.flyser42@gmx.de> References: <201011151947.41580.bluescreen_avenger@verizon.net> <201011160955.38142.flyser42@gmx.de> Message-ID: On Tue, Nov 16, 2010 at 3:55 AM, Fabian Henze wrote: > Hello, > > On Tuesday, 16 Nov 2010, 01:22:42-UTC, Dana Jansens wrote: >> I think it is important to point out that this conversation has been >> predicated entirely on the idea that window decorations and window >> managers are the same thing. >> >> Window management is - at its core - a filter for focus and window >> manipulation requests. ?It does not require that the WM also draw the >> window decorations. ?A window can initiate an move/resize just as well >> as the WM itself can, via a request to the WM. > > Could you elaborate, why this makes such a big difference? While I am aware of > this distinction, I don't think it changes the situation at all. Because the discussion was talking about where to put decorations, but the advantages/disadvantages were talking about where to put control of window placement/focus control. If talking about where to put decorations, it should only be talking about advantages/disadvantages of that decision, and the WM logic is independent. > >> I think it would be a >> big step to make this separation clear from the start, and have window >> decorations separate from the WM functionality, wherever they end up. > > The thing I don't understand about this whole discussion is: How would this be > a big step? Why would you want to put this kind of logic in the client? > > I see numerous issues (please correct me if they are actually non-issues): > 1. advanced WM features won't work, like: disallow fullscreen for certain > windows, always maximize a certain window, resize and move using user-defined > hotkeys, snap to window borders. > 2. I just don't believe that GTK, Qt and all the minor toolkits will agree on > standards for window decoration and behaviour. That would make the linux > desktop even more inconsistent than it is now. > 3. Freezing clients, remote clients with a hung connection, stopped clients > (CTRL-Z) may cause unmovable windows. > 4. code and bug (!) duplication in every toolkit. > 5. Malware, adware or scareware easily have way too much control about the > graphical environment. > > To sum it up: I am concerned, that most features that make X11 window managers > absolutely rock compared to Windows or OSX will be gone. I agree that WMs are great and have been working on one for years because of this. But I also believe separating functionality and presentation would be a good step, and an improvement over the current model in X. Separation along these boundaries is a pretty common pattern in software design. I'm not saying that applications should be responsible for behaviour, though. As you stated, and others have also pointed out shortcomings of that. Instead, I would like to see a standard interface in the compositor for a WM component that could act on focus and window change requests. But if decorations are drawn by the compositor, it should provide a separate interface for decorations. This way you can choose your decoration style independent of your WM behaviour. Of your above examples, the only one a toolkit could not cleanly handle is the ^Z case. And it would still be possible to kill the process in this case, so I don't think it is something that should be a deal breaker either way. >> >> Personally, I think toolkits could do a better job of rendering >> decorations than the compositor could. > > Why? and in which way? A lot of work goes into making themes match with the toolkit, and each WM has to do an equal amount of effort to do this. Or blending decorations and window contents together. GTK and Qt have both done a pretty good job of providing skinnable/malleable interfaces, and I would expect that continue with decorations. Also, if you'd like to allow windows to provide non-rectangular interfaces - such as many OSX apps can do - then the toolkit would be a much better place to worry about decorations, as it will understand the context of the shapes in its window, while an external decorator will not. I would like to leave the paradigm of everything is a rectangle far behind. >> Secondly, there seems to be a belief that people would write wayland >> applications without any toolkit - that wayland would be a toolkit in >> essence, like Xlib is. ?Also, similar to the demo apps that are >> currently given. ?But from what I see of the project, it would be >> expected that applications would be developed using a reasonable >> toolkit such as Qt or GTK, and thus those toolkits can provide all the >> functionality clients are concerned about - such as threading for >> window interaction and so on. ?I don't see any reason to try push any >> of that onto the compositor/WM. > > While I generally agree, I would like to point out that some applications > might not require a toolkit. The most prominent example would be 3d games, but > I think there are also other special purpose applications, that might not want > to use a toolkit (like proprietary ports of windows software). A toolkit provides a lot more than just widgets. Everything needs a toolkit of some sort, or else they are writing their own toolkit. X apps that use Xlib are also using a toolkit, abeit a simple and very obsolete one. Just dealing with things like window creation, window focus, interaction with the WM etc are functionalities of a toolkit. > btw. Has anyone ever asked the developers of the major desktop environments, > windows managers and toolkits what they want? For example: http://live.gnome.org/GTK+/ClientSideDecorations Cheers, Dana ps Being a WM developer (Openbox) for 7 years, I am at least one more voice on the issue with some awareness of the issues. -- http://openbox.org From justinlee5455 at gmail.com Tue Nov 16 08:27:49 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Wed, 17 Nov 2010 00:27:49 +0800 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: <201011160955.38142.flyser42@gmx.de> References: <201011151947.41580.bluescreen_avenger@verizon.net> <201011160955.38142.flyser42@gmx.de> Message-ID: 2010/11/16 Fabian Henze : > 3. Freezing clients, remote clients with a hung connection, stopped clients > (CTRL-Z) may cause unmovable windows. Good point. But CTRL-Z isn't supposed to cause unmovable windows if the toolkits create process (by fork()/execv() etc.) to handle decoration events instead of threading (by pthread_create()). From krh at bitplanet.net Tue Nov 16 09:13:24 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Tue, 16 Nov 2010 12:13:24 -0500 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: References: <201011151947.41580.bluescreen_avenger@verizon.net> <201011160955.38142.flyser42@gmx.de> Message-ID: On Tue, Nov 16, 2010 at 11:27 AM, Dana Jansens wrote: > On Tue, Nov 16, 2010 at 3:55 AM, Fabian Henze wrote: >> Hello, >> >> On Tuesday, 16 Nov 2010, 01:22:42-UTC, Dana Jansens wrote: >>> I think it is important to point out that this conversation has been >>> predicated entirely on the idea that window decorations and window >>> managers are the same thing. >>> >>> Window management is - at its core - a filter for focus and window >>> manipulation requests. ?It does not require that the WM also draw the >>> window decorations. ?A window can initiate an move/resize just as well >>> as the WM itself can, via a request to the WM. >> >> Could you elaborate, why this makes such a big difference? While I am aware of >> this distinction, I don't think it changes the situation at all. > > Because the discussion was talking about where to put decorations, but > the advantages/disadvantages were talking about where to put control > of window placement/focus control. ?If talking about where to put > decorations, it should only be talking about advantages/disadvantages > of that decision, and the WM logic is independent. > >> >>> I think it would be a >>> big step to make this separation clear from the start, and have window >>> decorations separate from the WM functionality, wherever they end up. >> >> The thing I don't understand about this whole discussion is: How would this be >> a big step? Why would you want to put this kind of logic in the client? >> >> I see numerous issues (please correct me if they are actually non-issues): >> 1. advanced WM features won't work, like: disallow fullscreen for certain >> windows, always maximize a certain window, resize and move using user-defined >> hotkeys, snap to window borders. >> 2. I just don't believe that GTK, Qt and all the minor toolkits will agree on >> standards for window decoration and behaviour. That would make the linux >> desktop even more inconsistent than it is now. >> 3. Freezing clients, remote clients with a hung connection, stopped clients >> (CTRL-Z) may cause unmovable windows. >> 4. code and bug (!) duplication in every toolkit. >> 5. Malware, adware or scareware easily have way too much control about the >> graphical environment. >> >> To sum it up: I am concerned, that most features that make X11 window managers >> absolutely rock compared to Windows or OSX will be gone. > > I agree that WMs are great and have been working on one for years > because of this. > > But I also believe separating functionality and presentation would be > a good step, and an improvement over the current model in X. > Separation along these boundaries is a pretty common pattern in > software design. ?I'm not saying that applications should be > responsible for behaviour, though. ?As you stated, and others have > also pointed out shortcomings of that. > > Instead, I would like to see a standard interface in the compositor > for a WM component that could act on focus and window change requests. > ?But if decorations are drawn by the compositor, it should provide a > separate interface for decorations. ?This way you can choose your > decoration style independent of your WM behaviour. > > Of your above examples, the only one a toolkit could not cleanly > handle is the ^Z case. ?And it would still be possible to kill the > process in this case, so I don't think it is something that should be > a deal breaker either way. > >>> >>> Personally, I think toolkits could do a better job of rendering >>> decorations than the compositor could. >> >> Why? and in which way? > > A lot of work goes into making themes match with the toolkit, and each > WM has to do an equal amount of effort to do this. ?Or blending > decorations and window contents together. ?GTK and Qt have both done a > pretty good job of providing skinnable/malleable interfaces, and I > would expect that continue with decorations. > > Also, if you'd like to allow windows to provide non-rectangular > interfaces - such as many OSX apps can do - then the toolkit would be > a much better place to worry about decorations, as it will understand > the context of the shapes in its window, while an external decorator > will not. ?I would like to leave the paradigm of everything is a > rectangle far behind. > >>> Secondly, there seems to be a belief that people would write wayland >>> applications without any toolkit - that wayland would be a toolkit in >>> essence, like Xlib is. ?Also, similar to the demo apps that are >>> currently given. ?But from what I see of the project, it would be >>> expected that applications would be developed using a reasonable >>> toolkit such as Qt or GTK, and thus those toolkits can provide all the >>> functionality clients are concerned about - such as threading for >>> window interaction and so on. ?I don't see any reason to try push any >>> of that onto the compositor/WM. >> >> While I generally agree, I would like to point out that some applications >> might not require a toolkit. The most prominent example would be 3d games, but >> I think there are also other special purpose applications, that might not want >> to use a toolkit (like proprietary ports of windows software). > > A toolkit provides a lot more than just widgets. Everything needs a > toolkit of some sort, or else they are writing their own toolkit. ?X > apps that use Xlib are also using a toolkit, abeit a simple and very > obsolete one. ?Just dealing with things like window creation, window > focus, interaction with the WM etc are functionalities of a toolkit. Dana, you're basically making all the points I was going to make. There's a difference between client side window management and client side window decorations. Wayland relies on clients drawing their own decorations, but the window management is done by the compositor. The clients are responsible for detecting when an input device tries to move, resize or lower the client surface, by handling clicks and drags in the title bar or window frame. Once a client has decided that an input device has clicked its title bar, the client tells the compositor "please move me". The compositor will then move the window around, snapping to other window and screen edges as it goes. The compositor can decide to move the window without the client getting involved, similar to how metacity (for example) can move a window if you alt+leftclick anywhere in the window, in the demo compositor this is bound to super+leftclick. I think some people have taken "client side decorations" to mean all bad things that Windows do, but it's really just about letting applications draw their own titlebars and borders. There will still be a central process that can move windows around, raise or lower them, or force-close them whether or not the clients are responsive. Letting clients draw their own decorations has a lot of benefits - better performance, less work when compositing, more flexibility for theming and better visuals for transformed windows. Kristian From scaroo at gmail.com Tue Nov 16 14:03:21 2010 From: scaroo at gmail.com (Alexandre Mazari) Date: Tue, 16 Nov 2010 23:03:21 +0100 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: References: <201011151947.41580.bluescreen_avenger@verizon.net> <201011160955.38142.flyser42@gmx.de> Message-ID: The points made by krh four years ago [0] still hold true and are still the most convincing arguments for CSD I've read. [0] http://people.freedesktop.org/~krh/client-side-decorations.txt for 4 years 2010/11/16 Kristian H?gsberg : > On Tue, Nov 16, 2010 at 11:27 AM, Dana Jansens wrote: >> On Tue, Nov 16, 2010 at 3:55 AM, Fabian Henze wrote: >>> Hello, >>> >>> On Tuesday, 16 Nov 2010, 01:22:42-UTC, Dana Jansens wrote: >>>> I think it is important to point out that this conversation has been >>>> predicated entirely on the idea that window decorations and window >>>> managers are the same thing. >>>> >>>> Window management is - at its core - a filter for focus and window >>>> manipulation requests. ?It does not require that the WM also draw the >>>> window decorations. ?A window can initiate an move/resize just as well >>>> as the WM itself can, via a request to the WM. >>> >>> Could you elaborate, why this makes such a big difference? While I am aware of >>> this distinction, I don't think it changes the situation at all. >> >> Because the discussion was talking about where to put decorations, but >> the advantages/disadvantages were talking about where to put control >> of window placement/focus control. ?If talking about where to put >> decorations, it should only be talking about advantages/disadvantages >> of that decision, and the WM logic is independent. >> >>> >>>> I think it would be a >>>> big step to make this separation clear from the start, and have window >>>> decorations separate from the WM functionality, wherever they end up. >>> >>> The thing I don't understand about this whole discussion is: How would this be >>> a big step? Why would you want to put this kind of logic in the client? >>> >>> I see numerous issues (please correct me if they are actually non-issues): >>> 1. advanced WM features won't work, like: disallow fullscreen for certain >>> windows, always maximize a certain window, resize and move using user-defined >>> hotkeys, snap to window borders. >>> 2. I just don't believe that GTK, Qt and all the minor toolkits will agree on >>> standards for window decoration and behaviour. That would make the linux >>> desktop even more inconsistent than it is now. >>> 3. Freezing clients, remote clients with a hung connection, stopped clients >>> (CTRL-Z) may cause unmovable windows. >>> 4. code and bug (!) duplication in every toolkit. >>> 5. Malware, adware or scareware easily have way too much control about the >>> graphical environment. >>> >>> To sum it up: I am concerned, that most features that make X11 window managers >>> absolutely rock compared to Windows or OSX will be gone. >> >> I agree that WMs are great and have been working on one for years >> because of this. >> >> But I also believe separating functionality and presentation would be >> a good step, and an improvement over the current model in X. >> Separation along these boundaries is a pretty common pattern in >> software design. ?I'm not saying that applications should be >> responsible for behaviour, though. ?As you stated, and others have >> also pointed out shortcomings of that. >> >> Instead, I would like to see a standard interface in the compositor >> for a WM component that could act on focus and window change requests. >> ?But if decorations are drawn by the compositor, it should provide a >> separate interface for decorations. ?This way you can choose your >> decoration style independent of your WM behaviour. >> >> Of your above examples, the only one a toolkit could not cleanly >> handle is the ^Z case. ?And it would still be possible to kill the >> process in this case, so I don't think it is something that should be >> a deal breaker either way. >> >>>> >>>> Personally, I think toolkits could do a better job of rendering >>>> decorations than the compositor could. >>> >>> Why? and in which way? >> >> A lot of work goes into making themes match with the toolkit, and each >> WM has to do an equal amount of effort to do this. ?Or blending >> decorations and window contents together. ?GTK and Qt have both done a >> pretty good job of providing skinnable/malleable interfaces, and I >> would expect that continue with decorations. >> >> Also, if you'd like to allow windows to provide non-rectangular >> interfaces - such as many OSX apps can do - then the toolkit would be >> a much better place to worry about decorations, as it will understand >> the context of the shapes in its window, while an external decorator >> will not. ?I would like to leave the paradigm of everything is a >> rectangle far behind. >> >>>> Secondly, there seems to be a belief that people would write wayland >>>> applications without any toolkit - that wayland would be a toolkit in >>>> essence, like Xlib is. ?Also, similar to the demo apps that are >>>> currently given. ?But from what I see of the project, it would be >>>> expected that applications would be developed using a reasonable >>>> toolkit such as Qt or GTK, and thus those toolkits can provide all the >>>> functionality clients are concerned about - such as threading for >>>> window interaction and so on. ?I don't see any reason to try push any >>>> of that onto the compositor/WM. >>> >>> While I generally agree, I would like to point out that some applications >>> might not require a toolkit. The most prominent example would be 3d games, but >>> I think there are also other special purpose applications, that might not want >>> to use a toolkit (like proprietary ports of windows software). >> >> A toolkit provides a lot more than just widgets. Everything needs a >> toolkit of some sort, or else they are writing their own toolkit. ?X >> apps that use Xlib are also using a toolkit, abeit a simple and very >> obsolete one. ?Just dealing with things like window creation, window >> focus, interaction with the WM etc are functionalities of a toolkit. > > Dana, you're basically making all the points I was going to make. > There's a difference between client side window management and client > side window decorations. ?Wayland relies on clients drawing their own > decorations, but the window management is done by the compositor. ?The > clients are responsible for detecting when an input device tries to > move, resize or lower the client surface, by handling clicks and drags > in the title bar or window frame. ?Once a client has decided that an > input device has clicked its title bar, the client tells the > compositor "please move me". ?The compositor will then move the window > around, snapping to other window and screen edges as it goes. ?The > compositor can decide to move the window without the client getting > involved, similar to how metacity (for example) can move a window if > you alt+leftclick anywhere in the window, in the demo compositor this > is bound to super+leftclick. > > I think some people have taken "client side decorations" to mean all > bad things that Windows do, but it's really just about letting > applications draw their own titlebars and borders. ?There will still > be a central process that can move windows around, raise or lower > them, or force-close them whether or not the clients are responsive. > Letting clients draw their own decorations has a lot of benefits - > better performance, less work when compositing, more flexibility for > theming and better visuals for transformed windows. > > Kristian > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- "If you open your mind too much, you brain will fall out" Tim Minchin From jonsmirl at gmail.com Tue Nov 16 18:14:40 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Tue, 16 Nov 2010 21:14:40 -0500 Subject: Getting anti-aliasing right Message-ID: What is the plan for anti-aliasing? If an app draws a beautiful anti-aliased scene to a buffer, and then that buffer is transformed by the compositor, all of that beautiful anti-aliasing is going to get messed up. Especially sub-pixel antialiasing if the compositor transform changes the alignment of the screen with the LCD pixels. One approach is to tell the app the final window transform and let them draw a transformed screen instead of a rectangle that gets transformed by the compositor. But this means an app need to be able to handle being told to project itself onto a rotating sphere. Another approach is for apps to create a screen graph out of primitives that some other system renders when it know the final transform. This method lets the compositor implement animations without involving the app. This problem is closely tied into glyph generation. Sooner or later we're going to be generating glyphs on the GPU in real-time. If we're doing that then you don't want anti-aliased glyphs being generated inside the apps like we do today. Apps will still need to compute glyph spacing and pick a spacing as a result of hinting, but the compositor may want to regenerate the glyphs if the window is shrunk, zoomed, twisted, etc. I'm sure there are other ways to handle anti-aliasing. If the goal is to make pixel perfect images every time then anti-aliasing strategy is something that needs to be planned. -- Jon Smirl jonsmirl at gmail.com From mostawesomedude at gmail.com Tue Nov 16 18:30:36 2010 From: mostawesomedude at gmail.com (Corbin Simpson) Date: Tue, 16 Nov 2010 18:30:36 -0800 Subject: Getting anti-aliasing right In-Reply-To: References: Message-ID: On Tue, Nov 16, 2010 at 6:14 PM, jonsmirl at gmail.com wrote: > What is the plan for anti-aliasing? If an app draws a beautiful > anti-aliased scene to a buffer, and then that buffer is transformed by > the compositor, all of that beautiful anti-aliasing is going to get > messed up. Especially sub-pixel antialiasing if the compositor > transform changes the alignment of the screen with the LCD pixels. > > One approach is to tell the app the final window transform and let > them draw a transformed screen instead of a rectangle that gets > transformed by the compositor. But this means an app need to be able > to handle being told to project itself onto a rotating sphere. > > Another approach is for apps to create a screen graph out of > primitives that some other system renders when it know the final > transform. This method lets the compositor implement animations > without involving the app. > > This problem is closely tied into glyph generation. Sooner or later > we're going to be generating glyphs on the GPU in real-time. If we're > doing that then you don't want anti-aliased glyphs being generated > inside the apps like we do today. Apps will still need to compute > glyph spacing and pick a spacing as a result of hinting, but the > compositor may want to regenerate the glyphs if the window is shrunk, > zoomed, twisted, etc. > > I'm sure there are other ways to handle anti-aliasing. If the goal is > to make pixel perfect images every time then anti-aliasing strategy is > something that needs to be planned. What's the difference between Wayland and X11 here, exactly? We *already* draw anti-aliased subpixel-specific font glyphs on GPUs and it looks fine. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson From christopher.halse.rogers at canonical.com Tue Nov 16 19:18:46 2010 From: christopher.halse.rogers at canonical.com (Christopher James Halse Rogers) Date: Wed, 17 Nov 2010 14:18:46 +1100 Subject: Getting anti-aliasing right In-Reply-To: References: Message-ID: <1289963926.7661.13.camel@Ed> On Tue, 2010-11-16 at 18:30 -0800, Corbin Simpson wrote: > On Tue, Nov 16, 2010 at 6:14 PM, jonsmirl at gmail.com wrote: > > What is the plan for anti-aliasing? If an app draws a beautiful > > anti-aliased scene to a buffer, and then that buffer is transformed by > > the compositor, all of that beautiful anti-aliasing is going to get > > messed up. Especially sub-pixel antialiasing if the compositor > > transform changes the alignment of the screen with the LCD pixels. > > > > One approach is to tell the app the final window transform and let > > them draw a transformed screen instead of a rectangle that gets > > transformed by the compositor. But this means an app need to be able > > to handle being told to project itself onto a rotating sphere. > > > > Another approach is for apps to create a screen graph out of > > primitives that some other system renders when it know the final > > transform. This method lets the compositor implement animations > > without involving the app. > > > > This problem is closely tied into glyph generation. Sooner or later > > we're going to be generating glyphs on the GPU in real-time. If we're > > doing that then you don't want anti-aliased glyphs being generated > > inside the apps like we do today. Apps will still need to compute > > glyph spacing and pick a spacing as a result of hinting, but the > > compositor may want to regenerate the glyphs if the window is shrunk, > > zoomed, twisted, etc. > > > > I'm sure there are other ways to handle anti-aliasing. If the goal is > > to make pixel perfect images every time then anti-aliasing strategy is > > something that needs to be planned. > > What's the difference between Wayland and X11 here, exactly? We > *already* draw anti-aliased subpixel-specific font glyphs on GPUs and > it looks fine. > - Unless your compositor is transforming the buffer before scanout, at which point your calculated antialiasing is no longer optimal. Say you've calculated subpixel AA with an RGB subpixel order, but the compositor flips your buffer. Or if the window buffer is being shrunk the fonts might be better rendered with a different algorithm altogether. I think the point here is that if you treat a window containing text as just an image you'll get less than optimal anti-aliasing under window transformations. This seems to be a special case of the more general observation that if applications knew the transformations applied to their surfaces then they could potentially perform higher quality rendering. I don't think the general case is feasible to accommodate, and I'd suspect that the font-rendering case won't be significantly easier. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From mostawesomedude at gmail.com Tue Nov 16 19:28:35 2010 From: mostawesomedude at gmail.com (Corbin Simpson) Date: Tue, 16 Nov 2010 19:28:35 -0800 Subject: Getting anti-aliasing right In-Reply-To: <1289963926.7661.13.camel@Ed> References: <1289963926.7661.13.camel@Ed> Message-ID: I should have been clearer. This is like compiz, where non-transformed viewports look perfect and transformed viewports look illegible. Nobody appears to have a problem with this for compiz; why should Wayland have anything different? Sending from a mobile, pardon the brevity. ~ C. On Nov 16, 2010 7:18 PM, "Christopher James Halse Rogers" < christopher.halse.rogers at canonical.com> wrote: > On Tue, 2010-11-16 at 18:30 -0800, Corbin Simpson wrote: >> On Tue, Nov 16, 2010 at 6:14 PM, jonsmirl at gmail.com wrote: >> > What is the plan for anti-aliasing? If an app draws a beautiful >> > anti-aliased scene to a buffer, and then that buffer is transformed by >> > the compositor, all of that beautiful anti-aliasing is going to get >> > messed up. Especially sub-pixel antialiasing if the compositor >> > transform changes the alignment of the screen with the LCD pixels. >> > >> > One approach is to tell the app the final window transform and let >> > them draw a transformed screen instead of a rectangle that gets >> > transformed by the compositor. But this means an app need to be able >> > to handle being told to project itself onto a rotating sphere. >> > >> > Another approach is for apps to create a screen graph out of >> > primitives that some other system renders when it know the final >> > transform. This method lets the compositor implement animations >> > without involving the app. >> > >> > This problem is closely tied into glyph generation. Sooner or later >> > we're going to be generating glyphs on the GPU in real-time. If we're >> > doing that then you don't want anti-aliased glyphs being generated >> > inside the apps like we do today. Apps will still need to compute >> > glyph spacing and pick a spacing as a result of hinting, but the >> > compositor may want to regenerate the glyphs if the window is shrunk, >> > zoomed, twisted, etc. >> > >> > I'm sure there are other ways to handle anti-aliasing. If the goal is >> > to make pixel perfect images every time then anti-aliasing strategy is >> > something that needs to be planned. >> >> What's the difference between Wayland and X11 here, exactly? We >> *already* draw anti-aliased subpixel-specific font glyphs on GPUs and >> it looks fine. >> > > - Unless your compositor is transforming the buffer before scanout, at > which point your calculated antialiasing is no longer optimal. Say > you've calculated subpixel AA with an RGB subpixel order, but the > compositor flips your buffer. Or if the window buffer is being shrunk > the fonts might be better rendered with a different algorithm > altogether. > > I think the point here is that if you treat a window containing text as > just an image you'll get less than optimal anti-aliasing under window > transformations. > > This seems to be a special case of the more general observation that if > applications knew the transformations applied to their surfaces then > they could potentially perform higher quality rendering. I don't think > the general case is feasible to accommodate, and I'd suspect that the > font-rendering case won't be significantly easier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonsmirl at gmail.com Tue Nov 16 21:37:34 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Wed, 17 Nov 2010 00:37:34 -0500 Subject: Getting anti-aliasing right In-Reply-To: References: <1289963926.7661.13.camel@Ed> Message-ID: On Tue, Nov 16, 2010 at 10:28 PM, Corbin Simpson wrote: > I should have been clearer. This is like compiz, where non-transformed > viewports look perfect and transformed viewports look illegible. Nobody > appears to have a problem with this for compiz; why should Wayland have > anything different? If Wayland ends up as our graphics foundation it may be with us for 20 years. This is a known problem and it can be fixed with some planning. Isn't the goal of Wayland to have pixel perfect graphics? Glyph generation inside the CPU is certainly going to happen in that time frame. You can already do it today on decent GPUs. We are very close to be able to run the entire compositor and scene graph engine inside the GPU. You want to plan for these things in the architecture so that we don't have to rip everything up again in five years. Today's high end GPU will be the low end GPU of 2015. > > Sending from a mobile, pardon the brevity. ~ C. > > On Nov 16, 2010 7:18 PM, "Christopher James Halse Rogers" > wrote: >> On Tue, 2010-11-16 at 18:30 -0800, Corbin Simpson wrote: >>> On Tue, Nov 16, 2010 at 6:14 PM, jonsmirl at gmail.com >>> wrote: >>> > What is the plan for anti-aliasing? If an app draws a beautiful >>> > anti-aliased scene to a buffer, and then that buffer is transformed by >>> > the compositor, all of that beautiful anti-aliasing is going to get >>> > messed up. Especially sub-pixel antialiasing if the compositor >>> > transform changes the alignment of the screen with the LCD pixels. >>> > >>> > One approach is to tell the app the final window transform and let >>> > them draw a transformed screen instead of a rectangle that gets >>> > transformed by the compositor. But this means an app need to be able >>> > to handle being told to project itself onto a rotating sphere. >>> > >>> > Another approach is for apps to create a screen graph out of >>> > primitives that some other system renders when it know the final >>> > transform. This method lets the compositor implement animations >>> > without involving the app. >>> > >>> > This problem is closely tied into glyph generation. Sooner or later >>> > we're going to be generating glyphs on the GPU in real-time. If we're >>> > doing that then you don't want anti-aliased glyphs being generated >>> > inside the apps like we do today. Apps will still need to compute >>> > glyph spacing and pick a spacing as a result of hinting, but the >>> > compositor may want to regenerate the glyphs if the window is shrunk, >>> > zoomed, twisted, etc. >>> > >>> > I'm sure there are other ways to handle anti-aliasing. If the goal is >>> > to make pixel perfect images every time then anti-aliasing strategy is >>> > something that needs to be planned. >>> >>> What's the difference between Wayland and X11 here, exactly? We >>> *already* draw anti-aliased subpixel-specific font glyphs on GPUs and >>> it looks fine. >>> >> >> - Unless your compositor is transforming the buffer before scanout, at >> which point your calculated antialiasing is no longer optimal. Say >> you've calculated subpixel AA with an RGB subpixel order, but the >> compositor flips your buffer. Or if the window buffer is being shrunk >> the fonts might be better rendered with a different algorithm >> altogether. >> >> I think the point here is that if you treat a window containing text as >> just an image you'll get less than optimal anti-aliasing under window >> transformations. >> >> This seems to be a special case of the more general observation that if >> applications knew the transformations applied to their surfaces then >> they could potentially perform higher quality rendering. I don't think >> the general case is feasible to accommodate, and I'd suspect that the >> font-rendering case won't be significantly easier. > -- Jon Smirl jonsmirl at gmail.com From spbnick at gmail.com Wed Nov 17 00:30:10 2010 From: spbnick at gmail.com (Nikolai Kondrashov) Date: Wed, 17 Nov 2010 11:30:10 +0300 Subject: Getting anti-aliasing right In-Reply-To: References: Message-ID: <4CE39292.4040303@gmail.com> On 11/17/2010 05:14 AM, jonsmirl at gmail.com wrote: > What is the plan for anti-aliasing? If an app draws a beautiful > anti-aliased scene to a buffer, and then that buffer is transformed by > the compositor, all of that beautiful anti-aliasing is going to get > messed up. Especially sub-pixel antialiasing if the compositor > transform changes the alignment of the screen with the LCD pixels. IMHO, one way to fix this is to abandon subpixel antialiasing altogether and hope the displays get better resolution instead :) After all, it is very much a hack, highly dependent on the output device, which often produces undesirable results whenever the device is wrong. Sincerely, Nick From microcai at fedoraproject.org Wed Nov 17 02:28:03 2010 From: microcai at fedoraproject.org (microcai) Date: Wed, 17 Nov 2010 18:28:03 +0800 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: <201011160955.38142.flyser42@gmx.de> References: <201011151947.41580.bluescreen_avenger@verizon.net> <201011160955.38142.flyser42@gmx.de> Message-ID: I guess wayland just *do not* want to render *anything*. Just composite composite composite composite composite composite composite 2010/11/16 Fabian Henze > Hello, > > On Tuesday, 16 Nov 2010, 01:22:42-UTC, Dana Jansens wrote: > > I think it is important to point out that this conversation has been > > predicated entirely on the idea that window decorations and window > > managers are the same thing. > > > > Window management is - at its core - a filter for focus and window > > manipulation requests. It does not require that the WM also draw the > > window decorations. A window can initiate an move/resize just as well > > as the WM itself can, via a request to the WM. > > Could you elaborate, why this makes such a big difference? While I am aware > of > this distinction, I don't think it changes the situation at all. > > > I think it would be a > > big step to make this separation clear from the start, and have window > > decorations separate from the WM functionality, wherever they end up. > > The thing I don't understand about this whole discussion is: How would this > be > a big step? Why would you want to put this kind of logic in the client? > > I see numerous issues (please correct me if they are actually non-issues): > 1. advanced WM features won't work, like: disallow fullscreen for certain > windows, always maximize a certain window, resize and move using > user-defined > hotkeys, snap to window borders. > 2. I just don't believe that GTK, Qt and all the minor toolkits will agree > on > standards for window decoration and behaviour. That would make the linux > desktop even more inconsistent than it is now. > 3. Freezing clients, remote clients with a hung connection, stopped clients > (CTRL-Z) may cause unmovable windows. > 4. code and bug (!) duplication in every toolkit. > 5. Malware, adware or scareware easily have way too much control about the > graphical environment. > > To sum it up: I am concerned, that most features that make X11 window > managers > absolutely rock compared to Windows or OSX will be gone. > > > > > Personally, I think toolkits could do a better job of rendering > > decorations than the compositor could. > > Why? and in which way? > > > Secondly, there seems to be a belief that people would write wayland > > applications without any toolkit - that wayland would be a toolkit in > > essence, like Xlib is. Also, similar to the demo apps that are > > currently given. But from what I see of the project, it would be > > expected that applications would be developed using a reasonable > > toolkit such as Qt or GTK, and thus those toolkits can provide all the > > functionality clients are concerned about - such as threading for > > window interaction and so on. I don't see any reason to try push any > > of that onto the compositor/WM. > > While I generally agree, I would like to point out that some applications > might not require a toolkit. The most prominent example would be 3d games, > but > I think there are also other special purpose applications, that might not > want > to use a toolkit (like proprietary ports of windows software). > > btw. Has anyone ever asked the developers of the major desktop > environments, > windows managers and toolkits what they want? > > -- regards, > Fabian Henze > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From microcai at fedoraproject.org Wed Nov 17 02:58:46 2010 From: microcai at fedoraproject.org (microcai) Date: Wed, 17 Nov 2010 18:58:46 +0800 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: <201011160955.38142.flyser42@gmx.de> References: <201011151947.41580.bluescreen_avenger@verizon.net> <201011160955.38142.flyser42@gmx.de> Message-ID: To avoid duplicated code of window decoration code, window decoration code can be just move to libwayland.so , and shared by all clients. 2010/11/16 Fabian Henze > > Why? and in which way? > > While I generally agree, I would like to point out that some applications > might not require a toolkit. The most prominent example would be 3d games, > but > I think there are also other special purpose applications, that might not > want > to use a toolkit (like proprietary ports of windows software). > > btw. Has anyone ever asked the developers of the major desktop > environments, > windows managers and toolkits what they want? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamilion at gmail.com Wed Nov 17 03:02:44 2010 From: kamilion at gmail.com (Graham Cantin) Date: Wed, 17 Nov 2010 03:02:44 -0800 Subject: Please Don't Use Cleint Side Window Decorations In-Reply-To: References: <201011151947.41580.bluescreen_avenger@verizon.net> <201011160955.38142.flyser42@gmx.de> Message-ID: On Wed, Nov 17, 2010 at 2:28 AM, microcai wrote: > I guess? wayland just? *do not* want to render *anything*. Just composite > composite composite composite composite composite composite > > > 2010/11/16 Fabian Henze >> On Tuesday, 16 Nov 2010, 01:22:42-UTC, Dana Jansens wrote: >> > I think it is important to point out that this conversation has been >> > predicated entirely on the idea that window decorations and window >> > managers are the same thing. >> > >> > Window management is - at its core - a filter for focus and window >> > manipulation requests. ?It does not require that the WM also draw the >> > window decorations. ?A window can initiate an move/resize just as well >> > as the WM itself can, via a request to the WM. It seems to be so, microcai. And it's a good design. Reading the following message was important to establish context for me on where in the stack "Wayland" fits. Originally posted under the benchmark thread, but I think it applies here as well: On Sat, Nov 13, 2010 at 1:23 AM, Chris Wilson wrote: > > Take a step back. It's time to review the system architecture once more. > Wayland is a input/output [de-]multiplexer. It does no rendering on the > behalf of the client, only compositing the many clients onto the scanouts. > The clients must prepare for themselves the shared memory buffers that > they pass to Wayland for compositing. (Under GEM those shared memory > buffers are merely GEM objects and therefore can also be used with > hardware accelerated rendering.) > > On Sat, 13 Nov 2010 12:20:29 +0800, Justin Lee wrote: > > Yep, I guess cairo-gl used by Wayland should get similar performance > > boosts as cairo-drm if it's also direct-rendered (by mesa-dri?). It > > seems that mixing 2D drawings with 3D drawings makes problems, > > therefore we want to draw everything by OpenGL even if for 2D > > graphics. Maybe that's the purpose of cairo-gl i.e. being a wrapper > > library which use OpenGL to draw 2D graphics. > > The difference between theory and practice... > > To put it bluntly, cairo-gl on my fastest boxes [g45, ironlake] is still > slower than cairo-xlib on one of my slowest boxes [q35, for pnv it's > close but the Atom is just no match for the CPUs in the desktop boxes]. > > This is all due to driver quality and the fact that RENDER is much easier > to accelerate than a full GL implementation. This also implies that there > is less opportunity for acceleration of RENDER because so much information > is thrown away upfront. (Having said that cairo-xlib on g45/ilk is > atrocious and much slower than cairo-gl on the same platforms, again due > to driver quality.) > > The promise of GL is that we only need to write one good driver per > chipset... > > The promise of Wayland is that every pixel is perfect. It takes the > architecture that X has organically developed over the last 25 years and > aims to implement that in a small footprint, low latency system. > > One of the killer ideas of Wayland is that it is self-hosting. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- [? ?? Graham Cantin? ? ? ] | (408) 890-7463 - Google Voice FindME "Never feel stupid for asking questions, feel stupid for ignoring answers." [? System Administrator? ] | (XXX) XXX-XXXX xXXX - IT & Office PBX "You're arrogant for thinking you can, ignorant for thinking you cannot." [ RFSpot Mobile Services ] | (XXX) XXX-XXXX - Main Office Direct "Asking questions is important, because that's when intuition gets converted into inspiration." [?? NASA Ames Research?? ] | Building 19, Moffett Field, CA "As living spies we must recruit men who are intelligent?but appear to be stupid; who seem to be dull but are strong in heart;?men who are agile, vigorous, hardy, and brave; well-versed in lowly matters?and able to endure hunger, cold, filth, and humiliation." - Tu Mu (803-825) From justinlee5455 at gmail.com Wed Nov 17 09:50:35 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Thu, 18 Nov 2010 01:50:35 +0800 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: 2010/11/13 Chris Wilson : > Take a step back. It's time to review the system architecture once more. > Wayland is a input/output [de-]multiplexer. It does no rendering on the > behalf of the client, only compositing the many clients onto the scanouts. > The clients must prepare for themselves the shared memory buffers that > they pass to Wayland for compositing. (Under GEM those shared memory > buffers are merely GEM objects and therefore can also be used with > hardware accelerated rendering.) That's right, we are talking about compositing, not rendering. If I guess correctly, Wayland server should start to composite each window whenever a client pass a GEM buffer (via some IPC such as Unix domain socket?) to it. However, the client and the Wayland server are two different processes. The compositing action is not performed until the Linux scheduler context switches from other process to the process of Wayland server. As a result, there is delay between client sending the GEM buffer and the GEM buffer actually being composited by Wayland server. This is one of latency due to client-server architecture. And in my opinion, the delay time should depend on kernel scheduling policy and the number of processes running on the system. I guess that the more processes running on the system, the more delay will be observed. (since more processes need more context switches to have each process a chance to be run) And the delay time could be as long as several milliseconds or even more. That means when a client wants to update its window content, it must wait probably several msecs so that the change can be seen on the screen. Recall that the stated goal of Wayland is: "every frame is perfect, by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker" However, if the latency exists, we should see lag in client-server architecture. Which violates the stated goal. This kind of latency due to OS scheduling could be eliminated by direct-procedure call. That is, the client passes the GEM buffer to the server just like it passes the GEM buffer as an argument to a function. In this approach, the compositor is not a process. Rather, the compositor is just a function live in the client program. So there will be no context switches. From jonsmirl at gmail.com Wed Nov 17 11:47:01 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Wed, 17 Nov 2010 14:47:01 -0500 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: On Sat, Nov 13, 2010 at 4:23 AM, Chris Wilson wrote: > Take a step back. It's time to review the system architecture once more. > Wayland is a input/output [de-]multiplexer. It does no rendering on the > behalf of the client, only compositing the many clients onto the scanouts. > The clients must prepare for themselves the shared memory buffers that > they pass to Wayland for compositing. (Under GEM those shared memory > buffers are merely GEM objects and therefore can also be used with > hardware accelerated rendering.) > > On Sat, 13 Nov 2010 12:20:29 +0800, Justin Lee wrote: >> Yep, I guess cairo-gl used by Wayland should get similar performance >> boosts as cairo-drm if it's also direct-rendered (by mesa-dri?). It >> seems that mixing 2D drawings with 3D drawings makes problems, >> therefore we want to draw everything by OpenGL even if for 2D >> graphics. Maybe that's the purpose of cairo-gl i.e. being a wrapper >> library which use OpenGL to draw 2D graphics. > > The difference between theory and practice... > > To put it bluntly, cairo-gl on my fastest boxes [g45, ironlake] is still > slower than cairo-xlib on one of my slowest boxes [q35, for pnv it's > close but the Atom is just no match for the CPUs in the desktop boxes]. > > This is all due to driver quality and the fact that RENDER is much easier > to accelerate than a full GL implementation. This also implies that there > is less opportunity for acceleration of RENDER because so much information > is thrown away upfront. (Having said that cairo-xlib on g45/ilk is > atrocious and much slower than cairo-gl on the same platforms, again due > to driver quality.) The core compositing model in Cairo is built on is the exactly same operations supported by render. Cairo was designed to be a perfect render client. It was not designed to be a perfect GL client. Some render operations don't map cleanly to GL, especial sub-pixel level ops (anti-aliasing). So with perfect drivers I would expect cairo-xlib to always beat cairo-gl. Right now we don't have perfect drivers so driver quality is dominating. But this gets back into the issue of anti-aliasing. Who should be doing the anti-aliasing? The app or the graphics subsystem? Without a global policy on anti-aliasing it is probably always going to be messed up somewhere. How are apps going to handle sub-pixel anti-aliasing? We have CRTs, LCDs (hor and vet), ePaper, Sharp Yellow, PixelQi, etc all with different pixel arrangements. > The promise of GL is that we only need to write one good driver per > chipset... > > The promise of Wayland is that every pixel is perfect. It takes the > architecture that X has organically developed over the last 25 years and > aims to implement that in a small footprint, low latency system. > > One of the killer ideas of Wayland is that it is self-hosting. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jon Smirl jonsmirl at gmail.com From boulabiar at gmail.com Wed Nov 17 12:48:15 2010 From: boulabiar at gmail.com (Mohamed Ikbel Boulabiar) Date: Wed, 17 Nov 2010 21:48:15 +0100 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: On Wed, Nov 17, 2010 at 8:47 PM, jonsmirl at gmail.com wrote: > How are apps going to handle sub-pixel anti-aliasing? We have CRTs, > LCDs (hor and vet), ePaper, Sharp Yellow, PixelQi, etc all with > different pixel arrangements. > isn't wayland supposed to stay for the next 20 years ? What about 3D screens (with active 3d glasses) and holographic rendering ? (3d screens/projectors are already everywhere...) and holographic ones are already here too: http://www.youtube.com/watch?v=jCx6dZXLe5A 3d input can be captured with cheap devices like Kinect. Even 3d force feedback can be made: http://www.youtube.com/watch?v=pLa1rdfu6Bg i -------------- next part -------------- An HTML attachment was scrubbed... URL: From dana at orodu.net Wed Nov 17 12:56:01 2010 From: dana at orodu.net (Dana Jansens) Date: Wed, 17 Nov 2010 15:56:01 -0500 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: On Wednesday, November 17, 2010, Mohamed Ikbel Boulabiar wrote: > > On Wed, Nov 17, 2010 at 8:47 PM, jonsmirl at gmail.com wrote: > How are apps going to handle sub-pixel anti-aliasing? We have CRTs, > LCDs (hor and vet), ePaper, Sharp Yellow, PixelQi, etc all with > different pixel arrangements. > isn't wayland supposed to stay for the next 20 years ?What about 3D screens (with active 3d glasses) and holographic rendering ?(3d screens/projectors are already everywhere...) > > > and holographic ones are already here too:3d interactive holographic mid-air displays? > > 3d input can be captured with cheap devices like Kinect.Even 3d force feedback can be made:Tangible hologram projector? Can you point to a single production kernel driver for 3d projection ? If not this smells like trolling.. From jonsmirl at gmail.com Wed Nov 17 13:06:22 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Wed, 17 Nov 2010 16:06:22 -0500 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: On Wed, Nov 17, 2010 at 3:56 PM, Dana Jansens wrote: > On Wednesday, November 17, 2010, Mohamed Ikbel Boulabiar > wrote: >> >> On Wed, Nov 17, 2010 at 8:47 PM, jonsmirl at gmail.com wrote: >> How are apps going to handle sub-pixel anti-aliasing? We have CRTs, >> LCDs (hor and vet), ePaper, Sharp Yellow, PixelQi, etc all with >> different pixel arrangements. >> isn't wayland supposed to stay for the next 20 years ?What about 3D screens (with active 3d glasses) and holographic rendering ?(3d screens/projectors are already everywhere...) >> >> >> and holographic ones are already here too:3d interactive holographic mid-air displays? >> >> 3d input can be captured with cheap devices like Kinect.Even 3d force feedback can be made:Tangible hologram projector? > > Can you point to a single production kernel driver for 3d projection ? > ?If not this smells like trolling.. How does this work? http://www.nvidia.com/object/3d-vision-main.html > -- Jon Smirl jonsmirl at gmail.com From boulabiar at gmail.com Wed Nov 17 13:06:44 2010 From: boulabiar at gmail.com (Mohamed Ikbel Boulabiar) Date: Wed, 17 Nov 2010 22:06:44 +0100 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: On Wed, Nov 17, 2010 at 9:56 PM, Dana Jansens wrote: > Can you point to a single production kernel driver for 3d projection ? > If not this smells like trolling.. > Please don't misunderstand my mail. I am not from those who are building holographic projection. but if you want active 3d systems which need a 3d glasses, they exist and you can buy them. http://www.3dmovielist.com/projectors.html And what about 3d input from Kinect? it's not trolling, but opening eyes about things that can happen, should we then reprogram everything? At least there should be a simple way to add that support by extensions. By showing all this I want that you start thinking what is possible to do with it. And sorry if I haven't expressed it right. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonsmirl at gmail.com Wed Nov 17 13:12:57 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Wed, 17 Nov 2010 16:12:57 -0500 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: On Wed, Nov 17, 2010 at 4:06 PM, jonsmirl at gmail.com wrote: > On Wed, Nov 17, 2010 at 3:56 PM, Dana Jansens wrote: >> On Wednesday, November 17, 2010, Mohamed Ikbel Boulabiar >> wrote: >>> >>> On Wed, Nov 17, 2010 at 8:47 PM, jonsmirl at gmail.com wrote: >>> How are apps going to handle sub-pixel anti-aliasing? We have CRTs, >>> LCDs (hor and vet), ePaper, Sharp Yellow, PixelQi, etc all with >>> different pixel arrangements. >>> isn't wayland supposed to stay for the next 20 years ?What about 3D screens (with active 3d glasses) and holographic rendering ?(3d screens/projectors are already everywhere...) >>> >>> >>> and holographic ones are already here too:3d interactive holographic mid-air displays? >>> >>> 3d input can be captured with cheap devices like Kinect.Even 3d force feedback can be made:Tangible hologram projector? >> >> Can you point to a single production kernel driver for 3d projection ? >> ?If not this smells like trolling.. > > How does this work? > http://www.nvidia.com/object/3d-vision-main.html If some has hardware like this, do a 3D desktop mock up in Wayland. You're guaranteed to get 15 minutes of fame. 3D is not hard to do. It is just pairs of frames rendered from slightly different angles. The shutter glasses then control which frame is seen by the eye. This brings up a valid point, show Wayland be manipulating everything in 3D coordinates? Most of us who own 2D screens would just see the 2D projection of the space - which equates to what we are seeing today. But if you owned a 3D one, the 3D projection would become visible. Think of coverflow in 3D! > > >> > > > > -- > Jon Smirl > jonsmirl at gmail.com > -- Jon Smirl jonsmirl at gmail.com From microcai at fedoraproject.org Wed Nov 17 17:11:35 2010 From: microcai at fedoraproject.org (microcai) Date: Thu, 18 Nov 2010 09:11:35 +0800 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: 2010/11/18 Justin Lee > This kind of latency due to OS scheduling could be eliminated by > direct-procedure call. That is, the client passes the GEM buffer to > the server just like it passes the GEM buffer as an argument to a > function. In this approach, the compositor is not a process. Rather, > the compositor is just a function live in the client program. So there > will be no context switches. > So ? Move wayland entirely into the kernel ? Then there will be no delay. And that's probably what MacOSX and Windows NT does. As far as I know, Darwin uses quantz (AGL?) as basis of their GUI system , but WIndows NT uses bullshit GDI ..... -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce at canonical.com Wed Nov 17 18:24:31 2010 From: bryce at canonical.com (Bryce Harrington) Date: Wed, 17 Nov 2010 18:24:31 -0800 Subject: Wayland on 945 (was Re: Ubuntu PPA) Message-ID: <20101118022431.GA3684@bryceharrington.org> On Tue, Nov 09, 2010 at 08:46:46PM +0800, Arthur Zhu wrote: > Have you compiled with --enable-debug option to get more information from > MESA? > > What's your INTEL chipset? > arthur at arthur-laptop:/sys/class/drm/card0/device$ cat device > 0x0046 [Sorry, been busy past week; death in the family] Turns out I'd initially been testing this on an 945GME netbook (8086:27ae), and from what I've been told, the 945 arch doesn't natively support programmable function shaders or something, and thus can't support full opengl es 2.0 support. Is this accurate? Bryce > const static struct pci_device_id pciidlist[] = { > INTEL_VGA_DEVICE(0x3577, &intel_i830_info), > INTEL_VGA_DEVICE(0x2562, &intel_845g_info), > INTEL_VGA_DEVICE(0x3582, &intel_i85x_info), > INTEL_VGA_DEVICE(0x35e8, &intel_i85x_info), > INTEL_VGA_DEVICE(0x2572, &intel_i865g_info), > INTEL_VGA_DEVICE(0x2582, &intel_i915g_info), > INTEL_VGA_DEVICE(0x258a, &intel_i915g_info), > INTEL_VGA_DEVICE(0x2592, &intel_i915gm_info), > INTEL_VGA_DEVICE(0x2772, &intel_i945g_info), > INTEL_VGA_DEVICE(0x27a2, &intel_i945gm_info), > INTEL_VGA_DEVICE(0x27ae, &intel_i945gm_info), > INTEL_VGA_DEVICE(0x2972, &intel_i965g_info), > INTEL_VGA_DEVICE(0x2982, &intel_i965g_info), > INTEL_VGA_DEVICE(0x2992, &intel_i965g_info), > INTEL_VGA_DEVICE(0x29a2, &intel_i965g_info), > INTEL_VGA_DEVICE(0x29b2, &intel_g33_info), > INTEL_VGA_DEVICE(0x29c2, &intel_g33_info), > INTEL_VGA_DEVICE(0x29d2, &intel_g33_info), > INTEL_VGA_DEVICE(0x2a02, &intel_i965gm_info), > INTEL_VGA_DEVICE(0x2a12, &intel_i965gm_info), > INTEL_VGA_DEVICE(0x2a42, &intel_gm45_info), > INTEL_VGA_DEVICE(0x2e02, &intel_g45_info), > INTEL_VGA_DEVICE(0x2e12, &intel_g45_info), > INTEL_VGA_DEVICE(0x2e22, &intel_g45_info), > INTEL_VGA_DEVICE(0x2e32, &intel_g45_info), > INTEL_VGA_DEVICE(0x2e42, &intel_g45_info), > INTEL_VGA_DEVICE(0xa001, &intel_pineview_info), > INTEL_VGA_DEVICE(0xa011, &intel_pineview_info), > INTEL_VGA_DEVICE(0x0042, &intel_ironlake_d_info), > INTEL_VGA_DEVICE(0x0046, &intel_ironlake_m_info), > {0, 0, 0} > }; > > > > Arthur ----- End forwarded message ----- From tpham3783 at gmail.com Wed Nov 17 18:28:44 2010 From: tpham3783 at gmail.com (Toan Pham) Date: Wed, 17 Nov 2010 21:28:44 -0500 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: >> >> This kind of latency due to OS scheduling could be eliminated by >> direct-procedure call. That is, the client passes the GEM buffer to >> the server just like it passes the GEM buffer as an argument to a >> function. In this approach, the compositor is not a process. Rather, >> the compositor is just a function live in the client program. So there >> will be no context switches. > > So ? Move wayland entirely into the kernel ? Then there will be no delay. > And that's probably what MacOSX and Windows NT does. As far as I know, > Darwin uses quantz (AGL?)? as basis of their GUI system , but WIndows NT > uses bullshit GDI ..... I thought about this but many people would disagree with us, especially the entire kernel development community. The kernel is designed to enforce policy not mechanism. However, Direct Rendering, particularly if we use the client/server model in userspace, would suffer from unavoidable latency. To make linux a better operation system, specially for hardcore gamers, we have to put it in the kernel. Also, kernel implementation of the compositor/driver and GPU syscalls shouldn't over complicate the existing kernel core API. I think this is the best solution! From mostawesomedude at gmail.com Wed Nov 17 18:39:47 2010 From: mostawesomedude at gmail.com (Corbin Simpson) Date: Wed, 17 Nov 2010 18:39:47 -0800 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: On Wed, Nov 17, 2010 at 6:28 PM, Toan Pham wrote: >>> >>> This kind of latency due to OS scheduling could be eliminated by >>> direct-procedure call. That is, the client passes the GEM buffer to >>> the server just like it passes the GEM buffer as an argument to a >>> function. In this approach, the compositor is not a process. Rather, >>> the compositor is just a function live in the client program. So there >>> will be no context switches. >> >> So ? Move wayland entirely into the kernel ? Then there will be no delay. >> And that's probably what MacOSX and Windows NT does. As far as I know, >> Darwin uses quantz (AGL?)? as basis of their GUI system , but WIndows NT >> uses bullshit GDI ..... > > > I thought about this but many people would disagree with us, > especially the entire kernel development community. > The kernel is designed to enforce policy not mechanism. ?However, > Direct Rendering, particularly if we use the client/server model in > userspace, would suffer from unavoidable latency. ?To make linux a > better operation system, specially for hardcore gamers, we have to put > it in the kernel. ?Also, kernel implementation of the > compositor/driver and GPU syscalls shouldn't over complicate the > existing kernel core API. ?I think this is the best solution! s/wayland/compiz/gi in this conversation, and then read it all again and see if you still agree with what you're saying. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson From justinlee5455 at gmail.com Wed Nov 17 18:56:26 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Thu, 18 Nov 2010 10:56:26 +0800 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: 2010/11/18 microcai : > > > 2010/11/18 Justin Lee >> >> This kind of latency due to OS scheduling could be eliminated by >> direct-procedure call. That is, the client passes the GEM buffer to >> the server just like it passes the GEM buffer as an argument to a >> function. In this approach, the compositor is not a process. Rather, >> the compositor is just a function live in the client program. So there >> will be no context switches. > > So ? Move wayland entirely into the kernel ? Then there will be no delay. No, I don't think so. The necessary infrastructure have been there in the kernel (i.e. DRM, GEM, KMS). I don't think we should bother writing kernel code which is error-prone and need specific care to avoid bugs and instability. Besides, I don't think moving Wayland into the kernel will be any beneficial if we could do all the same thing in user space. I pointed out the latency because I don't want to see any lag when I scroll down a web page in my browser. I have noticed that in X when I dragged down the scroll bar in browser, the scroll bar wasn't tied to the mouse pointer and the scroll bar fell behind the mouse pointer. When the scroll bar was dragged down, the web page wasn't updated immediately. Instead, the page got updated until a small period of time was passed after the drag happened. This kind of issue would be solved in direct-procedure call approach, because function call is synchronized. The function get executed right away after the caller calls it. It is the most *direct* manner I can think of. > And that's probably what MacOSX and Windows NT does. As far as I know, > Darwin uses quantz (AGL?)? as basis of their GUI system , but WIndows NT > uses bullshit GDI ..... <<>> GDI????? Sounds like you are radical Microsoft hater. Yeah, many Linux users hate MS, but there is no need to be so radical in a mailing list which is unrelated to MS. ...I mean there are many MS forums on the net, you know. From microcai at fedoraproject.org Wed Nov 17 19:08:47 2010 From: microcai at fedoraproject.org (microcai) Date: Thu, 18 Nov 2010 11:08:47 +0800 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: > > So ? Move wayland entirely into the kernel ? Then there will be no delay. > > This kind of issue would be solved in direct-procedure call approach, > because function call is synchronized. The function get executed > right away after the caller calls it. It is the most *direct* manner I > can think of. > direct-procedure call ? You mean similar mechanism of LPC ? I know Windows NT developed LPC, call RPC as local function, because the kernel will do context switch immediately when a program do LPC call. Thus, for every GUI thread, there must be a server thread serving it. <<>> GDI????? > Sounds like you are radical Microsoft hater. Yeah, many Linux users > hate MS, but there is no need to be so radical in a mailing list which > is unrelated to MS. ...I mean there are many MS forums on the net, you > know. > Sorry for personal emotion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjshaw at netspace.net.au Wed Nov 17 19:16:51 2010 From: rjshaw at netspace.net.au (Russell Shaw) Date: Thu, 18 Nov 2010 14:16:51 +1100 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: <4CE49AA3.7040401@netspace.net.au> On 18/11/10 13:28, Toan Pham wrote: >>> >>> This kind of latency due to OS scheduling could be eliminated by >>> direct-procedure call. That is, the client passes the GEM buffer to >>> the server just like it passes the GEM buffer as an argument to a >>> function. In this approach, the compositor is not a process. Rather, >>> the compositor is just a function live in the client program. So there >>> will be no context switches. >> >> So ? Move wayland entirely into the kernel ? Then there will be no delay. >> And that's probably what MacOSX and Windows NT does. As far as I know, >> Darwin uses quantz (AGL?) as basis of their GUI system , but WIndows NT >> uses bullshit GDI ..... > > > I thought about this but many people would disagree with us, > especially the entire kernel development community. > The kernel is designed to enforce policy not mechanism. However, > Direct Rendering, particularly if we use the client/server model in > userspace, would suffer from unavoidable latency. To make linux a > better operation system, specially for hardcore gamers, we have to put > it in the kernel. Also, kernel implementation of the > compositor/driver and GPU syscalls shouldn't over complicate the > existing kernel core API. I think this is the best solution! Creating drivers for large monolithic kernels is a real bitch. The kernel should have minimal code such as just for enforcing security and memory management. 95% of the graphics card driver could be just called as a library function from the application. The benefits of having code that is in a normal process that you can use a debugger like gdb on is very high. I don't see how putting it all in the kernel will reduce the latency any more. X is a daemon just to get network graphics. The X server could be modified to be linked with Xlib, and with client-side apps, so the whole X lib infrastructure exists as a userspace library and could have an api similar to the way it is now and everything still works. Later additions can add new APIs that are more suitable than the old Xlib APIs. To have old X network graphics, a new X2 daemon is created that accepts network connections, and drives the old X that is now a userspace library. From jonsmirl at gmail.com Wed Nov 17 19:22:08 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Wed, 17 Nov 2010 22:22:08 -0500 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: On Wed, Nov 17, 2010 at 9:56 PM, Justin Lee wrote: > 2010/11/18 microcai : >> >> >> 2010/11/18 Justin Lee >>> >>> This kind of latency due to OS scheduling could be eliminated by >>> direct-procedure call. That is, the client passes the GEM buffer to >>> the server just like it passes the GEM buffer as an argument to a >>> function. In this approach, the compositor is not a process. Rather, >>> the compositor is just a function live in the client program. So there >>> will be no context switches. >> >> So ? Move wayland entirely into the kernel ? Then there will be no delay. > > No, I don't think so. The necessary infrastructure have been there in > the kernel (i.e. DRM, GEM, KMS). I don't think we should bother > writing kernel code which is error-prone and need specific care to > avoid bugs and instability. Besides, I don't think moving Wayland into > the kernel will be any beneficial if we could do all the same thing in > user space. > > I pointed out the latency because I don't want to see any lag when I > scroll down a web page in my browser. I have noticed that in X when I > dragged down the scroll bar in browser, the scroll bar wasn't tied to > the mouse pointer and the scroll bar fell behind the mouse pointer. > When the scroll bar was dragged down, the web page wasn't updated > immediately. Instead, the page got updated until a small period of > time was passed after the drag happened. You won't see stuff like that in Wayland. In Wayland the apps paint their windows and then tell Wayland to display the complete picture. If an app updates the scroll bar, tells Wayland to draw, updates the window, tells Wayland to draw. Then you'll get what you describe. But it is the app that is broken, not Wayland. Get rid of the extra draw command in the app. Wayland is just doing what you told it to do. It is also pointless to update your video buffer faster than the scan rate of the video monitor. If you are generating 400fps, how do you display it on a 60fps monitor? Maybe update in the middle of a scan out, but that's probably going to tear the display. I believe the current design of the system is correct in regards to the kernel. The interesting path is moving more things (like glyph generation) onto the GPU. > > This kind of issue would be solved in direct-procedure call approach, > because ?function call is synchronized. The function get executed > right away after the caller calls it. It is the most *direct* manner I > can think of. > >> And that's probably what MacOSX and Windows NT does. As far as I know, >> Darwin uses quantz (AGL?)? as basis of their GUI system , but WIndows NT >> uses bullshit GDI ..... > > <<>> GDI????? > Sounds like you are radical Microsoft hater. Yeah, many Linux users > hate MS, but there is no need to be so radical in a mailing list which > is unrelated to MS. ...I mean there are many MS forums on the net, you > know. > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jon Smirl jonsmirl at gmail.com From rjshaw at netspace.net.au Wed Nov 17 19:25:34 2010 From: rjshaw at netspace.net.au (Russell Shaw) Date: Thu, 18 Nov 2010 14:25:34 +1100 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: <4CE49CAE.809@netspace.net.au> On 18/11/10 13:56, Justin Lee wrote: > 2010/11/18 microcai: >> >> >> 2010/11/18 Justin Lee >>> >>> This kind of latency due to OS scheduling could be eliminated by >>> direct-procedure call. That is, the client passes the GEM buffer to >>> the server just like it passes the GEM buffer as an argument to a >>> function. In this approach, the compositor is not a process. Rather, >>> the compositor is just a function live in the client program. So there >>> will be no context switches. >> >> So ? Move wayland entirely into the kernel ? Then there will be no delay. > > No, I don't think so. The necessary infrastructure have been there in > the kernel (i.e. DRM, GEM, KMS). I don't think we should bother > writing kernel code which is error-prone and need specific care to > avoid bugs and instability. Besides, I don't think moving Wayland into > the kernel will be any beneficial if we could do all the same thing in > user space. > > I pointed out the latency because I don't want to see any lag when I > scroll down a web page in my browser. I have noticed that in X when I > dragged down the scroll bar in browser, the scroll bar wasn't tied to > the mouse pointer and the scroll bar fell behind the mouse pointer. > When the scroll bar was dragged down, the web page wasn't updated > immediately. Instead, the page got updated until a small period of > time was passed after the drag happened. Laggy user interfaces are usually due to crappy inefficient drawing libraries doing software rendering. A lot of the blame can be on GPU vendors for not releasing detailed programming specs to enable decent drivers. If the widget toolkit isn't designed well, round-trip X11 requests between server and client can have a large impact. Also, the kernel itself can be a bottleneck. http://www.techworld.com.au/article/368448/tiny_linux_kernel_patch_delivers_huge_speed_boost/ > This kind of issue would be solved in direct-procedure call approach, > because function call is synchronized. The function get executed > right away after the caller calls it. It is the most *direct* manner I > can think of. > >> And that's probably what MacOSX and Windows NT does. As far as I know, >> Darwin uses quantz (AGL?) as basis of their GUI system , but WIndows NT >> uses bullshit GDI ..... > > <<>> GDI????? > Sounds like you are radical Microsoft hater. Yeah, many Linux users > hate MS, but there is no need to be so radical in a mailing list which > is unrelated to MS. ...I mean there are many MS forums on the net, you > know. From j.glisse at gmail.com Wed Nov 17 19:47:14 2010 From: j.glisse at gmail.com (Jerome Glisse) Date: Wed, 17 Nov 2010 22:47:14 -0500 Subject: Benchmark of Wayland In-Reply-To: <4CE49CAE.809@netspace.net.au> References: <4CE49CAE.809@netspace.net.au> Message-ID: On Wed, Nov 17, 2010 at 10:25 PM, Russell Shaw wrote: > On 18/11/10 13:56, Justin Lee wrote: >> >> 2010/11/18 microcai: >>> >>> >>> 2010/11/18 Justin Lee >>>> >>>> This kind of latency due to OS scheduling could be eliminated by >>>> direct-procedure call. That is, the client passes the GEM buffer to >>>> the server just like it passes the GEM buffer as an argument to a >>>> function. In this approach, the compositor is not a process. Rather, >>>> the compositor is just a function live in the client program. So there >>>> will be no context switches. >>> >>> So ? Move wayland entirely into the kernel ? Then there will be no delay. >> >> No, I don't think so. The necessary infrastructure have been there in >> the kernel (i.e. DRM, GEM, KMS). I don't think we should bother >> writing kernel code which is error-prone and need specific care to >> avoid bugs and instability. Besides, I don't think moving Wayland into >> the kernel will be any beneficial if we could do all the same thing in >> user space. >> >> I pointed out the latency because I don't want to see any lag when I >> scroll down a web page in my browser. I have noticed that in X when I >> dragged down the scroll bar in browser, the scroll bar wasn't tied to >> the mouse pointer and the scroll bar fell behind the mouse pointer. >> When the scroll bar was dragged down, the web page wasn't updated >> immediately. Instead, the page got updated until a small period of >> time was passed after the drag happened. > > Laggy user interfaces are usually due to crappy inefficient > drawing libraries doing software rendering. A lot of the blame > can be on GPU vendors for not releasing detailed programming > specs to enable decent drivers. > > If the widget toolkit isn't designed well, round-trip X11 > requests between server and client can have a large impact. > > Also, the kernel itself can be a bottleneck. > Maybe we should stop saying so, there is documentation from AMD and Intel for their GPU, yet the community is unable to produce fast GPU driver. Maybe it's just that we were overestimating the resource of the community. Cheers, Jerome Glisse From microcai at fedoraproject.org Wed Nov 17 20:02:07 2010 From: microcai at fedoraproject.org (microcai) Date: Thu, 18 Nov 2010 12:02:07 +0800 Subject: Benchmark of Wayland In-Reply-To: References: <4CE49CAE.809@netspace.net.au> Message-ID: > Maybe it's just that we were overestimating the resource of > the community. > Agree. I see high quality FOSS only from FSF or other foundations that actuary hires professional programer to do the job. Maybe community is a joke. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.halse.rogers at canonical.com Wed Nov 17 20:04:09 2010 From: christopher.halse.rogers at canonical.com (Christopher James Halse Rogers) Date: Thu, 18 Nov 2010 15:04:09 +1100 Subject: Getting anti-aliasing right In-Reply-To: References: <1289963926.7661.13.camel@Ed> Message-ID: <1290053050.7661.29.camel@Ed> On Wed, 2010-11-17 at 00:37 -0500, jonsmirl at gmail.com wrote: > On Tue, Nov 16, 2010 at 10:28 PM, Corbin Simpson > wrote: > > I should have been clearer. This is like compiz, where non-transformed > > viewports look perfect and transformed viewports look illegible. Nobody > > appears to have a problem with this for compiz; why should Wayland have > > anything different? > > If Wayland ends up as our graphics foundation it may be with us for 20 > years. This is a known problem and it can be fixed with some > planning. Isn't the goal of Wayland to have pixel perfect graphics? > > Glyph generation inside the CPU is certainly going to happen in that > time frame. You can already do it today on decent GPUs. We are very > close to be able to run the entire compositor and scene graph engine > inside the GPU. You want to plan for these things in the architecture > so that we don't have to rip everything up again in five years. > Today's high end GPU will be the low end GPU of 2015. GPU-based glyph generation is entirely orthogonal to preserving optimal anti-aliasing under window transformations. You can do GPU-based glyph rendering now, in X (I seem to recall Zack Rusin blogging about it a couple of years ago), and you can do optimal anti-aliasing under transformations without GPU-based glyph generation. I'm not sure that you *can* solve the optimal anti-aliasing problem without introducing deep knowledge of application rendering into Wayland, something which is an explicit anti-goal. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From airlied at gmail.com Wed Nov 17 20:13:23 2010 From: airlied at gmail.com (Dave Airlie) Date: Thu, 18 Nov 2010 14:13:23 +1000 Subject: Benchmark of Wayland In-Reply-To: References: <4CE49CAE.809@netspace.net.au> Message-ID: On Thu, Nov 18, 2010 at 2:02 PM, microcai wrote: > >> Maybe it's just that we were overestimating the resource of >> the community. > > Agree. I see high quality FOSS only from FSF or other foundations that > actuary hires professional programer to do the job. > > Maybe community is a joke. /me wonders which high quality FSF professional programmer software you seen? As far as I'm aware the FSF don't have any full time programmers attached to any of the major FSF projects. Dave. From microcai at fedoraproject.org Wed Nov 17 20:17:34 2010 From: microcai at fedoraproject.org (microcai) Date: Thu, 18 Nov 2010 12:17:34 +0800 Subject: Benchmark of Wayland In-Reply-To: References: <4CE49CAE.809@netspace.net.au> Message-ID: > me wonders which high quality FSF professional programmer software you > seen? > > As far as I'm aware the FSF don't have any full time programmers > attached to any of the major FSF projects. > > Dave. > GCC?Isn't that high quality ? PS: *You*, not *we*. -------------- next part -------------- An HTML attachment was scrubbed... URL: From airlied at gmail.com Wed Nov 17 20:19:41 2010 From: airlied at gmail.com (Dave Airlie) Date: Thu, 18 Nov 2010 14:19:41 +1000 Subject: Benchmark of Wayland In-Reply-To: References: <4CE49CAE.809@netspace.net.au> Message-ID: On Thu, Nov 18, 2010 at 2:17 PM, microcai wrote: > >> me wonders which high quality FSF professional programmer software you >> seen? >> >> As far as I'm aware the FSF don't have any full time programmers >> attached to any of the major FSF projects. >> >> Dave. > > GCC?Isn't that? high quality ? I'm not aware of any FSF funded gcc developers. also getting off-topic. Dave. From smspillaz at gmail.com Wed Nov 17 22:47:54 2010 From: smspillaz at gmail.com (Sam Spilsbury) Date: Thu, 18 Nov 2010 14:47:54 +0800 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: On Thu, Nov 18, 2010 at 10:39 AM, Corbin Simpson wrote: > On Wed, Nov 17, 2010 at 6:28 PM, Toan Pham wrote: >>>> >>>> This kind of latency due to OS scheduling could be eliminated by >>>> direct-procedure call. That is, the client passes the GEM buffer to >>>> the server just like it passes the GEM buffer as an argument to a >>>> function. In this approach, the compositor is not a process. Rather, >>>> the compositor is just a function live in the client program. So there >>>> will be no context switches. >>> >>> So ? Move wayland entirely into the kernel ? Then there will be no delay. >>> And that's probably what MacOSX and Windows NT does. As far as I know, >>> Darwin uses quantz (AGL?)? as basis of their GUI system , but WIndows NT >>> uses bullshit GDI ..... >> >> >> I thought about this but many people would disagree with us, >> especially the entire kernel development community. >> The kernel is designed to enforce policy not mechanism. ?However, >> Direct Rendering, particularly if we use the client/server model in >> userspace, would suffer from unavoidable latency. ?To make linux a >> better operation system, specially for hardcore gamers, we have to put >> it in the kernel. ?Also, kernel implementation of the >> compositor/driver and GPU syscalls shouldn't over complicate the >> existing kernel core API. ?I think this is the best solution! > > s/wayland/compiz/gi in this conversation, and then read it all again > and see if you still agree with what you're saying. > Corbin is right here. There is no point fretting over the *slight* performance increase that you're going to get if you move something in-kernel. If we were to adopt that ideology then there would be no userspace at all. The thing to remember here is that wayland is an interface for creating compositors for memory buffers on the hardware, and each wayland compositor exposes a memory buffer as a result. If we are to have things like nested servers, it makes no sense to put these things into the kernel at all. Especially since this imports *severe* security issues and stability problems when you are looking at compositors like compiz which load plugins at run time to do its work. The kind of performance penalty that you get from a context switch anyways is largely negligible and *really* the only performance bottlenecks we need to worry about is how fast we can make EGL go and how fast the clients are. Also, the number of roundtrips that you are going to have with wayland is quite a lot lower considering that, again, all rendering happens from the client straight to a memory buffer which the wayland compositor then displays on-screen. In between this process there is hardly any communication with the server at all because it was designed exactly to minimize this. Kind Regards, Sam > -- > When the facts change, I change my mind. What do you do, sir? ~ Keynes > > Corbin Simpson > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Sam Spilsbury From justinlee5455 at gmail.com Thu Nov 18 01:03:38 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Thu, 18 Nov 2010 17:03:38 +0800 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: 2010/11/18 jonsmirl at gmail.com : >>> 2010/11/18 Justin Lee >> I pointed out the latency because I don't want to see any lag when I >> scroll down a web page in my browser. I have noticed that in X when I >> dragged down the scroll bar in browser, the scroll bar wasn't tied to >> the mouse pointer and the scroll bar fell behind the mouse pointer. >> When the scroll bar was dragged down, the web page wasn't updated >> immediately. Instead, the page got updated until a small period of >> time was passed after the drag happened. > > You won't see stuff like that in Wayland. In Wayland the apps paint > their windows and then tell Wayland to display the complete picture. > If an app updates the scroll bar, tells Wayland to draw, updates the > window, tells Wayland to draw. Then you'll get what you describe. But > it is the app that is broken, not Wayland. Get rid of the extra draw > command in the app. Wayland is just doing what you told it to do. Good point, that's the real solution/usage to make mouse pointer, scroll bar and window update all tied together. I didn't come up with that. However, the latency issue will unlikely be solved! I mean when you start the drag down, you won't see any change on you screen. The change on you screen should occur at least until the scheduler hands on CPU resource to Wayland server process. So there are still interval in between and causes delay, but it appears in a more synchronized way (pointer, scroll bar, window update will all changed at once, not one after another). > It is also pointless to update your video buffer faster than the scan > rate of the video monitor. If you are generating 400fps, how do you > display it on a 60fps monitor? Maybe update in the middle of a scan > out, but that's probably going to tear the display. Yup, but I don't think we can easily make scheduler context switch synchronize with the video buffer scan, which means sometimes client update will miss the video buffer scan. For example, suppose that a client sends out a GEM buffer to Wayland server just 0.001 msec. ahead of the next video buffer scan, there is a big chance that the scheduler is not faster enough to switch to Wayland process in such a short period of time. So the GEM buffer sent by the client need to wait until the next-next video buffer scan such that the buffer gets composited and shown. If there are too many processes wait to be scheduled in the system, the GEM buffer will need to wait even more time, maybe until the next-next-next... video buffer scan to get composited and shown! If the scan rate is at 60Hz, the scan period is 16.7ms (1/60). So the latency will >= 16.7ms for the next-next video buffer scan, >= 33.3ms (2*16.7) for the next-next-next video buffer scan ... and so on. If the scan rate is half of 60Hz (i.e. 30Hz), the latency will be doubled. From justinlee5455 at gmail.com Thu Nov 18 01:26:20 2010 From: justinlee5455 at gmail.com (Justin Lee) Date: Thu, 18 Nov 2010 17:26:20 +0800 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: 2010/11/18 Toan Pham : >>> >>> This kind of latency due to OS scheduling could be eliminated by >>> direct-procedure call. That is, the client passes the GEM buffer to >>> the server just like it passes the GEM buffer as an argument to a >>> function. In this approach, the compositor is not a process. Rather, >>> the compositor is just a function live in the client program. So there >>> will be no context switches. >> >> So ? Move wayland entirely into the kernel ? Then there will be no delay. >> And that's probably what MacOSX and Windows NT does. As far as I know, >> Darwin uses quantz (AGL?)? as basis of their GUI system , but WIndows NT >> uses bullshit GDI ..... > > > I thought about this but many people would disagree with us, > especially the entire kernel development community. > The kernel is designed to enforce policy not mechanism. ?However, Is that typo? I think it should be "The kernel is designed to provide mechanism not to enforce policy .". > Direct Rendering, particularly if we use the client/server model in > userspace, would suffer from unavoidable latency. ?To make linux a > better operation system, specially for hardcore gamers, we have to put > it in the kernel. ?Also, kernel implementation of the > compositor/driver and GPU syscalls shouldn't over complicate the > existing kernel core API. ?I think this is the best solution! The only latency I can tell is that the system call overhead is larger than ordinary function call. Don't know what's the reasons to cause Mac/WinNT putting things into kernel, though. From jonsmirl at gmail.com Thu Nov 18 04:51:17 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Thu, 18 Nov 2010 07:51:17 -0500 Subject: Getting anti-aliasing right In-Reply-To: <1290053050.7661.29.camel@Ed> References: <1289963926.7661.13.camel@Ed> <1290053050.7661.29.camel@Ed> Message-ID: On Wed, Nov 17, 2010 at 11:04 PM, Christopher James Halse Rogers wrote: > On Wed, 2010-11-17 at 00:37 -0500, jonsmirl at gmail.com wrote: >> On Tue, Nov 16, 2010 at 10:28 PM, Corbin Simpson >> wrote: >> > I should have been clearer. This is like compiz, where non-transformed >> > viewports look perfect and transformed viewports look illegible. Nobody >> > appears to have a problem with this for compiz; why should Wayland have >> > anything different? >> >> If Wayland ends up as our graphics foundation it may be with us for 20 >> years. ?This is a known problem and it can be fixed with some >> planning. ?Isn't the goal of Wayland to have pixel perfect graphics? >> >> Glyph generation inside the CPU is certainly going to happen in that >> time frame. You can already do it today on decent GPUs. We are very >> close to be able to run the entire compositor and scene graph engine >> inside the GPU. ?You want to plan for these things in the architecture >> so that we don't have to rip everything up again in five years. >> Today's high end GPU will be the low end GPU of 2015. > > GPU-based glyph generation is entirely orthogonal to preserving optimal > anti-aliasing under window transformations. ?You can do GPU-based glyph > rendering now, in X (I seem to recall Zack Rusin blogging about it a > couple of years ago), and you can do optimal anti-aliasing under > transformations without GPU-based glyph generation. > > I'm not sure that you *can* solve the optimal anti-aliasing problem > without introducing deep knowledge of application rendering into > Wayland, something which is an explicit anti-goal. I can see two strategies, we may need both: 1) Wayland tells the app the window transform and the pixel layout of the screen. The app does antialiasing with this information. This works because Wayland is not going to transform the output buffer, the app has already transformed it. This is complicated because now an app has to be able to draw and antialias onto an arbitrarily transformed surface. It also has to understand the pixel layout. Direct GL apps will probably need this model. 2) Apps don't draw, instead they make a scene graph. As Wayland constructs the screen it then plays this scene graph into a rendering engine. The rendering engine is aware of the window transform and pixel layout. This allows desktop animations without app intervention. The common thread here is that Wayland needs to inform the rendering engine as to what the final window transform is going to be. Then the rendering engine will draw and anti-alias using that transform. These transforms can be complex 3D operations so a depth buffer is needed. This means Wayland is out of the transformation business. The rendering engines will have already transformed the windows. Wayland will just composite those transformed windows. All of the clipping will sort out because of the depth buffers. -------------------- GPU glyph generation does seem to be orthogonal. My objection to X is that the protocol forces you to generate glyph bitmaps in the app and send them to the server. The server then maintains a list of these glyph images and does a brute force compare of bitmaps on the list every time a new glyph image is received. The knowledge of which glyph generated the bitmap has been lost. The protocol was done this way to help network transparency. If the fonts are stored in the server the first thing the app has to is retrieve them all since it is the app that determines glyph spacing. X initially had the fonts in the server. Performance was bad so the fonts were moved into the client. The outcome of that was transmitting the bitmaps to the server. I don't want to build assumptions into the protocol that prevent GPU glyph generation. But this does seem to be an issue for the rendering engines, not Wayland. ------------------- I'm trying to come up with proposals for these problems as I write this. AFAIK none of this has been addressed in a windowing system before. Proposals will need to be built and tested to determine which solutions work. A key observation seem to be that Wayland needs to tell the apps what the final window transformation is, and the app needs to provide transformed windows including depth buffers. If you don't do that it is impossible to get the anti-aliasing right. -- Jon Smirl jonsmirl at gmail.com From linhaoxiang at gmail.com Wed Nov 17 19:16:24 2010 From: linhaoxiang at gmail.com (=?UTF-8?B?5p6X5piK57+U?=) Date: Thu, 18 Nov 2010 11:16:24 +0800 Subject: missing freeing previous data struction when new allocation fails Message-ID: The scenario is: struct A *foo() { A *a; a = malloc(sizeof(A)); if (a == NULL) return NULL; a->b = malloc(sizeof(B)); if (a->b == NULL) return NULL; return a; } There should be "free(a);" before the red line. I find that there are many such ommissions in the wayland source tree. The attached txt shows part of them. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- diff -Nur wayland/compositor/compositor-drm.c wayland-copy/compositor/compositor-drm.c --- wayland/compositor/compositor-drm.c 2010-11-18 10:10:46.680032600 +0800 +++ wayland-copy/compositor/compositor-drm.c 2010-11-18 10:54:42.738612100 +0800 @@ -243,6 +243,10 @@ wlsc_input_device_init(&input->base, &c->base); e = udev_enumerate_new(c->udev); + if (e == NULL) { + free(input); + return; + } udev_enumerate_add_match_subsystem(e, "input"); udev_enumerate_add_match_property(e, "WAYLAND_SEAT", "1"); udev_enumerate_scan_devices(e); @@ -395,6 +399,7 @@ encoder = drmModeGetEncoder(ec->base.drm.fd, connector->encoders[0]); if (encoder == NULL) { fprintf(stderr, "No encoder for connector.\n"); + free(output); return -1; } @@ -404,6 +409,7 @@ } if (i == resources->count_crtcs) { fprintf(stderr, "No usable crtc for encoder.\n"); + free(output); return -1; } @@ -435,6 +441,7 @@ 32, 32, stride, handle, &output->fb_id[i]); if (ret) { fprintf(stderr, "failed to add fb %d: %m\n", i); + free(output); return -1; } } @@ -449,6 +456,7 @@ &output->connector_id, 1, &output->mode); if (ret) { fprintf(stderr, "failed to set mode: %m\n"); + free(output); return -1; } @@ -645,10 +653,13 @@ ec->udev = udev_new(); if (ec->udev == NULL) { fprintf(stderr, "failed to initialize udev context\n"); + free(ec); return NULL; } e = udev_enumerate_new(ec->udev); + if (e == NULL) { + } udev_enumerate_add_match_subsystem(e, "drm"); udev_enumerate_add_match_property(e, "WAYLAND_SEAT", "1"); udev_enumerate_scan_devices(e); @@ -662,21 +673,29 @@ if (device == NULL) { fprintf(stderr, "no drm device found\n"); + free(ec->udev); + free(ec); return NULL; } ec->base.wl_display = display; if (init_egl(ec, device) < 0) { fprintf(stderr, "failed to initialize egl\n"); + free(ec->udev); + free(ec); return NULL; } /* Can't init base class until we have a current egl context */ if (wlsc_compositor_init(&ec->base, display) < 0) + free(ec->udev); + free(ec); return NULL; if (create_outputs(ec, connector) < 0) { fprintf(stderr, "failed to create output for %s\n", path); + free(ec->udev); + free(ec); return NULL; } @@ -686,6 +705,10 @@ ec->drm_source = wl_event_loop_add_fd(loop, ec->base.drm.fd, WL_EVENT_READABLE, on_drm_input, ec); + if (ec->drm_source == NULL) { + free(ec->udev); + free(ec); + } setup_tty(ec, loop); ec->base.authenticate = drm_authenticate; ec->base.present = drm_compositor_present; diff -Nur wayland/compositor/compositor-x11.c wayland-copy/compositor/compositor-x11.c --- wayland/compositor/compositor-x11.c 2010-11-18 10:10:46.681032700 +0800 +++ wayland-copy/compositor/compositor-x11.c 2010-11-18 10:57:17.284065100 +0800 @@ -413,15 +413,22 @@ output->window, 1, 1, attachments); reply = xcb_dri2_get_buffers_reply (c->conn, cookie, NULL); - if (reply == NULL) + if (reply == NULL) { + free(output); return -1; + } buffers = xcb_dri2_get_buffers_buffers (reply); - if (buffers == NULL) + if (buffers == NULL) { + free(reply); + free(output); return -1; + } if (reply->count != 1) { fprintf(stderr, "got wrong number of buffers (%d)\n", reply->count); + free(reply); + free(output); return -1; } diff -Nur wayland/wayland/connection.c wayland-copy/wayland/connection.c --- wayland/wayland/connection.c 2010-11-18 10:10:46.722036800 +0800 +++ wayland-copy/wayland/connection.c 2010-11-18 10:23:30.671424100 +0800 @@ -160,6 +160,9 @@ struct wl_connection *connection; connection = malloc(sizeof *connection); + if (connection == NULL) { + return NULL; + } memset(connection, 0, sizeof *connection); connection->fd = fd; connection->update = update; diff -Nur wayland/wayland/wayland-client.c wayland-copy/wayland/wayland-client.c --- wayland/wayland/wayland-client.c 2010-11-18 10:10:46.733037900 +0800 +++ wayland-copy/wayland/wayland-client.c 2010-11-18 10:25:33.851740900 +0800 @@ -366,6 +366,11 @@ } display->objects = wl_hash_table_create(); + if (display->objects == NULL) { + close(display->fd); + free(display); + return NULL; + } wl_list_init(&display->global_listener_list); display->proxy.base.interface = &wl_display_interface; @@ -382,6 +387,12 @@ display->connection = wl_connection_create(display->fd, connection_update, display); + if (display->connection == NULL) { + wl_hash_table_destroy(display->objects); + close(display->fd); + free(display); + return NULL; + } return display; } @@ -390,6 +401,7 @@ wl_display_destroy(struct wl_display *display) { wl_connection_destroy(display->connection); + wl_hash_table_destroy(display->objects); close(display->fd); free(display); } diff -Nur wayland/wayland/wayland-server.c wayland-copy/wayland/wayland-server.c --- wayland/wayland/wayland-server.c 2010-11-18 10:10:46.739038500 +0800 +++ wayland-copy/wayland/wayland-server.c 2010-11-18 10:20:00.165375600 +0800 @@ -368,6 +368,7 @@ display->objects = wl_hash_table_create(); if (display->objects == NULL) { + wl_event_loop_destroy(display->loop); free(display); return NULL; } @@ -382,6 +383,7 @@ display->base.implementation = (void (**)(void)) &display_interface; wl_display_add_object(display, &display->base); if (wl_display_add_global(display, &display->base, NULL)) { + wl_hash_table_destroy(display->objects); wl_event_loop_destroy(display->loop); free(display); return NULL; From Darxus at chaosreigns.com Thu Nov 18 14:57:46 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Thu, 18 Nov 2010 17:57:46 -0500 Subject: Ubuntu PPA Re: Ubuntu build tips In-Reply-To: References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101106192608.GM13517@chaosreigns.com> <20101106212842.GA1223@bryceharrington.org> <20101107004507.GN13517@chaosreigns.com> <20101107043521.GB1223@bryceharrington.org> Message-ID: <20101118225746.GR30262@chaosreigns.com> On 11/10, Chia-I Wu wrote: > Mesa can be configured to build gallium-based DRI drivers but not > gallium-based EGL driver. But it is not clearly documented. I've > added a new option, --disable-gallium-egl, to Mesa to easily disable > the gallium-based EGL driver. What do you think? Where did you add --disable-gallium-egl ? I don't see it in git://anongit.freedesktop.org/mesa/mesa . -- "For every complex problem, there is a solution that is simple, neat, and wrong." - H. L. Mencken http://www.ChaosReigns.com From olvaffe at gmail.com Thu Nov 18 21:59:49 2010 From: olvaffe at gmail.com (Chia-I Wu) Date: Fri, 19 Nov 2010 13:59:49 +0800 Subject: Ubuntu PPA Re: Ubuntu build tips In-Reply-To: <20101118225746.GR30262@chaosreigns.com> References: <20101106184810.GJ13517@chaosreigns.com> <20101106185126.GK13517@chaosreigns.com> <20101106190715.GL13517@chaosreigns.com> <20101106192608.GM13517@chaosreigns.com> <20101106212842.GA1223@bryceharrington.org> <20101107004507.GN13517@chaosreigns.com> <20101107043521.GB1223@bryceharrington.org> <20101118225746.GR30262@chaosreigns.com> Message-ID: On Fri, Nov 19, 2010 at 6:57 AM, wrote: > On 11/10, Chia-I Wu wrote: >> Mesa can be configured to build gallium-based DRI drivers but not >> gallium-based EGL driver. ?But it is not clearly documented. ?I've >> added a new option, --disable-gallium-egl, to Mesa to easily disable >> the gallium-based EGL driver. ?What do you think? > > Where did you add --disable-gallium-egl ? > I don't see it in git://anongit.freedesktop.org/mesa/mesa . commit dbacbb8219c529ed7e2b21e3447a36d4df18bc57 Author: Chia-I Wu Date: Tue Nov 2 02:00:36 2010 +0800 autoconf: Add --enable-gallium-egl. This option comes handy when we want to build gallium DRI drivers but not st/egl > -- > "For every complex problem, there is a solution that is simple, neat, > and wrong." - H. L. Mencken > http://www.ChaosReigns.com > -- olv at LunarG.com From Darxus at chaosreigns.com Thu Nov 18 22:45:33 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Fri, 19 Nov 2010 01:45:33 -0500 Subject: [PATCH] Some more error handling Message-ID: <20101119064533.GA1691@chaosreigns.com> Some additional error handling, a couple more \n's in prints, a slightly clearer error message, and one very minor white space reformat for consistency. --- clients/dnd.c | 2 ++ clients/flower.c | 2 ++ clients/gears.c | 3 +++ clients/image.c | 2 ++ clients/smoke.c | 2 ++ clients/terminal.c | 2 ++ clients/view.c | 2 ++ clients/window.c | 5 ++++- compositor/compositor-drm.c | 6 +++++- compositor/compositor-x11.c | 32 +++++++++++++++++++++----------- 10 files changed, 45 insertions(+), 13 deletions(-) diff --git a/clients/dnd.c b/clients/dnd.c index 766fc5c..f1009c5 100644 --- a/clients/dnd.c +++ b/clients/dnd.c @@ -581,6 +581,8 @@ main(int argc, char *argv[]) srandom(tv.tv_usec); d = display_create(&argc, &argv, option_entries); + if (d == NULL) + exit(EXIT_FAILURE); display_set_drag_offer_handler(d, drag_offer_handler); diff --git a/clients/flower.c b/clients/flower.c index 9054c0f..ff06f27 100644 --- a/clients/flower.c +++ b/clients/flower.c @@ -124,6 +124,8 @@ int main(int argc, char *argv[]) struct display *d; d = display_create(&argc, &argv, NULL); + if (d == NULL) + exit(EXIT_FAILURE); flower.x = 512; flower.y = 384; diff --git a/clients/gears.c b/clients/gears.c index 8669683..a8309c3 100644 --- a/clients/gears.c +++ b/clients/gears.c @@ -414,6 +414,9 @@ int main(int argc, char *argv[]) struct gears *gears; d = display_create(&argc, &argv, NULL); + if (d == NULL) + exit(EXIT_FAILURE); + gears = gears_create(d); display_run(d); diff --git a/clients/image.c b/clients/image.c index cf98266..a371c00 100644 --- a/clients/image.c +++ b/clients/image.c @@ -244,6 +244,8 @@ main(int argc, char *argv[]) int i; d = display_create(&argc, &argv, option_entries); + if (d == NULL) + exit(EXIT_FAILURE); for (i = 1; i < argc; i++) { struct image *image; diff --git a/clients/smoke.c b/clients/smoke.c index edd036c..c61088e 100644 --- a/clients/smoke.c +++ b/clients/smoke.c @@ -273,6 +273,8 @@ int main(int argc, char *argv[]) int size, x, y; d = display_create(&argc, &argv, NULL); + if (d == NULL) + exit(EXIT_FAILURE); smoke.x = 200; smoke.y = 200; diff --git a/clients/terminal.c b/clients/terminal.c index c841ef2..3e1eac8 100644 --- a/clients/terminal.c +++ b/clients/terminal.c @@ -548,6 +548,8 @@ int main(int argc, char *argv[]) struct terminal *terminal; d = display_create(&argc, &argv, option_entries); + if (d == NULL) + exit(EXIT_FAILURE); terminal = terminal_create(d, option_fullscreen); if (terminal_run(terminal, "/bin/bash")) diff --git a/clients/view.c b/clients/view.c index ace838d..f551a42 100644 --- a/clients/view.c +++ b/clients/view.c @@ -207,6 +207,8 @@ main(int argc, char *argv[]) int i; d = display_create(&argc, &argv, option_entries); + if (d == NULL) + exit(EXIT_FAILURE); for (i = 1; i < argc; i++) { struct view *view; diff --git a/clients/window.c b/clients/window.c index 9dfd355..2827dc1 100644 --- a/clients/window.c +++ b/clients/window.c @@ -1459,7 +1459,10 @@ display_create(int *argc, char **argv[], const GOptionEntry *option_entries) return NULL; } - eglBindAPI(EGL_OPENGL_API); + if (EGL_FALSE == eglBindAPI(EGL_OPENGL_API)) { + fprintf(stderr, "failed to bind api EGL_OPENGL_API\n"); + return NULL; + } d->ctx = eglCreateContext(d->dpy, NULL, EGL_NO_CONTEXT, NULL); if (d->ctx == NULL) { diff --git a/compositor/compositor-drm.c b/compositor/compositor-drm.c index e843e14..d06f769 100644 --- a/compositor/compositor-drm.c +++ b/compositor/compositor-drm.c @@ -339,7 +339,11 @@ init_egl(struct drm_compositor *ec, struct udev_device *device) return -1; } - eglBindAPI(EGL_OPENGL_ES_API); + if (EGL_FALSE == eglBindAPI(EGL_OPENGL_ES_API)) { + fprintf(stderr, "failed to bind api EGL_OPENGL_ES_API\n"); + return -1; + } + ec->base.context = eglCreateContext(ec->base.display, NULL, EGL_NO_CONTEXT, context_attribs); if (ec->base.context == NULL) { diff --git a/compositor/compositor-x11.c b/compositor/compositor-x11.c index 5178873..a3b1f3b 100644 --- a/compositor/compositor-x11.c +++ b/compositor/compositor-x11.c @@ -80,19 +80,21 @@ struct x11_input { }; -static void +static int x11_input_create(struct x11_compositor *c) { struct x11_input *input; input = malloc(sizeof *input); if (input == NULL) - return; + return -1; memset(input, 0, sizeof *input); wlsc_input_device_init(&input->base, &c->base); c->base.input_device = &input->base; + + return 0; } @@ -140,7 +142,7 @@ dri2_connect(struct x11_compositor *c) xcb_dri2_query_version_reply (c->conn, dri2_query_cookie, &error); if (dri2_query == NULL || error != NULL) { - fprintf(stderr, "DRI2: failed to query version"); + fprintf(stderr, "DRI2: failed to query version\n"); free(error); return EGL_FALSE; } @@ -152,7 +154,7 @@ dri2_connect(struct x11_compositor *c) connect_cookie, NULL); if (connect == NULL || connect->driver_name_length + connect->device_name_length == 0) { - fprintf(stderr, "DRI2: failed to authenticate"); + fprintf(stderr, "DRI2: driver name and device name are empty\n"); return -1; } @@ -177,7 +179,7 @@ dri2_connect(struct x11_compositor *c) fd = open(path, O_RDWR); if (fd < 0) { fprintf(stderr, - "DRI2: could not open %s (%s)", path, strerror(errno)); + "DRI2: could not open %s (%s)\n", path, strerror(errno)); return -1; } @@ -197,7 +199,7 @@ dri2_authenticate(struct x11_compositor *c, uint32_t magic) xcb_dri2_authenticate_reply(c->conn, authenticate_cookie, NULL); if (authenticate == NULL || !authenticate->authenticated) { - fprintf(stderr, "DRI2: failed to authenticate"); + fprintf(stderr, "DRI2: failed to authenticate\n"); free(authenticate); return -1; } @@ -222,7 +224,7 @@ x11_compositor_init_egl(struct x11_compositor *c) return -1; if (drmGetMagic(c->base.drm.fd, &magic)) { - fprintf(stderr, "DRI2: failed to get drm magic"); + fprintf(stderr, "DRI2: failed to get drm magic\n"); return -1; } @@ -246,7 +248,11 @@ x11_compositor_init_egl(struct x11_compositor *c) return -1; } - eglBindAPI(EGL_OPENGL_ES_API); + if (EGL_FALSE == eglBindAPI(EGL_OPENGL_ES_API)) { + fprintf(stderr, "failed to bind EGL_OPENGL_ES_API\n"); + return -1; + } + c->base.context = eglCreateContext(c->base.display, NULL, EGL_NO_CONTEXT, context_attribs); if (c->base.context == NULL) { @@ -660,15 +666,17 @@ x11_compositor_create(struct wl_display *display, int width, int height) c->base.wl_display = display; if (x11_compositor_init_egl(c) < 0) - return NULL; + return NULL; /* Can't init base class until we have a current egl context */ if (wlsc_compositor_init(&c->base, display) < 0) return NULL; - x11_compositor_create_output(c, width, height); + if (x11_compositor_create_output(c, width, height) < 0) + return NULL; - x11_input_create(c); + if (x11_input_create(c) < 0) + return NULL; loop = wl_display_get_event_loop(c->base.wl_display); @@ -678,6 +686,8 @@ x11_compositor_create(struct wl_display *display, int width, int height) x11_compositor_handle_event, c); c->base.authenticate = x11_authenticate; + if (c->base.authenticate < 0) + return NULL; c->base.present = x11_compositor_present; return &c->base; -- "Of course there's strength in numbers. But there's strength in sharp weaponry too. Ironically, this lead to what we call 'civilization'." - spore http://www.ChaosReigns.com From flyser42 at gmx.de Fri Nov 19 01:28:32 2010 From: flyser42 at gmx.de (Fabian Henze) Date: Fri, 19 Nov 2010 10:28:32 +0100 Subject: [PATCH] Two typo fixes in the documentation Message-ID: <201011191028.37504.flyser42@gmx.de> Two typo fixes in specs/main.tex, mentioned in an earlier mail. --- spec/main.tex | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/spec/main.tex b/spec/main.tex index 8c512be..e7a2b96 100644 --- a/spec/main.tex +++ b/spec/main.tex @@ -284,7 +284,7 @@ Issues: after the data has been transferred. \item How do we marshall several mime-types? We could make the drag - setup a multi-step operation: dnd.create, drag.offer(mime-type1, + setup a multi-step operation: dnd.create, drag.offer(mime-type1), drag.offer(mime-type2), drag.activate(). The drag object could send multiple offer events on each motion event. Or we could just implement an array type, but that's a pain to work with. @@ -429,7 +429,7 @@ ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/ \item multiseat \item linux implementation using libudev, egl, kms, evdev, cairo \item for fullscreen clients, the system compositor can reprogram the - video scanout address to source fromt the client provided buffer. + video scanout address to source from the client provided buffer. \end{itemize} \subsection{Session Compositor} From Darxus at chaosreigns.com Fri Nov 19 09:47:23 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Fri, 19 Nov 2010 12:47:23 -0500 Subject: Universal Ubuntu build script Message-ID: <20101119174723.GB1691@chaosreigns.com> http://www.chaosreigns.com/wayland/wayland-build-ubuntu-all.sh I would appreciate verification that this works with Intel video cards. I have only tested it with nVidea with nouveau. Instructions are here: http://www.chaosreigns.com/wayland/ubuntu.html This uses the mesa build option --disable-gallium-egl implemented by Chia-I Wu to handle the problem that had been handled by --disable-gallium without breaking support for nVidia and ATI/AMD. This is specifically for Ubuntu Maverick. -- "I finally figured out the only reason to be alive is to enjoy it." - Rita Mae Brown http://www.ChaosReigns.com From bryce at canonical.com Fri Nov 19 12:14:39 2010 From: bryce at canonical.com (Bryce Harrington) Date: Fri, 19 Nov 2010 12:14:39 -0800 Subject: [PATCH] Function declares a pointer return, so return one. Message-ID: <20101119201439.GE3076@bryceharrington.org> These two functions are just wrappers around display_create_*_surface but weren't forwarding along the result of those calls as is implied by their return value type. This fixes a compile-time warning. Signed-off-by: Bryce Harrington --- clients/window.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/clients/window.c b/clients/window.c index 9dfd355..66d7aad 100644 --- a/clients/window.c +++ b/clients/window.c @@ -454,9 +454,9 @@ display_create_surface(struct display *display, struct rectangle *rectangle) { #ifdef HAVE_CAIRO_GL - display_create_drm_surface(display, rectangle); + return display_create_drm_surface(display, rectangle); #else - display_create_shm_surface(display, rectangle); + return display_create_shm_surface(display, rectangle); #endif } @@ -466,9 +466,9 @@ display_create_surface_from_file(struct display *display, struct rectangle *rectangle) { #ifdef HAVE_CAIRO_GL - display_create_drm_surface_from_file(display, filename, rectangle); + return display_create_drm_surface_from_file(display, filename, rectangle); #else - display_create_shm_surface_from_file(display, filename, rectangle); + return display_create_shm_surface_from_file(display, filename, rectangle); #endif } -- 1.7.1 From bryce at canonical.com Fri Nov 19 12:14:55 2010 From: bryce at canonical.com (Bryce Harrington) Date: Fri, 19 Nov 2010 12:14:55 -0800 Subject: [PATCH] Quell warning about potentially uninitialized variable 'surface' Message-ID: <20101119201455.GF3076@bryceharrington.org> In theory, it was possible for an undefined 'surface' to be passed to window_set_surface(). Instead, explicitly pass NULL. Signed-off-by: Bryce Harrington --- clients/window.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/clients/window.c b/clients/window.c index 66d7aad..37f6872 100644 --- a/clients/window.c +++ b/clients/window.c @@ -601,6 +601,9 @@ window_create_surface(struct window *window) surface = display_create_shm_surface(window->display, &window->allocation); break; + default: + surface = NULL; + break; } window_set_surface(window, surface); -- 1.7.1 From bryce at canonical.com Fri Nov 19 12:15:15 2010 From: bryce at canonical.com (Bryce Harrington) Date: Fri, 19 Nov 2010 12:15:15 -0800 Subject: [PATCH] Expose window_set_surface() in window.h Message-ID: <20101119201515.GG3076@bryceharrington.org> gears.c uses this routine and was complaining about it being implicitly declared. Signed-off-by: Bryce Harrington --- clients/window.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/clients/window.h b/clients/window.h index 871e46b..de7ccce 100644 --- a/clients/window.h +++ b/clients/window.h @@ -158,6 +158,9 @@ void window_flush(struct window *window); void +window_set_surface(struct window *window, cairo_surface_t *surface); + +void window_create_surface(struct window *window); enum window_buffer_type { -- 1.7.1 From bryce at canonical.com Fri Nov 19 12:15:36 2010 From: bryce at canonical.com (Bryce Harrington) Date: Fri, 19 Nov 2010 12:15:36 -0800 Subject: [PATCH] Cleanup declared but unused variables. Message-ID: <20101119201536.GH3076@bryceharrington.org> Make was complaining about a bunch of unused variables that were being declared. Signed-off-by: Bryce Harrington --- clients/gears.c | 1 - clients/smoke.c | 14 ++++---------- clients/window.c | 3 +-- 3 files changed, 5 insertions(+), 13 deletions(-) diff --git a/clients/gears.c b/clients/gears.c index 8669683..17536cb 100644 --- a/clients/gears.c +++ b/clients/gears.c @@ -341,7 +341,6 @@ static struct gears * gears_create(struct display *display) { const int x = 200, y = 200, width = 450, height = 500; - EGLint major, minor; struct gears *gears; int i; diff --git a/clients/smoke.c b/clients/smoke.c index edd036c..246e347 100644 --- a/clients/smoke.c +++ b/clients/smoke.c @@ -65,7 +65,6 @@ static void set_boundary(struct smoke *smoke, float x, float y, float *p) static void diffuse(struct smoke *smoke, uint32_t time, float *source, float *dest) { - cairo_t *cr; float *s, *d; int x, y, k, stride; float t, a = 0.0002; @@ -88,10 +87,9 @@ static void diffuse(struct smoke *smoke, uint32_t time, static void advect(struct smoke *smoke, uint32_t time, float *uu, float *vv, float *source, float *dest) { - cairo_t *cr; float *s, *d; float *u, *v; - int x, y, k, stride; + int x, y, stride; int i, j; float px, py, fx, fy; @@ -128,7 +126,7 @@ static void project(struct smoke *smoke, uint32_t time, float *u, float *v, float *p, float *div) { int x, y, k, l, s; - float h, *d, *q; + float h; h = 1.0 / smoke->width; s = smoke->width; @@ -166,10 +164,8 @@ static void project(struct smoke *smoke, uint32_t time, static void render(struct smoke *smoke) { - cairo_t *cr; - unsigned char *source, *dest; + unsigned char *dest; int x, y, width, height, stride; - int k, t; float *s; uint32_t *d, c, a; @@ -196,9 +192,7 @@ static void render(struct smoke *smoke) static void frame_callback(void *data, uint32_t time) { - cairo_surface_t *t; struct smoke *smoke = data; - static int i; diffuse(smoke, time / 30, smoke->b[0].u, smoke->b[1].u); diffuse(smoke, time / 30, smoke->b[0].v, smoke->b[1].v); @@ -270,7 +264,7 @@ int main(int argc, char *argv[]) struct timespec ts; struct smoke smoke; struct display *d; - int size, x, y; + int size; d = display_create(&argc, &argv, NULL); diff --git a/clients/window.c b/clients/window.c index 37f6872..3abc2b0 100644 --- a/clients/window.c +++ b/clients/window.c @@ -203,7 +203,6 @@ display_create_drm_surface(struct display *display, EGLDisplay dpy = display->dpy; cairo_surface_t *surface; struct wl_visual *visual; - struct wl_buffer *buffer; EGLint name, stride; EGLint image_attribs[] = { @@ -343,7 +342,7 @@ display_create_shm_surface(struct display *display, struct shm_surface_data *data; cairo_surface_t *surface; struct wl_visual *visual; - int stride, alloc, fd; + int stride, fd; char filename[] = "/tmp/wayland-shm-XXXXXX"; data = malloc(sizeof *data); -- 1.7.1 From olvaffe at gmail.com Fri Nov 19 23:15:34 2010 From: olvaffe at gmail.com (Chia-I Wu) Date: Sat, 20 Nov 2010 15:15:34 +0800 Subject: Universal Ubuntu build script In-Reply-To: <20101119174723.GB1691@chaosreigns.com> References: <20101119174723.GB1691@chaosreigns.com> Message-ID: On Sat, Nov 20, 2010 at 1:47 AM, wrote: > http://www.chaosreigns.com/wayland/wayland-build-ubuntu-all.sh > > I would appreciate verification that this works with Intel video cards. ?I > have only tested it with nVidea with nouveau. > > Instructions are here: ?http://www.chaosreigns.com/wayland/ubuntu.html > > This uses the mesa build option --disable-gallium-egl implemented by Chia-I > Wu to handle the problem that had been handled by --disable-gallium without > breaking support for nVidia and ATI/AMD. I think $ ./autogen.sh --prefix=$HOME/install --enable-gles2 \ --enable-gallium-nouveau --with-state-trackers=dri should suffice, for mesa. > This is specifically for Ubuntu Maverick. > > -- > "I finally figured out the only reason to be alive is to enjoy it." > - Rita Mae Brown > http://www.ChaosReigns.com > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- olv at LunarG.com From Darxus at chaosreigns.com Sat Nov 20 11:56:39 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sat, 20 Nov 2010 14:56:39 -0500 Subject: Universal Ubuntu build script In-Reply-To: References: <20101119174723.GB1691@chaosreigns.com> Message-ID: <20101120195639.GF1691@chaosreigns.com> On 11/20, Chia-I Wu wrote: > I think > > $ ./autogen.sh --prefix=$HOME/install --enable-gles2 \ > --enable-gallium-nouveau --with-state-trackers=dri > > should suffice, for mesa. Doesn't worth with my nVidia card: libEGL debug: EGL user error 0x3003 (EGL_BAD_ALLOC) in DRI2: failed to get driver name egl_dri2 only has PCI IDs for Intel and ATI/AMD. I successfully added my card to the dri2_driver_map, but that's not the kind of automated build I'm looking for. After suggestions from bnf, I've got: ./autogen.sh --prefix=$HOME/install --enable-egl --enable-gles2 --enable-gallium-nouveau --with-state-trackers=glx,dri,egl --with-egl-platforms=drm --enable-gles-overlay --enable-gallium-r600 --with-dri-drivers=i915,i965 --disable-gallium-{915,965} http://www.chaosreigns.com/wayland/wayland-build-ubuntu-all.sh is updated with this. Tested only with nouveau (nvidia). --with-dri-drivers=i915,i965 is to disable the classic r600 driver. -- "Life is either a daring adventure or it is nothing at all." - Helen Keller http://www.ChaosReigns.com From bluescreen_avenger at verizon.net Sat Nov 20 16:05:36 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Sat, 20 Nov 2010 19:05:36 -0500 Subject: Using the Wayland port of QT Message-ID: <201011201905.37259.bluescreen_avenger@verizon.net> Hi. I am trying to see if I can get http://gitorious.org/~krh/qt/qt-wayland working. After I ran git clone on that repo, I ran git checkout lighthouse- wayland, and then configure, make, and make install. I saw some lines about qt 4.8, and after I ran make install, some apps gave missing fuction error, but the ones that run, like qtdemo still run in X11 mode. Am I using the correct repo? Is there some command line I need? or do the apps need to be recompiled as well? From andre at aspinformatica.com.br Sat Nov 20 17:04:05 2010 From: andre at aspinformatica.com.br (=?ISO-8859-1?Q?Andr=E9?= de Souza Pinto) Date: Sat, 20 Nov 2010 23:04:05 -0200 Subject: Universal Ubuntu build script In-Reply-To: <20101120195639.GF1691@chaosreigns.com> References: <20101119174723.GB1691@chaosreigns.com> <20101120195639.GF1691@chaosreigns.com> Message-ID: <20101120230405.49faa2e4.andre@aspinformatica.com.br> I make some changes to work on my laptop with i915 kms (Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller) -- by Andr? de Souza Pinto From ASP Inform?tica Ltda. Fone: +55 54 3212.7111 / 9198.5204 email: andre at aspinformatica.com.br Address: Rua Bortolo Zani, 190 Bairro Bela Vista 95072-000 / Caxias do Sul / RS / Brasil S? imprima este documento se realmente for necess?rio. Pense no seu comprometimento com o meio ambiente e com a sua empresa. Solo imprima este documento si realmente es necesario. Piense en su compromiso con el medio ambiente y con su empresa. Only print this document if really necessary. Think of your commitment to the environment and with your company. -------------- next part -------------- A non-text attachment was scrubbed... Name: wayland-build-ubuntu-all.sh Type: text/x-sh Size: 3577 bytes Desc: not available URL: From bluescreen_avenger at verizon.net Sat Nov 20 17:16:07 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Sat, 20 Nov 2010 20:16:07 -0500 Subject: Using the Wayland port of QT Message-ID: <201011202016.08057.bluescreen_avenger@verizon.net> Hi. I forgot to add that I had to copy the stuff in /usr/local/Trolltech/Qt-4.8.0 to /usr From matthias.fauconneau at gmail.com Sat Nov 20 17:21:05 2010 From: matthias.fauconneau at gmail.com (Matthias Fauconneau) Date: Sun, 21 Nov 2010 02:21:05 +0100 Subject: Using the Wayland port of QT In-Reply-To: <201011202016.08057.bluescreen_avenger@verizon.net> References: <201011202016.08057.bluescreen_avenger@verizon.net> Message-ID: This ebuild contains all necessary informations to compile Qt/Wayland : http://git.overlays.gentoo.org/gitweb/?p=user/benf.git;a=blob;f=x11-libs/qt-wayland/qt-wayland-9999.ebuild;hb=HEAD The important configure options are: -qpa -opengl es2 and at runtime LD_LIBRARY_PATH="/usr/lib/qt-wayland" qt-application -platform wayland From Darxus at chaosreigns.com Sat Nov 20 20:13:36 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sat, 20 Nov 2010 23:13:36 -0500 Subject: Universal Ubuntu build script In-Reply-To: <20101120230405.49faa2e4.andre@aspinformatica.com.br> References: <20101119174723.GB1691@chaosreigns.com> <20101120195639.GF1691@chaosreigns.com> <20101120230405.49faa2e4.andre@aspinformatica.com.br> Message-ID: <20101121041336.GG1691@chaosreigns.com> On 11/20, Andr? de Souza Pinto wrote: > I make some changes to work on my laptop with > i915 kms (Intel Corporation Mobile 945GM/GMS, 943/940GML Express > Integrated Graphics Controller) Thanks. I believe I added everything you did that didn't break nouveau support. I'd appreciate it if you would test the new version: http://www.chaosreigns.com/wayland/wayland-build-ubuntu-all.sh I kept the install prefix as $HOME/install, but now it's defined at the top of the script so it's easy to change. I kept --enable-nouveau-experimental-api and --enable-gallium-nouveau in. I believe they shouldn't cause you problems. Thanks for adding the git pulls if the repos have already been cloned. I added some git cleans, so don't run it if you have locally modified code. Also, --with-xkb-rootdir=/usr/share/X11/xkb doesn't work. I checked strace, and it's still loading from $HOME/install/share/X11/xkb. -- "Of course there's strength in numbers. But there's strength in sharp weaponry too. Ironically, this lead to what we call 'civilization'." - spore http://www.ChaosReigns.com From benjaminfranzke at googlemail.com Sun Nov 21 02:47:11 2010 From: benjaminfranzke at googlemail.com (Benjamin Franzke) Date: Sun, 21 Nov 2010 11:47:11 +0100 Subject: [PATCH] scanner: include stddef.h to provide NULL and size_t Message-ID: <1290336431-9706-1-git-send-email-benjaminfranzke@googlemail.com> --- wayland/scanner.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/wayland/scanner.c b/wayland/scanner.c index aaaf551..9d099fb 100644 --- a/wayland/scanner.c +++ b/wayland/scanner.c @@ -520,6 +520,7 @@ emit_header(struct protocol *protocol, int server) "#endif\n" "\n" "#include \n" + "#include \n" "#include \"wayland-util.h\"\n\n" "struct wl_client;\n\n", copyright, -- 1.7.2.2 From Carl-Philip.Haensch at mailbox.tu-dresden.de Sat Nov 20 14:12:24 2010 From: Carl-Philip.Haensch at mailbox.tu-dresden.de (Carl-Philip Haensch) Date: Sat, 20 Nov 2010 23:12:24 +0100 Subject: Language bindings for wayland Message-ID: <20101120231224.7rfadugao0sk08sk@mail.zih.tu-dresden.de> Hi, i'm planning to write languate bindings for freepascal (fpc) but there are some things that make it hard for me to port (=blocks automatic header generation) - inline functions and their implementation in the header file - "struct foo *" as declaration in return types - #define inline function magic An other idea would be to make the files needed for language bindings (wayland-util.h, wayland-client.j, wayland-protocol.h, window.h) auto-generated so that everyone who needs a language binding can add his code generator to scanner.c There is a lot of work to do to make wayland bindings usable. From bacn at zhasha.com Sun Nov 21 05:02:37 2010 From: bacn at zhasha.com (Joakim Sindholt) Date: Sun, 21 Nov 2010 14:02:37 +0100 Subject: Language bindings for wayland In-Reply-To: <20101120231224.7rfadugao0sk08sk@mail.zih.tu-dresden.de> References: <20101120231224.7rfadugao0sk08sk@mail.zih.tu-dresden.de> Message-ID: <1290344557.2462.3.camel@ztoshiba> On Sat, 2010-11-20 at 23:12 +0100, Carl-Philip Haensch wrote: > Hi, > > i'm planning to write languate bindings for freepascal (fpc) but there > are some things that make it hard for me to port (=blocks automatic > header generation) > - inline functions and their implementation in the header file > - "struct foo *" as declaration in return types > - #define inline function magic Wayland only communicates to clients over a UNIX socket. You could in fact just implement the protocol in freepascal instead of trying to use the toytoolkit or the like. This interface should be completely language neutral. > An other idea would be to make the files needed for language bindings > (wayland-util.h, wayland-client.j, wayland-protocol.h, window.h) > auto-generated so that everyone who needs a language binding can add > his code generator to scanner.c > > There is a lot of work to do to make wayland bindings usable. From bluescreen_avenger at verizon.net Sun Nov 21 09:26:43 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Sun, 21 Nov 2010 12:26:43 -0500 Subject: Using the Wayland port of QT Message-ID: <201011211226.44496.bluescreen_avenger@verizon.net> I'm having a bit of trouble trying to decypher the ebuild file I think I must be missing somthing from there... I ran configure with the -qpa -opengl es2 options But whenever I try tohen ever I try to run a QT app I get: Failed to load platform plugin "wayland". Available platforms are: Aborted -platform does not seem to be in the standard QT libraries, but it is in these, so I think I must be close. I see a line in there that says EGIT_PATCHES=( "${FILESDIR}/config-test- wayland.patch" ) . I don't think I can see that file, or know where the $FILESDIR variable is being defined. I don't know if this has anything to do with the missing plugin... I think I am using the correct repo: when I run 'git branch' in the folder I get: 4.7 * lighthouse-wayland From benjaminfranzke at googlemail.com Sun Nov 21 09:39:02 2010 From: benjaminfranzke at googlemail.com (Benjamin Franzke) Date: Sun, 21 Nov 2010 18:39:02 +0100 Subject: Using the Wayland port of QT In-Reply-To: <201011211226.44496.bluescreen_avenger@verizon.net> References: <201011211226.44496.bluescreen_avenger@verizon.net> Message-ID: $FILESDIR is a gentoo specific vairable inside ebuild, which points to ebuild-pwd/files (doesnt matter for you..) however this patch is located there in the repo: http://git.overlays.gentoo.org/gitweb/?p=user/benf.git;a=blob;f=x11-libs/qt-wayland/files/config-test-wayland.patch I've also created a merge request for that stuff now, so you could also use that: http://qt.gitorious.org/~krh/qt/qt-wayland/merge_requests/1 After you have patched and compiled again you should install qt. the wayland platform isnt found if you run from within the builddir without installing list of the basic instructions again here: patch ..... ./configure -prefix $HOME/your_prefix -qpa -opengl es2 make make install export LD_LIBRARY_PATH=$HOME/your_prefix/lib examples/widgets/analogclock/analogclock -platform wayland 2010/11/21 nerdopolis : > I'm having a bit of trouble trying to decypher the ebuild file I think I must > be missing somthing from there... > > I ran configure with the ?-qpa -opengl es2 options > > But whenever I try tohen ever I try to run a QT app I get: > Failed to load platform plugin "wayland". Available platforms are: > > Aborted > > > -platform does not seem to be in the standard QT libraries, but it is in > these, so I think I must be close. > > > > I see a line in there that says EGIT_PATCHES=( "${FILESDIR}/config-test- > wayland.patch" ) . I don't think I can see that file, or know where the > $FILESDIR variable is being defined. I don't know if this has anything to do > with the missing plugin... > > I think I am using the correct repo: when I run 'git branch' in the folder I > get: > ?4.7 > * lighthouse-wayland > > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From benjaminfranzke at googlemail.com Sun Nov 21 09:40:52 2010 From: benjaminfranzke at googlemail.com (Benjamin Franzke) Date: Sun, 21 Nov 2010 18:40:52 +0100 Subject: Using the Wayland port of QT In-Reply-To: References: <201011211226.44496.bluescreen_avenger@verizon.net> Message-ID: oh I forgot to say the merge request needs the scanner PATCH i posted earlier.. so you should use the first patch for now 2010/11/21 Benjamin Franzke : > $FILESDIR is a gentoo specific vairable inside ebuild, which points to > ebuild-pwd/files (doesnt matter for you..) > however this patch is located there in the repo: > http://git.overlays.gentoo.org/gitweb/?p=user/benf.git;a=blob;f=x11-libs/qt-wayland/files/config-test-wayland.patch > > I've also created a merge request for that stuff now, so you could > also use that: > http://qt.gitorious.org/~krh/qt/qt-wayland/merge_requests/1 > > After you have patched and compiled again you should install qt. > the wayland platform isnt found if you run from within the builddir > without installing > > list of the basic instructions again here: > ?patch ..... > ?./configure -prefix $HOME/your_prefix -qpa -opengl es2 > ?make > ?make install > ?export LD_LIBRARY_PATH=$HOME/your_prefix/lib > ?examples/widgets/analogclock/analogclock -platform wayland > > 2010/11/21 nerdopolis : >> I'm having a bit of trouble trying to decypher the ebuild file I think I must >> be missing somthing from there... >> >> I ran configure with the ?-qpa -opengl es2 options >> >> But whenever I try tohen ever I try to run a QT app I get: >> Failed to load platform plugin "wayland". Available platforms are: >> >> Aborted >> >> >> -platform does not seem to be in the standard QT libraries, but it is in >> these, so I think I must be close. >> >> >> >> I see a line in there that says EGIT_PATCHES=( "${FILESDIR}/config-test- >> wayland.patch" ) . I don't think I can see that file, or know where the >> $FILESDIR variable is being defined. I don't know if this has anything to do >> with the missing plugin... >> >> I think I am using the correct repo: when I run 'git branch' in the folder I >> get: >> ?4.7 >> * lighthouse-wayland >> >> >> _______________________________________________ >> wayland-devel mailing list >> wayland-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > From Carl-Philip.Haensch at mailbox.tu-dresden.de Sun Nov 21 11:12:02 2010 From: Carl-Philip.Haensch at mailbox.tu-dresden.de (Carl-Philip Haensch) Date: Sun, 21 Nov 2010 20:12:02 +0100 Subject: wayland client headers Message-ID: <20101121201202.plor8rqv44scswok@mail.zih.tu-dresden.de> > Wayland only communicates to clients over a UNIX socket. You could in > fact just implement the protocol in freepascal instead of trying to use > the toytoolkit or the like. This interface should be completely language > neutral. I have no knowledge about the interface at all and it would be a lot of effort to reimplement the full libwayland-client.so. Making the headers portable would be easier, really. You can benchmark them if it is a speed loss when you replace the inline functions and preprocessor magic by header conform declarations From j3parker at uwaterloo.ca Sun Nov 21 12:02:27 2010 From: j3parker at uwaterloo.ca (Jacob Parker) Date: Sun, 21 Nov 2010 15:02:27 -0500 Subject: Typos in the FAQ Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-typos-in-faq.patch Type: application/octet-stream Size: 1337 bytes Desc: not available URL: From kai.mast at freakybytes.org Sun Nov 21 12:30:36 2010 From: kai.mast at freakybytes.org (Kai Mast) Date: Sun, 21 Nov 2010 21:30:36 +0100 Subject: Porting Apps to Wayland Message-ID: <4CE9816C.9060804@freakybytes.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Guys, I am pretty new to Wayland and just have a general question. What exactly does change for me as a game developer on the programming site when I switch to Wayland. Obviously the OpenGL calls will be untouched. But what about Input? Will i still be able to use libxcb or will there a completely different API to handle that kind of stuff? greets, Kai -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM6YFsAAoJEKU5B2k1XeMEKIUP/3mCdkPWljNYrmmGAtC78CVk 8XHow3MjcBt6OrgU1pfbCJREUHKF848gmS4bB1IluqCAU4h15pHj8N7ujs9MiN7i xCNCVPLp1P+fR2pDnr1hQjJ5OAMq4/KGEN4qlug2nsXHHYY4KBZqUFsXJL4O/IaH YmSsNJe6urJu6dBkE1Ry1mzk7ET8UJf4s+Mtk0dl/YJUnlzUm1ZCmnkGZe3Dd8YB 6fPuRGTItQRJifiMOKcAw8dm9SV3m7fDDtPFRdZRz/CQ272SICSIsLWhB1n71p/0 3dHoIazafVApEWQjFYfbTsjGfuzGK1L/AfdpZNQc7MbsVSkQVS39gveCVS+bYBhi OTruRjmg7CXb0LkdhA6ZNzmDGg8SD0OJ1rj/vnzA46SBOmyIiBsr56rHJFMQfzaP ZxzT8y4BReD8GBe2xIuKwXtidiNSIaCLOm5zTw455JAEalv+E6BJKa6L54DJRvrx lqkjSevLoDzNar9WZ//kfh6oG5DtHCfZ+yxdxZZav9GuW5wo1BgPhVKshUA9o4Gy 8d5o3XmzmGdtXVCQyoT/7198v3UdEafjbBpjynsfVgRh2dpZXCto39Ue++eB34YX VTtytFPjCBCajgrr1YeLfFcVMXf6kZscB6x23CEdIryZpeXDYxVc3DIbEpwMdnnm lbgls9l+G9UEm+6smw+Y =TLrQ -----END PGP SIGNATURE----- From cynapsia at gmail.com Sun Nov 21 14:01:48 2010 From: cynapsia at gmail.com (Lia Chan) Date: Sun, 21 Nov 2010 23:01:48 +0100 Subject: Porting Apps to Wayland In-Reply-To: <4CE9816C.9060804@freakybytes.org> References: <4CE9816C.9060804@freakybytes.org> Message-ID: Heyas.. I'm not a wayland developer and following this list just out of curiosity, but libxcb is a dependency of wayland and builds against it. It seems like nothing much will change for you. I hope this post is working now. It's my mailing list premiere, never used one before ^^ baba Lia On Sun, Nov 21, 2010 at 9:30 PM, Kai Mast wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey Guys, > > I am pretty new to Wayland and just have a general question. > > What exactly does change for me as a game developer on the programming > site when I switch to Wayland. Obviously the OpenGL calls will be > untouched. But what about Input? Will i still be able to use libxcb or > will there a completely different API to handle that kind of stuff? > > greets, > Kai > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJM6YFsAAoJEKU5B2k1XeMEKIUP/3mCdkPWljNYrmmGAtC78CVk > 8XHow3MjcBt6OrgU1pfbCJREUHKF848gmS4bB1IluqCAU4h15pHj8N7ujs9MiN7i > xCNCVPLp1P+fR2pDnr1hQjJ5OAMq4/KGEN4qlug2nsXHHYY4KBZqUFsXJL4O/IaH > YmSsNJe6urJu6dBkE1Ry1mzk7ET8UJf4s+Mtk0dl/YJUnlzUm1ZCmnkGZe3Dd8YB > 6fPuRGTItQRJifiMOKcAw8dm9SV3m7fDDtPFRdZRz/CQ272SICSIsLWhB1n71p/0 > 3dHoIazafVApEWQjFYfbTsjGfuzGK1L/AfdpZNQc7MbsVSkQVS39gveCVS+bYBhi > OTruRjmg7CXb0LkdhA6ZNzmDGg8SD0OJ1rj/vnzA46SBOmyIiBsr56rHJFMQfzaP > ZxzT8y4BReD8GBe2xIuKwXtidiNSIaCLOm5zTw455JAEalv+E6BJKa6L54DJRvrx > lqkjSevLoDzNar9WZ//kfh6oG5DtHCfZ+yxdxZZav9GuW5wo1BgPhVKshUA9o4Gy > 8d5o3XmzmGdtXVCQyoT/7198v3UdEafjbBpjynsfVgRh2dpZXCto39Ue++eB34YX > VTtytFPjCBCajgrr1YeLfFcVMXf6kZscB6x23CEdIryZpeXDYxVc3DIbEpwMdnnm > lbgls9l+G9UEm+6smw+Y > =TLrQ > -----END PGP SIGNATURE----- > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Darxus at chaosreigns.com Sun Nov 21 15:52:14 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sun, 21 Nov 2010 18:52:14 -0500 Subject: Using the Wayland port of QT In-Reply-To: References: <201011211226.44496.bluescreen_avenger@verizon.net> Message-ID: <20101121235214.GA11570@chaosreigns.com> I spent a lot of time today trying to get this to work under ubuntu, with input from Benjamin Franzke in the IRC channel. I was not successful. On 11/21, Benjamin Franzke wrote: > http://git.overlays.gentoo.org/gitweb/?p=user/benf.git;a=blob;f=x11-libs/qt-wayland/files/config-test-wayland.patch That doesn't work, apparently due to hardcoding the path to drm.h instead of using the version from the defined library path. On 11/21, Benjamin Franzke wrote: > 2010/11/21 Benjamin Franzke : > > I've also created a merge request for that stuff now, so you could > > also use that: > > http://qt.gitorious.org/~krh/qt/qt-wayland/merge_requests/1 > oh I forgot to say the merge request needs the scanner PATCH i posted earlier.. > so you should use the first patch for now The scanner patch (for wayland, not qt) is: http://lists.freedesktop.org/archives/wayland-devel/2010-November/000222.html These two patches together (one for qt, one for wayland) result in a segfault. < Darxus> $ examples/widgets/analogclock/analogclock -platform wayland < Darxus> Segmentation fault < bnf> Darxus: had that too... only doing a clean rebuild helped me < Darxus> bnf: Rebuild of what? < bnf> Darxus: qt (yes it sucks) I rebuilt wayland and qt (after "git reset --hard && git clean -x -f" in both), and got the segfault again. A script of what I did (applying the qt-wayland merge request, and the scanner patch for wayland): http://www.chaosreigns.com/wayland/wayland-qt-build.sh You'll probably need some more stuff built from git which is done by my ubuntu build script. Some useful Qt build debugging stuff: 03:39PM < Darxus> Failed to load platform plugin "wayland". Available platforms are: 03:39PM < Darxus> Minimal 03:40PM < bnf> Darxus: search for qwayland.so 03:40PM < bnf> *libqwayland.so 03:41PM < Darxus> No libqwayland.so. 03:42PM < bnf> go to config.tests/qpa/wayland/ 03:42PM < bnf> ist there a file "wayland"? 03:42PM < Darxus> No. Just Makefile wayland.cpp wayland.pro 03:43PM < bnf> qmake wayland.pro && make wayland 03:45PM < Darxus> wayland.cpp:2: fatal error: wayland-client.h: No such file or directory 03:45PM < Darxus> $ export | grep INCL 03:45PM < Darxus> declare -x C_INCLUDE_PATH="/home/darxus/install/include" 03:46PM < Darxus> $ ls -l /home/darxus/install/include/wayland-client.h 03:46PM < Darxus> -rw-r--r-- 1 darxus darxus 2907 2010-11-20 22:53 /home/darxus/install/include/wayland-client.h 03:46PM < bnf> Darxus: oh maybe you need CPLUS_INCLUDE_PATH? 03:48PM < Darxus> Yup, that did it, thanks. 04:17PM < Darxus> In file included from /home/darxus/install/include/xf86drm.h:40, from qwaylandintegration.cpp:20: 04:17PM < Darxus> /usr/include/libdrm/drm.h:376: error: expected unqualified-id before ?virtual? 04:17PM < bnf> Darxus: update you libdrm 04:18PM < Darxus> bnf: from git://anongit.freedesktop.org/git/mesa/drm ? 04:19PM < Darxus> $ git pull 04:19PM < Darxus> Already up-to-date. 04:21PM < bnf> Darxus: /usr/include/libdrm/drm.h is used thats a problem of the first patch.. This is the problem with hardcoding the path to drm.h, which is fixed by http://qt.gitorious.org/~krh/qt/qt-wayland/merge_requests/1 -- "Forget not that the earth delights to feel your bare feet and the winds long to play with your hair." - Kahlil Gibran http://www.ChaosReigns.com From bacn at zhasha.com Sun Nov 21 16:26:40 2010 From: bacn at zhasha.com (Joakim Sindholt) Date: Mon, 22 Nov 2010 01:26:40 +0100 Subject: Porting Apps to Wayland In-Reply-To: <4CE9816C.9060804@freakybytes.org> References: <4CE9816C.9060804@freakybytes.org> Message-ID: <1290385600.2473.3.camel@ztoshiba> I basically have no valid clue about how this will look when it's done, but if you open protocol/wayland.xml you'll see the input system as it's exposed to you the developer in its current form: It's definitely a new interface. IIRC you might want to use the new libxkbcommon to translate keycodes to keysyms. You will not be able to use libxcb, and the interface will probably be easier to deal with. On Sun, 2010-11-21 at 21:30 +0100, Kai Mast wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey Guys, > > I am pretty new to Wayland and just have a general question. > > What exactly does change for me as a game developer on the programming > site when I switch to Wayland. Obviously the OpenGL calls will be > untouched. But what about Input? Will i still be able to use libxcb or > will there a completely different API to handle that kind of stuff? > > greets, > Kai > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJM6YFsAAoJEKU5B2k1XeMEKIUP/3mCdkPWljNYrmmGAtC78CVk > 8XHow3MjcBt6OrgU1pfbCJREUHKF848gmS4bB1IluqCAU4h15pHj8N7ujs9MiN7i > xCNCVPLp1P+fR2pDnr1hQjJ5OAMq4/KGEN4qlug2nsXHHYY4KBZqUFsXJL4O/IaH > YmSsNJe6urJu6dBkE1Ry1mzk7ET8UJf4s+Mtk0dl/YJUnlzUm1ZCmnkGZe3Dd8YB > 6fPuRGTItQRJifiMOKcAw8dm9SV3m7fDDtPFRdZRz/CQ272SICSIsLWhB1n71p/0 > 3dHoIazafVApEWQjFYfbTsjGfuzGK1L/AfdpZNQc7MbsVSkQVS39gveCVS+bYBhi > OTruRjmg7CXb0LkdhA6ZNzmDGg8SD0OJ1rj/vnzA46SBOmyIiBsr56rHJFMQfzaP > ZxzT8y4BReD8GBe2xIuKwXtidiNSIaCLOm5zTw455JAEalv+E6BJKa6L54DJRvrx > lqkjSevLoDzNar9WZ//kfh6oG5DtHCfZ+yxdxZZav9GuW5wo1BgPhVKshUA9o4Gy > 8d5o3XmzmGdtXVCQyoT/7198v3UdEafjbBpjynsfVgRh2dpZXCto39Ue++eB34YX > VTtytFPjCBCajgrr1YeLfFcVMXf6kZscB6x23CEdIryZpeXDYxVc3DIbEpwMdnnm > lbgls9l+G9UEm+6smw+Y > =TLrQ > -----END PGP SIGNATURE----- > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel From Darxus at chaosreigns.com Sun Nov 21 20:37:45 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sun, 21 Nov 2010 23:37:45 -0500 Subject: Wayland partially working outside of X with a frame buffer (on nvidia) Message-ID: <20101122043745.GD11570@chaosreigns.com> "The Linux framebuffer is a graphic hardware-independent abstraction layer to show graphics on a console without relying on system-specific libraries such as SVGALib or the heavy overhead of the X Window System." - https://wiki.ubuntu.com/FrameBuffer I hope uv doesn't get too mad at me for posting this. It's not done. It's broken. But I ran the wayland compositor outside of X on my nvidia card with nouveau, on nouveaufb. With mouse and keyboard input even working. He was using it with uvesafb. No DRI / mesa required. And, well, I'm excited about that enough that I feel a need to share. It sucked up over 8 gigabytes of virtual ram, on my machine with 8 gigs of ram. The only client I got to work was terminal. Backgrounds didn't work. Apply this patch to wayland: http://www.iarc.org/~4z5uv/wayland-fb-2.diff Copy this into the compositor directory: http://www.iarc.org/~4z5uv/compositor-fb.c I also needed to comment out three lines in compositor/compositor.c: else { //ec = drm_compositor_create(display, option_connector); //if (ec == NULL) { ec = fb_compositor_create(display); //} } Because it was selecting the DRM compositor (which doesn't work on nvidia). Then build. The most problematic part by far was figuring out that it only supports 16 bits per pixel. If you have it at 32bpp, it breaks video output before printing that error. What I eventually did to get nouveaufb into 16bpp was: GRUB_CMDLINE_LINUX_DEFAULT="video=DVI-I-1:1600x1200-16 at 75" in /etc/default/grub, and then run update-grub nouveaufb was set up under ubuntu by default after I disabled the proprietary driver. Unfortunately DVI-I-1 probably isn't going to be right for a lot of people. To run wayland and the terminal client at the same time: (sudo compositor/compositor &);sleep 1;clients/terminal & Yeah I actually ran the compositor as root instead of figuring out what was up with the permissions problems. Using a background is broken too. Using a jpeg doesn't seem to work. I noticed something about pngs in the patch, so I tried that. It loaded the background but then crashed. -- "For every complex problem, there is a solution that is simple, neat, and wrong." - H. L. Mencken http://www.ChaosReigns.com From Darxus at chaosreigns.com Sun Nov 21 21:45:06 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Mon, 22 Nov 2010 00:45:06 -0500 Subject: Wayland partially working outside of X with a frame buffer (on nvidia) In-Reply-To: <20101122043745.GD11570@chaosreigns.com> References: <20101122043745.GD11570@chaosreigns.com> Message-ID: <20101122054506.GE11570@chaosreigns.com> I didn't make it clear enough: This frame buffer support was written by uv in the IRC channel. -- "Don't go around saying the world owes you a living. The world owes you nothing. It was here first." - Mark Twain http://www.ChaosReigns.com From yuvalfl at gmail.com Mon Nov 22 00:28:43 2010 From: yuvalfl at gmail.com (Yuval Fledel) Date: Mon, 22 Nov 2010 10:28:43 +0200 Subject: Wayland partially working outside of X with a frame buffer (on nvidia) In-Reply-To: <20101122054506.GE11570@chaosreigns.com> References: <20101122043745.GD11570@chaosreigns.com> <20101122054506.GE11570@chaosreigns.com> Message-ID: Hi, uv is me. This is a very early patch! I will clean it up and send it to krh. I was going to sleep, and I wake up with a mailing list post and a Phoronix entry ;-) Quite an accomplishment. For all the innocent readers: It won't work for you! I'm not accepting bug reports before it is cleaned up and committed. But yes, its great and as far as I'm concerned, it will be there for you to test later on. -- Yuval On 22 November 2010 07:45, wrote: > I didn't make it clear enough: ?This frame buffer support was written by uv > in the IRC channel. > > -- > "Don't go around saying the world owes you a living. The world owes you > nothing. It was here first." ?- Mark Twain > http://www.ChaosReigns.com > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From tpham3783 at gmail.com Mon Nov 22 06:34:58 2010 From: tpham3783 at gmail.com (Toan Pham) Date: Mon, 22 Nov 2010 09:34:58 -0500 Subject: Language bindings for wayland In-Reply-To: <1290344557.2462.3.camel@ztoshiba> References: <20101120231224.7rfadugao0sk08sk@mail.zih.tu-dresden.de> <1290344557.2462.3.camel@ztoshiba> Message-ID: Carl-Philip, Would you please give me more info on the wrapper and if it would be published on freepascal.org after you're done. I am interested in using/developing object-pascal wrapper for wayland as well. -thanks, toan From krh at bitplanet.net Mon Nov 22 07:02:54 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 22 Nov 2010 10:02:54 -0500 Subject: Language bindings for wayland In-Reply-To: <20101120231224.7rfadugao0sk08sk@mail.zih.tu-dresden.de> References: <20101120231224.7rfadugao0sk08sk@mail.zih.tu-dresden.de> Message-ID: On Sat, Nov 20, 2010 at 5:12 PM, Carl-Philip Haensch wrote: > Hi, > > i'm planning to write languate bindings for freepascal (fpc) but there are > some things that make it hard for me to port (=blocks automatic header > generation) > ?- inline functions and their implementation in the header file > ?- "struct foo *" as declaration in return types > ?- #define inline function magic Ok, first of all, I think it's a little too early to do bindings for wayland, and taking a step back, I'm not event sure that it makes sense. The wayland libraries are first a foremost a platform for toolkits like gtk+, qt, clutter, fltk, and so on. So the way to write a wayland client in your favorite non-C language would be to port the toolkit you intend to use, and then just use the language bindings for that toolkit. Of course, in case your toolkit is written in something else that C or if your application doesn't use a toolkit, you'll need wayland bindings for that language (as well as EGL bindings, libxkbcommon bindings etc). For the wayland part, you're better off binding at a lower level than the C API level. As a minimum you'll want to generate language specific stubs from the protocol xml directly instead of binding the generated C code, but for an interpreted language, you definitely don't want libffi in there to call a C functions which then calls into the interpreted language (I understand this probably doesn't apply to fpc). Kristian From krh at bitplanet.net Mon Nov 22 07:31:00 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 22 Nov 2010 10:31:00 -0500 Subject: Porting Apps to Wayland In-Reply-To: <4CE9816C.9060804@freakybytes.org> References: <4CE9816C.9060804@freakybytes.org> Message-ID: On Sun, Nov 21, 2010 at 3:30 PM, Kai Mast wrote: > > Hey Guys, > > I am pretty new to Wayland and just have a general question. > > What exactly does change for me as a game developer on the programming > site when I switch to Wayland. Obviously the OpenGL calls will be > untouched. But what about Input? Will i still be able to use libxcb or > will there a completely different API to handle that kind of stuff? OpenGL is mostly the same, yes. You'll be using EGL to set it up instead of GLX, but other than that it's the GL you know. On the input side, things will be different, but the idea is to basically take the consensus of XI2 and MPX. The protocol xml that Joakim posted describes how things work today, and the MPX support is in there already, but we need more meta-data about the input devices (valuator labels, absolute device range, relative events and more). Also, this thread provides a bit more detail on games in wayland: http://lists.freedesktop.org/archives/wayland-devel/2010-November/000080.html Kristian From krh at bitplanet.net Mon Nov 22 07:36:09 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 22 Nov 2010 10:36:09 -0500 Subject: Typos in the FAQ In-Reply-To: References: Message-ID: Thanks. Kristian On Sun, Nov 21, 2010 at 3:02 PM, Jacob Parker wrote: > > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > From krh at bitplanet.net Mon Nov 22 07:38:12 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 22 Nov 2010 10:38:12 -0500 Subject: [PATCH] scanner: include stddef.h to provide NULL and size_t In-Reply-To: <1290336431-9706-1-git-send-email-benjaminfranzke@googlemail.com> References: <1290336431-9706-1-git-send-email-benjaminfranzke@googlemail.com> Message-ID: Thanks, applied. Kristian On Sun, Nov 21, 2010 at 5:47 AM, Benjamin Franzke wrote: > --- > ?wayland/scanner.c | ? ?1 + > ?1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/wayland/scanner.c b/wayland/scanner.c > index aaaf551..9d099fb 100644 > --- a/wayland/scanner.c > +++ b/wayland/scanner.c > @@ -520,6 +520,7 @@ emit_header(struct protocol *protocol, int server) > ? ? ? ? ? ? ? "#endif\n" > ? ? ? ? ? ? ? "\n" > ? ? ? ? ? ? ? "#include \n" > + ? ? ? ? ? ? ?"#include \n" > ? ? ? ? ? ? ? "#include \"wayland-util.h\"\n\n" > ? ? ? ? ? ? ? "struct wl_client;\n\n", > ? ? ? ? ? ? ? copyright, > -- > 1.7.2.2 > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From tpham3783 at gmail.com Mon Nov 22 07:53:19 2010 From: tpham3783 at gmail.com (Toan Pham) Date: Mon, 22 Nov 2010 10:53:19 -0500 Subject: Language bindings for wayland In-Reply-To: References: <20101120231224.7rfadugao0sk08sk@mail.zih.tu-dresden.de> Message-ID: > So the way to write > a wayland client in your favorite non-C language would be to port the > toolkit you intend to use, and then just use the language bindings for > that toolkit. This statement makes it sound like porting existing applications to Wayland almost effortless; since most existing GUI applications use binding to gtk+ and qt etc. Good to know, thanks -toan From krh at bitplanet.net Mon Nov 22 08:06:30 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 22 Nov 2010 11:06:30 -0500 Subject: missing freeing previous data struction when new allocation fails In-Reply-To: References: Message-ID: On Wed, Nov 17, 2010 at 10:16 PM, ??? wrote: > The scenario is: > struct A *foo() > { > ??? A *a; > > ??? a = malloc(sizeof(A)); > ??? if (a == NULL) > ??????? return NULL; > > ??? a->b = malloc(sizeof(B)); > ??? if (a->b == NULL) > ??????? return NULL; > > ??? return a; > } You're right, there's a bunch of those in the code. Could you please create your patches by committing the changes and then either attach the output of git format-patch -1 (where -1 means "one commit", use whatever number of patches you have) or even better use git send-email -1 --to=wayland-devel at lists.freedesktop.org. Thanks, Kristian From krh at bitplanet.net Mon Nov 22 08:48:57 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 22 Nov 2010 11:48:57 -0500 Subject: [PATCH] Two typo fixes in the documentation In-Reply-To: <201011191028.37504.flyser42@gmx.de> References: <201011191028.37504.flyser42@gmx.de> Message-ID: On Fri, Nov 19, 2010 at 4:28 AM, Fabian Henze wrote: > Two typo fixes in specs/main.tex, mentioned in an earlier mail. Thanks, applied. > --- > ?spec/main.tex | ? ?4 ++-- > ?1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/spec/main.tex b/spec/main.tex > index 8c512be..e7a2b96 100644 > --- a/spec/main.tex > +++ b/spec/main.tex > @@ -284,7 +284,7 @@ Issues: > ? after the data has been transferred. > > ?\item How do we marshall several mime-types? ?We could make the drag > - ?setup a multi-step operation: dnd.create, drag.offer(mime-type1, > + ?setup a multi-step operation: dnd.create, drag.offer(mime-type1), > ? drag.offer(mime-type2), drag.activate(). ?The drag object could send > ? multiple offer events on each motion event. ?Or we could just > ? implement an array type, but that's a pain to work with. > @@ -429,7 +429,7 @@ ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/ > ?\item multiseat > ?\item linux implementation using libudev, egl, kms, evdev, cairo > ?\item for fullscreen clients, the system compositor can reprogram the > - ? video scanout address to source fromt the client provided buffer. > + ? video scanout address to source from the client provided buffer. > ?\end{itemize} > > ?\subsection{Session Compositor} > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From jonsmirl at gmail.com Mon Nov 22 09:14:57 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Mon, 22 Nov 2010 12:14:57 -0500 Subject: Summary of the anti-aliasing issue Message-ID: Right now the rendering engines are drawing into flat, rectangular buffers. These buffers are then composited by Wayland using transforms. The problem with this is that any transform (other than simple copy) done by Wayland will mess up the anti-aliasing computations made by the rendering engine (or app). To fix this there needs to be another compositing mode. In this mode Wayland tells the rendering ending (or app) the equation of the final compositing transform. The rendering engine uses this transform to draw it's window already transformed the way Wayland needs it. Wayland then takes these windows and just copies them onto the screen. Note that the transforms in Wayland don't have to be planar 2D transform, instead they could distort the window into 3D space. That means the window buffer handed back to Wayland needs to have a depth buffer. The depth buffer will make sure everything gets sorted out right when the window is copied. This mode is easy for OpenGL apps. Just set the transform and turn on hardware full-screen anti-aliasing. Implementing this mode in existing text based apps is much harder because the way current apps paint text on the screen. These existing apps contain logic for painting clipped regions. They also generate font glyphs with the assumption that they won't be transformed by later stages of the graphics pipe lines. I think the simplest way to convert existing apps is to rip out the paint function and replace it with a function that builds a scene graph reflecting the contents of the paint region. This is just my opinion and other solutions should be discussed. The scene graph would be regenerated each time paint is requested. It is passed into the rendering engine which would convert it to a bitmap with depth. Font glyphs are generated in the rendering engine and the rendering engine would contain the logic needed to make transformed anti-aliased glyphs. I think this is easier than teaching every app about a depth buffer. Also, take a second and reflect on the implications of this for network transparency. Of course you can use the first mode to run these apps without modification. The easiest existing apps for converting to this model are web browsers. Web browsers already use a scene graph internally and some have OpenGL backends. In that case they need to be taught to take the transform from Wayland and use it to modify how the bitmaps are generated. Pretty much everything will cleanly map except for glyph generation. The code for making glyphs will need to be taught about transformations. Webkit is the obvious place to start hacking. -- Jon Smirl jonsmirl at gmail.com From krh at bitplanet.net Mon Nov 22 09:23:30 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 22 Nov 2010 12:23:30 -0500 Subject: Summary of the anti-aliasing issue In-Reply-To: References: Message-ID: On Mon, Nov 22, 2010 at 12:14 PM, jonsmirl at gmail.com wrote: > Right now the rendering engines are drawing into flat, rectangular > buffers. These buffers are then composited by Wayland using > transforms. The problem with this is that any transform (other than > simple copy) done by Wayland will mess up the anti-aliasing > computations made by the rendering engine (or app). And that's the core design of wayland. You're welcome to propose and implement an extension that lets the compositor inform the clients of the transformation being applied to them on a per frame basis. It's not something I'm working on, and I think it's outside the scope of Wayland as it is. We can add it later if it turns out it's a killer feature, but right it's your baby and if you want to see it happen, put your code where your mouth is. Kristian From jonsmirl at gmail.com Mon Nov 22 09:54:13 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Mon, 22 Nov 2010 12:54:13 -0500 Subject: Summary of the anti-aliasing issue In-Reply-To: References: Message-ID: 2010/11/22 Kristian H?gsberg : > On Mon, Nov 22, 2010 at 12:14 PM, jonsmirl at gmail.com wrote: >> Right now the rendering engines are drawing into flat, rectangular >> buffers. These buffers are then composited by Wayland using >> transforms. The problem with this is that any transform (other than >> simple copy) done by Wayland will mess up the anti-aliasing >> computations made by the rendering engine (or app). > > And that's the core design of wayland. ?You're welcome to propose and > implement an extension that lets the compositor inform the clients of > the transformation being applied to them on a per frame basis. ?It's > not something I'm working on, and I think it's outside the scope of > Wayland as it is. ?We can add it later if it turns out it's a killer > feature, but right it's your baby and if you want to see it happen, > put your code where your mouth is. I'm committed to working full time on an embedded system (with no screen) so I'm unable to spend time on graphics code. The issue is out there now. If we are serious about making every screen pixel perfect it is something that needs to be implemented. Adding it to the API early will make it easier for app writers to adopt to using it. > > Kristian > -- Jon Smirl jonsmirl at gmail.com From krh at bitplanet.net Mon Nov 22 10:08:26 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 22 Nov 2010 13:08:26 -0500 Subject: [PATCH] client: don't call drag_offer_handler if it not hooked In-Reply-To: <4CDDE74C.8030301@21cn.com> References: <4CDDE74C.8030301@21cn.com> Message-ID: On Fri, Nov 12, 2010 at 8:18 PM, wucan wrote: > When play with dnd and terminal, if you drag any item in dnd to > terminal,terminal segvment fault. It's because terminal not setup > drag_offer_handler, but when a item draged on it's window, > display_handle_global() trigger the handler. Yup, thanks. I just rolled this and the follow-on patch into one. Kristian > --- > ?clients/window.c | ? ?4 +++- > ?1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/clients/window.c b/clients/window.c > index 9dfd355..5f69561 100644 > --- a/clients/window.c > +++ b/clients/window.c > @@ -1329,7 +1329,9 @@ display_handle_global(struct wl_display *display, > uint32_t id, > ? ? ? ? ? ? ? ?d->shm = wl_shm_create(display, id); > ? ? ? ?} else if (strcmp(interface, "drag_offer") == 0) { > ? ? ? ? ? ? ? ?offer = wl_drag_offer_create(display, id); > - ? ? ? ? ? ? ? d->drag_offer_handler(offer, d); > + ? ? ? ? ? ? ? if (d->drag_offer_handler) { > + ? ? ? ? ? ? ? ? ? ? ? d->drag_offer_handler(offer, d); > + ? ? ? ? ? ? ? } > ? ? ? ?} > ?} > > -- > 1.6.4.GIT > -- > wucan > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From krh at bitplanet.net Mon Nov 22 13:12:53 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 22 Nov 2010 16:12:53 -0500 Subject: Wayland license clarification Message-ID: Hi, I wanted to clear up the wayland licensing a bit before I apply more patches. The main "output" of the wayland git repo is the two libraries: libwayland-server and libwayland-client. Right now those libraries are under the MIT license, but I'm going to move them to be LGPLv2. The purpose of these libraries are to provide a C API for the wayland protocol. libwayland-client will typically be a dependency of toolkits such as Qt, GTK+ or clutter, or perhaps used directly by wine, qemu or rdesktop type of applications. Moving libwayland-client to LGPLv2 shouldn't be a problem for these cases, indeed those toolkits are all already LGPLv2. The most notable change will be that you can't fix a bunch of bugs in the library and keep them to yourself. libwayland-server will be a dependency of any compositor, but as for the client side library, this shouldn't have any consequences on how you can use it, only on how you contribute to it. I'm aware of the uncertainty about static linking and LGPLv2, but just don't link statically. The demo compositor and clients are currently under GPLv2, but I'm changing them to LGPLv2 as well. This is a bit odd on the face of it, but the point of these applications is to prototype new functionality that will eventually migrate into either the client or server wayland libraries or one of the above toolkits. As we move forward and start adding developers, I just want to make sure that that won't be a problem. Obivously, I am not a lawyer and the above is only an informal discussion of the differences between MIT and LGPLv2, meant to describe the motivation behind the specific license choices. The license text is always the last word. If I've applied patches from anybody opposed to this license change, please let me know and I'll back them out. Thanks, Kristian From bluescreen_avenger at verizon.net Mon Nov 22 15:49:52 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Mon, 22 Nov 2010 18:49:52 -0500 Subject: Wayland suspended app bug report Message-ID: <201011221849.53590.bluescreen_avenger@verizon.net> Hi. I don't know where else to report this I noticed that whenever a Wayland client process is suspended, and then resumed, the client hangs, and uses up an entire CPU core. If its an inactive window, and you try to activate it while its frozen, and then click on another window, and resume it, it turns to the active color, and then hangs. It seems that it loses sync with events, as it picks up that it was once activated, even when it is no longer. This happens most of the time a wayland cleint is suspended, including the qt one. From Darxus at chaosreigns.com Mon Nov 22 18:24:39 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Mon, 22 Nov 2010 21:24:39 -0500 Subject: [PATCH] Some additional return value checking, updated. Message-ID: <20101123022439.GF11570@chaosreigns.com> --- clients/window.c | 5 ++++- compositor/compositor-drm.c | 6 +++++- compositor/compositor-x11.c | 22 ++++++++++++++++------ 3 files changed, 25 insertions(+), 8 deletions(-) diff --git a/clients/window.c b/clients/window.c index 9ed96be..8a2c4ab 100644 --- a/clients/window.c +++ b/clients/window.c @@ -1463,7 +1463,10 @@ display_create(int *argc, char **argv[], const GOptionEntry *option_entries) return NULL; } - eglBindAPI(EGL_OPENGL_API); + if (EGL_FALSE == eglBindAPI(EGL_OPENGL_API)) { + fprintf(stderr, "failed to bind api EGL_OPENGL_API\n"); + return NULL; + } d->ctx = eglCreateContext(d->dpy, NULL, EGL_NO_CONTEXT, NULL); if (d->ctx == NULL) { diff --git a/compositor/compositor-drm.c b/compositor/compositor-drm.c index e843e14..d06f769 100644 --- a/compositor/compositor-drm.c +++ b/compositor/compositor-drm.c @@ -339,7 +339,11 @@ init_egl(struct drm_compositor *ec, struct udev_device *device) return -1; } - eglBindAPI(EGL_OPENGL_ES_API); + if (EGL_FALSE == eglBindAPI(EGL_OPENGL_ES_API)) { + fprintf(stderr, "failed to bind api EGL_OPENGL_ES_API\n"); + return -1; + } + ec->base.context = eglCreateContext(ec->base.display, NULL, EGL_NO_CONTEXT, context_attribs); if (ec->base.context == NULL) { diff --git a/compositor/compositor-x11.c b/compositor/compositor-x11.c index f6e705b..c348296 100644 --- a/compositor/compositor-x11.c +++ b/compositor/compositor-x11.c @@ -80,19 +80,21 @@ struct x11_input { }; -static void +static int x11_input_create(struct x11_compositor *c) { struct x11_input *input; input = malloc(sizeof *input); if (input == NULL) - return; + return -1; memset(input, 0, sizeof *input); wlsc_input_device_init(&input->base, &c->base); c->base.input_device = &input->base; + + return 0; } @@ -247,7 +249,11 @@ x11_compositor_init_egl(struct x11_compositor *c) return -1; } - eglBindAPI(EGL_OPENGL_ES_API); + if (EGL_FALSE == eglBindAPI(EGL_OPENGL_ES_API)) { + fprintf(stderr, "failed to bind EGL_OPENGL_ES_API\n"); + return -1; + } + c->base.context = eglCreateContext(c->base.display, NULL, EGL_NO_CONTEXT, context_attribs); if (c->base.context == NULL) { @@ -661,15 +667,17 @@ x11_compositor_create(struct wl_display *display, int width, int height) c->base.wl_display = display; if (x11_compositor_init_egl(c) < 0) - return NULL; + return NULL; /* Can't init base class until we have a current egl context */ if (wlsc_compositor_init(&c->base, display) < 0) return NULL; - x11_compositor_create_output(c, width, height); + if (x11_compositor_create_output(c, width, height) < 0) + return NULL; - x11_input_create(c); + if (x11_input_create(c) < 0) + return NULL; loop = wl_display_get_event_loop(c->base.wl_display); @@ -679,6 +687,8 @@ x11_compositor_create(struct wl_display *display, int width, int height) x11_compositor_handle_event, c); c->base.authenticate = x11_authenticate; + if (c->base.authenticate < 0) + return NULL; c->base.present = x11_compositor_present; return &c->base; -- 1.7.1 From krh at bitplanet.net Mon Nov 22 18:59:22 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 22 Nov 2010 21:59:22 -0500 Subject: [PATCH] Some additional return value checking, updated. In-Reply-To: <20101123022439.GF11570@chaosreigns.com> References: <20101123022439.GF11570@chaosreigns.com> Message-ID: On Mon, Nov 22, 2010 at 9:24 PM, wrote: > --- > ?clients/window.c ? ? ? ? ? ?| ? ?5 ++++- > ?compositor/compositor-drm.c | ? ?6 +++++- > ?compositor/compositor-x11.c | ? 22 ++++++++++++++++------ > ?3 files changed, 25 insertions(+), 8 deletions(-) Applied with a few changes, see below. > diff --git a/clients/window.c b/clients/window.c > index 9ed96be..8a2c4ab 100644 > --- a/clients/window.c > +++ b/clients/window.c > @@ -1463,7 +1463,10 @@ display_create(int *argc, char **argv[], const GOptionEntry *option_entries) > ? ? ? ? ? ? ? ?return NULL; > ? ? ? ?} > > - ? ? ? eglBindAPI(EGL_OPENGL_API); > + ? ? ? if (EGL_FALSE == eglBindAPI(EGL_OPENGL_API)) { > + ? ? ? ? ? ? ? fprintf(stderr, "failed to bind api EGL_OPENGL_API\n"); > + ? ? ? ? ? ? ? return NULL; > + ? ? ? } I don't use the "if (EGL_FALSE == stuff())" idiom in wayland. I get that the idea is that by putting the constant on the left hand side of ==, we avoid accidents like "if (a = 5) ...", but gcc already warns about that and "if (5 == a)" just isn't very intuitive. Don't take it personal, it's one of my pet peeves ;-) > ? ? ? ?d->ctx = eglCreateContext(d->dpy, NULL, EGL_NO_CONTEXT, NULL); > ? ? ? ?if (d->ctx == NULL) { > diff --git a/compositor/compositor-drm.c b/compositor/compositor-drm.c > index e843e14..d06f769 100644 > --- a/compositor/compositor-drm.c > +++ b/compositor/compositor-drm.c > @@ -339,7 +339,11 @@ init_egl(struct drm_compositor *ec, struct udev_device *device) > ? ? ? ? ? ? ? ?return -1; > ? ? ? ?} > > - ? ? ? eglBindAPI(EGL_OPENGL_ES_API); > + ? ? ? if (EGL_FALSE == eglBindAPI(EGL_OPENGL_ES_API)) { > + ? ? ? ? ? ? ? fprintf(stderr, "failed to bind api EGL_OPENGL_ES_API\n"); > + ? ? ? ? ? ? ? return -1; > + ? ? ? } > + > ? ? ? ?ec->base.context = eglCreateContext(ec->base.display, NULL, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?EGL_NO_CONTEXT, context_attribs); > ? ? ? ?if (ec->base.context == NULL) { > diff --git a/compositor/compositor-x11.c b/compositor/compositor-x11.c > index f6e705b..c348296 100644 > --- a/compositor/compositor-x11.c > +++ b/compositor/compositor-x11.c > @@ -80,19 +80,21 @@ struct x11_input { > ?}; > > > -static void > +static int > ?x11_input_create(struct x11_compositor *c) > ?{ > ? ? ? ?struct x11_input *input; > > ? ? ? ?input = malloc(sizeof *input); > ? ? ? ?if (input == NULL) > - ? ? ? ? ? ? ? return; > + ? ? ? ? ? ? ? return -1; > > ? ? ? ?memset(input, 0, sizeof *input); > ? ? ? ?wlsc_input_device_init(&input->base, &c->base); > > ? ? ? ?c->base.input_device = &input->base; > + > + ? ? ? return 0; > ?} > > > @@ -247,7 +249,11 @@ x11_compositor_init_egl(struct x11_compositor *c) > ? ? ? ? ? ? ? ?return -1; > ? ? ? ?} > > - ? ? ? eglBindAPI(EGL_OPENGL_ES_API); > + ? ? ? if (EGL_FALSE == eglBindAPI(EGL_OPENGL_ES_API)) { > + ? ? ? ? ? ? ? fprintf(stderr, "failed to bind EGL_OPENGL_ES_API\n"); > + ? ? ? ? ? ? ? return -1; > + ? ? ? } > + > ? ? ? ?c->base.context = eglCreateContext(c->base.display, NULL, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? EGL_NO_CONTEXT, context_attribs); > ? ? ? ?if (c->base.context == NULL) { > @@ -661,15 +667,17 @@ x11_compositor_create(struct wl_display *display, int width, int height) > > ? ? ? ?c->base.wl_display = display; > ? ? ? ?if (x11_compositor_init_egl(c) < 0) > - ? ? ? ?return NULL; > + ? ? ? ? ? ? ? return NULL; > > ? ? ? ?/* Can't init base class until we have a current egl context */ > ? ? ? ?if (wlsc_compositor_init(&c->base, display) < 0) > ? ? ? ? ? ? ? ?return NULL; > > - ? ? ? x11_compositor_create_output(c, width, height); > + ? ? ? if (x11_compositor_create_output(c, width, height) < 0) > + ? ? ? ? ? ? ? return NULL; > > - ? ? ? x11_input_create(c); > + ? ? ? if (x11_input_create(c) < 0) > + ? ? ? ? ? ? ? return NULL; > > ? ? ? ?loop = wl_display_get_event_loop(c->base.wl_display); > > @@ -679,6 +687,8 @@ x11_compositor_create(struct wl_display *display, int width, int height) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? x11_compositor_handle_event, c); > > ? ? ? ?c->base.authenticate = x11_authenticate; > + ? ? ? if (c->base.authenticate < 0) > + ? ? ? ? ? ? ? return NULL; > ? ? ? ?c->base.present = x11_compositor_present; This is setting a function pointer, not calling the functions, checking for < 0 doesn't make sense. I edited this part out. Kristian From behdad at behdad.org Mon Nov 22 20:01:16 2010 From: behdad at behdad.org (Behdad Esfahbod) Date: Mon, 22 Nov 2010 23:01:16 -0500 Subject: [PATCH] Some additional return value checking, updated. In-Reply-To: References: <20101123022439.GF11570@chaosreigns.com> Message-ID: <4CEB3C8C.4070201@behdad.org> On 11/22/10 21:59, Kristian H?gsberg wrote: >> - eglBindAPI(EGL_OPENGL_API); >> + if (EGL_FALSE == eglBindAPI(EGL_OPENGL_API)) { >> + fprintf(stderr, "failed to bind api EGL_OPENGL_API\n"); >> + return NULL; >> + } > > I don't use the "if (EGL_FALSE == stuff())" idiom in wayland. I get > that the idea is that by putting the constant on the left hand side of > ==, we avoid accidents like "if (a = 5) ...", but gcc already warns > about that and "if (5 == a)" just isn't very intuitive. Don't take it > personal, it's one of my pet peeves ;-) http://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined/2430307#2430307 :) b From linhaoxiang at gmail.com Mon Nov 22 21:22:39 2010 From: linhaoxiang at gmail.com (=?UTF-8?B?5p6X5piK57+U?=) Date: Tue, 23 Nov 2010 13:22:39 +0800 Subject: missing freeing previous data struction when new allocation fails In-Reply-To: References: Message-ID: I think the best way is borrowing constructor and destructor concepts from C++. For each internal data structure *foo*, maintain a *foo_create*function as the constructor(many data structures are already done), and a *foo_destroy* function as the destructor. Then we avoid duplicate and complicate clean work at each failure exit in *foo_create*. 2010/11/23 Kristian H?gsberg > On Wed, Nov 17, 2010 at 10:16 PM, ??? wrote: > > The scenario is: > > struct A *foo() > > { > > A *a; > > > > a = malloc(sizeof(A)); > > if (a == NULL) > > return NULL; > > > > a->b = malloc(sizeof(B)); > > if (a->b == NULL) > > return NULL; > > > > return a; > > } > > You're right, there's a bunch of those in the code. Could you please > create your patches by committing the changes and then either attach > the output of git format-patch -1 (where -1 means "one commit", use > whatever number of patches you have) or even better use git send-email > -1 --to=wayland-devel at lists.freedesktop.org. > > Thanks, > Kristian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Darxus at chaosreigns.com Mon Nov 22 21:34:43 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Tue, 23 Nov 2010 00:34:43 -0500 Subject: [PATCH] Return value checks, error messages, \n's, etc. Message-ID: <20101123053443.GG11570@chaosreigns.com> 5 \n's in prints 4 Return value checks 2 Additional error messages 2 Typos 1 Change return value for consistency (EGL_FALSE -> -1) 1 Check if array was created before writing to it 1 Corrected error message --- clients/gears.c | 2 +- clients/screenshot.c | 6 +++++- clients/window.c | 17 ++++++++++------- compositor/compositor-x11.c | 3 ++- compositor/compositor.c | 11 +++++++++-- wayland/scanner.c | 4 ++-- wayland/wayland-server.c | 3 ++- 7 files changed, 31 insertions(+), 15 deletions(-) diff --git a/clients/gears.c b/clients/gears.c index 7d3c310..6f47971 100644 --- a/clients/gears.c +++ b/clients/gears.c @@ -227,7 +227,7 @@ allocate_buffer(struct gears *gears) gears->surface[gears->current]); if (!eglMakeCurrent(gears->display, NULL, NULL, gears->context)) - die("faile to make context current\n"); + die("failed to make context current\n"); glBindRenderbuffer(GL_RENDERBUFFER_EXT, gears->color_rbo[gears->current]); diff --git a/clients/screenshot.c b/clients/screenshot.c index e9fa5aa..40867dc 100644 --- a/clients/screenshot.c +++ b/clients/screenshot.c @@ -61,7 +61,11 @@ int main(int argc, char *argv[]) } screenshooter = NULL; - wl_display_add_global_listener(display, handle_global, &screenshooter); + if (wl_display_add_global_listener(display, handle_global, &screenshooter) == NULL) { + fprintf(stderr, "failed to create listener\n"); + return -1; + } + wl_display_iterate(display, WL_DISPLAY_READABLE); if (screenshooter == NULL) { fprintf(stderr, "display doesn't support screenshooter\n"); diff --git a/clients/window.c b/clients/window.c index bc76937..12753bb 100644 --- a/clients/window.c +++ b/clients/window.c @@ -354,11 +354,11 @@ display_create_shm_surface(struct display *display, data->length = stride * rectangle->height; fd = mkstemp(filename); if (fd < 0) { - fprintf(stderr, "open %s failed: %m", filename); + fprintf(stderr, "open %s failed: %m\n", filename); return NULL; } if (ftruncate(fd, data->length) < 0) { - fprintf(stderr, "ftruncate failed: %m"); + fprintf(stderr, "ftruncate failed: %m\n"); close(fd); return NULL; } @@ -368,7 +368,7 @@ display_create_shm_surface(struct display *display, unlink(filename); if (data->map == MAP_FAILED) { - fprintf(stderr, "mmap failed: %m"); + fprintf(stderr, "mmap failed: %m\n"); close(fd); return NULL; } @@ -1434,8 +1434,11 @@ display_create(int *argc, char **argv[], const GOptionEntry *option_entries) wl_list_init(&d->input_list); /* Set up listener so we'll catch all events. */ - wl_display_add_global_listener(d->display, - display_handle_global, d); + if (wl_display_add_global_listener(d->display, + display_handle_global, d) == NULL) { + fprintf(stderr, "failed to create listener\n"); + return NULL; + } /* Process connection events. */ wl_display_iterate(d->display, WL_DISPLAY_READABLE); @@ -1447,7 +1450,7 @@ display_create(int *argc, char **argv[], const GOptionEntry *option_entries) } if (drmGetMagic(fd, &magic)) { - fprintf(stderr, "DRI2: failed to get drm magic"); + fprintf(stderr, "DRI2: failed to get drm magic\n"); return NULL; } @@ -1475,7 +1478,7 @@ display_create(int *argc, char **argv[], const GOptionEntry *option_entries) } if (!eglMakeCurrent(d->dpy, NULL, NULL, d->ctx)) { - fprintf(stderr, "faile to make context current\n"); + fprintf(stderr, "failed to make context current\n"); return NULL; } diff --git a/compositor/compositor-x11.c b/compositor/compositor-x11.c index 3f6d842..5b9c630 100644 --- a/compositor/compositor-x11.c +++ b/compositor/compositor-x11.c @@ -133,6 +133,7 @@ dri2_connect(struct x11_compositor *c) xfixes_query_cookie, &error); if (xfixes_query == NULL || error != NULL || xfixes_query->major_version < 2) { + fprintf(stderr, "DRI2: major version < 2\n"); free(error); return -1; } @@ -144,7 +145,7 @@ dri2_connect(struct x11_compositor *c) if (dri2_query == NULL || error != NULL) { fprintf(stderr, "DRI2: failed to query version\n"); free(error); - return EGL_FALSE; + return -1; } c->dri2_major = dri2_query->major_version; c->dri2_minor = dri2_query->minor_version; diff --git a/compositor/compositor.c b/compositor/compositor.c index ff24224..0878a4c 100644 --- a/compositor/compositor.c +++ b/compositor/compositor.c @@ -182,8 +182,10 @@ texture_from_png(const char *filename, int width, int height) pixbuf = gdk_pixbuf_new_from_file_at_scale(filename, width, height, FALSE, &error); - if (error != NULL) + if (error != NULL) { + fprintf(stderr, "could not open %s\n", filename); return -1; + } data = gdk_pixbuf_get_pixels(pixbuf); @@ -989,7 +991,8 @@ notify_key(struct wlsc_input_device *device, device->keys.size = (void *) end - device->keys.data; if (state) { k = wl_array_add(&device->keys, sizeof *k); - *k = key; + if (k) + *k = key; } if (device->keyboard_focus != NULL) @@ -1463,6 +1466,10 @@ int main(int argc, char *argv[]) } display = wl_display_create(); + if (display == NULL) { + fprintf(stderr, "failed to create display\n"); + exit(EXIT_FAILURE); + } if (getenv("DISPLAY")) ec = x11_compositor_create(display, width, height); diff --git a/wayland/scanner.c b/wayland/scanner.c index 9d099fb..4326f3a 100644 --- a/wayland/scanner.c +++ b/wayland/scanner.c @@ -156,7 +156,7 @@ start_element(void *data, const char *element_name, const char **atts) } if (version == 0) { - fprintf(stderr, "no interface version given\n"); + fprintf(stderr, "version is 0\n"); exit(EXIT_FAILURE); } @@ -322,7 +322,7 @@ emit_stubs(struct wl_list *message_list, struct interface *interface) if (!has_destructor && has_destroy) { fprintf(stderr, "interface %s has method named destroy but" - "no destructor", interface->name); + "no destructor\n", interface->name); exit(EXIT_FAILURE); } diff --git a/wayland/wayland-server.c b/wayland/wayland-server.c index 3ddfc33..3f6ad66 100644 --- a/wayland/wayland-server.c +++ b/wayland/wayland-server.c @@ -452,7 +452,8 @@ socket_data(int fd, uint32_t mask, void *data) if (client_fd < 0) fprintf(stderr, "failed to accept\n"); - wl_client_create(display, client_fd); + if (wl_client_create(display, client_fd) == NULL) + fprintf(stderr, "failed to create client\n"); } WL_EXPORT int -- 1.7.1 From Wolf.St.Kappesser at gmx.de Tue Nov 23 04:17:38 2010 From: Wolf.St.Kappesser at gmx.de (Wolf Stephan Kappesser) Date: Tue, 23 Nov 2010 13:17:38 +0100 Subject: Bug report Message-ID: <9B444B0F-BA77-4F47-9087-9B5C926A63E8@gmx.de> Hello, while building wayland on Ubuntu 10.10 x64 (under OSX 10.6 with VirtualBox) with all needed libs I get the attached compiling error. Complete log of the build using is appended: ./autogen.sh --prefix=$HOME/install --sysconfdir=/etc POPPLER_LIBS=-L/home/wolf/install/lib POPPLER_CFLAGS=-I/home/wolf/install/include CLIENT_LIBS=-L/home/wolf/install/lib CLIENT_CFLAGS=-I/home/wolf/install/include CAIRO_GL_LIBS=-L/home/wolf/install/lib/cairo CAIRO_GL_CFLAGS=-I/home/wolf/install/include/cairo &>> wayland_build.log ./configure --prefix=$HOME/install --sysconfdir=/etc POPPLER_LIBS=-L/home/wolf/install/lib POPPLER_CFLAGS=-I/home/wolf/install/include CLIENT_LIBS=-L/home/wolf/install/lib CLIENT_CFLAGS=-I/home/wolf/install/include CAIRO_GL_LIBS=-L/home/wolf/install/lib/cairo CAIRO_GL_CFLAGS=-I/home/wolf/install/include/cairo &>> wayland_build.log make &>> wayland_build.log -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wayland_build.txt URL: -------------- next part -------------- Best regards WSK From bryce at canonical.com Tue Nov 23 09:55:56 2010 From: bryce at canonical.com (Bryce Harrington) Date: Tue, 23 Nov 2010 09:55:56 -0800 Subject: Bug report In-Reply-To: <9B444B0F-BA77-4F47-9087-9B5C926A63E8@gmx.de> References: <9B444B0F-BA77-4F47-9087-9B5C926A63E8@gmx.de> Message-ID: <20101123175556.GB10542@bryceharrington.org> You need to build and install cairo from git as well, with GL enabled. I don't see in your logs whether you did that or not, but it's not finding the cairo.h header. You probably should use Darxus' build script, which takes care of all the dependencies and so on, without disrupting your system installation. On Tue, Nov 23, 2010 at 01:17:38PM +0100, Wolf Stephan Kappesser wrote: > Hello, > > while building wayland on Ubuntu 10.10 x64 (under OSX 10.6 with VirtualBox) with all needed libs I get the attached compiling error. > > Complete log of the build using is appended: > ./autogen.sh --prefix=$HOME/install --sysconfdir=/etc POPPLER_LIBS=-L/home/wolf/install/lib POPPLER_CFLAGS=-I/home/wolf/install/include CLIENT_LIBS=-L/home/wolf/install/lib CLIENT_CFLAGS=-I/home/wolf/install/include CAIRO_GL_LIBS=-L/home/wolf/install/lib/cairo CAIRO_GL_CFLAGS=-I/home/wolf/install/include/cairo &>> wayland_build.log > > ./configure --prefix=$HOME/install --sysconfdir=/etc POPPLER_LIBS=-L/home/wolf/install/lib POPPLER_CFLAGS=-I/home/wolf/install/include CLIENT_LIBS=-L/home/wolf/install/lib CLIENT_CFLAGS=-I/home/wolf/install/include CAIRO_GL_LIBS=-L/home/wolf/install/lib/cairo CAIRO_GL_CFLAGS=-I/home/wolf/install/include/cairo &>> wayland_build.log > > make &>> wayland_build.log > > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal --force -I m4 ${ACLOCAL_FLAGS} > configure.ac:2: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=wayland > autoreconf: configure.ac: tracing > configure.ac:2: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=wayland > autoreconf: running: libtoolize --install --copy --force > libtoolize: putting auxiliary files in `.'. > libtoolize: copying file `./config.guess' > libtoolize: copying file `./config.sub' > libtoolize: copying file `./install-sh' > libtoolize: copying file `./ltmain.sh' > libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. > libtoolize: copying file `m4/libtool.m4' > libtoolize: copying file `m4/ltoptions.m4' > libtoolize: copying file `m4/ltsugar.m4' > libtoolize: copying file `m4/ltversion.m4' > libtoolize: copying file `m4/lt~obsolete.m4' > configure.ac:2: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=wayland > autoreconf: running: /usr/bin/autoconf --force > configure.ac:2: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=wayland > autoreconf: running: /usr/bin/autoheader --force > configure.ac:2: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=wayland > autoreconf: running: automake --add-missing --copy --force-missing > configure.ac:2: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=wayland > autoreconf: Leaving directory `.' > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... no > checking for mawk... mawk > checking whether make sets $(MAKE)... yes > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for style of include used by make... GNU > checking dependency style of gcc... gcc3 > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking for a sed that does not truncate output... /bin/sed > checking for grep that handles long lines and -e... /bin/grep > checking for egrep... /bin/grep -E > checking for fgrep... /bin/grep -F > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B > checking the name lister (/usr/bin/nm -B) interface... BSD nm > checking whether ln -s works... yes > checking the maximum length of command line arguments... 1572864 > checking whether the shell understands some XSI constructs... yes > checking whether the shell understands "+="... yes > checking for /usr/bin/ld option to reload object files... -r > checking for objdump... objdump > checking how to recognize dependent libraries... pass_all > checking for ar... ar > checking for strip... strip > checking for ranlib... ranlib > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking for dlfcn.h... yes > checking for objdir... .libs > checking if gcc supports -fno-rtti -fno-exceptions... no > checking for gcc option to produce PIC... -fPIC -DPIC > checking if gcc PIC flag -fPIC -DPIC works... yes > checking if gcc static flag -static works... yes > checking if gcc supports -c -o file.o... yes > checking if gcc supports -c -o file.o... (cached) yes > checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... yes > checking for pkg-config... /usr/bin/pkg-config > checking pkg-config is at least version 0.9.0... yes > checking for FFI... yes > checking for COMPOSITOR... yes > checking for CLIENT... yes > checking for POPPLER... yes > checking for CAIRO_GL... yes > checking expat.h usability... yes > checking expat.h presence... yes > checking for expat.h... yes > checking for XML_ParserCreate in -lexpat... yes > checking for xcb_dri2_connect_alignment_pad in -lxcb-dri2... no > configure: creating ./config.status > config.status: creating wayland/wayland-server.pc > config.status: creating wayland/wayland-client.pc > config.status: creating Makefile > config.status: creating wayland/Makefile > config.status: creating compositor/Makefile > config.status: creating clients/Makefile > config.status: creating data/Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > config.status: executing libtool commands > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... no > checking for mawk... mawk > checking whether make sets $(MAKE)... yes > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for style of include used by make... GNU > checking dependency style of gcc... gcc3 > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking for a sed that does not truncate output... /bin/sed > checking for grep that handles long lines and -e... /bin/grep > checking for egrep... /bin/grep -E > checking for fgrep... /bin/grep -F > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B > checking the name lister (/usr/bin/nm -B) interface... BSD nm > checking whether ln -s works... yes > checking the maximum length of command line arguments... 1572864 > checking whether the shell understands some XSI constructs... yes > checking whether the shell understands "+="... yes > checking for /usr/bin/ld option to reload object files... -r > checking for objdump... objdump > checking how to recognize dependent libraries... pass_all > checking for ar... ar > checking for strip... strip > checking for ranlib... ranlib > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking for dlfcn.h... yes > checking for objdir... .libs > checking if gcc supports -fno-rtti -fno-exceptions... no > checking for gcc option to produce PIC... -fPIC -DPIC > checking if gcc PIC flag -fPIC -DPIC works... yes > checking if gcc static flag -static works... yes > checking if gcc supports -c -o file.o... yes > checking if gcc supports -c -o file.o... (cached) yes > checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... yes > checking for pkg-config... /usr/bin/pkg-config > checking pkg-config is at least version 0.9.0... yes > checking for FFI... yes > checking for COMPOSITOR... yes > checking for CLIENT... yes > checking for POPPLER... yes > checking for CAIRO_GL... yes > checking expat.h usability... yes > checking expat.h presence... yes > checking for expat.h... yes > checking for XML_ParserCreate in -lexpat... yes > checking for xcb_dri2_connect_alignment_pad in -lxcb-dri2... no > configure: creating ./config.status > config.status: creating wayland/wayland-server.pc > config.status: creating wayland/wayland-client.pc > config.status: creating Makefile > config.status: creating wayland/Makefile > config.status: creating compositor/Makefile > config.status: creating clients/Makefile > config.status: creating data/Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > config.status: executing libtool commands > make all-recursive > make[1]: Betrete Verzeichnis '/home/wolf/wayland' > Making all in wayland > make[2]: Betrete Verzeichnis '/home/wolf/wayland/wayland' > make all-am > make[3]: Betrete Verzeichnis '/home/wolf/wayland/wayland' > make[3]: F??r das Ziel ??all-am?? ist nichts zu tun. > make[3]: Verlasse Verzeichnis '/home/wolf/wayland/wayland' > make[2]: Verlasse Verzeichnis '/home/wolf/wayland/wayland' > Making all in compositor > make[2]: Betrete Verzeichnis '/home/wolf/wayland/compositor' > make all-am > make[3]: Betrete Verzeichnis '/home/wolf/wayland/compositor' > make[3]: F??r das Ziel ??all-am?? ist nichts zu tun. > make[3]: Verlasse Verzeichnis '/home/wolf/wayland/compositor' > make[2]: Verlasse Verzeichnis '/home/wolf/wayland/compositor' > Making all in clients > make[2]: Betrete Verzeichnis '/home/wolf/wayland/clients' > make all-am > make[3]: Betrete Verzeichnis '/home/wolf/wayland/clients' > CC window.lo > window.c:33: fatal error: cairo.h: No such file or directory > compilation terminated. > make[3]: *** [window.lo] Fehler 1 > make[3]: Verlasse Verzeichnis '/home/wolf/wayland/clients' > make[2]: *** [all] Fehler 2 > make[2]: Verlasse Verzeichnis '/home/wolf/wayland/clients' > make[1]: *** [all-recursive] Fehler 1 > make[1]: Verlasse Verzeichnis '/home/wolf/wayland' > make: *** [all] Fehler 2 > > > > Best regards > WSK > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel From dana at orodu.net Tue Nov 23 14:11:44 2010 From: dana at orodu.net (Dana Jansens) Date: Tue, 23 Nov 2010 17:11:44 -0500 Subject: missing freeing previous data struction when new allocation fails In-Reply-To: References: Message-ID: 2010/11/23 ??? : > I think the best way is borrowing constructor and destructor concepts from > C++. For each internal data structure foo, maintain a foo_create function as > the constructor(many data structures are already done), and a foo_destroy > function as the destructor. Then we avoid duplicate and complicate clean > work at each failure exit in foo_create. In my own experience, using an unref() (and ref()) - ie. reference counting - for all objects, rather than a destroy(), always pays off. - Dana > 2010/11/23 Kristian H?gsberg >> >> On Wed, Nov 17, 2010 at 10:16 PM, ??? wrote: >> > The scenario is: >> > struct A *foo() >> > { >> > ??? A *a; >> > >> > ??? a = malloc(sizeof(A)); >> > ??? if (a == NULL) >> > ??????? return NULL; >> > >> > ??? a->b = malloc(sizeof(B)); >> > ??? if (a->b == NULL) >> > ??????? return NULL; >> > >> > ??? return a; >> > } >> >> You're right, there's a bunch of those in the code. ?Could you please >> create your patches by committing the changes and then either attach >> the output of git format-patch -1 (where -1 means "one commit", use >> whatever number of patches you have) or even better use git send-email >> -1 --to=wayland-devel at lists.freedesktop.org. >> >> Thanks, >> Kristian > > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > From joel at teichroeb.net Tue Nov 23 14:56:26 2010 From: joel at teichroeb.net (Joel Teichroeb) Date: Tue, 23 Nov 2010 14:56:26 -0800 Subject: [PATCH] Fix potentially undefined behavior Message-ID: --- wayland/wayland-util.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/wayland/wayland-util.h b/wayland/wayland-util.h index 575e657..dcda75b 100644 --- a/wayland/wayland-util.h +++ b/wayland/wayland-util.h @@ -94,11 +94,13 @@ int wl_list_empty(struct wl_list *list); ((char *)&(sample)->member - (char *)(sample))) #define wl_list_for_each(pos, head, member) \ + pos = 0; \ for (pos = __container_of((head)->next, pos, member); \ &pos->member != (head); \ pos = __container_of(pos->member.next, pos, member)) #define wl_list_for_each_safe(pos, tmp, head, member) \ + pos = 0; \ for (pos = __container_of((head)->next, pos, member), \ tmp = __container_of((pos)->member.next, tmp, member); \ &pos->member != (head); \ @@ -106,6 +108,7 @@ int wl_list_empty(struct wl_list *list); tmp = __container_of(pos->member.next, tmp, member)) #define wl_list_for_each_reverse(pos, head, member) \ + pos = 0; \ for (pos = __container_of((head)->prev, pos, member); \ &pos->member != (head); \ pos = __container_of(pos->member.prev, pos, member)) -- 1.7.3.2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bluescreen_avenger at verizon.net Tue Nov 23 15:44:24 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Tue, 23 Nov 2010 18:44:24 -0500 Subject: Using the Wayland port of QT In-Reply-To: <20101121235214.GA11570@chaosreigns.com> References: <201011211226.44496.bluescreen_avenger@verizon.net> <20101121235214.GA11570@chaosreigns.com> Message-ID: <201011231844.24800.bluescreen_avenger@verizon.net> On Sunday, November 21, 2010 06:52:14 pm Darxus at chaosreigns.com wrote: > I spent a lot of time today trying to get this to work under ubuntu, with > input from Benjamin Franzke in the IRC channel. > > I was not successful. > > On 11/21, Benjamin Franzke wrote: > > http://git.overlays.gentoo.org/gitweb/?p=user/benf.git;a=blob;f=x11-libs/ > > qt-wayland/files/config-test-wayland.patch > > That doesn't work, apparently due to hardcoding the path to drm.h instead > of using the version from the defined library path. > > On 11/21, Benjamin Franzke wrote: > > 2010/11/21 Benjamin Franzke : > > > I've also created a merge request for that stuff now, so you could > > > also use that: > > > http://qt.gitorious.org/~krh/qt/qt-wayland/merge_requests/1 > > > > oh I forgot to say the merge request needs the scanner PATCH i posted > > earlier.. so you should use the first patch for now > > The scanner patch (for wayland, not qt) is: > http://lists.freedesktop.org/archives/wayland-devel/2010-November/000222.ht > ml > > These two patches together (one for qt, one for wayland) result in a > segfault. > > < Darxus> $ examples/widgets/analogclock/analogclock -platform wayland > < Darxus> Segmentation fault > < bnf> Darxus: had that too... only doing a clean rebuild helped me > < Darxus> bnf: Rebuild of what? > < bnf> Darxus: qt (yes it sucks) > > I rebuilt wayland and qt (after "git reset --hard && git clean -x -f" in > both), and got the segfault again. > > > A script of what I did (applying the qt-wayland merge request, and the > scanner patch for wayland): > http://www.chaosreigns.com/wayland/wayland-qt-build.sh > > You'll probably need some more stuff built from git which is done by my > ubuntu build script. > > > Some useful Qt build debugging stuff: > > 03:39PM < Darxus> Failed to load platform plugin "wayland". Available > platforms are: 03:39PM < Darxus> Minimal > 03:40PM < bnf> Darxus: search for qwayland.so > 03:40PM < bnf> *libqwayland.so > 03:41PM < Darxus> No libqwayland.so. > 03:42PM < bnf> go to config.tests/qpa/wayland/ > 03:42PM < bnf> ist there a file "wayland"? > 03:42PM < Darxus> No. Just Makefile wayland.cpp wayland.pro > 03:43PM < bnf> qmake wayland.pro && make wayland > 03:45PM < Darxus> wayland.cpp:2: fatal error: wayland-client.h: No such > file or directory 03:45PM < Darxus> $ export | grep INCL > 03:45PM < Darxus> declare -x C_INCLUDE_PATH="/home/darxus/install/include" > 03:46PM < Darxus> $ ls -l /home/darxus/install/include/wayland-client.h > 03:46PM < Darxus> -rw-r--r-- 1 darxus darxus 2907 2010-11-20 22:53 > /home/darxus/install/include/wayland-client.h 03:46PM < bnf> Darxus: oh > maybe you need CPLUS_INCLUDE_PATH? > 03:48PM < Darxus> Yup, that did it, thanks. > > 04:17PM < Darxus> In file included from > /home/darxus/install/include/xf86drm.h:40, from > qwaylandintegration.cpp:20: 04:17PM < Darxus> > /usr/include/libdrm/drm.h:376: error: expected unqualified-id before > ?virtual? 04:17PM < bnf> Darxus: update you libdrm > 04:18PM < Darxus> bnf: from git://anongit.freedesktop.org/git/mesa/drm ? > 04:19PM < Darxus> $ git pull > 04:19PM < Darxus> Already up-to-date. > 04:21PM < bnf> Darxus: /usr/include/libdrm/drm.h is used thats a problem of > the first patch.. > > This is the problem with hardcoding the path to drm.h, which is fixed by > http://qt.gitorious.org/~krh/qt/qt-wayland/merge_requests/1 Hi. I got it to build and work under Kubuntu Natty, I don't know how your system is configured, or that much about compiling things, but from the looks of it here is what I did different: I did not use the merge request (as I did know how to apply it) But I did use the patch. I only used the development packages that come installed by defualt in Kubuntu, and the ones I needed to use to build Wayland Cairo Mese and some xproto stuff. I was using kubuntu natty, maybe there is a version differance, or some dependancy already installed with Kubuntu. And be careful, I did not do this on a production install, but the install now causes KDE apps to fail to load, so be careful. I hope this helps a little bit. I noticed that only ./bin/qtdemo works, others say symbol lookup error: /usr/lib/egl/egl_dri2.so: undefined symbol: _glapi_get_proc_address From benjaminfranzke at googlemail.com Tue Nov 23 15:50:35 2010 From: benjaminfranzke at googlemail.com (Benjamin Franzke) Date: Wed, 24 Nov 2010 00:50:35 +0100 Subject: Using the Wayland port of QT In-Reply-To: <201011231844.24800.bluescreen_avenger@verizon.net> References: <201011211226.44496.bluescreen_avenger@verizon.net> <20101121235214.GA11570@chaosreigns.com> <201011231844.24800.bluescreen_avenger@verizon.net> Message-ID: Just for further reference: all these patches listed here are not needed any longer, the stuff is in the repos now. 2010/11/24 nerdopolis : > On Sunday, November 21, 2010 06:52:14 pm Darxus at chaosreigns.com wrote: >> I spent a lot of time today trying to get this to work under ubuntu, with >> input from Benjamin Franzke in the IRC channel. >> >> I was not successful. >> >> On 11/21, Benjamin Franzke wrote: >> > http://git.overlays.gentoo.org/gitweb/?p=user/benf.git;a=blob;f=x11-libs/ >> > qt-wayland/files/config-test-wayland.patch >> >> That doesn't work, apparently due to hardcoding the path to drm.h instead >> of using the version from the defined library path. >> >> On 11/21, Benjamin Franzke wrote: >> > 2010/11/21 Benjamin Franzke : >> > > I've also created a merge request for that stuff now, so you could >> > > also use that: >> > > http://qt.gitorious.org/~krh/qt/qt-wayland/merge_requests/1 >> > >> > oh I forgot to say the merge request needs the scanner PATCH i posted >> > earlier.. so you should use the first patch for now >> >> The scanner patch (for wayland, not qt) is: >> http://lists.freedesktop.org/archives/wayland-devel/2010-November/000222.ht >> ml >> >> These two patches together (one for qt, one for wayland) result in a >> segfault. >> >> < Darxus> $ examples/widgets/analogclock/analogclock -platform wayland >> < Darxus> Segmentation fault >> < bnf> Darxus: had that too... ?only doing a clean rebuild helped me >> < Darxus> bnf: Rebuild of what? >> < bnf> Darxus: qt (yes it sucks) >> >> I rebuilt wayland and qt (after "git reset --hard && git clean -x -f" in >> both), and got the segfault again. >> >> >> A script of what I did (applying the qt-wayland merge request, and the >> scanner patch for wayland): >> http://www.chaosreigns.com/wayland/wayland-qt-build.sh >> >> You'll probably need some more stuff built from git which is done by my >> ubuntu build script. >> >> >> Some useful Qt build debugging stuff: >> >> 03:39PM < Darxus> Failed to load platform plugin "wayland". Available >> platforms are: 03:39PM < Darxus> Minimal >> 03:40PM < bnf> Darxus: search for qwayland.so >> 03:40PM < bnf> *libqwayland.so >> 03:41PM < Darxus> No libqwayland.so. >> 03:42PM < bnf> go to config.tests/qpa/wayland/ >> 03:42PM < bnf> ist there a file "wayland"? >> 03:42PM < Darxus> No. ?Just Makefile ?wayland.cpp ?wayland.pro >> 03:43PM < bnf> qmake wayland.pro && make wayland >> 03:45PM < Darxus> wayland.cpp:2: fatal error: wayland-client.h: No such >> file or directory 03:45PM < Darxus> $ export | grep INCL >> 03:45PM < Darxus> declare -x C_INCLUDE_PATH="/home/darxus/install/include" >> 03:46PM < Darxus> $ ls -l /home/darxus/install/include/wayland-client.h >> 03:46PM < Darxus> -rw-r--r-- 1 darxus darxus 2907 2010-11-20 22:53 >> /home/darxus/install/include/wayland-client.h 03:46PM < bnf> Darxus: oh >> maybe you need CPLUS_INCLUDE_PATH? >> 03:48PM < Darxus> Yup, that did it, thanks. >> >> 04:17PM < Darxus> In file included from >> /home/darxus/install/include/xf86drm.h:40, from >> qwaylandintegration.cpp:20: 04:17PM < Darxus> >> /usr/include/libdrm/drm.h:376: error: expected unqualified-id before >> ?virtual? 04:17PM < bnf> Darxus: update you libdrm >> 04:18PM < Darxus> bnf: from git://anongit.freedesktop.org/git/mesa/drm ? >> 04:19PM < Darxus> $ git pull >> 04:19PM < Darxus> Already up-to-date. >> 04:21PM < bnf> Darxus: /usr/include/libdrm/drm.h is used thats a problem of >> the first patch.. >> >> This is the problem with hardcoding the path to drm.h, which is fixed by >> http://qt.gitorious.org/~krh/qt/qt-wayland/merge_requests/1 > > > Hi. > I got it to build and work under Kubuntu Natty, I don't know how your system > is configured, or that much about compiling things, but from the looks of it > here is what I did different: I did not use the merge request (as I did know > how to apply it) But I did use the patch. I only used the development packages > that come installed by defualt in Kubuntu, and the ones I needed to use to > build Wayland Cairo Mese and some xproto stuff. I was using kubuntu natty, > maybe there is a version differance, or some dependancy already installed with > Kubuntu. > > And be careful, I did not do this on a production install, but the install now > causes KDE apps to fail to load, so be careful. > > I hope this helps a little bit. > > I noticed that only ./bin/qtdemo works, others say symbol lookup error: > /usr/lib/egl/egl_dri2.so: undefined symbol: _glapi_get_proc_address > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From joel at teichroeb.net Tue Nov 23 16:17:13 2010 From: joel at teichroeb.net (Joel Teichroeb) Date: Tue, 23 Nov 2010 16:17:13 -0800 Subject: [PATCH] Fix potentially undefined behavior Message-ID: This patch is also needed. --- wayland/wayland-util.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/wayland/wayland-util.h b/wayland/wayland-util.h index dcda75b..2675c7a 100644 --- a/wayland/wayland-util.h +++ b/wayland/wayland-util.h @@ -101,6 +101,7 @@ int wl_list_empty(struct wl_list *list); #define wl_list_for_each_safe(pos, tmp, head, member) \ pos = 0; \ + tmp = 0; \ for (pos = __container_of((head)->next, pos, member), \ tmp = __container_of((pos)->member.next, tmp, member); \ &pos->member != (head); \ -- 1.7.3.2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel at teichroeb.net Tue Nov 23 18:01:40 2010 From: joel at teichroeb.net (Joel Teichroeb) Date: Tue, 23 Nov 2010 18:01:40 -0800 Subject: [PATCH] Fix potentially undefined behavior Message-ID: Really this time. --- wayland/wayland-util.h | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/wayland/wayland-util.h b/wayland/wayland-util.h index 575e657..ebac305 100644 --- a/wayland/wayland-util.h +++ b/wayland/wayland-util.h @@ -94,19 +94,20 @@ int wl_list_empty(struct wl_list *list); ((char *)&(sample)->member - (char *)(sample))) #define wl_list_for_each(pos, head, member) \ - for (pos = __container_of((head)->next, pos, member); \ + for (pos = 0, pos = __container_of((head)->next, pos, member); \ &pos->member != (head); \ pos = __container_of(pos->member.next, pos, member)) #define wl_list_for_each_safe(pos, tmp, head, member) \ - for (pos = __container_of((head)->next, pos, member), \ + for (pos = 0, tmp = 0, \ + pos = __container_of((head)->next, pos, member), \ tmp = __container_of((pos)->member.next, tmp, member); \ &pos->member != (head); \ pos = tmp, \ tmp = __container_of(pos->member.next, tmp, member)) #define wl_list_for_each_reverse(pos, head, member) \ - for (pos = __container_of((head)->prev, pos, member); \ + for (pos = 0, pos = __container_of((head)->prev, pos, member); \ &pos->member != (head); \ pos = __container_of(pos->member.prev, pos, member)) -- 1.7.3.2 From Wolf.St.Kappesser at gmx.de Tue Nov 23 18:09:03 2010 From: Wolf.St.Kappesser at gmx.de (Wolf Stephan Kappesser) Date: Wed, 24 Nov 2010 03:09:03 +0100 Subject: Using Wayland on VirtualBox Message-ID: Hello, I am no Linux-nativ so please be patient if it seems trivial: I have successfully build wayland now (thanks to http://lists.freedesktop.org/archives/wayland-devel/2010-November/000121.html ) after upgrading to ubuntu "natty" but get the error #./compositor DRI2: failed to connect, DRI2 version: 0.0 failed to create compositor Could it be a problem with the virtualbox graphics driver and if, there are a solution for to run wayland on VB? Best regards WSK From Darxus at chaosreigns.com Tue Nov 23 18:15:12 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Tue, 23 Nov 2010 21:15:12 -0500 Subject: Using Wayland on VirtualBox In-Reply-To: References: Message-ID: <20101124021512.GB7079@chaosreigns.com> On 11/24, Wolf Stephan Kappesser wrote: > #./compositor > DRI2: failed to connect, DRI2 version: 0.0 > failed to create compositor > > Could it be a problem with the virtualbox graphics driver and if, there are a solution for to run wayland on VB? Yes, you don't have DRI2 support in your X server in virtualbox. I've seen hints that some people have DRI2 working with virtualbox, but I haven't been able to figure out how. If you do, please post. The only possibility I know if is uv's patch to run wayland with a framebuffer (outside of X) instead of with DRM/DRI. -- "Wash daily from nose-tip to tail-tip; drink deeply, but never too deep; And remember the night is for hunting, and forget not the day is for sleep." - The Law of the Jungle, Rudyard Kipling http://www.ChaosReigns.com From linhaoxiang at gmail.com Tue Nov 23 18:44:21 2010 From: linhaoxiang at gmail.com (=?UTF-8?B?5p6X5piK57+U?=) Date: Wed, 24 Nov 2010 10:44:21 +0800 Subject: missing freeing previous data struction when new allocation fails In-Reply-To: References: Message-ID: Lock-free reference counting is hard to be implemented on architectures without double compare-and-swap instruction(one possible solution is binding counter with the pointer). The overhead of reference counting may be significant. Thanks. Haoxiang Lin 2010/11/24 Dana Jansens > 2010/11/23 ??? : > > I think the best way is borrowing constructor and destructor concepts > from > > C++. For each internal data structure foo, maintain a foo_create function > as > > the constructor(many data structures are already done), and a foo_destroy > > function as the destructor. Then we avoid duplicate and complicate clean > > work at each failure exit in foo_create. > > In my own experience, using an unref() (and ref()) - ie. reference > counting - for all objects, rather than a destroy(), always pays off. > > - Dana > > > 2010/11/23 Kristian H?gsberg > >> > >> On Wed, Nov 17, 2010 at 10:16 PM, ??? wrote: > >> > The scenario is: > >> > struct A *foo() > >> > { > >> > A *a; > >> > > >> > a = malloc(sizeof(A)); > >> > if (a == NULL) > >> > return NULL; > >> > > >> > a->b = malloc(sizeof(B)); > >> > if (a->b == NULL) > >> > return NULL; > >> > > >> > return a; > >> > } > >> > >> You're right, there's a bunch of those in the code. Could you please > >> create your patches by committing the changes and then either attach > >> the output of git format-patch -1 (where -1 means "one commit", use > >> whatever number of patches you have) or even better use git send-email > >> -1 --to=wayland-devel at lists.freedesktop.org. > >> > >> Thanks, > >> Kristian > > > > > > _______________________________________________ > > wayland-devel mailing list > > wayland-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martyj19 at comcast.net Wed Nov 24 05:42:31 2010 From: martyj19 at comcast.net (Marty Jack) Date: Wed, 24 Nov 2010 08:42:31 -0500 Subject: Who is working on the non-drawing parts? Message-ID: <4CED1647.9010804@comcast.net> This is all good that the drawing and input event path is cleaned up. I am concerned that will be elegant, and the parts that aren't drawing will be tacked on in a poor way. I would be interested in helping make sure this comes out well. Having worked on LXDE and a potential follow-on for a few years now, I have come away with a very good understanding of all the existing X mechanism. Maybe this is all understood and I simply haven't found where it is written down. I am interested in what will replace things like - ICCCM/EWMH, where a desktop environment can enumerate and control the display clients - the things that root and application window properties are used for under X - some of the things that selections are used for under X (poor man's system-wide lock manager) - DPMS, XRandR, mouse and keyboard properties (the new xset, xinput, and xrandr, if you will) - Accessibility knobs ("AccessX features") - Window states (Iconify, deiconify, "I'm a dock", fullscreen, and such) - Xembed, Xdnd, clipboard replacements that applications are all converted to use And I haven't found a clear explanation of what controls window placement. From krh at bitplanet.net Wed Nov 24 05:53:16 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Wed, 24 Nov 2010 08:53:16 -0500 Subject: [PATCH] Fix potentially undefined behavior In-Reply-To: References: Message-ID: On Tue, Nov 23, 2010 at 9:01 PM, Joel Teichroeb wrote: > Really this time. > --- > ?wayland/wayland-util.h | ? ?7 ++++--- > ?1 files changed, 4 insertions(+), 3 deletions(-) Thanks committed. I added a reference to the llvm bug in the commit message. Kristian > diff --git a/wayland/wayland-util.h b/wayland/wayland-util.h > index 575e657..ebac305 100644 > --- a/wayland/wayland-util.h > +++ b/wayland/wayland-util.h > @@ -94,19 +94,20 @@ int wl_list_empty(struct wl_list *list); > ? ? ? ? ? ? ? ? ((char *)&(sample)->member - (char *)(sample))) > > ?#define wl_list_for_each(pos, head, member) ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > - ? ? ? for (pos = __container_of((head)->next, pos, member); ? ? ? ? ? \ > + ? ? ? for (pos = 0, pos = __container_of((head)->next, pos, member); ?\ > ? ? ? ? ? ? &pos->member != (head); ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > ? ? ? ? ? ? pos = __container_of(pos->member.next, pos, member)) > > ?#define wl_list_for_each_safe(pos, tmp, head, member) ? ? ? ? ? ? ? ? ?\ > - ? ? ? for (pos = __container_of((head)->next, pos, member), ? ? ? ? ? \ > + ? ? ? for (pos = 0, tmp = 0, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > + ? ? ? ? ? ?pos = __container_of((head)->next, pos, member), ? ? ? ? ? \ > ? ? ? ? ? ? tmp = __container_of((pos)->member.next, tmp, member); ? ? \ > ? ? ? ? ? ? &pos->member != (head); ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > ? ? ? ? ? ? pos = tmp, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > ? ? ? ? ? ? tmp = __container_of(pos->member.next, tmp, member)) > > ?#define wl_list_for_each_reverse(pos, head, member) ? ? ? ? ? ? ? ? ? ?\ > - ? ? ? for (pos = __container_of((head)->prev, pos, member); ? ? ? ? ? \ > + ? ? ? for (pos = 0, pos = __container_of((head)->prev, pos, member); ?\ > ? ? ? ? ? ? &pos->member != (head); ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > ? ? ? ? ? ? pos = __container_of(pos->member.prev, pos, member)) > > -- > 1.7.3.2 > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From j.glisse at gmail.com Wed Nov 24 07:38:38 2010 From: j.glisse at gmail.com (Jerome Glisse) Date: Wed, 24 Nov 2010 10:38:38 -0500 Subject: Who is working on the non-drawing parts? In-Reply-To: <4CED1647.9010804@comcast.net> References: <4CED1647.9010804@comcast.net> Message-ID: On Wed, Nov 24, 2010 at 8:42 AM, Marty Jack wrote: > This is all good that the drawing and input event path is cleaned up. ?I am concerned that will be elegant, and the parts that aren't drawing will be tacked on in a poor way. ?I would be interested in helping make sure this comes out well. ?Having worked on LXDE and a potential follow-on for a few years now, I have come away with a very good understanding of all the existing X mechanism. > > Maybe this is all understood and I simply haven't found where it is written down. > > I am interested in what will replace things like > > - ICCCM/EWMH, where a desktop environment can enumerate and control the display clients > - the things that root and application window properties are used for under X > - some of the things that selections are used for under X (poor man's system-wide lock manager) > - Accessibility knobs ("AccessX features") > - Window states (Iconify, deiconify, "I'm a dock", fullscreen, and such) Up to toolkit, wayland is about compositing buffer and sending input. I would advice to leave wayland out of this business and to encourage some common platform on freedesktop for window properties valid accross toolkits (gtk, qt, ...) > - DPMS, XRandR, mouse and keyboard properties (the new xset, xinput, and xrandr, if you will) Not sure about those. Cheers, Jerome From krh at bitplanet.net Wed Nov 24 09:14:51 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Wed, 24 Nov 2010 12:14:51 -0500 Subject: Who is working on the non-drawing parts? In-Reply-To: References: <4CED1647.9010804@comcast.net> Message-ID: On Wed, Nov 24, 2010 at 10:38 AM, Jerome Glisse wrote: > On Wed, Nov 24, 2010 at 8:42 AM, Marty Jack wrote: >> This is all good that the drawing and input event path is cleaned up. ?I am concerned that will be elegant, and the parts that aren't drawing will be tacked on in a poor way. ?I would be interested in helping make sure this comes out well. ?Having worked on LXDE and a potential follow-on for a few years now, I have come away with a very good understanding of all the existing X mechanism. >> >> Maybe this is all understood and I simply haven't found where it is written down. >> >> I am interested in what will replace things like >> >> - ICCCM/EWMH, where a desktop environment can enumerate and control the display clients >> - the things that root and application window properties are used for under X >> - some of the things that selections are used for under X (poor man's system-wide lock manager) >> - Accessibility knobs ("AccessX features") >> - Window states (Iconify, deiconify, "I'm a dock", fullscreen, and such) > > Up to toolkit, wayland is about compositing buffer and sending input. > I would advice to leave wayland out of this business and to encourage > some common platform on freedesktop for window properties valid > accross toolkits (gtk, qt, ...) No, this is actually something Wayland has to handle as well. You can't just implement these protocols in the toolkit if there's nobody to talk to. Wayland combines the display server, the window manager and the compositor in one process and thus, must provide an alternative for the functionality provided by these processes and protocols layered on top of X mechanisms. This means that the Wayland protocol ends up being a mix of (the useful pieces of) X protocol, ICCCM, EWMH, XDnD. It's not something that's going to be tacked on, it's going to be directly supported in the protocol. When you look at ICCCM and EWMH, they base all the protocols and conventions on atoms, window properties and selections. This is the only way it can work, since the window manager is just another client. In Wayland the window manager is the server and it doesn't really make sense to serialize all this meta data into window properties, when you can just define an interface that lets you set the data directly. The Wayland protocol lets you query for extensions similar to how X works, so we can add, extend and phase out extensions over time. So for example, instead of setting the _NET_WM_VISIBLE_NAME property, there will be a protocol request that lets you set this meta data. Right now drag and drop is implemented, I have a good plan for copy and paste. Move and resize works similar to the _NET_WM_MOVERESIZE message. One of the things I'm looking into now is how to translate the different EWMH window types into Wayland terms. One of the challenges in the Wayland protocol is that clients can't specify an absolute position for their window or query the current location of the window. So when showing up a drop-down menu, the application has to specify surface position relative to the menubar window, for pop-up menus, relative to the pointer etc. The current idea is that surface.map(x, y, w, h) is going to be replaced with a number of map requests: surface.map_toplevel() - show a surface as a toplevel window; the compositor picks a location. surface.map_popup(device, dx, dy, flags) - show a surface as a popup menu relative to the devices pointer location; flags specify behavior in case the surface extends beyond screen edges. surface.map_overlay(surface, dx, dy) - map a surface with a static offset relative to a parent surface (drop down menus etc) surface.map_fullscreen() - map a surface fullscreen; the compositor can change resolution to match the surface size if necessary/desired and possibly others. There's a lot of ground to cover there, but it's not as daunting as it may seem. A lot of the more hairy X protocol is only there to make it possible to run a window manager or compositor as an X client, and there a bit of overlap between ICCCM and EMWH. A great contribution would be a writeup that provides an overview of the functionality in the X protocol, ICCCM, EWMH, Xdnd, xsettings specs and then a classification into "not necessary", "already done", "needs wayland support", or "can be done over dbus or such". Kristian From martyj19 at comcast.net Wed Nov 24 10:01:06 2010 From: martyj19 at comcast.net (Marty Jack) Date: Wed, 24 Nov 2010 13:01:06 -0500 Subject: Who is working on the non-drawing parts? In-Reply-To: References: <4CED1647.9010804@comcast.net> Message-ID: <4CED52E2.6080608@comcast.net> Excellent to hear. I support an overall model that carries forward the aspects of X that are still helpful and tosses the rest. Kristian is right, you can't push it to the toolkit. You need something central that has the client database and can update it race condition free. I am prepared to sign up to help out. Give me a few days to understand the protocol spec. I could come up with the other list very quickly based on what I have already working. Two things that come to mind immediately that could stand a complete redesign are the situation with multiple monitors and the situation with multiple desktops. I am sure I will have a few more after I think for a few days. Right now we have a drastically different way of handling monitors connected to different video cards as opposed to several monitors connected to the same video card. One is handled by addressing different screens and the other is handled by partitioning the coordinate space on a single screen. It would be great to have a single model and a single coordinate space that handles everything. Right now we have two drastically different models of multiple desktops. One uses the _NET_DESKTOP_NUMBER to assign windows to desktops and one partitions the coordinate space on a single virtual desktop (VIEWPORT and GEOMETRY). There is a major issue with the single virtual desktop because the reported window coordinates move depending on what the visible part of the virtual desktop is, and you end up having to do headstands and extra round trips to implement the pager. This could be fixed easily if there were only one definition of the coordinate space. I notice you are planning on using the keymapping library, which is good, but the keydefinition compiler is another thing that could stand to be reimplemented from a blank sheet of paper. I will get to that eventually. I only wrote four production quality compilers, so it should be easy if I get to break compatibility on some parts of the language. I don't know how well it will go over to fold the window manager in with the server, given how many different models there are for toplevel window layout (tiling, stacking, and such), and people are fervent about the way that they like. Also, I don't yet fully buy into the part about no client controlled window placement. We need some way for docks to position themselves appropriately. On 11/24/2010 12:14 PM, Kristian H?gsberg wrote: > On Wed, Nov 24, 2010 at 10:38 AM, Jerome Glisse wrote: >> On Wed, Nov 24, 2010 at 8:42 AM, Marty Jack wrote: >>> This is all good that the drawing and input event path is cleaned up. I am concerned that will be elegant, and the parts that aren't drawing will be tacked on in a poor way. I would be interested in helping make sure this comes out well. Having worked on LXDE and a potential follow-on for a few years now, I have come away with a very good understanding of all the existing X mechanism. >>> >>> Maybe this is all understood and I simply haven't found where it is written down. >>> >>> I am interested in what will replace things like >>> >>> - ICCCM/EWMH, where a desktop environment can enumerate and control the display clients >>> - the things that root and application window properties are used for under X >>> - some of the things that selections are used for under X (poor man's system-wide lock manager) >>> - Accessibility knobs ("AccessX features") >>> - Window states (Iconify, deiconify, "I'm a dock", fullscreen, and such) >> >> Up to toolkit, wayland is about compositing buffer and sending input. >> I would advice to leave wayland out of this business and to encourage >> some common platform on freedesktop for window properties valid >> accross toolkits (gtk, qt, ...) > > No, this is actually something Wayland has to handle as well. You > can't just implement these protocols in the toolkit if there's nobody > to talk to. Wayland combines the display server, the window manager > and the compositor in one process and thus, must provide an > alternative for the functionality provided by these processes and > protocols layered on top of X mechanisms. This means that the Wayland > protocol ends up being a mix of (the useful pieces of) X protocol, > ICCCM, EWMH, XDnD. > > It's not something that's going to be tacked on, it's going to be > directly supported in the protocol. When you look at ICCCM and EWMH, > they base all the protocols and conventions on atoms, window > properties and selections. This is the only way it can work, since > the window manager is just another client. In Wayland the window > manager is the server and it doesn't really make sense to serialize > all this meta data into window properties, when you can just define an > interface that lets you set the data directly. The Wayland protocol > lets you query for extensions similar to how X works, so we can add, > extend and phase out extensions over time. So for example, instead of > setting the _NET_WM_VISIBLE_NAME property, there will be a protocol > request that lets you set this meta data. > > Right now drag and drop is implemented, I have a good plan for copy > and paste. Move and resize works similar to the _NET_WM_MOVERESIZE > message. One of the things I'm looking into now is how to translate > the different EWMH window types into Wayland terms. One of the > challenges in the Wayland protocol is that clients can't specify an > absolute position for their window or query the current location of > the window. So when showing up a drop-down menu, the application has > to specify surface position relative to the menubar window, for pop-up > menus, relative to the pointer etc. The current idea is that > surface.map(x, y, w, h) is going to be replaced with a number of map > requests: > > surface.map_toplevel() - show a surface as a toplevel window; the > compositor picks a location. > > surface.map_popup(device, dx, dy, flags) - show a surface as a popup > menu relative to the devices pointer location; flags specify behavior > in case the surface extends beyond screen edges. > > surface.map_overlay(surface, dx, dy) - map a surface with a static > offset relative to a parent surface (drop down menus etc) > > surface.map_fullscreen() - map a surface fullscreen; the compositor > can change resolution to match the surface size if necessary/desired > > and possibly others. > > There's a lot of ground to cover there, but it's not as daunting as it > may seem. A lot of the more hairy X protocol is only there to make it > possible to run a window manager or compositor as an X client, and > there a bit of overlap between ICCCM and EMWH. A great contribution > would be a writeup that provides an overview of the functionality in > the X protocol, ICCCM, EWMH, Xdnd, xsettings specs and then a > classification into "not necessary", "already done", "needs wayland > support", or "can be done over dbus or such". > > Kristian > From jonsmirl at gmail.com Wed Nov 24 10:49:24 2010 From: jonsmirl at gmail.com (jonsmirl at gmail.com) Date: Wed, 24 Nov 2010 13:49:24 -0500 Subject: Who is working on the non-drawing parts? In-Reply-To: <4CED52E2.6080608@comcast.net> References: <4CED1647.9010804@comcast.net> <4CED52E2.6080608@comcast.net> Message-ID: 2010/11/24 Marty Jack : > I notice you are planning on using the keymapping library, which is good, but the keydefinition compiler is another thing that could stand to be reimplemented from a blank sheet of paper. ?I will get to that eventually. ?I only wrote four production quality compilers, so it should be easy if I get to break compatibility on some parts of the language. > There is an existing problem with multi-media key events being generated in kernel evdev and X not being able to deliver them. Things like those email, chat, etc buttons on your keyboard and IR input generates these events. The X key define is only eight bits and I believe the kernel is up to 517 key defines now. One possible way to handle these keys would be to map them into vendor specific Unicode space. I fully support putting parts of X keyboard support out of its misery. -- Jon Smirl jonsmirl at gmail.com From julien at danjou.info Wed Nov 24 12:15:29 2010 From: julien at danjou.info (Julien Danjou) Date: Wed, 24 Nov 2010 21:15:29 +0100 Subject: Who is working on the non-drawing parts? In-Reply-To: <4CED52E2.6080608@comcast.net> (Marty Jack's message of "Wed, 24 Nov 2010 13:01:06 -0500") References: <4CED1647.9010804@comcast.net> <4CED52E2.6080608@comcast.net> Message-ID: <87sjyq5vha.fsf@keller.adm.naquadah.org> On Wed, Nov 24 2010, Marty Jack wrote: > Two things that come to mind immediately that could stand a complete > redesign are the situation with multiple monitors and the situation with > multiple desktops. I am sure I will have a few more after I think for a few > days. > > Right now we have a drastically different way of handling monitors connected > to different video cards as opposed to several monitors connected to the > same video card. One is handled by addressing different screens and the > other is handled by partitioning the coordinate space on a single screen. It > would be great to have a single model and a single coordinate space that > handles everything. > > Right now we have two drastically different models of multiple desktops. One > uses the _NET_DESKTOP_NUMBER to assign windows to desktops and one > partitions the coordinate space on a single virtual desktop (VIEWPORT and > GEOMETRY). There is a major issue with the single virtual desktop because > the reported window coordinates move depending on what the visible part of > the virtual desktop is, and you end up having to do headstands and extra > round trips to implement the pager. This could be fixed easily if there were > only one definition of the coordinate space. Please, refrain to implement such ugly things in Wayland all over again. Writing such concepts like "desktop handling" in the core like it has been done with EWMH is a *VERY* bad idea. For example, several X window managers are now using so-called "tags" instead of desktop. This can be compared with a desktop implementation where several desktop could be viewed at the same time. This is NOT compatible with EWMH since the beginning, and always causing trouble to many application which cannot know they are on multiple desktop due to the narrow-minded design of EWMH. The same things happens for window manager handling a set of desktop (or tags) on each physical screen connected to the X server. This is *impossible* to do with EWMH. We even had to *remove* some EWMH support in "awesome" (a window manager), because some application were abusing the spec to change desktop, like OpenOffice. I beg you to not do the same mistakes that have been done years ago. Providing communication means and mechanisms is OK, but do not write in marble how a desktop should be implemented. -- Julien Danjou // ? http://julien.danjou.info -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bluescreen_avenger at verizon.net Wed Nov 24 16:51:21 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Wed, 24 Nov 2010 19:51:21 -0500 Subject: Multiple Wayland Servers Message-ID: <201011241951.21993.bluescreen_avenger@verizon.net> Hi. Just a quick quseion is how are Wayland servers identified? In X we have the DISPLAY identifier, can be specified by an environment variable, or argument. How is it going to specified in Wayland? Also, what will replace xhost? its prevent one user from running an app in another users server to take a screenshot, or capture key codes, and at the same time allow wanted user accounts, like a deamon or something display stuff on the screen. From bluescreen_avenger at verizon.net Wed Nov 24 18:16:22 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Wed, 24 Nov 2010 21:16:22 -0500 Subject: Multiple Wayland Servers In-Reply-To: References: <201011241951.21993.bluescreen_avenger@verizon.net> Message-ID: <201011242116.22417.bluescreen_avenger@verizon.net> On Wednesday, November 24, 2010 09:04:51 pm microcai wrote: > What ever it is , DISPLAY seems still be the best option ..... ^_^ > xhost is useless , Wayland only works locally. > > 2010/11/25 nerdopolis : > > Hi. > > > > Just a quick quseion is how are Wayland servers identified? > > > > In X we have the DISPLAY identifier, can be specified by an environment > > variable, or argument. > > > > How is it going to specified in Wayland? > > > > Also, what will replace xhost? its prevent one user from running an app > > in another users server to take a screenshot, or capture key codes, and > > at the same time allow wanted user accounts, like a deamon or something > > display stuff on the screen. > > _______________________________________________ > > wayland-devel mailing list > > wayland-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel But DISPLAY is already used by X... If we are going to be using X clients with Wayland, then there might be problems... Also display can also be something like 192.168.1.1:9, using a remote display :9 on 192.168.1.1... I don't know how Wayland would react if that was the display... If its supported, Wayland probably would need to invent a new variable... And as far as xhost goes, I know that Wayland is local only, but I guess I was asking more about Wayland security in multiuser environments using the switch user feature, and how to prevent authenticated users from spying on each others Wayland sessions. From microcai at fedoraproject.org Wed Nov 24 18:28:40 2010 From: microcai at fedoraproject.org (microcai) Date: Thu, 25 Nov 2010 10:28:40 +0800 Subject: Multiple Wayland Servers In-Reply-To: <201011242116.22417.bluescreen_avenger@verizon.net> References: <201011241951.21993.bluescreen_avenger@verizon.net> <201011242116.22417.bluescreen_avenger@verizon.net> Message-ID: > Wayland, then there might be problems... Also display can also be something > like 192.168.1.1:9, using a remote display :9 on 192.168.1.1... I don't know > how Wayland would react if that was the display... If its supported, Wayland > probably would need to invent a new variable... > > And as far as xhost goes, I know that Wayland is local only, but I guess I was > asking more about Wayland security in multiuser environments using the switch > user feature, and how to prevent authenticated users from spying on each > others Wayland sessions. > They won't . Wayland uses UNIX socket, you can set file permission on it. From boulabiar at gmail.com Wed Nov 24 18:55:47 2010 From: boulabiar at gmail.com (Mohamed Ikbel Boulabiar) Date: Thu, 25 Nov 2010 03:55:47 +0100 Subject: Who is working on the non-drawing parts? In-Reply-To: <4CED52E2.6080608@comcast.net> References: <4CED1647.9010804@comcast.net> <4CED52E2.6080608@comcast.net> Message-ID: 2010/11/24 Marty Jack : > I notice you are planning on using the keymapping library, which is good, but the keydefinition compiler is another thing that could stand to be reimplemented from a blank sheet of paper. ?I will get to that eventually. ?I only wrote four production quality compilers, so it should be easy if I get to break compatibility on some parts of the language. All the input should be reimplemented from a blank sheet of paper. X is considering every input as "a some sort" of keyboard+mouse and this needs to change. multimedia key are just a small part of the problem, sensors are just input devices, many other input devices are arriving (like the kinect for example, it would be possible to attach some code blocks to read the bare stream and generate whatever events, etc). Multi-touch Gestures are a form of a computed input from multi-touch events. Better to consider the input in a more generalized and not design everything as to be used only for keyboard/mouse only. I think there is a need to be able to easily: 1. Add "filtering" blocks to input from the kernel which may come from multiple sources. 2. Map them to whatever virtual input device seen by applications. (usual apps see the keyboard/mouse, new advanced apps can see and use others devices) I imagine these 2 points supported by a sub layer/library of input which wayland can use. I really wish to hear some feedback/brainstorming for the handling of input. i From mcpoet.marro at gmail.com Wed Nov 24 18:57:02 2010 From: mcpoet.marro at gmail.com (mcpoet) Date: Thu, 25 Nov 2010 10:57:02 +0800 Subject: comparison statics Message-ID: <5A65362F-3AD8-498A-A627-EC573EFE8752@gmail.com> Hi all : I just new to Wayland and I 'm wondering is there any performance statics or benchmarks comparison between the Wayland server and X-server ? Thanks a lot . From joel at teichroeb.net Wed Nov 24 19:15:16 2010 From: joel at teichroeb.net (Joel Teichroeb) Date: Wed, 24 Nov 2010 19:15:16 -0800 Subject: Multiple Wayland Servers In-Reply-To: <201011241951.21993.bluescreen_avenger@verizon.net> References: <201011241951.21993.bluescreen_avenger@verizon.net> Message-ID: <4CEDD4C4.4070502@teichroeb.net> On 11/24/2010 04:51 PM, nerdopolis wrote: > Hi. > > Just a quick quseion is how are Wayland servers identified? > > In X we have the DISPLAY identifier, can be specified by an environment > variable, or argument. > > How is it going to specified in Wayland? > > Also, what will replace xhost? its prevent one user from running an app in > another users server to take a screenshot, or capture key codes, and at the > same time allow wanted user accounts, like a deamon or something display stuff > on the screen. > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel compositor.c:1438 /* The plan here is to generate a random anonymous socket name and * advertise that through a service on the session dbus. */ static const char socket_name[] = "\0wayland"; I am not sure how this will work for running multiple Wayland servers at the same time though. It is possible though https://dl.dropbox.com/u/820737/MultipleCompositors.png From mcpoet.marro at gmail.com Wed Nov 24 19:33:56 2010 From: mcpoet.marro at gmail.com (mcpoet) Date: Thu, 25 Nov 2010 11:33:56 +0800 Subject: comparison statics In-Reply-To: References: <5A65362F-3AD8-498A-A627-EC573EFE8752@gmail.com> Message-ID: sure , I know that's a killing feature . But actually I'm planning to port Wayland to some architecture which doesn't have GPU and OpenGL support . So , when both sides are living on the cpu , which is better ? ? 2010-11-25???11:27? microcai ??? > Wayland is 100x faster than X ..... > Because Wayland is base on OpenGL, every thing is done by GPU ... > > ^_^ > > 2010/11/25 mcpoet : >> Hi all : >> I just new to Wayland and I 'm wondering is there any performance statics or benchmarks >> comparison between the Wayland server and X-server ? >> Thanks a lot . >> _______________________________________________ >> wayland-devel mailing list >> wayland-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> From bluescreen_avenger at verizon.net Wed Nov 24 19:56:35 2010 From: bluescreen_avenger at verizon.net (nerdopolis) Date: Wed, 24 Nov 2010 22:56:35 -0500 Subject: Multiple Wayland Servers In-Reply-To: <4CEDD4C4.4070502@teichroeb.net> References: <201011241951.21993.bluescreen_avenger@verizon.net> <4CEDD4C4.4070502@teichroeb.net> Message-ID: <201011242256.35627.bluescreen_avenger@verizon.net> On Wednesday, November 24, 2010 10:15:16 pm you wrote: > On 11/24/2010 04:51 PM, nerdopolis wrote: > > Hi. > > > > Just a quick quseion is how are Wayland servers identified? > > > > In X we have the DISPLAY identifier, can be specified by an environment > > variable, or argument. > > > > How is it going to specified in Wayland? > > > > Also, what will replace xhost? its prevent one user from running an app > > in another users server to take a screenshot, or capture key codes, and > > at the same time allow wanted user accounts, like a deamon or something > > display stuff on the screen. > > _______________________________________________ > > wayland-devel mailing list > > wayland-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > compositor.c:1438 > /* The plan here is to generate a random anonymous socket name and > * advertise that through a service on the session dbus. > */ > static const char socket_name[] = "\0wayland"; > > I am not sure how this will work for running multiple Wayland servers at > the same time though. It is possible though > https://dl.dropbox.com/u/820737/MultipleCompositors.png So if its by a random DBUS token,how would the user tell the app what session to tell the app to connect to if they are using a nested session or something like that? From roffermanns at sysgo.com Thu Nov 25 03:13:30 2010 From: roffermanns at sysgo.com (Rolf Offermanns) Date: Thu, 25 Nov 2010 12:13:30 +0100 Subject: [PATCH] Fix for uninitialized member in QWaylandCursor Message-ID: <20101125111330.GA3343@sysgo.com> Without this patch Qt applications will crash the moment the mouse pointer enters the window. Signed-off-by: Rolf Offermanns --- .../platforms/wayland/qwaylandintegration.cpp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/plugins/platforms/wayland/qwaylandintegration.cpp b/src/plugins/platforms/wayland/qwaylandintegration.cpp index 19f339a..82789c8 100644 --- a/src/plugins/platforms/wayland/qwaylandintegration.cpp +++ b/src/plugins/platforms/wayland/qwaylandintegration.cpp @@ -25,7 +25,7 @@ public: QWaylandCursor(QWaylandDisplay *display, QPlatformScreen *screen) : QPlatformCursor(screen) - , mDisplay(display) { } + , mBuffer(0), mDisplay(display) { } void changeCursor(QCursor *cursor, QWidget *widget); QWaylandShmBuffer *mBuffer; -- 1.7.3.2 From yuvalfl at gmail.com Thu Nov 25 03:48:18 2010 From: yuvalfl at gmail.com (Yuval Fledel) Date: Thu, 25 Nov 2010 13:48:18 +0200 Subject: comparison statics In-Reply-To: References: <5A65362F-3AD8-498A-A627-EC573EFE8752@gmail.com> Message-ID: In the past week I'm trying to make Wayland run on a Linux framebuffer. My first attempt was to use cairo. It was fast. Fast enough to not have shutter when moving the mouse. Darxus published the patches to mailing list the a few days ago. But using cairo would mean a different compositor, as this one is pretty tied to EGL. So I went on to explore OpenGL. Mesa has a fbdev target, which seems like a great match. Now I have the basic Wayland compositor with OpenGL on fbdev (I'm now cleaning up and sending patches). It uses Gallium3D's softpipe, and its slow. I get <1 FPS. It could be that I'm doing something I shouldn't, and I don't really know how to profile it, but it can't be faster than cairo by design. What architecure are you porting it to? -- Yuval 2010/11/25 mcpoet : > sure , I know that's a killing feature . > But actually I'm planning to port Wayland to some architecture which doesn't have GPU and OpenGL support . > So , when both sides are living on the cpu , which is better ? > > ? 2010-11-25???11:27? microcai ??? > >> Wayland is 100x faster than X ..... >> Because Wayland is base on OpenGL, every thing is done by GPU ... >> >> ^_^ >> >> 2010/11/25 mcpoet : >>> Hi all : >>> ? ? ? ?I just new to Wayland and I 'm wondering is there any performance statics or benchmarks >>> comparison between the Wayland server and X-server ? >>> ? ? ? ?Thanks a lot . >>> _______________________________________________ >>> wayland-devel mailing list >>> wayland-devel at lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >>> > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From renaud.hebert at alcatel-lucent.com Thu Nov 25 00:26:30 2010 From: renaud.hebert at alcatel-lucent.com (Renaud Hebert) Date: Thu, 25 Nov 2010 09:26:30 +0100 Subject: Benchmark of Wayland In-Reply-To: References: Message-ID: <4CEE1DB6.7020004@alcatel-lucent.com> > Chris Wilson chris at chris-wilson.co.uk > Sat Nov 13 01:23:04 PST 2010 [cut] > The promise of Wayland is that every pixel is perfect. You shouldn't say this: Wayland is a compositor if the composition involve anything more than simple translation then the font antialiasing won't work as well. (This is not new as this is already the case with Compiz.) So Wayland (as it is now) don't promise pixel perfection! This is not marketing, exagerated claims are a nuisance.. BR, Renaud. From joel at teichroeb.net Thu Nov 25 11:16:52 2010 From: joel at teichroeb.net (Joel Teichroeb) Date: Thu, 25 Nov 2010 11:16:52 -0800 Subject: [WIP PATCH] Make DND actually work. Message-ID: <4CEEB624.7050905@teichroeb.net> This patch makes the flowers actually move and move between windows. There are currently two problems that I know of. When something is dragged, I do not know how to get the final coordinates of it, so I just send (0, 0). When the window is redrawn it gets moved back to the original location, unless it has been resized after it was moved. Any feedback would be appreciated. Thanks, Joel Teichroeb -------------- next part -------------- A non-text attachment was scrubbed... Name: dndenhance.patch Type: text/x-patch Size: 4728 bytes Desc: not available URL: From trick at icculus.org Thu Nov 25 18:43:49 2010 From: trick at icculus.org (Gerry JJ) Date: Fri, 26 Nov 2010 03:43:49 +0100 Subject: Who is working on the non-drawing parts? In-Reply-To: <4CED52E2.6080608@comcast.net> References: <4CED1647.9010804@comcast.net> <4CED52E2.6080608@comcast.net> Message-ID: <20101126034349.5076243e@lighthouse> Den Wed, 24 Nov 2010 13:01:06 -0500 skrev Marty Jack : > Also, I don't yet fully buy > into the part about no client controlled window placement. We need > some way for docks to position themselves appropriately. Client controlled window placement is important. Without it, you can't restore multi-window sessions properly (or even single-window, if position matters), splash screens won't be centered as they should be, dialog boxes will pop up at random positions, and whatever else that wants to put specific windows at specific positions on the screen for other (possibly good) reasons won't work. Some things may have less valid reasons, but that's a tiny issue compared to not being able to do all those things properly under Wayland. (The option of having the window manager choose placement is good, but it should be an option, not a requirement.) -g From benjaminfranzke at googlemail.com Sat Nov 27 10:04:10 2010 From: benjaminfranzke at googlemail.com (Benjamin Franzke) Date: Sat, 27 Nov 2010 19:04:10 +0100 Subject: [PATCH 0/2] Add nested/session-compositor backend Message-ID: <1290881052-19088-1-git-send-email-benjaminfranzke@googlemail.com> This patches add support for a nested compositor as client of X11,DRM-compositor or of course itself. sample textcase: compositor/compositor -b /path/to/your/bg --socket wayland2 & # for testing a smaller compositor is fine WAYLAND_DISPLAY="wayland2" compositor/compositor -g 800x600 & clients/flower & clients/terminal & The support for $WAYLAND_DISPLAY still needs to be added to the clients. Patches: [PATCH 1/2] wl/wayland_client: rename wl_display_create to wl_display_connect [PATCH 2/2] Add wayland backend for compositor (nested) clients/screenshot.c | 2 +- clients/window.c | 2 +- compositor/Makefile.am | 2 + compositor/compositor-wayland.c | 569 +++++++++++++++++++++++++++++++++++++++ compositor/compositor.c | 24 ++- compositor/compositor.h | 3 + wayland/wayland-client.c | 2 +- wayland/wayland-client.h | 2 +- 8 files changed, 596 insertions(+), 10 deletions(-) From benjaminfranzke at googlemail.com Sat Nov 27 10:04:11 2010 From: benjaminfranzke at googlemail.com (Benjamin Franzke) Date: Sat, 27 Nov 2010 19:04:11 +0100 Subject: [PATCH 1/2] wl/wayland_client: rename wl_display_create to wl_display_connect In-Reply-To: <1290881052-19088-1-git-send-email-benjaminfranzke@googlemail.com> References: <1290881052-19088-1-git-send-email-benjaminfranzke@googlemail.com> Message-ID: <1290881052-19088-2-git-send-email-benjaminfranzke@googlemail.com> avoid conflict when using wayland-{server,client} together later to be fixed (not important now): redifinition of WL_DISPLAY_{SYNC,FRAME} in wayland-{server,client}-protocol.h --- clients/screenshot.c | 2 +- clients/window.c | 2 +- wayland/wayland-client.c | 2 +- wayland/wayland-client.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/clients/screenshot.c b/clients/screenshot.c index e9fa5aa..8b7dd8b 100644 --- a/clients/screenshot.c +++ b/clients/screenshot.c @@ -54,7 +54,7 @@ int main(int argc, char *argv[]) GSource *source; struct wl_screenshooter *screenshooter; - display = wl_display_create(socket_name, sizeof socket_name); + display = wl_display_connect(socket_name, sizeof socket_name); if (display == NULL) { fprintf(stderr, "failed to create display: %m\n"); return -1; diff --git a/clients/window.c b/clients/window.c index bc76937..23e975b 100644 --- a/clients/window.c +++ b/clients/window.c @@ -1425,7 +1425,7 @@ display_create(int *argc, char **argv[], const GOptionEntry *option_entries) if (d == NULL) return NULL; - d->display = wl_display_create(socket_name, sizeof socket_name); + d->display = wl_display_connect(socket_name, sizeof socket_name); if (d->display == NULL) { fprintf(stderr, "failed to create display: %m\n"); return NULL; diff --git a/wayland/wayland-client.c b/wayland/wayland-client.c index 9715307..ebc076c 100644 --- a/wayland/wayland-client.c +++ b/wayland/wayland-client.c @@ -337,7 +337,7 @@ static const struct wl_display_listener display_listener = { }; WL_EXPORT struct wl_display * -wl_display_create(const char *name, size_t name_size) +wl_display_connect(const char *name, size_t name_size) { struct wl_display *display; struct sockaddr_un addr; diff --git a/wayland/wayland-client.h b/wayland/wayland-client.h index 4fcb00b..6ebf9ac 100644 --- a/wayland/wayland-client.h +++ b/wayland/wayland-client.h @@ -37,7 +37,7 @@ typedef int (*wl_display_update_func_t)(uint32_t mask, void *data); typedef void (*wl_display_sync_func_t)(void *data); typedef void (*wl_display_frame_func_t)(void *data, uint32_t time); -struct wl_display *wl_display_create(const char *name, size_t name_size); +struct wl_display *wl_display_connect(const char *name, size_t name_size); void wl_display_destroy(struct wl_display *display); int wl_display_get_fd(struct wl_display *display, wl_display_update_func_t update, void *data); -- 1.7.2.2 From benjaminfranzke at googlemail.com Sat Nov 27 10:04:12 2010 From: benjaminfranzke at googlemail.com (Benjamin Franzke) Date: Sat, 27 Nov 2010 19:04:12 +0100 Subject: =?UTF-8?q?=5BPATCH=202/2=5D=20Add=20wayland=20backend=20for=20compositor=20=28nested=29?= In-Reply-To: <1290881052-19088-1-git-send-email-benjaminfranzke@googlemail.com> References: <1290881052-19088-1-git-send-email-benjaminfranzke@googlemail.com> Message-ID: <1290881052-19088-3-git-send-email-benjaminfranzke@googlemail.com> --- compositor/Makefile.am | 2 + compositor/compositor-wayland.c | 569 +++++++++++++++++++++++++++++++++++++++ compositor/compositor.c | 24 ++- compositor/compositor.h | 3 + 4 files changed, 592 insertions(+), 6 deletions(-) create mode 100644 compositor/compositor-wayland.c diff --git a/compositor/Makefile.am b/compositor/Makefile.am index a13e9d9..07d3b61 100644 --- a/compositor/Makefile.am +++ b/compositor/Makefile.am @@ -9,6 +9,7 @@ AM_CPPFLAGS = -DDATADIR='"$(datadir)"' compositor_LDADD = \ $(top_builddir)/wayland/libwayland-server.la \ + $(top_builddir)/wayland/libwayland-client.la \ $(COMPOSITOR_LIBS) compositor_SOURCES = \ @@ -16,6 +17,7 @@ compositor_SOURCES = \ compositor.h \ compositor-drm.c \ compositor-x11.c \ + compositor-wayland.c \ screenshooter.c \ screenshooter-protocol.c \ screenshooter-server-protocol.h \ diff --git a/compositor/compositor-wayland.c b/compositor/compositor-wayland.c new file mode 100644 index 0000000..58d179c --- /dev/null +++ b/compositor/compositor-wayland.c @@ -0,0 +1,569 @@ +/* + * Copyright ? 2010 Benjamin Franzke + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software Foundation, + * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ + +#ifdef HAVE_CONFIG_H +#include +#endif + +#include +#define _GNU_SOURCE +#include +#include +#include +#include +#include +#include + +#include "wayland-client.h" + +#define GL_GLEXT_PROTOTYPES +#define EGL_EGLEXT_PROTOTYPES +#include +#include +#include +#include + +#include "compositor.h" + +struct wayland_compositor { + struct wlsc_compositor base; + + struct { + struct wl_display *display; + struct wl_compositor *compositor; + struct wl_shell *shell; + struct wl_drm *drm; + struct wl_output *output; + + struct { + int32_t x, y, width, height; + } screen_allocation; + + char *device_name; + int authenticated; + + struct wl_event_source *wl_source; + uint32_t event_mask; + } parent; + + EGLDisplay dpy; + EGLContext ctx; + + struct wl_list window_list; + struct wl_list input_list; +}; + +struct wayland_output { + struct wlsc_output base; + + struct { + struct wl_surface *surface; + struct wl_buffer *buffer[2]; + } parent; + EGLImageKHR image[2]; + GLuint rbo[2]; + uint32_t fb_id[2]; + uint32_t current; +}; + +struct wayland_input { + struct wayland_compositor *compositor; + struct wl_input_device *input_device; + struct wl_list link; +}; + +static int +wayland_input_create(struct wayland_compositor *c) +{ + struct wlsc_input_device *input; + + input = malloc(sizeof *input); + if (input == NULL) + return -1; + + memset(input, 0, sizeof *input); + wlsc_input_device_init(input, &c->base); + + c->base.input_device = input; + + return 0; +} + +static int +wayland_compositor_init_egl(struct wayland_compositor *c) +{ + EGLint major, minor; + const char *extensions; + drm_magic_t magic; + int fd; + static const EGLint context_attribs[] = { + EGL_CONTEXT_CLIENT_VERSION, 2, + EGL_NONE + }; + + fd = open(c->parent.device_name, O_RDWR); + if (fd < 0) { + fprintf(stderr, "drm open failed: %m\n"); + return -1; + } + + wlsc_drm_init(&c->base, fd, c->parent.device_name); + + if (drmGetMagic(fd, &magic)) { + fprintf(stderr, "DRI2: failed to get drm magic"); + return -1; + } + + wl_drm_authenticate(c->parent.drm, magic); + wl_display_iterate(c->parent.display, WL_DISPLAY_WRITABLE); + while (!c->parent.authenticated) + wl_display_iterate(c->parent.display, WL_DISPLAY_READABLE); + + c->base.display = eglGetDRMDisplayMESA(fd); + if (c->base.display == NULL) { + fprintf(stderr, "failed to create display\n"); + return -1; + } + + if (!eglInitialize(c->base.display, &major, &minor)) { + fprintf(stderr, "failed to initialize display\n"); + return -1; + } + + extensions = eglQueryString(c->base.display, EGL_EXTENSIONS); + if (!strstr(extensions, "EGL_KHR_surfaceless_opengl")) { + fprintf(stderr, "EGL_KHR_surfaceless_opengl not available\n"); + return -1; + } + + if (!eglBindAPI(EGL_OPENGL_ES_API)) { + fprintf(stderr, "failed to bind EGL_OPENGL_ES_API\n"); + return -1; + } + + c->base.context = eglCreateContext(c->base.display, NULL, + EGL_NO_CONTEXT, context_attribs); + if (c->base.context == NULL) { + fprintf(stderr, "failed to create context\n"); + return -1; + } + + if (!eglMakeCurrent(c->base.display, EGL_NO_SURFACE, + EGL_NO_SURFACE, c->base.context)) { + fprintf(stderr, "failed to make context current\n"); + return -1; + } + + return 0; +} + +static void +wayland_compositor_present(struct wlsc_compositor *base) +{ + struct wayland_compositor *c = (struct wayland_compositor *) base; + struct wayland_output *output; + struct timeval tv; + uint32_t msec; + + glFinish(); + wl_list_for_each(output, &base->output_list, base.link) { + output->current ^= 1; + + glFramebufferRenderbuffer(GL_FRAMEBUFFER, + GL_COLOR_ATTACHMENT0, + GL_RENDERBUFFER, + output->rbo[output->current]); + + wl_surface_attach(output->parent.surface, + output->parent.buffer[output->current ^ 1]); + wl_surface_damage(output->parent.surface, 0, 0, + output->base.width, output->base.height); + } + + + gettimeofday(&tv, NULL); + msec = tv.tv_sec * 1000 + tv.tv_usec / 1000; + wlsc_compositor_finish_frame(&c->base, msec); +} + +static int +wayland_authenticate(struct wlsc_compositor *ec, uint32_t id) +{ + struct wayland_compositor *c = (struct wayland_compositor *) ec; + + wl_drm_authenticate(c->parent.drm, id); + /* FIXME: recv drm_authenticated event from parent? */ + wl_display_iterate(c->parent.display, WL_DISPLAY_WRITABLE); + + return 0; +} + +static int +wayland_compositor_create_output(struct wayland_compositor *c, + int width, int height) +{ + struct wayland_output *output; + struct wl_visual *visual; + int i; + EGLint name, stride, attribs[] = { + EGL_WIDTH, 0, + EGL_HEIGHT, 0, + EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA, + EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA, + EGL_NONE + }; + + output = malloc(sizeof *output); + if (output == NULL) + return -1; + memset(output, 0, sizeof *output); + + wlsc_output_init(&output->base, &c->base, 0, 0, width, height); + output->parent.surface = + wl_compositor_create_surface(c->parent.compositor); + wl_surface_set_user_data(output->parent.surface, output); + + glGenRenderbuffers(2, output->rbo); + visual = wl_display_get_premultiplied_argb_visual(c->parent.display); + for (i = 0; i < 2; i++) { + glBindRenderbuffer(GL_RENDERBUFFER, output->rbo[i]); + + attribs[1] = width; + attribs[3] = height; + output->image[i] = + eglCreateDRMImageMESA(c->base.display, attribs); + glEGLImageTargetRenderbufferStorageOES(GL_RENDERBUFFER, + output->image[i]); + eglExportDRMImageMESA(c->base.display, output->image[i], + &name, NULL, &stride); + output->parent.buffer[i] = + wl_drm_create_buffer(c->parent.drm, name, + width, height, + stride, visual); + } + + output->current = 0; + glFramebufferRenderbuffer(GL_FRAMEBUFFER, + GL_COLOR_ATTACHMENT0, + GL_RENDERBUFFER, + output->rbo[output->current]); + + wl_surface_attach(output->parent.surface, + output->parent.buffer[output->current]); + wl_surface_map(output->parent.surface, + output->base.x, output->base.y, + output->base.width, output->base.height); + + glClearColor(0, 0, 0, 0.5); + + wl_list_insert(c->base.output_list.prev, &output->base.link); + + return 0; +} + +static struct wl_buffer * +create_invisible_pointer(struct wayland_compositor *c) +{ + struct wlsc_drm_buffer *wlsc_buffer; + struct wl_buffer *buffer; + int name, stride; + struct wl_visual *visual; + GLuint texture; + const int width = 1, height = 1; + const GLubyte data[] = { 0, 0, 0, 0 }; + + glGenTextures(1, &texture); + glBindTexture(GL_TEXTURE_2D, texture); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); + + visual = wl_display_get_premultiplied_argb_visual(c->parent.display); + wlsc_buffer = wlsc_drm_buffer_create(&c->base, width, height, visual); + + glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, wlsc_buffer->image); + glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, width, height, + GL_RGBA, GL_UNSIGNED_BYTE, data); + + eglExportDRMImageMESA(c->base.display, wlsc_buffer->image, + &name, NULL, &stride); + + buffer = wl_drm_create_buffer(c->parent.drm, name, + width, height, + stride, visual); + return buffer; +} + +/* Events received from the wayland-server this compositor is client of: */ + +/* parent output interface */ +static void +display_handle_geometry(void *data, + struct wl_output *output, + int32_t width, int32_t height) +{ + struct wayland_compositor *c = data; + + c->parent.screen_allocation.x = 0; + c->parent.screen_allocation.y = 0; + c->parent.screen_allocation.width = width; + c->parent.screen_allocation.height = height; +} + +static const struct wl_output_listener output_listener = { + display_handle_geometry, +}; + +/* parent shell interface */ +static void +handle_configure(void *data, struct wl_shell *shell, + uint32_t time, uint32_t edges, + struct wl_surface *surface, + int32_t x, int32_t y, int32_t width, int32_t height) +{ +#if 0 + struct output *output = wl_surface_get_user_data(surface); + + /* FIXME: add resize? */ +#endif +} + +static const struct wl_shell_listener shell_listener = { + handle_configure, +}; + +/* parent drm interface */ +static void +drm_handle_device(void *data, struct wl_drm *drm, const char *device) +{ + struct wayland_compositor *c = data; + + c->parent.device_name = strdup(device); +} + +static void drm_handle_authenticated(void *data, struct wl_drm *drm) +{ + struct wayland_compositor *c = data; + + c->parent.authenticated = 1; +} + +static const struct wl_drm_listener drm_listener = { + drm_handle_device, + drm_handle_authenticated +}; + +/* parent input interface */ +static void +input_handle_motion(void *data, struct wl_input_device *input_device, + uint32_t time, + int32_t x, int32_t y, int32_t sx, int32_t sy) +{ + struct wayland_input *input = data; + struct wayland_compositor *c = input->compositor; + + notify_motion(c->base.input_device, time, sx, sy); +} + +static void +input_handle_button(void *data, + struct wl_input_device *input_device, + uint32_t time, uint32_t button, uint32_t state) +{ + struct wayland_input *input = data; + struct wayland_compositor *c = input->compositor; + + notify_button(c->base.input_device, time, button, state); +} + +static void +input_handle_key(void *data, struct wl_input_device *input_device, + uint32_t time, uint32_t key, uint32_t state) +{ + struct wayland_input *input = data; + struct wayland_compositor *c = input->compositor; + + notify_key(c->base.input_device, time, key, state); +} + +static void +input_handle_pointer_focus(void *data, + struct wl_input_device *input_device, + uint32_t time, struct wl_surface *surface, + int32_t x, int32_t y, int32_t sx, int32_t sy) +{ + struct wayland_input *input = data; + struct wayland_compositor *c = input->compositor; + static struct wl_buffer *pntr_buffer = NULL; + + if (surface) { + c->base.focus = 1; + /* FIXME: extend protocol to allow hiding the cursor? */ + if (pntr_buffer == NULL) + pntr_buffer = create_invisible_pointer(c); + wl_input_device_attach(input_device, time, pntr_buffer, x, y); + } else { + /* FIXME. hide our own pointer */ + c->base.focus = 0; + } +} + +static void +input_handle_keyboard_focus(void *data, + struct wl_input_device *input_device, + uint32_t time, + struct wl_surface *surface, + struct wl_array *keys) +{ + /* FIXME: sth to be done here? */ +} + +static const struct wl_input_device_listener input_device_listener = { + input_handle_motion, + input_handle_button, + input_handle_key, + input_handle_pointer_focus, + input_handle_keyboard_focus, +}; + +static void +display_add_input(struct wayland_compositor *c, uint32_t id) +{ + struct wayland_input *input; + + input = malloc(sizeof *input); + if (input == NULL) + return; + + memset(input, 0, sizeof *input); + + input->compositor = c; + input->input_device = wl_input_device_create(c->parent.display, id); + wl_list_insert(c->input_list.prev, &input->link); + + wl_input_device_add_listener(input->input_device, + &input_device_listener, input); + wl_input_device_set_user_data(input->input_device, input); +} + +static void +display_handle_global(struct wl_display *display, uint32_t id, + const char *interface, uint32_t version, void *data) +{ + struct wayland_compositor *c = data; + + if (strcmp(interface, "compositor") == 0) { + c->parent.compositor = wl_compositor_create(display, id); + } else if (strcmp(interface, "output") == 0) { + c->parent.output = wl_output_create(display, id); + wl_output_add_listener(c->parent.output, &output_listener, c); + } else if (strcmp(interface, "input_device") == 0) { + display_add_input(c, id); + } else if (strcmp(interface, "shell") == 0) { + c->parent.shell = wl_shell_create(display, id); + wl_shell_add_listener(c->parent.shell, &shell_listener, c); + } else if (strcmp(interface, "drm") == 0) { + c->parent.drm = wl_drm_create(display, id); + wl_drm_add_listener(c->parent.drm, &drm_listener, c); + } +} + +static int +update_event_mask(uint32_t mask, void *data) +{ + struct wayland_compositor *c = data; + + c->parent.event_mask = mask; + if (c->parent.wl_source) + wl_event_source_fd_update(c->parent.wl_source, mask); + + return 0; +} + +static void +wayland_compositor_handle_event(int fd, uint32_t mask, void *data) +{ + struct wayland_compositor *c = data; + + if (mask & WL_EVENT_READABLE) + wl_display_iterate(c->parent.display, WL_DISPLAY_READABLE); + if (mask & WL_EVENT_WRITEABLE) + wl_display_iterate(c->parent.display, WL_DISPLAY_WRITABLE); +} + +struct wlsc_compositor * +wayland_compositor_create(struct wl_display *display, int width, int height) +{ + struct wayland_compositor *c; + struct wl_event_loop *loop; + int fd; + char *socket_name; + int socket_name_size; + + c = malloc(sizeof *c); + if (c == NULL) + return NULL; + + memset(c, 0, sizeof *c); + + socket_name_size = 1 + asprintf(&socket_name, "%c%s", '\0', + getenv("WAYLAND_DISPLAY")); + + c->parent.display = wl_display_connect(socket_name, socket_name_size); + free(socket_name); + + if (c->parent.display == NULL) { + fprintf(stderr, "failed to create display: %m\n"); + return NULL; + } + + wl_list_init(&c->input_list); + wl_display_add_global_listener(c->parent.display, + display_handle_global, c); + + wl_display_iterate(c->parent.display, WL_DISPLAY_READABLE); + + c->base.wl_display = display; + if (wayland_compositor_init_egl(c) < 0) + return NULL; + + /* Can't init base class until we have a current egl context */ + if (wlsc_compositor_init(&c->base, display) < 0) + return NULL; + + if (wayland_compositor_create_output(c, width, height) < 0) + return NULL; + + if (wayland_input_create(c) < 0) + return NULL; + + loop = wl_display_get_event_loop(c->base.wl_display); + + fd = wl_display_get_fd(c->parent.display, update_event_mask, c); + c->parent.wl_source = + wl_event_loop_add_fd(loop, fd, c->parent.event_mask, + wayland_compositor_handle_event, c); + if (c->parent.wl_source == NULL) + return NULL; + + c->base.authenticate = wayland_authenticate; + c->base.present = wayland_compositor_present; + + return &c->base; +} diff --git a/compositor/compositor.c b/compositor/compositor.c index ff24224..cbb0b6b 100644 --- a/compositor/compositor.c +++ b/compositor/compositor.c @@ -32,6 +32,11 @@ #include "wayland-server-protocol.h" #include "compositor.h" +/* The plan here is to generate a random anonymous socket name and + * advertise that through a service on the session dbus. + */ +static const char *option_socket_name = "wayland"; + static const char *option_background = "background.jpg"; static const char *option_geometry = "1024x640"; static int option_connector = 0; @@ -43,6 +48,8 @@ static const GOptionEntry option_entries[] = { &option_connector, "KMS connector" }, { "geometry", 'g', 0, G_OPTION_ARG_STRING, &option_geometry, "Geometry" }, + { "socket", 's', 0, G_OPTION_ARG_STRING, + &option_socket_name, "Socket Name" }, { NULL } }; @@ -1011,6 +1018,7 @@ input_device_attach(struct wl_client *client, return; if (device->pointer_focus == NULL) return; + if (device->pointer_focus->base.client != client && !(&device->pointer_focus->base == &wl_grab_surface && device->grab_surface->base.client == client)) @@ -1435,10 +1443,6 @@ wlsc_compositor_init(struct wlsc_compositor *ec, struct wl_display *display) return 0; } -/* The plan here is to generate a random anonymous socket name and - * advertise that through a service on the session dbus. - */ -static const char socket_name[] = "\0wayland"; int main(int argc, char *argv[]) { @@ -1447,6 +1451,8 @@ int main(int argc, char *argv[]) GError *error = NULL; GOptionContext *context; int width, height; + char *socket_name; + int socket_name_size; g_type_init(); /* GdkPixbuf needs this, it seems. */ @@ -1464,7 +1470,9 @@ int main(int argc, char *argv[]) display = wl_display_create(); - if (getenv("DISPLAY")) + if (getenv("WAYLAND_DISPLAY")) + ec = wayland_compositor_create(display, width, height); + else if (getenv("DISPLAY")) ec = x11_compositor_create(display, width, height); else ec = drm_compositor_create(display, option_connector); @@ -1474,10 +1482,14 @@ int main(int argc, char *argv[]) exit(EXIT_FAILURE); } - if (wl_display_add_socket(display, socket_name, sizeof socket_name)) { + socket_name_size = 1 + asprintf(&socket_name, "%c%s", '\0', + option_socket_name); + + if (wl_display_add_socket(display, socket_name, socket_name_size)) { fprintf(stderr, "failed to add socket: %m\n"); exit(EXIT_FAILURE); } + free(socket_name); wl_display_run(display); diff --git a/compositor/compositor.h b/compositor/compositor.h index 85535f3..921f137 100644 --- a/compositor/compositor.h +++ b/compositor/compositor.h @@ -234,6 +234,9 @@ x11_compositor_create(struct wl_display *display, int width, int height); struct wlsc_compositor * drm_compositor_create(struct wl_display *display, int connector); +struct wlsc_compositor * +wayland_compositor_create(struct wl_display *display, int width, int height); + void screenshooter_create(struct wlsc_compositor *ec); -- 1.7.2.2 From joel at teichroeb.net Sat Nov 27 16:26:08 2010 From: joel at teichroeb.net (Joel Teichroeb) Date: Sat, 27 Nov 2010 16:26:08 -0800 Subject: [PATCH] Made the dnd client actually work Message-ID: <4CF1A1A0.4020906@teichroeb.net> This patch makes the dnd client work a lot better. There is one small issue. If you drag a flower to a place where it is not accepted, it will just be gone. I can not find a work around for this because it does not seem that Wayland has a way to tell a client if their drag was rejected. I also fixed a bug where when the window was moved and a shell configure event was sent, the new x and y locations where not saved it the window was not resized. Joel Teichroeb -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Made-the-dnd-client-actually-work.patch URL: From = Sat Nov 27 15:41:42 2010 From: = (=) Date: Sat, 27 Nov 2010 15:41:42 -0800 Subject: [PATCH] Made the dnd client actually work Message-ID: --- clients/dnd.c | 108 ++++++++++++++++++++++++++++++++++++++++++++--------- clients/window.c | 5 ++- 2 files changed, 93 insertions(+), 20 deletions(-) diff --git a/clients/dnd.c b/clients/dnd.c index dedf353..fdbd79e 100644 --- a/clients/dnd.c +++ b/clients/dnd.c @@ -53,6 +53,9 @@ struct dnd_drag { struct dnd *dnd; struct input *input; uint32_t time; + struct item *item; + int x_offset, y_offset; + const char *mime_type; }; struct dnd_offer { @@ -60,20 +63,39 @@ struct dnd_offer { struct wl_array types; const char *drag_type; uint32_t tag; + int x, y; }; struct item { cairo_surface_t *surface; + int seed; int x, y; }; +struct message { + int seed, x_offset, y_offset; +}; + + static const int item_width = 64; static const int item_height = 64; static const int item_padding = 16; static struct item * -item_create(struct display *display, int x, int y) +item_create(struct display *display, int x, int y, int seed) { + struct item *item; + struct timeval tv; + + item = malloc(sizeof *item); + if (item == NULL) + return NULL; + + + gettimeofday(&tv, NULL); + item->seed = seed ? seed : tv.tv_usec; + srandom(item->seed); + const int petal_count = 3 + random() % 5; const double r1 = 20 + random() % 10; const double r2 = 5 + random() % 12; @@ -85,11 +107,7 @@ item_create(struct display *display, int x, int y) double t, dt = 2 * M_PI / (petal_count * 2); double x1, y1, x2, y2, x3, y3; struct rectangle rect; - struct item *item; - item = malloc(sizeof *item); - if (item == NULL) - return NULL; rect.width = item_width; rect.height = item_height; @@ -205,6 +223,17 @@ keyboard_focus_handler(struct window *window, window_schedule_redraw(dnd->window); } +static int +dnd_add_item(struct dnd *dnd, struct item *item){ + int i; + for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) { + if (dnd->items[i] == 0){ + dnd->items[i] = item; + return i; + } + } + return -1; +} static struct item * dnd_get_item(struct dnd *dnd, int32_t x, int32_t y) @@ -241,6 +270,7 @@ drag_target(void *data, fprintf(stderr, "target %s\n", mime_type); device = input_get_input_device(dnd_drag->input); + dnd_drag->mime_type = mime_type; if (mime_type) surface = dnd_drag->opaque; else @@ -255,11 +285,28 @@ static void drag_finish(void *data, struct wl_drag *drag, int fd) { struct dnd_drag *dnd_drag = data; - char text[] = "[drop data]"; + + if (!dnd_drag->mime_type){ + + dnd_add_item(dnd_drag->dnd, dnd_drag->item); + return; + } + + struct message *message; + message = malloc(sizeof *message); + if (message == NULL) + return; + + + + message->seed = dnd_drag->item->seed; + + message->x_offset = dnd_drag->x_offset; + message->y_offset = dnd_drag->y_offset; fprintf(stderr, "got 'finish', fd %d, sending message\n", fd); - write(fd, text, sizeof text); + write(fd, message, sizeof *message); close(fd); /* The 'finish' event marks the end of the session on the drag @@ -269,6 +316,7 @@ drag_finish(void *data, struct wl_drag *drag, int fd) cairo_surface_destroy(dnd_drag->translucent); cairo_surface_destroy(dnd_drag->opaque); free(dnd_drag); + free(message); } static const struct wl_drag_listener drag_listener = { @@ -305,8 +353,6 @@ drag_offer_pointer_focus(void *data, * allocated. */ if (!surface) { fprintf(stderr, "pointer focus NULL, session over\n"); - wl_array_release(&dnd_offer->types); - free(dnd_offer); wl_drag_offer_destroy(offer); return; } @@ -335,13 +381,14 @@ drag_offer_motion(void *data, int32_t x, int32_t y, int32_t surface_x, int32_t surface_y) { struct dnd_offer *dnd_offer = data; - struct dnd *dnd = dnd_offer->dnd; - if (!dnd_get_item(dnd, surface_x, surface_y)) { + if (!dnd_get_item(dnd_offer->dnd, surface_x, surface_y)) { fprintf(stderr, "drag offer motion %d, %d, accepting\n", surface_x, surface_y); wl_drag_offer_accept(offer, time, "text/plain"); dnd_offer->drag_type = "text/plain"; + dnd_offer->x = surface_x; + dnd_offer->y = surface_y; } else { fprintf(stderr, "drag offer motion %d, %d, declining\n", surface_x, surface_y); @@ -354,19 +401,34 @@ static gboolean drop_io_func(GIOChannel *source, GIOCondition condition, gpointer data) { struct dnd_offer *dnd_offer = data; + struct dnd *dnd = dnd_offer->dnd; char buffer[256]; int fd; unsigned int len; - GError *err = NULL; - g_io_channel_read_chars(source, buffer, sizeof buffer, &len, &err); - fprintf(stderr, "read %d bytes: %s\n", len, buffer); fd = g_io_channel_unix_get_fd(source); + len = read(fd, buffer, sizeof buffer); + fprintf(stderr, "read %d bytes\n", len); + close(fd); g_source_remove(dnd_offer->tag); g_io_channel_unref(source); + + struct message *message = (struct message *)buffer; + + + struct item *item = item_create(dnd->display, + dnd_offer->x-message->x_offset-26, + dnd_offer->y-message->y_offset-66, + message->seed); + + dnd_add_item(dnd, item); + window_schedule_redraw(dnd->window); + wl_array_release(&dnd_offer->types); + free(dnd_offer); + return TRUE; } @@ -491,6 +553,17 @@ dnd_button_handler(struct window *window, dnd_drag->dnd = dnd; dnd_drag->input = input; dnd_drag->time = time; + dnd_drag->item = item; + dnd_drag->x_offset = x - item->x; + dnd_drag->y_offset = y - item->y; + + int i; + for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) { + if (item == dnd->items[i]){ + dnd->items[i] = 0; + break; + } + } dnd_drag->opaque = create_drag_cursor(dnd_drag, item, x, y, 1); @@ -499,6 +572,7 @@ dnd_button_handler(struct window *window, window_start_drag(window, input, time, &drag_listener, dnd_drag); + window_schedule_redraw(dnd->window); } } @@ -542,7 +616,7 @@ dnd_create(struct display *display) x = (i % 4) * (item_width + item_padding) + item_padding; y = (i / 4) * (item_height + item_padding) + item_padding; if ((i ^ (i >> 2)) & 1) - dnd->items[i] = item_create(display, x, y); + dnd->items[i] = item_create(display, x, y, 0); else dnd->items[i] = NULL; } @@ -575,10 +649,6 @@ main(int argc, char *argv[]) { struct display *d; struct dnd *dnd; - struct timeval tv; - - gettimeofday(&tv, NULL); - srandom(tv.tv_usec); d = display_create(&argc, &argv, option_entries); if (d == NULL) { diff --git a/clients/window.c b/clients/window.c index bc76937..58b14a2 100644 --- a/clients/window.c +++ b/clients/window.c @@ -1018,8 +1018,11 @@ handle_configure(void *data, struct wl_shell *shell, window->pending_allocation.width = width; window->pending_allocation.height = height; - if (!(edges & 15)) + if (!(edges & 15)){ + window->allocation.x = window->pending_allocation.x; + window->allocation.y = window->pending_allocation.y; return; + } if (window->resize_handler) (*window->resize_handler)(window, -- 1.7.3.2 --------------010904060001050300090402-- From Darxus at chaosreigns.com Sat Nov 27 23:29:51 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sun, 28 Nov 2010 02:29:51 -0500 Subject: "hosted" patch for nouveau - X under wayland Message-ID: <20101128072951.GI7079@chaosreigns.com> Warning: What I did has broken X in a way that strangely persists across reboots. Might just be that my keyboard and mouse aren't responding, I haven't fixed it yet (I'm booted off a CF card). I also had a hard drive crash last night, which probably wasn't directly related. Am I correct in believing that I should be able to just run the wayland compositor under X, and then run "./Xorg :1" with the "hosted" patches? I got that far with nouveau, and got a black screen and a hung system. When I ran that patched version outside of X it complained about not being able to connect to wayland. How do I get it to run rootless? "./Xorg :1 -rootless" ? Oh, there's a -hosted flag. Hmm. So "./Xorg :1 -hosted -rootless"? Background: It's possible to run X.org as a client of wayland, rootless or not, if you have an Intel video card: http://wayland.freedesktop.org/rootless-x-under-wayland.png http://wayland.freedesktop.org/fullscreen-x-compiz.png This requires a modified X.org from here: http://cgit.freedesktop.org/~krh/xserver/log/?h=hosted And a patch to the X.org video driver, here: http://cgit.freedesktop.org/~krh/xf86-video-intel/log/?h=hosted I attempted to port that patch to the nouveau driver: http://www.chaosreigns.com/wayland/nouveau.hosted.git.patch Getting it to run goes something like this (assuming you have wayland and all its dependencies in $HOME/install): git clone git://anongit.freedesktop.org/git/mesa/drm cd drm ./autogen.sh --prefix=$HOME/install --enable-nouveau-experimental-api make make install cd .. git clone git://anongit.freedesktop.org/~krh/xserver --branch hosted cd xserver ./autogen.sh --prefix=$HOME/install --enable-nouveau-experimental-api make make install cd .. wget http://www.chaosreigns.com/wayland/nouveau.hosted.git.patch git clone git://anongit.freedesktop.org/nouveau/xf86-video-nouveau cd xf86-video-nouveau patch -p1 < ../nouveau.hosted.git.patch ./autogen.sh --prefix=$HOME/install --enable-nouveau-experimental-api make make install cd .. mkdir -p $HOME/install/etc/X11 echo -e 'Section "Device"\nIdentifier "n"\nDriver "nouveau"\nEndSection' > $HOME/install/etc/X11/xorg.conf wayland/compositor/compositor & sleep 1 $HOME/install/bin/Xorg :1 -hosted -rootless & # Haven't gotten this last one to work. I also rebuilt my kernel from the nouveau git repo, under ubuntu maverick: git clone --depth 1 git://anongit.freedesktop.org/nouveau/linux-2.6 cd linux-2.6 cp /boot/config-`uname -r` .config # use .config of currently running kernel yes "" | make oldconfig # use defaults of newer features make clean && make && make modules && sudo make modules_install && sudo make install mkinitramfs -o initrd.img `make kernelversion`+ sudo mv initrd.img /boot/initrd.img-`make kernelversion`+ sudo update-grub Reboot. Note that the "+"'s in the kernel build steps seem to be a peculiarity of the nouveau kernel tree. I was really amazed it worked that easily, once I figured it out. That kernel directory alone ended up being 6.6 gigabytes. The kernel install is nice and clean, creating only two files in /boot and a directory in /lib/modules. -- "Some people will tell you that slow is good - and it may be, on some days - but I am here to tell you that fast is better.... That is why God made fast motorcycles...." - Hunter S. Thompson http://www.ChaosReigns.com From Darxus at chaosreigns.com Sun Nov 28 00:31:52 2010 From: Darxus at chaosreigns.com (Darxus at chaosreigns.com) Date: Sun, 28 Nov 2010 03:31:52 -0500 Subject: "hosted" patch for nouveau - X under wayland In-Reply-To: <20101128072951.GI7079@chaosreigns.com> References: <20101128072951.GI7079@chaosreigns.com> Message-ID: <20101128083152.GJ7079@chaosreigns.com> On 11/28, Darxus at chaosreigns.com wrote: > Warning: What I did has broken X in a way that strangely persists across Yeah, that was me doing: mv /usr/share/X11/xorg.conf.d /usr/share/X11/xorg.conf.d.0 > $HOME/install/bin/Xorg :1 -hosted -rootless & Still not working: xf86OpenConsole: Cannot open virtual console 8 (Permission denied) Trying to open /dev/vc/8 or /dev/tty8. Don't think it should be doing that? -- "Life is either a daring adventure or it is nothing at all." - Helen Keller http://www.ChaosReigns.com From fred.morcos at gmail.com Sun Nov 28 07:16:20 2010 From: fred.morcos at gmail.com (Fred Morcos) Date: Sun, 28 Nov 2010 16:16:20 +0100 Subject: Missing includes in clients/window.h and clients/wayland-glib.h Message-ID: Hi, small patch to fix some missing includes i noticed in clients/window.h and clients/wayland-glib.h while trying to write my own example client. -- Regards, Fred Morcos -------------- next part -------------- A non-text attachment was scrubbed... Name: wl-clients-missing-includes.patch Type: application/octet-stream Size: 583 bytes Desc: not available URL: From krh at bitplanet.net Sun Nov 28 08:27:59 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Sun, 28 Nov 2010 11:27:59 -0500 Subject: Wayland patches Message-ID: Hi, Just a few quick guidelines on submitting patches to wayland. It is much like the kernel or the X server and comes down to "use git send-email". This means that you have to commit the changes locally and then use git send-email to send it. The commit messages themselves have to have a one line summary (no period at the end) then a blank line and then a more elaborate description of the change, if it's not a simple fix. Existing wayland commits, X server or kernel commits are good examples. If you're fixing different bugs or implementing a feature in a number of steps, use multiple commits, that each fix/implement one thing. Then send the patches using git send-email -N, where N is the number of patches to send. git send-email can be a bit finicky to set up, so an alternative is to use git format-patch -N, which will generate N patch files which can be attached in an email. The git send-email method is much preferred though, since it makes it easy to comment and review by following up to the patch email. If sending a series of patches, it's also nice to provide a branch somewhere (one of the git hosting sites or a personal freedesktop repo, for example) with the patches applied. That way I can just say git pull and git will pull that branch into my repo directly. Kristian From fred.morcos at gmail.com Sun Nov 28 10:49:36 2010 From: fred.morcos at gmail.com (Fred Morcos) Date: Sun, 28 Nov 2010 19:49:36 +0100 Subject: [PATCH] Missing includes in clients/window.h and clients/wayland-glib.h In-Reply-To: References: Message-ID: On Sun, Nov 28, 2010 at 4:16 PM, Fred Morcos wrote: > Hi, > > small patch to fix some missing includes i noticed in clients/window.h > and clients/wayland-glib.h while trying to write my own example > client. > > -- > Regards, > Fred Morcos > -- Thank You and Best Regards, Fred Morcos -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-missing-includes-in-clients-window.h-and-clients.patch Type: application/octet-stream Size: 956 bytes Desc: not available URL: From krh at bitplanet.net Mon Nov 29 05:17:07 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 29 Nov 2010 08:17:07 -0500 Subject: [PATCH] Missing includes in clients/window.h and clients/wayland-glib.h In-Reply-To: References: Message-ID: On Sun, Nov 28, 2010 at 1:49 PM, Fred Morcos wrote: > On Sun, Nov 28, 2010 at 4:16 PM, Fred Morcos wrote: >> Hi, >> >> small patch to fix some missing includes i noticed in clients/window.h >> and clients/wayland-glib.h while trying to write my own example >> client. Thanks, applied. One last nitpick about commit messages - please capitalize sentences properly. Kristian From krh at bitplanet.net Mon Nov 29 07:35:08 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 29 Nov 2010 10:35:08 -0500 Subject: [PATCH] Made the dnd client actually work In-Reply-To: <4CF1A1A0.4020906@teichroeb.net> References: <4CF1A1A0.4020906@teichroeb.net> Message-ID: On Sat, Nov 27, 2010 at 7:26 PM, Joel Teichroeb wrote: > This patch makes the dnd client work a lot better. There is one small issue. > If you drag a flower to a place where it is not accepted, it will just be > gone. I can not find a work around for this because it does not seem that > Wayland has a way to tell a client if their drag was rejected. > > I also fixed a bug where when the window was moved and a shell configure > event was sent, the new x and y locations where not saved it the window was > not resized. Hi Joel, That's a great patch, it definitely shows off the drag and drop feature better when you can actually move the flowers around. There's a couple of minor problems with patch though: First, configure git name and email address so the patch has the right author info. See here for details: http://book.git-scm.com/2_setup_and_initialization.html Then please split the window.c patch into a separate commit (see my other email about wayland patches). Also, the patch mostly follows the indentation style, but theres a couple of places where it's breaks (dnd_add_item, missing newline between functions and between variables and code, and the opening '{' of the functions should be on its own line. The last return in a function always has an empty line above it, etc. Look around in the code and just copy that style). Also, since we're now sending a wayland dnd specific blob around, we should change the offered mime-type to application/x-wayland-dnd-flower or such. Also, in drag_finish, you can just make the message a stack variable instead of malloc-ing it, and I'd prefer to send the random values (petal_count, r1, r2, u, v) instead of the random seed, but that's really just nitpicking. Where do the magic numbers (26 and 66) come from in drop_io_func?. Last nit-pick: don't mix declarations and code (int i; in dnd_button_handler). (And a meta-comment: the above is a good example of how it's hard to review and comment on a patch when it's attached - git send-email makes this much easier), On a more serious note, this part of the patch looks wrong: @@ -305,8 +353,6 @@ drag_offer_pointer_focus(void *data, * allocated. */ if (!surface) { fprintf(stderr, "pointer focus NULL, session over\n"); - wl_array_release(&dnd_offer->types); - free(dnd_offer); wl_drag_offer_destroy(offer); return; } We need to free the dnd_offer when the dnd session is over, which is when the drag pointer leaves the surface or when we receive the drop. It looks like I missed that in the drop_io_func (which you fixed, maybe this should be a separate patch too), but we still need it in the case where the pointer leaves the window without dropping. Anyway thanks, I appreciate it, the overall direction of the patch is exactly right. I had a few ideas for future improvements, if you're interested: - We'll need to update the protocol to separate the pointer image from the dragged item. This will make it easier for applications to attach the surface and update the pointer, and it allows the compositor to animate the "snap-back" to drag origin when the drag is rejected. - Avoid losing flowers when the target rejects the drop. This means adding a new 'reject' method to the drag_offer interface and a similar event to the drag interface. Or make fd = -1 mean reject and update the protocol code to handle that. - Make a rejected drag "snap" back to the origin (has to be done in the compositor). This requires the two above steps so the compositor can reliably detect a reject drop and so that it has the dragged icon without the cursor image overlaid. - Make the root window send x-wayland/dnd-delete mime type accept events if the drag source advertises that type and delete the flower if we drop it there. - Advertise image/svg and render the flower to svg using cairos svg surface, accept image/svg in the image client. This is a good way to demonstrate the multi-format dnd, but a bit of work, of course. Kristian From yuvalfl at gmail.com Mon Nov 29 11:24:34 2010 From: yuvalfl at gmail.com (Yuval Fledel) Date: Mon, 29 Nov 2010 21:24:34 +0200 Subject: [PATCH] Describe the wayland protocol using inline XML comments In-Reply-To: References: Message-ID: Describe interfaces, requests and events in the protocol using inline XML comments. Signed-off-by: Yuval Fledel --- ?protocol/wayland.xml | ? 95 ++++++++++++++++++++++++++++++++++++++++++++++++-- ?1 files changed, 92 insertions(+), 3 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 506e59b..ac1db0c 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1,57 +1,103 @@ + ? + ? ? + ? ? ? ? ? ? ? ? ? + ? ? ? ? ? ? ? ? ? + ? ? ? ? ? ? ? ? ? + ? ? ? ? ? ? ? ? ? ? ? ? + ? ? ? ? + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? + ? ? ? ? ? ? ? ? ? + ? ? ? ? ? ? ? ? ? + ? ? ? ? ? ? ? ? ? ? ? ? ? + ? ? + ? ? ? ? ? ? ? ? ? ? + ? ? - ? ? + ? ? ? ? ? ? ? ? ? + ? ? ? ? ? ? ? ? ? ? @@ -61,14 +107,26 @@ ? ? ? ? ? + ? ? ? ? ? ? ? ? ? + ? ? ? ? ? + ? ? + ? ? ? ? ? ? ? ? ? ? @@ -79,7 +137,10 @@ ? ? ? + ? ? + ? ? ? ? ? @@ -184,7 +245,7 @@ ? ? ? ? + ? ? ? ? as the drag pointer moves around in the surface. --> ? ? ? ? ? ? ? ? @@ -200,13 +261,19 @@ ? ? ? + ? ? + ? ? ? ? + ? ? ? ? ? ? ? ? ? + ? ? ? ? ? ? ? ? ? ? @@ -214,6 +281,10 @@ ? ? ? ? ? + ? ? ? ? ? ? ? ? ? ? @@ -222,7 +293,10 @@ ? ? ? + ? ? + ? ? ? ? ? ? ? ? ? ? @@ -230,6 +304,9 @@ ? ? ? ? ? + ? ? ? ? ? ? ? ? ? ? @@ -238,18 +315,22 @@ ? ? ? ? ? + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? + ? ? ? ? ? ? ? ? ? ? @@ -266,13 +347,21 @@ ? ? ? + ? ? + ? ? ? ? ? ? ? ? ? ? ? ? ? - ? + ? + ? ? \ No newline at end of file -- 1.7.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: Describe-interfaces-requests-and-events-in-the-proto.patch Type: application/octet-stream Size: 10145 bytes Desc: not available URL: From yuvalfl at gmail.com Mon Nov 29 11:29:10 2010 From: yuvalfl at gmail.com (Yuval Fledel) Date: Mon, 29 Nov 2010 21:29:10 +0200 Subject: [PATCH] Document wl_list Message-ID: Comments only. --- wayland/wayland-util.h | 29 ++++++++++++++++++++++++++++- 1 files changed, 28 insertions(+), 1 deletions(-) diff --git a/wayland/wayland-util.h b/wayland/wayland-util.h index ebac305..840f1fa 100644 --- a/wayland/wayland-util.h +++ b/wayland/wayland-util.h @@ -77,7 +77,34 @@ void *wl_hash_table_lookup(struct wl_hash_table *ht, uint32_t hash); int wl_hash_table_insert(struct wl_hash_table *ht, uint32_t hash, void *data); void wl_hash_table_remove(struct wl_hash_table *ht, uint32_t hash); - +/** + * wl_list - linked list + * + * The list container is of "struct wl_list" type, and needs to be initialized + * using wl_list_init(). All items must be of the same type. The item type + * must have a "struct wl_list" member. This member will be initialized by + * wl_list_insert(). There is no need to call wl_list_init() on the individual + * item. To query if the list is empty in O(1), use wl_list_empty(). + * + * Let's call the list reference "struct wl_list foo_list", the item type as + * "item_t", and the item member as "struct wl_list link". The following code + * + * The following code will initialize a list: + * + * wl_list_init(foo_list); + * wl_list_insert(foo_list, item1); Pushes item1 at the head + * wl_list_insert(foo_list, item2); Pushes item2 at the head + * wl_list_insert(item2, item3); Pushes item3 after item2 + * + * The list now looks like [item2, item3, item1] + * + * Will iterate the list in ascending order: + * + * item_t *item; + * wl_list_for_each(item, foo_list, link) { + * Do_something_with_item(item); + * } + */ struct wl_list { struct wl_list *prev; struct wl_list *next; -- 1.7.1 From yuvalfl at gmail.com Mon Nov 29 11:35:46 2010 From: yuvalfl at gmail.com (Yuval Fledel) Date: Mon, 29 Nov 2010 21:35:46 +0200 Subject: [PATCH 1/3] Factor evdev and TTY out of the DRM backend. Message-ID: evdev and TTY handling are not specific for DRM, and could be useful for Linux framebuffer too. This patch will move them to evdev.c --- compositor/Makefile.am | 1 + compositor/compositor-drm.c | 296 +--------------------------------- compositor/compositor.h | 15 ++ compositor/evdev.c | 377 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 398 insertions(+), 291 deletions(-) create mode 100644 compositor/evdev.c diff --git a/compositor/Makefile.am b/compositor/Makefile.am index f8f2307..bcb6cf3 100644 --- a/compositor/Makefile.am +++ b/compositor/Makefile.am @@ -20,6 +20,7 @@ compositor_SOURCES = \ screenshooter-protocol.c \ screenshooter-server-protocol.h \ drm.c \ + evdev.c \ shm.c udevrulesddir = $(sysconfdir)/udev/rules.d diff --git a/compositor/compositor-drm.c b/compositor/compositor-drm.c index e3e9b6f..db5f1e4 100644 --- a/compositor/compositor-drm.c +++ b/compositor/compositor-drm.c @@ -42,16 +42,8 @@ struct drm_compositor { struct udev *udev; struct wl_event_source *drm_source; - struct wl_event_source *term_signal_source; - /* tty handling state */ - int tty_fd; - uint32_t vt_active : 1; - - struct termios terminal_attributes; - struct wl_event_source *tty_input_source; - struct wl_event_source *enter_vt_source; - struct wl_event_source *leave_vt_source; + struct tty_evdev *ttyevdev; }; struct drm_output { @@ -66,197 +58,6 @@ struct drm_output { uint32_t current; }; -struct drm_input { - struct wlsc_input_device base; -}; - -struct evdev_input_device { - struct drm_input *master; - struct wl_event_source *source; - int tool, new_x, new_y; - int base_x, base_y; - int fd; -}; - -static void evdev_input_device_data(int fd, uint32_t mask, void *data) -{ - struct drm_compositor *c; - struct evdev_input_device *device = data; - struct input_event ev[8], *e, *end; - int len, value, dx, dy, absolute_event; - int x, y; - uint32_t time; - - c = (struct drm_compositor *) device->master->base.ec; - if (!c->vt_active) - return; - - dx = 0; - dy = 0; - absolute_event = 0; - x = device->master->base.x; - y = device->master->base.y; - - len = read(fd, &ev, sizeof ev); - if (len < 0 || len % sizeof e[0] != 0) { - /* FIXME: handle error... reopen device? */; - return; - } - - e = ev; - end = (void *) ev + len; - for (e = ev; e < end; e++) { - /* Get the signed value, earlier kernels had this as unsigned */ - value = e->value; - time = e->time.tv_sec * 1000 + e->time.tv_usec / 1000; - - switch (e->type) { - case EV_REL: - switch (e->code) { - case REL_X: - dx += value; - break; - - case REL_Y: - dy += value; - break; - } - break; - - case EV_ABS: - absolute_event = 1; - switch (e->code) { - case ABS_X: - if (device->new_x) { - device->base_x = x - value; - device->new_x = 0; - } - x = device->base_x + value; - break; - case ABS_Y: - if (device->new_y) { - device->base_y = y - value; - device->new_y = 0; - } - y = device->base_y + value; - break; - } - break; - - case EV_KEY: - if (value == 2) - break; - - switch (e->code) { - case BTN_TOUCH: - case BTN_TOOL_PEN: - case BTN_TOOL_RUBBER: - case BTN_TOOL_BRUSH: - case BTN_TOOL_PENCIL: - case BTN_TOOL_AIRBRUSH: - case BTN_TOOL_FINGER: - case BTN_TOOL_MOUSE: - case BTN_TOOL_LENS: - if (device->tool == 0 && value) { - device->new_x = 1; - device->new_y = 1; - } - device->tool = value ? e->code : 0; - break; - - case BTN_LEFT: - case BTN_RIGHT: - case BTN_MIDDLE: - case BTN_SIDE: - case BTN_EXTRA: - case BTN_FORWARD: - case BTN_BACK: - case BTN_TASK: - notify_button(&device->master->base, - time, e->code, value); - break; - - default: - notify_key(&device->master->base, - time, e->code, value); - break; - } - } - } - - if (dx != 0 || dy != 0) - notify_motion(&device->master->base, time, x + dx, y + dy); - if (absolute_event && device->tool) - notify_motion(&device->master->base, time, x, y); -} - -static struct evdev_input_device * -evdev_input_device_create(struct drm_input *master, - struct wl_display *display, const char *path) -{ - struct evdev_input_device *device; - struct wl_event_loop *loop; - - device = malloc(sizeof *device); - if (device == NULL) - return NULL; - - device->tool = 1; - device->new_x = 1; - device->new_y = 1; - device->master = master; - - device->fd = open(path, O_RDONLY); - if (device->fd < 0) { - free(device); - fprintf(stderr, "couldn't create pointer for %s: %m\n", path); - return NULL; - } - - loop = wl_display_get_event_loop(display); - device->source = wl_event_loop_add_fd(loop, device->fd, - WL_EVENT_READABLE, - evdev_input_device_data, device); - if (device->source == NULL) { - close(device->fd); - free(device); - return NULL; - } - - return device; -} - -static void -drm_input_create(struct drm_compositor *c) -{ - struct drm_input *input; - struct udev_enumerate *e; - struct udev_list_entry *entry; - struct udev_device *device; - const char *path; - - input = malloc(sizeof *input); - if (input == NULL) - return; - - memset(input, 0, sizeof *input); - wlsc_input_device_init(&input->base, &c->base); - - e = udev_enumerate_new(c->udev); - udev_enumerate_add_match_subsystem(e, "input"); - udev_enumerate_add_match_property(e, "WAYLAND_SEAT", "1"); - udev_enumerate_scan_devices(e); - udev_list_entry_foreach(entry, udev_enumerate_get_list_entry(e)) { - path = udev_list_entry_get_name(entry); - device = udev_device_new_from_syspath(c->udev, path); - evdev_input_device_create(input, c->base.wl_display, - udev_device_get_devnode(device)); - } - udev_enumerate_unref(e); - - c->base.input_device = &input->base; -} - static void drm_compositor_present(struct wlsc_compositor *ec) { @@ -498,7 +299,7 @@ create_outputs(struct drm_compositor *ec, int option_connector) return 0; } -static void on_enter_vt(int signal_number, void *data) +static void on_enter_vt(void *data) { struct drm_compositor *ec = data; struct drm_output *output; @@ -513,12 +314,6 @@ static void on_enter_vt(int signal_number, void *data) fprintf(stderr, "enter vt\n"); - ioctl(ec->tty_fd, VT_RELDISP, VT_ACKACQ); - ret = ioctl(ec->tty_fd, KDSETMODE, KD_GRAPHICS); - if (ret) - fprintf(stderr, "failed to set KD_GRAPHICS mode on console: %m\n"); - ec->vt_active = 1; - wl_list_for_each(output, &ec->base.output_list, base.link) { ret = drmModeSetCrtc(ec->base.drm.fd, output->crtc_id, output->fb_id[output->current ^ 1], 0, 0, @@ -530,7 +325,7 @@ static void on_enter_vt(int signal_number, void *data) } } -static void on_leave_vt(int signal_number, void *data) +static void on_leave_vt(void *data) { struct drm_compositor *ec = data; int ret; @@ -541,86 +336,6 @@ static void on_leave_vt(int signal_number, void *data) kill(0, SIGTERM); return; } - - ioctl (ec->tty_fd, VT_RELDISP, 1); - ret = ioctl(ec->tty_fd, KDSETMODE, KD_TEXT); - if (ret) - fprintf(stderr, "failed to set KD_TEXT mode on console: %m\n"); - ec->vt_active = 0; -} - -static void -on_tty_input(int fd, uint32_t mask, void *data) -{ - struct drm_compositor *ec = data; - - /* Ignore input to tty. We get keyboard events from evdev - */ - tcflush(ec->tty_fd, TCIFLUSH); -} - -static void on_term_signal(int signal_number, void *data) -{ - struct drm_compositor *ec = data; - - if (tcsetattr(ec->tty_fd, TCSANOW, &ec->terminal_attributes) < 0) - fprintf(stderr, "could not restore terminal to canonical mode\n"); - - exit(0); -} - -static int setup_tty(struct drm_compositor *ec, struct wl_event_loop *loop) -{ - struct termios raw_attributes; - struct vt_mode mode = { 0 }; - int ret; - - ec->tty_fd = open("/dev/tty0", O_RDWR | O_NOCTTY); - if (ec->tty_fd <= 0) { - fprintf(stderr, "failed to open active tty: %m\n"); - return -1; - } - - if (tcgetattr(ec->tty_fd, &ec->terminal_attributes) < 0) { - fprintf(stderr, "could not get terminal attributes: %m\n"); - return -1; - } - - /* Ignore control characters and disable echo */ - raw_attributes = ec->terminal_attributes; - cfmakeraw(&raw_attributes); - - /* Fix up line endings to be normal (cfmakeraw hoses them) */ - raw_attributes.c_oflag |= OPOST | OCRNL; - - if (tcsetattr(ec->tty_fd, TCSANOW, &raw_attributes) < 0) - fprintf(stderr, "could not put terminal into raw mode: %m\n"); - - ec->term_signal_source = - wl_event_loop_add_signal(loop, SIGTERM, on_term_signal, ec); - - ec->tty_input_source = - wl_event_loop_add_fd(loop, ec->tty_fd, - WL_EVENT_READABLE, on_tty_input, ec); - - ret = ioctl(ec->tty_fd, KDSETMODE, KD_GRAPHICS); - if (ret) - fprintf(stderr, "failed to set KD_GRAPHICS mode on tty: %m\n"); - - ec->vt_active = 1; - mode.mode = VT_PROCESS; - mode.relsig = SIGUSR1; - mode.acqsig = SIGUSR2; - if (!ioctl(ec->tty_fd, VT_SETMODE, &mode) < 0) { - fprintf(stderr, "failed to take control of vt handling\n"); - } - - ec->leave_vt_source = - wl_event_loop_add_signal(loop, SIGUSR1, on_leave_vt, ec); - ec->enter_vt_source = - wl_event_loop_add_signal(loop, SIGUSR2, on_enter_vt, ec); - - return 0; } static int @@ -684,13 +399,12 @@ drm_compositor_create(struct wl_display *display, int connector) return NULL; } - drm_input_create(ec); - loop = wl_display_get_event_loop(ec->base.wl_display); ec->drm_source = wl_event_loop_add_fd(loop, ec->base.drm.fd, WL_EVENT_READABLE, on_drm_input, ec); - setup_tty(ec, loop); + ec->ttyevdev = evdev_tty_setup(&ec->base, loop, ec->udev, on_enter_vt, on_leave_vt, ec); + ec->base.authenticate = drm_authenticate; ec->base.present = drm_compositor_present; ec->base.focus = 1; diff --git a/compositor/compositor.h b/compositor/compositor.h index 85535f3..4280a33 100644 --- a/compositor/compositor.h +++ b/compositor/compositor.h @@ -40,6 +40,7 @@ struct wlsc_matrix { }; struct wlsc_surface; +struct tty_evdev; struct wlsc_listener { struct wl_list link; @@ -228,12 +229,26 @@ struct wl_buffer * wl_buffer_create_drm(struct wlsc_compositor *compositor, struct wl_visual *visual); +/* Backends */ + struct wlsc_compositor * x11_compositor_create(struct wl_display *display, int width, int height); struct wlsc_compositor * drm_compositor_create(struct wl_display *display, int connector); +/* TTY and evdev */ + +typedef void (* on_enter_vt_t)(void *data); +typedef void (* on_leave_vt_t)(void *data); + +struct tty_evdev *evdev_tty_setup(struct wlsc_compositor *ec, + struct wl_event_loop *loop, struct udev *udev, + on_enter_vt_t on_enter, on_leave_vt_t on_leave, + void *callback_data); + +/* Extensions */ + void screenshooter_create(struct wlsc_compositor *ec); diff --git a/compositor/evdev.c b/compositor/evdev.c new file mode 100644 index 0000000..8ff23ce --- /dev/null +++ b/compositor/evdev.c @@ -0,0 +1,377 @@ +/* + * Copyright ?? 2008-2010 Kristian H??gsberg + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software Foundation, + * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ + +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#define GL_GLEXT_PROTOTYPES +#define EGL_EGLEXT_PROTOTYPES +#include +#include +#include +#include + +#include "compositor.h" + +struct tty_evdev { + struct wlsc_compositor *ec; + struct wl_list input_devices; + + /* tty handling state */ + int tty_fd; + uint32_t vt_active : 1; + struct termios terminal_attributes; + struct wl_event_source *term_signal_source; + struct wl_event_source *tty_input_source; + struct wl_event_source *enter_vt_source; + struct wl_event_source *leave_vt_source; + + on_enter_vt_t on_enter; + on_leave_vt_t on_leave; + void *callback_data; +}; + +struct evdev_input_device { + struct wlsc_input_device *master; + struct tty_evdev *tty_evdev; + struct wl_event_source *source; + int tool, new_x, new_y; + int base_x, base_y; + int fd; +}; + +static void evdev_input_device_data(int fd, uint32_t mask, void *data) +{ + struct evdev_input_device *device = data; + struct input_event ev[8], *e, *end; + int len, value, dx, dy, absolute_event; + int x, y; + uint32_t time; + + dx = 0; + dy = 0; + absolute_event = 0; + x = device->master->x; + y = device->master->y; + + len = read(fd, &ev, sizeof ev); + if (len < 0 || len % sizeof e[0] != 0) { + /* FIXME: handle error... reopen device? */; + return; + } + + /* evdev events aren't targeted only to the current VT */ + if (!device->tty_evdev->vt_active) + return; + + e = ev; + end = (void *) ev + len; + for (e = ev; e < end; e++) { + /* Get the signed value, earlier kernels had this as unsigned */ + value = e->value; + time = e->time.tv_sec * 1000 + e->time.tv_usec / 1000; + + switch (e->type) { + case EV_REL: + switch (e->code) { + case REL_X: + dx += value; + break; + + case REL_Y: + dy += value; + break; + } + break; + + case EV_ABS: + absolute_event = 1; + switch (e->code) { + case ABS_X: + if (device->new_x) { + device->base_x = x - value; + device->new_x = 0; + } + x = device->base_x + value; + break; + case ABS_Y: + if (device->new_y) { + device->base_y = y - value; + device->new_y = 0; + } + y = device->base_y + value; + break; + } + break; + + case EV_KEY: + if (value == 2) + break; + + switch (e->code) { + case BTN_TOUCH: + case BTN_TOOL_PEN: + case BTN_TOOL_RUBBER: + case BTN_TOOL_BRUSH: + case BTN_TOOL_PENCIL: + case BTN_TOOL_AIRBRUSH: + case BTN_TOOL_FINGER: + case BTN_TOOL_MOUSE: + case BTN_TOOL_LENS: + if (device->tool == 0 && value) { + device->new_x = 1; + device->new_y = 1; + } + device->tool = value ? e->code : 0; + break; + + case BTN_LEFT: + case BTN_RIGHT: + case BTN_MIDDLE: + case BTN_SIDE: + case BTN_EXTRA: + case BTN_FORWARD: + case BTN_BACK: + case BTN_TASK: + notify_button(device->master, + time, e->code, value); + break; + + default: + notify_key(device->master, + time, e->code, value); + break; + } + } + } + + if (dx != 0 || dy != 0) + notify_motion(device->master, time, x + dx, y + dy); + if (absolute_event && device->tool) + notify_motion(device->master, time, x, y); +} + +static struct evdev_input_device * +evdev_input_device_create(struct tty_evdev *te, + struct wlsc_input_device *master, + struct wl_display *display, const char *path) +{ + struct evdev_input_device *device; + struct wl_event_loop *loop; + + if (path == NULL) + return NULL; + + device = malloc(sizeof *device); + if (device == NULL) + return NULL; + + device->tool = 1; + device->new_x = 1; + device->new_y = 1; + device->master = master; + device->tty_evdev = te; + + device->fd = open(path, O_RDONLY); + if (device->fd < 0) { + free(device); + fprintf(stderr, "couldn't create pointer for %s: %m\n", path); + return NULL; + } + + loop = wl_display_get_event_loop(display); + device->source = wl_event_loop_add_fd(loop, device->fd, + WL_EVENT_READABLE, + evdev_input_device_data, device); + if (device->source == NULL) { + close(device->fd); + free(device); + return NULL; + } + + return device; +} + +static void +evdev_input_init(struct tty_evdev *te, struct udev *udev) +{ + struct wlsc_compositor *c = te->ec; + struct wlsc_input_device *input; + struct udev_enumerate *e; + struct udev_list_entry *entry; + struct udev_device *device; + const char *path; + + input = malloc(sizeof *input); + if (input == NULL) + return; + + memset(input, 0, sizeof *input); + wlsc_input_device_init(input, c); + + e = udev_enumerate_new(udev); + udev_enumerate_add_match_subsystem(e, "input"); +// udev_enumerate_add_match_property(e, "WAYLAND_SEAT", "1"); + udev_enumerate_scan_devices(e); + udev_list_entry_foreach(entry, udev_enumerate_get_list_entry(e)) { + path = udev_list_entry_get_name(entry); + device = udev_device_new_from_syspath(udev, path); + evdev_input_device_create(te, input, c->wl_display, + udev_device_get_devnode(device)); + } + udev_enumerate_unref(e); + + c->input_device = input; +} + +static void on_enter_vt(int signal_number, void *data) +{ + struct tty_evdev *te = data; + int ret; + + ioctl(te->tty_fd, VT_RELDISP, VT_ACKACQ); + ret = ioctl(te->tty_fd, KDSETMODE, KD_GRAPHICS); + if (ret) + fprintf(stderr, + "failed to set KD_GRAPHICS mode on console: %m\n"); + te->vt_active = 1; + + if (te->on_enter != NULL) + (*te->on_enter)(te->callback_data); +} + +static void on_leave_vt(int signal_number, void *data) +{ + struct tty_evdev *te = data; + int ret; + + if (te->on_leave != NULL) + (*te->on_leave)(te->callback_data); + + ioctl (te->tty_fd, VT_RELDISP, 1); + ret = ioctl(te->tty_fd, KDSETMODE, KD_TEXT); + if (ret) + fprintf(stderr, + "failed to set KD_TEXT mode on console: %m\n"); + te->vt_active = 0; +} + +static void +on_tty_input(int fd, uint32_t mask, void *data) +{ + struct tty_evdev *te = data; + + /* Ignore input to tty. We get keyboard events from evdev. */ + tcflush(te->tty_fd, TCIFLUSH); +} + +static void on_term_signal(int signal_number, void *data) +{ + struct tty_evdev *te = data; + + if (tcsetattr(te->tty_fd, TCSANOW, &te->terminal_attributes) < 0) + fprintf(stderr, + "Could not restore terminal to canonical mode\n"); + + exit(0); +} + +static int setup_tty(struct tty_evdev *te, struct wl_event_loop *loop) +{ + struct termios raw_attributes; + struct vt_mode mode = { 0 }; + int ret; + + te->tty_fd = open("/dev/tty0", O_RDWR | O_NOCTTY); + if (te->tty_fd <= 0) { + fprintf(stderr, "failed to open active tty: %m\n"); + return -1; + } + + if (tcgetattr(te->tty_fd, &te->terminal_attributes) < 0) { + fprintf(stderr, "could not get terminal attributes: %m\n"); + return -1; + } + + /* Ignore control characters and disable echo */ + raw_attributes = te->terminal_attributes; + cfmakeraw(&raw_attributes); + + /* Fix up line endings to be normal (cfmakeraw hoses them) */ + raw_attributes.c_oflag |= OPOST | OCRNL; + + if (tcsetattr(te->tty_fd, TCSANOW, &raw_attributes) < 0) + fprintf(stderr, "could not put terminal into raw mode: %m\n"); + + te->term_signal_source = + wl_event_loop_add_signal(loop, SIGTERM, on_term_signal, te); + + te->tty_input_source = + wl_event_loop_add_fd(loop, te->tty_fd, + WL_EVENT_READABLE, on_tty_input, te); + + ret = ioctl(te->tty_fd, KDSETMODE, KD_GRAPHICS); + if (ret) + fprintf(stderr, "failed to set KD_GRAPHICS mode on tty: %m\n"); + + te->vt_active = 1; + mode.mode = VT_PROCESS; + mode.relsig = SIGUSR1; + mode.acqsig = SIGUSR2; + if (!ioctl(te->tty_fd, VT_SETMODE, &mode) < 0) { + fprintf(stderr, "failed to take control of vt handling\n"); + } + + te->leave_vt_source = + wl_event_loop_add_signal(loop, SIGUSR1, on_leave_vt, te); + te->enter_vt_source = + wl_event_loop_add_signal(loop, SIGUSR2, on_enter_vt, te); + + return 0; +} + +struct tty_evdev *evdev_tty_setup(struct wlsc_compositor *ec, + struct wl_event_loop *loop, struct udev *udev, + on_enter_vt_t on_enter, on_leave_vt_t on_leave, + void *callback_data) +{ + struct tty_evdev *te; + + te = calloc(1, sizeof(*te)); + if (te == NULL) + return NULL; + + te->ec = ec; + te->on_enter = on_enter; + te->on_leave = on_leave; + te->callback_data = callback_data; + wl_list_init(&te->input_devices); + + evdev_input_init(te, udev); + setup_tty(te, loop); + + return te; +} -- 1.7.1 From yuvalfl at gmail.com Mon Nov 29 11:39:07 2010 From: yuvalfl at gmail.com (Yuval Fledel) Date: Mon, 29 Nov 2010 21:39:07 +0200 Subject: [PATCH 2/3] Use generic buffers for pointer images instead of drm buffers Message-ID: EGLImageKHR can only be used with current mesa if DRM is present. This is a too strict requirement for Wayland. This patch will stop using EGLImageKHR for pointer images. This has the downside of having to load the pointer image from RAM every time the pointer changes, but since it doesn't happen too often, and the cpu is already involved in this act, it shouldn't degrade performance. On the upside, it prepares for using Wayland in non-drm environments. --- compositor/compositor.c | 53 +++++++++++++++++++++++++--------------------- compositor/compositor.h | 20 ++++++----------- compositor/drm.c | 5 ++++ compositor/shm.c | 45 +++++++++++++++++++++++++++++++++++++++ 4 files changed, 86 insertions(+), 37 deletions(-) diff --git a/compositor/compositor.c b/compositor/compositor.c index ff24224..e9acbd3 100644 --- a/compositor/compositor.c +++ b/compositor/compositor.c @@ -171,33 +171,49 @@ destroy_surface(struct wl_resource *resource, struct wl_client *client) wlsc_compositor_schedule_repaint(compositor); } -static int -texture_from_png(const char *filename, int width, int height) +static struct wl_buffer * +load_png(struct wlsc_compositor *ec, const char *filename, + int width, int height) { GdkPixbuf *pixbuf; GError *error = NULL; - void *data; - GLenum format; + void *data, *data2; + struct wl_visual *format; + struct wl_buffer *buffer; + int stride; pixbuf = gdk_pixbuf_new_from_file_at_scale(filename, width, height, FALSE, &error); if (error != NULL) - return -1; + return NULL; data = gdk_pixbuf_get_pixels(pixbuf); + stride = gdk_pixbuf_get_rowstride(pixbuf); if (gdk_pixbuf_get_has_alpha(pixbuf)) - format = GL_RGBA; + format = &ec->argb_visual; else - format = GL_RGB; + format = &ec->rgb_visual; + + data2 = malloc(stride * height); + if (data2 == NULL) { + gdk_pixbuf_unref(pixbuf); + return NULL; + } + memcpy(data2, data, stride * height); - glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, width, height, - format, GL_UNSIGNED_BYTE, data); + buffer = wl_ram_buffer_create(&ec->base, width, height, stride, format, + data2); gdk_pixbuf_unref(pixbuf); - return 0; + if (buffer == NULL) { + free(data2); + return NULL; + } + + return buffer; } static const struct { @@ -221,25 +237,14 @@ static void create_pointer_images(struct wlsc_compositor *ec) { int i, count; - GLuint texture; const int width = 32, height = 32; - glGenTextures(1, &texture); - glBindTexture(GL_TEXTURE_2D, texture); - glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); - glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); - glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); - glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); - count = ARRAY_LENGTH(pointer_images); ec->pointer_buffers = malloc(count * sizeof *ec->pointer_buffers); for (i = 0; i < count; i++) { ec->pointer_buffers[i] = - wlsc_drm_buffer_create(ec, width, height, - &ec->argb_visual); - glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, - ec->pointer_buffers[i]->image); - texture_from_png(pointer_images[i].filename, width, height); + load_png(ec, pointer_images[i].filename, + width, height); } } @@ -473,7 +478,7 @@ wlsc_input_device_set_pointer_image(struct wlsc_input_device *device, struct wlsc_compositor *compositor = device->ec; wlsc_input_device_attach(device, - &compositor->pointer_buffers[type]->base, + compositor->pointer_buffers[type], pointer_images[type].hotspot_x, pointer_images[type].hotspot_y); } diff --git a/compositor/compositor.h b/compositor/compositor.h index 4280a33..a15a29b 100644 --- a/compositor/compositor.h +++ b/compositor/compositor.h @@ -40,6 +40,7 @@ struct wlsc_matrix { }; struct wlsc_surface; +struct wlsc_drm_buffer; struct tty_evdev; struct wlsc_listener { @@ -120,21 +121,10 @@ struct wlsc_drm { char *filename; }; -struct wlsc_drm_buffer { - struct wl_buffer base; - EGLImageKHR image; -}; - struct wlsc_shm { struct wl_object base; }; -struct wlsc_shm_buffer { - struct wl_buffer base; - int32_t stride; - void *data; -}; - struct wlsc_compositor { struct wl_compositor base; struct wl_visual argb_visual, premultiplied_argb_visual, rgb_visual; @@ -145,7 +135,7 @@ struct wlsc_compositor { EGLContext context; GLuint fbo, vbo; GLuint proj_uniform, tex_uniform; - struct wlsc_drm_buffer **pointer_buffers; + struct wl_buffer **pointer_buffers; struct wl_display *wl_display; /* We implement the shell interface. */ @@ -226,9 +216,13 @@ int wlsc_shm_init(struct wlsc_compositor *ec); struct wl_buffer * -wl_buffer_create_drm(struct wlsc_compositor *compositor, +wl_drm_buffer_create(struct wlsc_compositor *compositor, struct wl_visual *visual); +struct wl_buffer * +wl_ram_buffer_create(struct wl_compositor *c, int32_t width, int32_t height, + uint32_t stride, struct wl_visual *visual, void *data); + /* Backends */ struct wlsc_compositor * diff --git a/compositor/drm.c b/compositor/drm.c index 1fe5fa5..982e697 100644 --- a/compositor/drm.c +++ b/compositor/drm.c @@ -22,6 +22,11 @@ #include "compositor.h" +struct wlsc_drm_buffer { + struct wl_buffer base; + EGLImageKHR image; +}; + static void drm_authenticate(struct wl_client *client, struct wl_drm *drm_base, uint32_t id) diff --git a/compositor/shm.c b/compositor/shm.c index cdade52..5a58ad9 100644 --- a/compositor/shm.c +++ b/compositor/shm.c @@ -24,6 +24,12 @@ #include "compositor.h" +struct wlsc_shm_buffer { + struct wl_buffer base; + int32_t stride; + void *data; +}; + static void destroy_buffer(struct wl_resource *resource, struct wl_client *client) { @@ -147,6 +153,45 @@ const static struct wl_shm_interface shm_interface = { shm_create_buffer }; +static void +wl_ram_destroy_buffer(struct wl_resource *resource, struct wl_client *client) +{ + struct wlsc_shm_buffer *buffer = + container_of(resource, struct wlsc_shm_buffer, base.base); + + free(buffer->data); + free(buffer); +} + +struct wl_buffer * +wl_ram_buffer_create(struct wl_compositor *c, int32_t width, int32_t height, + uint32_t stride, struct wl_visual *visual, void *data) +{ + struct wlsc_shm_buffer *buffer; + + buffer = calloc(1, sizeof *buffer); + if (buffer == NULL) { + return NULL; + } + + buffer->base.compositor = c; + buffer->base.width = width; + buffer->base.height = height; + buffer->base.visual = visual; + buffer->base.attach = shm_buffer_attach; + buffer->base.damage = shm_buffer_damage; + buffer->stride = stride; + buffer->data = data; + + buffer->base.base.base.id = 0; + buffer->base.base.base.interface = NULL; + buffer->base.base.base.implementation = NULL; + + buffer->base.base.destroy = wl_ram_destroy_buffer; + + return &buffer->base; +} + int wlsc_shm_init(struct wlsc_compositor *ec) { -- 1.7.1 From yuvalfl at gmail.com Mon Nov 29 11:41:50 2010 From: yuvalfl at gmail.com (Yuval Fledel) Date: Mon, 29 Nov 2010 21:41:50 +0200 Subject: [PATCH 3/3] Fix crashes in clients when no DRM is present. Message-ID: When no DRM present, clients (window.c actually) now either exit orderly, or if that check is removed - crash (unsurprisingly). This patch relieves this assumption, and allow some clients (terminal, image, flower) to run in a non-DRM environment --- clients/window.c | 129 ++++++++++++++++++++++++++++++------------------------ 1 files changed, 72 insertions(+), 57 deletions(-) diff --git a/clients/window.c b/clients/window.c index ae55819..9ee13c7 100644 --- a/clients/window.c +++ b/clients/window.c @@ -453,10 +453,11 @@ display_create_surface(struct display *display, struct rectangle *rectangle) { #ifdef HAVE_CAIRO_GL - return display_create_drm_surface(display, rectangle); -#else - return display_create_shm_surface(display, rectangle); + if (display->drm) { + return display_create_drm_surface(display, rectangle); + } #endif + return display_create_shm_surface(display, rectangle); } cairo_surface_t * @@ -465,10 +466,11 @@ display_create_surface_from_file(struct display *display, struct rectangle *rectangle) { #ifdef HAVE_CAIRO_GL - return display_create_drm_surface_from_file(display, filename, rectangle); -#else - return display_create_shm_surface_from_file(display, filename, rectangle); + if (display->drm) { + return display_create_drm_surface_from_file(display, filename, rectangle); + } #endif + return display_create_shm_surface_from_file(display, filename, rectangle); } static const struct { @@ -1231,10 +1233,11 @@ window_create(struct display *display, const char *title, window->margin = 16; window->decoration = 1; -#ifdef HAVE_CAIRO_GL - window->buffer_type = WINDOW_BUFFER_TYPE_DRM; -#else window->buffer_type = WINDOW_BUFFER_TYPE_SHM; +#ifdef HAVE_CAIRO_GL + if (display->drm) { + window->buffer_type = WINDOW_BUFFER_TYPE_DRM; + } #endif wl_surface_set_user_data(window->surface, window); @@ -1391,16 +1394,69 @@ init_xkb(struct display *d) } } +static int +display_drm_init(struct display *d) +{ + EGLint major, minor; + int fd; + drm_magic_t magic; + + fd = open(d->device_name, O_RDWR); + if (fd < 0) { + fprintf(stderr, "drm open failed: %m\n"); + return FALSE; + } + + if (drmGetMagic(fd, &magic)) { + fprintf(stderr, "DRI2: failed to get drm magic"); + return FALSE; + } + + /* Wait for authenticated event */ + wl_drm_authenticate(d->drm, magic); + wl_display_iterate(d->display, WL_DISPLAY_WRITABLE); + while (!d->authenticated) + wl_display_iterate(d->display, WL_DISPLAY_READABLE); + + d->dpy = eglGetDRMDisplayMESA(fd); + if (!eglInitialize(d->dpy, &major, &minor)) { + fprintf(stderr, "failed to initialize display\n"); + return FALSE; + } + + if (!eglBindAPI(EGL_OPENGL_API)) { + fprintf(stderr, "failed to bind api EGL_OPENGL_API\n"); + return FALSE; + } + + d->ctx = eglCreateContext(d->dpy, NULL, EGL_NO_CONTEXT, NULL); + if (d->ctx == NULL) { + fprintf(stderr, "failed to create context\n"); + return FALSE; + } + + if (!eglMakeCurrent(d->dpy, NULL, NULL, d->ctx)) { + fprintf(stderr, "faile to make context current\n"); + return FALSE; + } + +#ifdef HAVE_CAIRO_GL + d->device = cairo_egl_device_create(d->dpy, d->ctx); + if (d->device == NULL) { + fprintf(stderr, "failed to get cairo drm device\n"); + return FALSE; + } +#endif + return TRUE; +} + struct display * display_create(int *argc, char **argv[], const GOptionEntry *option_entries) { struct display *d; - EGLint major, minor; - int fd; GOptionContext *context; GOptionGroup *xkb_option_group; GError *error; - drm_magic_t magic; g_type_init(); @@ -1440,52 +1496,11 @@ display_create(int *argc, char **argv[], const GOptionEntry *option_entries) /* Process connection events. */ wl_display_iterate(d->display, WL_DISPLAY_READABLE); - fd = open(d->device_name, O_RDWR); - if (fd < 0) { - fprintf(stderr, "drm open failed: %m\n"); - return NULL; - } - - if (drmGetMagic(fd, &magic)) { - fprintf(stderr, "DRI2: failed to get drm magic"); - return NULL; - } - - /* Wait for authenticated event */ - wl_drm_authenticate(d->drm, magic); - wl_display_iterate(d->display, WL_DISPLAY_WRITABLE); - while (!d->authenticated) - wl_display_iterate(d->display, WL_DISPLAY_READABLE); - - d->dpy = eglGetDRMDisplayMESA(fd); - if (!eglInitialize(d->dpy, &major, &minor)) { - fprintf(stderr, "failed to initialize display\n"); - return NULL; - } - - if (!eglBindAPI(EGL_OPENGL_API)) { - fprintf(stderr, "failed to bind api EGL_OPENGL_API\n"); - return NULL; - } - - d->ctx = eglCreateContext(d->dpy, NULL, EGL_NO_CONTEXT, NULL); - if (d->ctx == NULL) { - fprintf(stderr, "failed to create context\n"); - return NULL; - } - - if (!eglMakeCurrent(d->dpy, NULL, NULL, d->ctx)) { - fprintf(stderr, "faile to make context current\n"); - return NULL; - } - -#ifdef HAVE_CAIRO_GL - d->device = cairo_egl_device_create(d->dpy, d->ctx); - if (d->device == NULL) { - fprintf(stderr, "failed to get cairo drm device\n"); - return NULL; + if (d->device_name) { + if (!display_drm_init(d)) { + return NULL; + } } -#endif create_pointer_surfaces(d); -- 1.7.1 From krh at bitplanet.net Mon Nov 29 13:11:50 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 29 Nov 2010 16:11:50 -0500 Subject: [PATCH] Fix for uninitialized member in QWaylandCursor In-Reply-To: <20101125111330.GA3343@sysgo.com> References: <20101125111330.GA3343@sysgo.com> Message-ID: On Thu, Nov 25, 2010 at 6:13 AM, Rolf Offermanns wrote: > Without this patch Qt applications will crash the moment the mouse pointer > enters the window. Thanks, applied. > Signed-off-by: Rolf Offermanns > --- > ?.../platforms/wayland/qwaylandintegration.cpp ? ? ?| ? ?2 +- > ?1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/plugins/platforms/wayland/qwaylandintegration.cpp b/src/plugins/platforms/wayland/qwaylandintegration.cpp > index 19f339a..82789c8 100644 > --- a/src/plugins/platforms/wayland/qwaylandintegration.cpp > +++ b/src/plugins/platforms/wayland/qwaylandintegration.cpp > @@ -25,7 +25,7 @@ public: > ? ? QWaylandCursor(QWaylandDisplay *display, > ? ? ? ? ? ? ? ? ? QPlatformScreen *screen) > ? ? ? ?: QPlatformCursor(screen) > - ? ? ? , mDisplay(display) { } > + ? ? ? , mBuffer(0), mDisplay(display) { } > > ? ? void changeCursor(QCursor *cursor, QWidget *widget); > ? ? QWaylandShmBuffer *mBuffer; > -- > 1.7.3.2 > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From krh at bitplanet.net Mon Nov 29 13:27:45 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 29 Nov 2010 16:27:45 -0500 Subject: Who is working on the non-drawing parts? In-Reply-To: <20101126034349.5076243e@lighthouse> References: <4CED1647.9010804@comcast.net> <4CED52E2.6080608@comcast.net> <20101126034349.5076243e@lighthouse> Message-ID: On Thu, Nov 25, 2010 at 9:43 PM, Gerry JJ wrote: > Den Wed, 24 Nov 2010 13:01:06 -0500 > skrev Marty Jack : >> Also, I don't yet fully buy >> into the part about no client controlled window placement. ?We need >> some way for docks to position themselves appropriately. > > Client controlled window placement is important. ?Without it, you > can't restore multi-window sessions properly (or even single-window, if > position matters), splash screens won't be centered as they should be, > dialog boxes will pop up at random positions, and whatever else that > wants to put specific windows at specific positions on the screen for > other (possibly good) reasons won't work. ?Some things may have less > valid reasons, but that's a tiny issue compared to not being able to do > all those things properly under Wayland. All of those can be handled by the compositor. The key is to let the compositor know what kind of window you're showing and how it relates to your other windows. Once the compositor knows whether you're showing a new toplevel window, a dialog box for an existing window or a popup menu, the compositor/wm is always in a better position than the client to determine where that window should be. The core of the issue is that the compositor may at any time be applying transformations to the clients windows that it can't express to the client. If a client computes the exact location of a dialog box or popup menu, there is an implicit assumption that the client knows it current location and can compute from that a good location for the new window. That's just not the case in a composited environment and it's one of the assumption that makes it impossible to really fix input redirection. (Disclaimer: session management isn't even at the hand-waving stage yet, but I'm pretty sure we can deal with that without requiring clients to specific their position on screen). Kristian From fred.morcos at gmail.com Mon Nov 29 14:30:37 2010 From: fred.morcos at gmail.com (Fred Morcos) Date: Mon, 29 Nov 2010 23:30:37 +0100 Subject: Who is working on the non-drawing parts? In-Reply-To: References: <4CED1647.9010804@comcast.net> <4CED52E2.6080608@comcast.net> <20101126034349.5076243e@lighthouse> Message-ID: 2010/11/29 Kristian H?gsberg : > On Thu, Nov 25, 2010 at 9:43 PM, Gerry JJ wrote: >> Den Wed, 24 Nov 2010 13:01:06 -0500 >> skrev Marty Jack : >>> Also, I don't yet fully buy >>> into the part about no client controlled window placement. ?We need >>> some way for docks to position themselves appropriately. >> >> Client controlled window placement is important. ?Without it, you >> can't restore multi-window sessions properly (or even single-window, if >> position matters), splash screens won't be centered as they should be, >> dialog boxes will pop up at random positions, and whatever else that >> wants to put specific windows at specific positions on the screen for >> other (possibly good) reasons won't work. ?Some things may have less >> valid reasons, but that's a tiny issue compared to not being able to do >> all those things properly under Wayland. > > All of those can be handled by the compositor. ?The key is to let the > compositor know what kind of window you're showing and how it relates > to your other windows. ?Once the compositor knows whether you're > showing a new toplevel window, a dialog box for an existing window or > a popup menu, the compositor/wm is always in a better position than > the client to determine where that window should be. ?The core of the > issue is that the compositor may at any time be applying > transformations to the clients windows that it can't express to the > client. ?If a client computes the exact location of a dialog box or > popup menu, there is an implicit assumption that the client knows it > current location and can compute from that a good location for the new > window. ?That's just not the case in a composited environment and it's > one of the assumption that makes it impossible to really fix input > redirection. > > (Disclaimer: session management isn't even at the hand-waving stage > yet, but I'm pretty sure we can deal with that without requiring > clients to specific their position on screen). > > Kristian > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > I second Kristian's opinion. Panels can request certain placements in sequence of their priorities (left, right, top-left, ...) and the compositor will be the best to decide which area is free (non-overlapping with any other panels already running) to contain that panel. I find that quite nice but also limiting. I wonder, isn't that problem analogous to the client-side decorations? Allowing client-side decorations but rejecting client-side placement seems hypocritical to me. I really think the X way (server, wm and clients) is the best way and truly is one-size-fits-all. A humble idea that I thought of was to have: wayland <-> [compositor <-> decorator] <-> clients (where <-> denotes talks-to)... But that looks awfully familiar... Regards, Fred Morcos From dana at orodu.net Mon Nov 29 14:38:23 2010 From: dana at orodu.net (Dana Jansens) Date: Mon, 29 Nov 2010 17:38:23 -0500 Subject: Who is working on the non-drawing parts? In-Reply-To: References: <4CED1647.9010804@comcast.net> <4CED52E2.6080608@comcast.net> <20101126034349.5076243e@lighthouse> Message-ID: 2010/11/29 Fred Morcos > 2010/11/29 Kristian H?gsberg : > > On Thu, Nov 25, 2010 at 9:43 PM, Gerry JJ wrote: > >> Den Wed, 24 Nov 2010 13:01:06 -0500 > >> skrev Marty Jack : > >>> Also, I don't yet fully buy > >>> into the part about no client controlled window placement. We need > >>> some way for docks to position themselves appropriately. > >> > >> Client controlled window placement is important. Without it, you > >> can't restore multi-window sessions properly (or even single-window, if > >> position matters), splash screens won't be centered as they should be, > >> dialog boxes will pop up at random positions, and whatever else that > >> wants to put specific windows at specific positions on the screen for > >> other (possibly good) reasons won't work. Some things may have less > >> valid reasons, but that's a tiny issue compared to not being able to do > >> all those things properly under Wayland. > > > > All of those can be handled by the compositor. The key is to let the > > compositor know what kind of window you're showing and how it relates > > to your other windows. Once the compositor knows whether you're > > showing a new toplevel window, a dialog box for an existing window or > > a popup menu, the compositor/wm is always in a better position than > > the client to determine where that window should be. The core of the > > issue is that the compositor may at any time be applying > > transformations to the clients windows that it can't express to the > > client. If a client computes the exact location of a dialog box or > > popup menu, there is an implicit assumption that the client knows it > > current location and can compute from that a good location for the new > > window. That's just not the case in a composited environment and it's > > one of the assumption that makes it impossible to really fix input > > redirection. > > > > (Disclaimer: session management isn't even at the hand-waving stage > > yet, but I'm pretty sure we can deal with that without requiring > > clients to specific their position on screen). > > > > Kristian > > _______________________________________________ > > wayland-devel mailing list > > wayland-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > I second Kristian's opinion. Panels can request certain placements in > sequence of their priorities (left, right, top-left, ...) and the > compositor will be the best to decide which area is free > (non-overlapping with any other panels already running) to contain > that panel. I find that quite nice but also limiting. > One big problem in the current iteration of the wm-spec under X is that multiple panels sharing the edge conflict and there is no nice way atm to specify their positions properly. The WM is in control of behaviour, but then various WMs give various amounts of control to applications, which then come to depend on it to work properly. Which in the end means that apps only work correctly under some WMs. I think personally that all control of behaviour should be in the WM. It is only as limiting as the protocol/interface which really is unbounded. > I wonder, isn't that problem analogous to the client-side decorations? > Allowing client-side decorations but rejecting client-side placement > seems hypocritical to me. > They are completely orthogonal issues, so I don't agree. One is visible drawing of the window, and one is behaviour. > I really think the X way (server, wm and clients) is the best way and > truly is one-size-fits-all. A humble idea that I thought of was to > have: > wayland <-> [compositor <-> decorator] <-> clients (where <-> denotes > talks-to)... But that looks awfully familiar... > Well, wayland is the compositor, so there is no use separating them out here. This is just describing the X server environment, which you stated you like, but a wayland compositor is a different kind of environment. - Dana > > Regards, > Fred Morcos > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krh at bitplanet.net Mon Nov 29 14:43:34 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 29 Nov 2010 17:43:34 -0500 Subject: [PATCH 0/2] Add nested/session-compositor backend In-Reply-To: <1290881052-19088-1-git-send-email-benjaminfranzke@googlemail.com> References: <1290881052-19088-1-git-send-email-benjaminfranzke@googlemail.com> Message-ID: On Sat, Nov 27, 2010 at 1:04 PM, Benjamin Franzke wrote: > This patches add support for a nested compositor as client > of X11,DRM-compositor or of course itself. > > sample textcase: > ? ? ? ?compositor/compositor -b /path/to/your/bg --socket wayland2 & > ? ? ? ?# for testing a smaller compositor is fine > ? ? ? ?WAYLAND_DISPLAY="wayland2" compositor/compositor -g 800x600 & > ? ? ? ?clients/flower & > ? ? ? ?clients/terminal & Yup, very nice, I've applied the patches. As we talked about in irc, there are few open issues still such as the cursor issue (we should just not draw a cursor when nesting under wayland) but I'm happy to see how little code this turned out to be. I fixed up the frame/sync clashes before pushing your patches so that part should be fine. > The support for $WAYLAND_DISPLAY still needs to be added to the clients. Yeah, that would be nice. Kristian From martyj19 at comcast.net Mon Nov 29 15:02:33 2010 From: martyj19 at comcast.net (Marty Jack) Date: Mon, 29 Nov 2010 18:02:33 -0500 Subject: Who is working on the non-drawing parts? In-Reply-To: References: <4CED1647.9010804@comcast.net> <4CED52E2.6080608@comcast.net> <20101126034349.5076243e@lighthouse> Message-ID: <4CF43109.1000002@comcast.net> Okay, let us take the setup I am running with. I have two monitors Screen 0: minimum 320 x 200, current 3600 x 1080, maximum 8192 x 8192 HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm HDMI2 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 433mm x 271mm I am running experimental non-released LXDE. I have three panels configured. One is on the bottom of HDMI1 so is at (0,1080-h) to (1920,1080) One is on the bottom of HDMI2 so is at (1920,1050-h) to (3600,1050) One is at the left of HDMI2 and configured to be of dynamic height so is at (1920,y1) to (1920+w,y2) where y1 and y2 vary depending on what is in the window at any given moment. I also have different backgrounds on the two monitors. Moreover, for one example, when I pop up a task control popup or the volume control slider, I want it to be next to its button, but not covering anything on the panel. I have it so that the entire panel is one X window and would intend for it to be only one Wayland window, so only I know where the button is. If someone can explain to me how some simple hinting to the compositor will get this done, I am listening. But I suspect you cannot. I am confident there are other applications that will want the level of control that they have now. I agree for simple application use cases, totally compositor controlled placement will work fine. You may find you limit the rate of adoption of your new stuff the more you limit the use cases that it works properly with. I do agree the Strut concept in EWMH is very weak in terms of semantics and being able to do all that is needed, especially with big virtual root. That is one of the things we should discuss when I come out with the EWMH-for-Wayland proposal I have promised. I have a screenshot of this with the task control popup and a regular dialog also popped up if anyone needed it to understand what it looks like. On 11/29/2010 04:27 PM, Kristian H?gsberg wrote: > On Thu, Nov 25, 2010 at 9:43 PM, Gerry JJ wrote: >> Den Wed, 24 Nov 2010 13:01:06 -0500 >> skrev Marty Jack : >>> Also, I don't yet fully buy >>> into the part about no client controlled window placement. We need >>> some way for docks to position themselves appropriately. >> >> Client controlled window placement is important. Without it, you >> can't restore multi-window sessions properly (or even single-window, if >> position matters), splash screens won't be centered as they should be, >> dialog boxes will pop up at random positions, and whatever else that >> wants to put specific windows at specific positions on the screen for >> other (possibly good) reasons won't work. Some things may have less >> valid reasons, but that's a tiny issue compared to not being able to do >> all those things properly under Wayland. > > All of those can be handled by the compositor. The key is to let the > compositor know what kind of window you're showing and how it relates > to your other windows. Once the compositor knows whether you're > showing a new toplevel window, a dialog box for an existing window or > a popup menu, the compositor/wm is always in a better position than > the client to determine where that window should be. The core of the > issue is that the compositor may at any time be applying > transformations to the clients windows that it can't express to the > client. If a client computes the exact location of a dialog box or > popup menu, there is an implicit assumption that the client knows it > current location and can compute from that a good location for the new > window. That's just not the case in a composited environment and it's > one of the assumption that makes it impossible to really fix input > redirection. > > (Disclaimer: session management isn't even at the hand-waving stage > yet, but I'm pretty sure we can deal with that without requiring > clients to specific their position on screen). > > Kristian > From krh at bitplanet.net Mon Nov 29 15:49:38 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 29 Nov 2010 18:49:38 -0500 Subject: Who is working on the non-drawing parts? In-Reply-To: <4CF43109.1000002@comcast.net> References: <4CED1647.9010804@comcast.net> <4CED52E2.6080608@comcast.net> <20101126034349.5076243e@lighthouse> <4CF43109.1000002@comcast.net> Message-ID: 2010/11/29 Marty Jack : > Okay, let us take the setup I am running with. ?I have two monitors > > Screen 0: minimum 320 x 200, current 3600 x 1080, maximum 8192 x 8192 > HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm > HDMI2 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 433mm x 271mm > > I am running experimental non-released LXDE. ?I have three panels configured. > One is on the bottom of HDMI1 so is at (0,1080-h) to (1920,1080) > One is on the bottom of HDMI2 so is at (1920,1050-h) to (3600,1050) > One is at the left of HDMI2 and configured to be of dynamic height so is at (1920,y1) to (1920+w,y2) > > where y1 and y2 vary depending on what is in the window at any given moment. > > I also have different backgrounds on the two monitors. > > Moreover, for one example, when I pop up a task control popup or the volume control slider, I want it to be next to its button, but not covering anything on the panel. ?I have it so that the entire panel is one X window and would intend for it to be only one Wayland window, so only I know where the button is. > > If someone can explain to me how some simple hinting to the compositor will get this done, I am listening. ?But I suspect you cannot. ?I am confident there are other applications that will want the level of control that they have now. I think you more or less described the solution: you don't want to specify absolute position of that popup or volume slider, you want it "next to" the button in the panel. One of the planned window hints is "overlay for surface", which lets you specify an offset of a surface relative to a parent surface. The panel can be positioned by specifying that it's a top-left, bottom-right surface or such. Or alternatively, the entire panel with popups and all could be part of the compositor/wm. In general, there is never really a good reason for any client to specify an absolute, arbitrary position. It will always be some function of the position of an existing surface, a pointer or screen edge and that relation ship can be communicated to the compositor. Kristian From christoph.frieben at googlemail.com Tue Nov 30 00:31:32 2010 From: christoph.frieben at googlemail.com (Christoph Frieben) Date: Tue, 30 Nov 2010 09:31:32 +0100 Subject: Incompatible pointer type in dnd.c Message-ID: dnd.c: In function ?drop_io_func?: dnd.c:362:2: warning: passing argument 4 of ?g_io_channel_read_chars? from incompatible pointer type /usr/include/glib-2.0/glib/giochannel.h:247:11: note: expected ?gsize *? but argument is of type ?unsigned int *? Issued by GCC 4.5.1. ~C From alexander.preisinger at gmail.com Tue Nov 30 01:15:16 2010 From: alexander.preisinger at gmail.com (Alexander Preisinger) Date: Tue, 30 Nov 2010 10:15:16 +0100 Subject: Incompatible pointer type in dnd.c In-Reply-To: References: Message-ID: Here is the patch for it. My very first patch ever :). 2010/11/30 Christoph Frieben : > dnd.c: In function ?drop_io_func?: > dnd.c:362:2: warning: passing argument 4 of ?g_io_channel_read_chars? > from incompatible pointer type > /usr/include/glib-2.0/glib/giochannel.h:247:11: note: expected ?gsize > *? but argument is of type ?unsigned int *? > > Issued by GCC 4.5.1. > ~C > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: dnd.patch Type: text/x-patch Size: 399 bytes Desc: not available URL: From joel at teichroeb.net Tue Nov 30 10:22:13 2010 From: joel at teichroeb.net (Joel Teichroeb) Date: Tue, 30 Nov 2010 10:22:13 -0800 Subject: [PATCH 1/4] Made the window save the coordinates when being draged. Message-ID: <1291141336-7890-1-git-send-email-joel@teichroeb.net> --- clients/window.c | 18 ++++++++++-------- 1 files changed, 10 insertions(+), 8 deletions(-) diff --git a/clients/window.c b/clients/window.c index 3860d1e..f720bf8 100644 --- a/clients/window.c +++ b/clients/window.c @@ -1018,14 +1018,16 @@ handle_configure(void *data, struct wl_shell *shell, window->pending_allocation.width = width; window->pending_allocation.height = height; - if (!(edges & 15)) - return; - - if (window->resize_handler) - (*window->resize_handler)(window, - window->user_data); - else if (window->redraw_handler) - window_schedule_redraw(window); + if (edges & WINDOW_TITLEBAR) { + window->allocation.x = window->pending_allocation.x; + window->allocation.y = window->pending_allocation.y; + } else if (edges & WINDOW_RESIZING_MASK) { + if (window->resize_handler) + (*window->resize_handler)(window, + window->user_data); + else if (window->redraw_handler) + window_schedule_redraw(window); + } } static const struct wl_shell_listener shell_listener = { -- 1.7.3.2 From joel at teichroeb.net Tue Nov 30 10:22:14 2010 From: joel at teichroeb.net (Joel Teichroeb) Date: Tue, 30 Nov 2010 10:22:14 -0800 Subject: [PATCH 2/4] Removed default drag types. In-Reply-To: <1291141336-7890-1-git-send-email-joel@teichroeb.net> References: <1291141336-7890-1-git-send-email-joel@teichroeb.net> Message-ID: <1291141336-7890-2-git-send-email-joel@teichroeb.net> The window no longer assumes that the client wants to have text/plain and text/html draged onto it. The client will have to tell wayland about the things it wants dragged manually. --- clients/window.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/clients/window.c b/clients/window.c index f720bf8..f91977e 100644 --- a/clients/window.c +++ b/clients/window.c @@ -996,8 +996,6 @@ window_start_drag(struct window *window, struct input *input, uint32_t time, cairo_device_flush (window->display->device); drag = wl_shell_create_drag(window->display->shell); - wl_drag_offer(drag, "text/plain"); - wl_drag_offer(drag, "text/html"); wl_drag_activate(drag, window->surface, input->input_device, time); wl_drag_add_listener(drag, listener, data); -- 1.7.3.2 From joel at teichroeb.net Tue Nov 30 10:22:15 2010 From: joel at teichroeb.net (Joel Teichroeb) Date: Tue, 30 Nov 2010 10:22:15 -0800 Subject: [PATCH 3/4] Added a reject method to drag_offer. In-Reply-To: <1291141336-7890-1-git-send-email-joel@teichroeb.net> References: <1291141336-7890-1-git-send-email-joel@teichroeb.net> Message-ID: <1291141336-7890-3-git-send-email-joel@teichroeb.net> Currently reject just calles drag_finish and does not bother with any fd stuff. In the future this should be extended to tell the compositor to do some kind of animation when a drag is rejected. --- compositor/compositor.c | 13 ++++++++++++- protocol/wayland.xml | 4 ++++ 2 files changed, 16 insertions(+), 1 deletions(-) diff --git a/compositor/compositor.c b/compositor/compositor.c index cbb0b6b..1a7a44f 100644 --- a/compositor/compositor.c +++ b/compositor/compositor.c @@ -1137,9 +1137,20 @@ drag_offer_receive(struct wl_client *client, close(fd); } +static void +drag_offer_reject(struct wl_client *client, + struct wl_drag_offer *offer) +{ + struct wl_drag *drag = container_of(offer, struct wl_drag, drag_offer); + + wl_client_post_event(drag->source->client, &drag->resource.base, + WL_DRAG_FINISH, -1); +} + static const struct wl_drag_offer_interface drag_offer_interface = { drag_offer_accept, - drag_offer_receive + drag_offer_receive, + drag_offer_reject }; static void diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 24c53c2..edfa130 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -226,6 +226,10 @@ + + + -- 1.7.3.2 From joel at teichroeb.net Tue Nov 30 10:22:16 2010 From: joel at teichroeb.net (Joel Teichroeb) Date: Tue, 30 Nov 2010 10:22:16 -0800 Subject: [PATCH 4/4] Make the DND client actually work. In-Reply-To: <1291141336-7890-1-git-send-email-joel@teichroeb.net> References: <1291141336-7890-1-git-send-email-joel@teichroeb.net> Message-ID: <1291141336-7890-4-git-send-email-joel@teichroeb.net> The DND client now sends a "application/x-wayland-dnd-flower" instead of "text/plain". Made each flower keep its own seed. This may change in the future, but this is a good starting point. Added a simple reference counter for dnd_offer so that it will be freed if the flower is dragged out of the window and not freed when dropped, untill it is done with. This reference counter is not used everywhere beucase there are only two places where the dnd_offer should be destroyed. Fixed a crash with using g_io_channel_read_chars by using read instead. Used the new wl_drag_offer_reject to tell the client that their drag was not wanted so they can reset the flower. Some animation from the compositor could come in the future. --- clients/dnd.c | 154 +++++++++++++++++++++++++++++++++++++++++++++------------ 1 files changed, 122 insertions(+), 32 deletions(-) diff --git a/clients/dnd.c b/clients/dnd.c index dedf353..b902a67 100644 --- a/clients/dnd.c +++ b/clients/dnd.c @@ -53,6 +53,9 @@ struct dnd_drag { struct dnd *dnd; struct input *input; uint32_t time; + struct item *item; + int x_offset, y_offset; + const char *mime_type; }; struct dnd_offer { @@ -60,20 +63,43 @@ struct dnd_offer { struct wl_array types; const char *drag_type; uint32_t tag; + int x, y; + + /* Reference counting to see if the dnd_offer should be freed + * when the surface is null. */ + int refs; }; struct item { cairo_surface_t *surface; + int seed; int x, y; }; +struct dnd_flower_message { + int seed, x_offset, y_offset; +}; + + static const int item_width = 64; static const int item_height = 64; static const int item_padding = 16; static struct item * -item_create(struct display *display, int x, int y) +item_create(struct display *display, int x, int y, int seed) { + struct item *item; + struct timeval tv; + + item = malloc(sizeof *item); + if (item == NULL) + return NULL; + + + gettimeofday(&tv, NULL); + item->seed = seed ? seed : tv.tv_usec; + srandom(item->seed); + const int petal_count = 3 + random() % 5; const double r1 = 20 + random() % 10; const double r2 = 5 + random() % 12; @@ -85,11 +111,7 @@ item_create(struct display *display, int x, int y) double t, dt = 2 * M_PI / (petal_count * 2); double x1, y1, x2, y2, x3, y3; struct rectangle rect; - struct item *item; - item = malloc(sizeof *item); - if (item == NULL) - return NULL; rect.width = item_width; rect.height = item_height; @@ -206,6 +228,31 @@ keyboard_focus_handler(struct window *window, window_schedule_redraw(dnd->window); } +static void +dnd_offer_destroy(struct dnd_offer *dnd_offer) +{ + if (dnd_offer->refs <= 0) { + wl_array_release(&dnd_offer->types); + free(dnd_offer); + } else { + --dnd_offer->refs; + } +} + +static int +dnd_add_item(struct dnd *dnd, struct item *item) +{ + int i; + + for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) { + if (dnd->items[i] == 0) { + dnd->items[i] = item; + return i; + } + } + return -1; +} + static struct item * dnd_get_item(struct dnd *dnd, int32_t x, int32_t y) { @@ -241,6 +288,7 @@ drag_target(void *data, fprintf(stderr, "target %s\n", mime_type); device = input_get_input_device(dnd_drag->input); + dnd_drag->mime_type = mime_type; if (mime_type) surface = dnd_drag->opaque; else @@ -255,17 +303,35 @@ static void drag_finish(void *data, struct wl_drag *drag, int fd) { struct dnd_drag *dnd_drag = data; - char text[] = "[drop data]"; - fprintf(stderr, "got 'finish', fd %d, sending message\n", fd); + if (!dnd_drag->mime_type) { + dnd_add_item(dnd_drag->dnd, dnd_drag->item); + window_schedule_redraw(dnd_drag->dnd->window); + return; + } + + struct dnd_flower_message dnd_flower_message; + + + dnd_flower_message.seed = dnd_drag->item->seed; + + dnd_flower_message.x_offset = dnd_drag->x_offset; + dnd_flower_message.y_offset = dnd_drag->y_offset; + + fprintf(stderr, "got 'finish', fd %d, sending dnd_flower_message\n", fd); - write(fd, text, sizeof text); + write(fd, &dnd_flower_message, sizeof dnd_flower_message); close(fd); /* The 'finish' event marks the end of the session on the drag * source side and we need to clean up the drag object created * and the local state. */ wl_drag_destroy(drag); + + /* Destroy the item that has been dragged out */ + cairo_surface_destroy(dnd_drag->item->surface); + free(dnd_drag->item); + cairo_surface_destroy(dnd_drag->translucent); cairo_surface_destroy(dnd_drag->opaque); free(dnd_drag); @@ -305,9 +371,8 @@ drag_offer_pointer_focus(void *data, * allocated. */ if (!surface) { fprintf(stderr, "pointer focus NULL, session over\n"); - wl_array_release(&dnd_offer->types); - free(dnd_offer); wl_drag_offer_destroy(offer); + dnd_offer_destroy(dnd_offer); return; } @@ -321,8 +386,8 @@ drag_offer_pointer_focus(void *data, dnd_offer->dnd = window_get_user_data(window); if (!dnd_get_item(dnd_offer->dnd, surface_x, surface_y)) { - wl_drag_offer_accept(offer, time, "text/plain"); - dnd_offer->drag_type = "text/plain"; + wl_drag_offer_accept(offer, time, "application/x-wayland-dnd-flower"); + dnd_offer->drag_type = "application/x-wayland-dnd-flower"; } else { wl_drag_offer_accept(offer, time, NULL); dnd_offer->drag_type = NULL; @@ -335,13 +400,14 @@ drag_offer_motion(void *data, int32_t x, int32_t y, int32_t surface_x, int32_t surface_y) { struct dnd_offer *dnd_offer = data; - struct dnd *dnd = dnd_offer->dnd; - if (!dnd_get_item(dnd, surface_x, surface_y)) { + if (!dnd_get_item(dnd_offer->dnd, surface_x, surface_y)) { fprintf(stderr, "drag offer motion %d, %d, accepting\n", surface_x, surface_y); - wl_drag_offer_accept(offer, time, "text/plain"); - dnd_offer->drag_type = "text/plain"; + wl_drag_offer_accept(offer, time, "application/x-wayland-dnd-flower"); + dnd_offer->drag_type = "application/x-wayland-dnd-flower"; + dnd_offer->x = surface_x; + dnd_offer->y = surface_y; } else { fprintf(stderr, "drag offer motion %d, %d, declining\n", surface_x, surface_y); @@ -354,19 +420,31 @@ static gboolean drop_io_func(GIOChannel *source, GIOCondition condition, gpointer data) { struct dnd_offer *dnd_offer = data; - char buffer[256]; + struct dnd *dnd = dnd_offer->dnd; + struct dnd_flower_message dnd_flower_message; int fd; unsigned int len; - GError *err = NULL; - g_io_channel_read_chars(source, buffer, sizeof buffer, &len, &err); - fprintf(stderr, "read %d bytes: %s\n", len, buffer); fd = g_io_channel_unix_get_fd(source); + len = read(fd, &dnd_flower_message, sizeof dnd_flower_message); + fprintf(stderr, "read %d bytes\n", len); + close(fd); g_source_remove(dnd_offer->tag); g_io_channel_unref(source); - + + + struct item *item = item_create(dnd->display, + dnd_offer->x-dnd_flower_message.x_offset-26, + dnd_offer->y-dnd_flower_message.y_offset-66, + dnd_flower_message.seed); + + dnd_add_item(dnd, item); + window_schedule_redraw(dnd->window); + + dnd_offer_destroy(dnd_offer); + return TRUE; } @@ -379,15 +457,14 @@ drag_offer_drop(void *data, struct wl_drag_offer *offer) if (!dnd_offer->drag_type) { fprintf(stderr, "got 'drop', but no target\n"); - /* FIXME: Should send response so compositor and - * source knows it's over. Can't send -1 to indicate - * 'no target' though becauses of the way fd passing - * currently works. */ + wl_drag_offer_reject(offer); return; } fprintf(stderr, "got 'drop', sending write end of pipe\n"); + ++dnd_offer->refs; + pipe(p); wl_drag_offer_receive(offer, p[1]); close(p[1]); @@ -412,6 +489,8 @@ drag_offer_handler(struct wl_drag_offer *offer, struct display *display) dnd_offer = malloc(sizeof *dnd_offer); if (dnd_offer == NULL) return; + + dnd_offer->refs = 0; wl_drag_offer_add_listener(offer, &drag_offer_listener, dnd_offer); wl_array_init(&dnd_offer->types); @@ -477,6 +556,7 @@ dnd_button_handler(struct window *window, struct item *item; struct rectangle rectangle; struct dnd_drag *dnd_drag; + int i; window_get_child_rectangle(dnd->window, &rectangle); input_get_position(input, &x, &y); @@ -491,14 +571,28 @@ dnd_button_handler(struct window *window, dnd_drag->dnd = dnd; dnd_drag->input = input; dnd_drag->time = time; + dnd_drag->item = item; + dnd_drag->x_offset = x - item->x; + dnd_drag->y_offset = y - item->y; + + for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) { + if (item == dnd->items[i]){ + dnd->items[i] = 0; + break; + } + } dnd_drag->opaque = create_drag_cursor(dnd_drag, item, x, y, 1); dnd_drag->translucent = create_drag_cursor(dnd_drag, item, x, y, 0.2); - window_start_drag(window, input, time, - &drag_listener, dnd_drag); + struct wl_drag *wl_drag = + window_start_drag(window, input, time, + &drag_listener, dnd_drag); + + wl_drag_offer(wl_drag, "application/x-wayland-dnd-flower"); + window_schedule_redraw(dnd->window); } } @@ -542,7 +636,7 @@ dnd_create(struct display *display) x = (i % 4) * (item_width + item_padding) + item_padding; y = (i / 4) * (item_height + item_padding) + item_padding; if ((i ^ (i >> 2)) & 1) - dnd->items[i] = item_create(display, x, y); + dnd->items[i] = item_create(display, x, y, 0); else dnd->items[i] = NULL; } @@ -575,10 +669,6 @@ main(int argc, char *argv[]) { struct display *d; struct dnd *dnd; - struct timeval tv; - - gettimeofday(&tv, NULL); - srandom(tv.tv_usec); d = display_create(&argc, &argv, option_entries); if (d == NULL) { -- 1.7.3.2 From krh at bitplanet.net Tue Nov 30 11:03:41 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Tue, 30 Nov 2010 14:03:41 -0500 Subject: [PATCH 2/4] Removed default drag types. In-Reply-To: <1291141336-7890-2-git-send-email-joel@teichroeb.net> References: <1291141336-7890-1-git-send-email-joel@teichroeb.net> <1291141336-7890-2-git-send-email-joel@teichroeb.net> Message-ID: On Tue, Nov 30, 2010 at 1:22 PM, Joel Teichroeb wrote: > The window no longer assumes that the client wants to have text/plain > and text/html draged onto it. The client will have to tell wayland about > the things it wants dragged manually. I ended up doing this a little differently. We need to call wl_drag_offer() before activating the drag, so I split the window helper function into create and activate functions. Kristia > --- > ?clients/window.c | ? ?2 -- > ?1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/clients/window.c b/clients/window.c > index f720bf8..f91977e 100644 > --- a/clients/window.c > +++ b/clients/window.c > @@ -996,8 +996,6 @@ window_start_drag(struct window *window, struct input *input, uint32_t time, > ? ? ? ?cairo_device_flush (window->display->device); > > ? ? ? ?drag = wl_shell_create_drag(window->display->shell); > - ? ? ? wl_drag_offer(drag, "text/plain"); > - ? ? ? wl_drag_offer(drag, "text/html"); > ? ? ? ?wl_drag_activate(drag, window->surface, input->input_device, time); > ? ? ? ?wl_drag_add_listener(drag, listener, data); > > -- > 1.7.3.2 > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From krh at bitplanet.net Tue Nov 30 11:04:07 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Tue, 30 Nov 2010 14:04:07 -0500 Subject: [PATCH 1/4] Made the window save the coordinates when being draged. In-Reply-To: <1291141336-7890-1-git-send-email-joel@teichroeb.net> References: <1291141336-7890-1-git-send-email-joel@teichroeb.net> Message-ID: On Tue, Nov 30, 2010 at 1:22 PM, Joel Teichroeb wrote: Thanks, committed. Kristian > --- > ?clients/window.c | ? 18 ++++++++++-------- > ?1 files changed, 10 insertions(+), 8 deletions(-) > > diff --git a/clients/window.c b/clients/window.c > index 3860d1e..f720bf8 100644 > --- a/clients/window.c > +++ b/clients/window.c > @@ -1018,14 +1018,16 @@ handle_configure(void *data, struct wl_shell *shell, > ? ? ? ?window->pending_allocation.width = width; > ? ? ? ?window->pending_allocation.height = height; > > - ? ? ? if (!(edges & 15)) > - ? ? ? ? ? ? ? return; > - > - ? ? ? if (window->resize_handler) > - ? ? ? ? ? ? ? (*window->resize_handler)(window, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? window->user_data); > - ? ? ? else if (window->redraw_handler) > - ? ? ? ? ? ? ? window_schedule_redraw(window); > + ? ? ? if (edges & WINDOW_TITLEBAR) { > + ? ? ? ? ? ? ? window->allocation.x = window->pending_allocation.x; > + ? ? ? ? ? ? ? window->allocation.y = window->pending_allocation.y; > + ? ? ? } else if (edges & WINDOW_RESIZING_MASK) { > + ? ? ? ? ? ? ? if (window->resize_handler) > + ? ? ? ? ? ? ? ? ? ? ? (*window->resize_handler)(window, > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? window->user_data); > + ? ? ? ? ? ? ? else if (window->redraw_handler) > + ? ? ? ? ? ? ? ? ? ? ? window_schedule_redraw(window); > + ? ? ? } > ?} > > ?static const struct wl_shell_listener shell_listener = { > -- > 1.7.3.2 > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > From krh at bitplanet.net Tue Nov 30 12:16:16 2010 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Tue, 30 Nov 2010 15:16:16 -0500 Subject: [PATCH 3/4] Added a reject method to drag_offer. In-Reply-To: <1291141336-7890-3-git-send-email-joel@teichroeb.net> References: <1291141336-7890-1-git-send-email-joel@teichroeb.net> <1291141336-7890-3-git-send-email-joel@teichroeb.net> Message-ID: On Tue, Nov 30, 2010 at 1:22 PM, Joel Teichroeb wrote: > Currently reject just calles drag_finish and does not bother with any fd > stuff. In the future this should be extended to tell the compositor to > do some kind of animation when a drag is rejected. I ended up redoing this one as well - we can't send -1 as a illegal fd, that means the event sent to the drag source can't have fd = -1 either. I added a reject event to the drag interface. Kristian > --- > ?compositor/compositor.c | ? 13 ++++++++++++- > ?protocol/wayland.xml ? ?| ? ?4 ++++ > ?2 files changed, 16 insertions(+), 1 deletions(-) > > diff --git a/compositor/compositor.c b/compositor/compositor.c > index cbb0b6b..1a7a44f 100644 > --- a/compositor/compositor.c > +++ b/compositor/compositor.c > @@ -1137,9 +1137,20 @@ drag_offer_receive(struct wl_client *client, > ? ? ? ?close(fd); > ?} > > +static void > +drag_offer_reject(struct wl_client *client, > + ? ? ? ? ? ? ? ? ?struct wl_drag_offer *offer) > +{ > + ? ? ? struct wl_drag *drag = container_of(offer, struct wl_drag, drag_offer); > + > + ? ? ? wl_client_post_event(drag->source->client, &drag->resource.base, > + ? ? ? ? ? ? ? ? ? ? ? ? ? ?WL_DRAG_FINISH, -1); > +} > + > ?static const struct wl_drag_offer_interface drag_offer_interface = { > ? ? ? ?drag_offer_accept, > - ? ? ? drag_offer_receive > + ? ? ? drag_offer_receive, > + ? ? ? drag_offer_reject > ?}; > > ?static void > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 24c53c2..edfa130 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -226,6 +226,10 @@ > ? ? ? > ? ? > > + ? ? > + ? ? > + > ? ? > ? ? > -- > 1.7.3.2 > > _______________________________________________ > wayland-devel mailing list > wayland-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel >