Re: Window placement
On Wed, 2 Jul 2014 20:57:47 +0200 Fabrice Rey faboune...@gmail.com wrote: Why does it not have a parent window, if it is a normal application? There is only 1 window in this application; there is no menu or whatever. The circular menu is just its name, it's not even a menu. It's an application that owns a surface to display stuff on it, and has to place this surface centered on the mouse. Sounds like it is not a normal application but a component of the DE, Nope, it's a regular application that can work on any Window Manager currently, and should be able to work on any Compositor as well. No, your video of the thing proves, that it really is a DE component, see my other reply today. It sounds more like a DE feature. As I said to Bill, there is currently such an application, and it's not linked to Gnome/KDE/any-DE. Really it shouldn't, we need to have compositor-agnostic applications. If KDE apps start to not work under Gnome, we're in a serious trouble. That thing is not a normal desktop application. It is only an artefact of the unsecurity and lack of policy of the X11 protocol, that you can actually write such generic but global can-do-whatever apps. The X11 server is really a slave to all the clients. A Wayland server is not. The whole premise you are assuming here is not what we have in mind for Wayland. I explain that in my other email. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Window placement
On Wed, 2 Jul 2014 16:16:36 -0700 Jason Gerecke killert...@gmail.com wrote: On Wed, Jul 2, 2014 at 3:33 PM, Fabrice Rey faboune...@gmail.com wrote: The question is: what action triggers it to make this ring of icons appear? A global shortkey (and yes I know it's not yet possible on Wayland, that's another problem on its own). What's the application doing? Does it have keyboard focus but is potentially not under the mouse pointer? Do you have a screenshot or video of this feature you can share? I'm not the developper of it, I actually don't even use it ^^ I was just thinking of it to see how it would fit in Wayland, what's potentially missing now in the protocol. Here is an article about it: http://www.webupd8.org/2011/10/gnome-pie-02-released.html and a video: https://www.youtube.com/watch?v=TFQDyZyMxO4. Basically, it appears under the mouse when you trigger the shortkey, and you can also use the keyboard to navigate in the items. So I see 2 main points here: - it places its window not relatively to a parent (which there is not), but to the mouse - it takes the (keyboard) focus when it appears The second point is not related to this topic, so we can probably think of it later. This reminds me of a something similar[1] that comes with the Wacom drivers on Windows and Mac. Its not a normal application that you would open, interact with, (possibly switch away from temporarily), and close. Rather, the application sits in the background and waits for some button/mouse/hotkey to be pressed before spawning a window under the mouse that you interact with for only a moment before returning to your original task. Right, though on a quick glimpse on that video without really understanding what's going on there, the circular menu seems more like belonging to the image processing application. Fabrice's example OTOH is obviously a DE component, as it is a launcher, window control, and stuff. I do not mean to put words into Pekka's mouth, but I believe what he means when saying that things like this are a DE-component he's speaking conceptually more than anything else. Alternative menu systems like this and desklets essentially exist to augment the desktop itself. Just because they can be written in a DE-agnostic manner and run on GNOME, KDE, or TWM (all hail xeyes?) doesn't change that. They have fundamentally different needs than the average application, and -- at least as far as I understand Wayland -- it makes sense to leave some of these things up to the desktops to define. Quite right. Defining a generic protocol (designed from above, a little like the core Wayland protocol has been done) for adding DE components like pagers, task bars, launcher systems, window management thingies, desklets, etc. is so far an explicit non-goal. On Wayland, desktop environments are intended to be much more tightly integrated than on X11. We are not planning to intentionally design support for custom desktop environment arrangements where you pick the window manager from here, pager from there, a 3rd party task bar, and then a few desklets all from different other DEs. Yes, you can say it is a loss for the people who like to build their own DE from various pieces (I'm one of them, but mostly just because I can't bother learning anything else). However, it should be a great win in freedom of design, stability and usablity for the seriously developed DEs used by the masses. Every DE has its own thing for DE components already. Inventing yet another way that doesn't really fit well for any DE and forcing everyone to support that is not a good plan. Some components in some DEs could be not programs but plugins, some may talk via dbus rather than the display protocol, and so on. Instead, we are trying to allow DEs to define their own interfaces for these DE components, and if there actually emerges some common interfaces that could be standardised, then we can look into it. One hope is, that one DE starts to use a public interface for some DE components, some other DE finds it good and starts using it too, and so it slowly becomes a standard. Note, that nothing requires the standard protocol to be part of the display (Wayland) protocol. Unfortunately such organic, cooperative protocol design does not really work for the core protocol that all applications will depend on, and that's why we have and are centrally designing the Wayland core protocols and xdg_shell. We cannot really test much without a stable core protocol, and we cannot be sure the core protocol is good until it is put into serious use; we also have already been bitten by this chicken-and-egg problem. Thanks, pq [1]: https://www.youtube.com/watch?v=McJMnMJydes Jason ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH V2] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).
On 06/25/2014 05:09 PM, Alvaro Fernando García wrote:
Init cursor size to 64x64 if drmGetCap() fails.
Use Mesa GBM_BO_USE_CURSOR define (which removes 64x64 restriction)
Signed-off-by: Alvaro Fernando García alvarofernandogar...@gmail.com
---
src/compositor-drm.c | 43 ---
1 file changed, 36 insertions(+), 7 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 7d514e4..61ddea1 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -55,6 +55,14 @@
#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
#endif
+#ifndef DRM_CAP_CURSOR_WIDTH
+#define DRM_CAP_CURSOR_WIDTH 0x8
+#endif
+
+#ifndef DRM_CAP_CURSOR_HEIGHT
+#define DRM_CAP_CURSOR_HEIGHT 0x9
+#endif
+
static int option_current_mode = 0;
enum output_config {
[...]
@@ -1554,15 +1577,21 @@ drm_output_init_egl(struct drm_output *output, struct
drm_compositor *ec)
return -1;
}
- flags = GBM_BO_USE_CURSOR_64X64 | GBM_BO_USE_WRITE;
+#ifdef GBM_BO_USE_CURSOR
+ flags = GBM_BO_USE_CURSOR | GBM_BO_USE_WRITE;
+#else
+ flags = GBM_BO_USE_WRITE;
+ if (ec-cursor_width == 64 ec-cursor_height == 64)
+ flags = GBM_BO_USE_CURSOR_64X64 | flags;
+#endif
Do we really need this? GBM_BO_USE_CURSOR has the same value as the old
_64X64 flag. GBM will check if the dimensions are 64x64 and fail
otherwise. So this could just be
flags = GBM_BO_USE_CURSOR | GBM_BO_USE_WRITE;
and a
#ifndef GBM_BO_USE_CURSOR
#define GBM_BO_USE_CURSOR GBM_BO_USE_CURSOR_64X64
#endif
earlier in the file.
Cheers,
Ander
for (i = 0; i 2; i++) {
if (output-cursor_bo[i])
continue;
output-cursor_bo[i] =
- gbm_bo_create(ec-gbm, 64, 64, GBM_FORMAT_ARGB,
- flags);
+ gbm_bo_create(ec-gbm, ec-cursor_width,
ec-cursor_height,
+ GBM_FORMAT_ARGB, flags);
}
if (output-cursor_bo[0] == NULL || output-cursor_bo[1] == NULL) {
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 14:15:34 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: On Thu, 3 Jul 2014 13:49:06 +0300 Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 3 Jul 2014 12:10:36 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: On Thu, 3 Jul 2014 12:24:44 +0300 Pekka Paalanen ppaala...@gmail.com wrote: Weston's overlay planes code however totally depends on EGL to provide hw-capable buffers from clients. A software renderer support in EGL-DRM won't help in that. Okay, if I understand correctly, this means I'll have to implement an atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? Well, uhh, I suppose... That means you need to get clients actually rendering into hw-capable buffers, so that usually means having a GL(ES) rendering working on EGL Wayland platform, too. Or, clients could use something like libva(?) to fill the buffers and use Mesa's internal wl_drm protocol to pass those to the compositor. If the compositor is able to initialize EGL_WL_bind_wayland_display extension, then with Mesa, the clients will have wl_drm available. Still probably requires working GLESv2 rendering for the EGL DRM/GBM platform, because the pixman renderer cannot handle anything else than wl_shm buffers. Or, you migh hack Weston to copy pixels from wl_shm buffers into dumb buffers, and put those into overlays (err, did dumb buffers support going on overlays, or were they primary plane only?). But if you have like less than 10 overlays in hw, that might be a net lose in performance. I have, at most, 3 overlays (it depends on the HLCDC IP version), so this might be an acceptable solution. ITOH, I'd like to keep the implementation as clean as possible in order to be able to base future work on offical weston versions (and tell me if I'm wrong, but I'm not sure the proposed solution can ever make it to the official weston version). Or, you might go wild and have a hack on my hacky zlinux_dmabuf support in weston: http://cgit.collabora.com/git/user/pq/weston.git/log/?h=dmabuf-WIP It is missing pixman-renderer integration, and the test client is intel-only, but if you hack around those, you can have clients filling dmabufs, sending those to Weston, and Weston using GBM to import them to put them on overlays via DRM - unless the scenegraph forces them to go through pixman-renderer in which case you are in a slight pickle. That sounds interesting! I'll take a closer look at it. Note, that the protocol there does not address the problem of compatibility at all, and the implementation does not even advertise any pixel formats. It is all based on luck and clairvoyance, that the client just happens to create exactly the right kind of dmabufs that the compositor can use. If you fail that, the client gets kicked or you get a mess on the screen. Obviously not upstreamable material. ;-) Warning: that weston branch may get rewritten or deleted without notice. I guess the take-away from this is that DRM overlay planes have not really been considered for use with server nor client software rendering in Weston. Yes, I kinda realize that know. My main goal here is to provide a video player demo application where the primary plane (or an overlay plane) is used to display video player controls (play, pause, ...) and another plane is used to display video content (using gstreamer or any other alternative). This needs to be done using overlays in order to get acceptable performances (avoid software rendering for plane composition), and thus should use drm overlay planes. Oh, a video player! How do you get the video frames? Do you have hardware decoding? Can you perhaps decode straight into dmabufs? If yes, then you could use zlinux_dmabuf to throw those video frames to Weston zero-copy. Then the tricky part is to make Weston cope with those video frame buffers, as if they even attempt to go through the pixman-renderer, Weston will... hm, not sure what it does, but it won't work. So you have to somehow guarantee, that the surface which those buffers are targeting will *always* be assigned to an overlay. That may be a fair amount of hacking. Good luck! :-) Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 15:46:14 +0300 Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 3 Jul 2014 14:15:34 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: On Thu, 3 Jul 2014 13:49:06 +0300 Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 3 Jul 2014 12:10:36 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: On Thu, 3 Jul 2014 12:24:44 +0300 Pekka Paalanen ppaala...@gmail.com wrote: Weston's overlay planes code however totally depends on EGL to provide hw-capable buffers from clients. A software renderer support in EGL-DRM won't help in that. Okay, if I understand correctly, this means I'll have to implement an atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? Well, uhh, I suppose... That means you need to get clients actually rendering into hw-capable buffers, so that usually means having a GL(ES) rendering working on EGL Wayland platform, too. Or, clients could use something like libva(?) to fill the buffers and use Mesa's internal wl_drm protocol to pass those to the compositor. If the compositor is able to initialize EGL_WL_bind_wayland_display extension, then with Mesa, the clients will have wl_drm available. Still probably requires working GLESv2 rendering for the EGL DRM/GBM platform, because the pixman renderer cannot handle anything else than wl_shm buffers. Or, you migh hack Weston to copy pixels from wl_shm buffers into dumb buffers, and put those into overlays (err, did dumb buffers support going on overlays, or were they primary plane only?). But if you have like less than 10 overlays in hw, that might be a net lose in performance. I have, at most, 3 overlays (it depends on the HLCDC IP version), so this might be an acceptable solution. ITOH, I'd like to keep the implementation as clean as possible in order to be able to base future work on offical weston versions (and tell me if I'm wrong, but I'm not sure the proposed solution can ever make it to the official weston version). Or, you might go wild and have a hack on my hacky zlinux_dmabuf support in weston: http://cgit.collabora.com/git/user/pq/weston.git/log/?h=dmabuf-WIP It is missing pixman-renderer integration, and the test client is intel-only, but if you hack around those, you can have clients filling dmabufs, sending those to Weston, and Weston using GBM to import them to put them on overlays via DRM - unless the scenegraph forces them to go through pixman-renderer in which case you are in a slight pickle. That sounds interesting! I'll take a closer look at it. Note, that the protocol there does not address the problem of compatibility at all, and the implementation does not even advertise any pixel formats. It is all based on luck and clairvoyance, that the client just happens to create exactly the right kind of dmabufs that the compositor can use. If you fail that, the client gets kicked or you get a mess on the screen. Obviously not upstreamable material. ;-) Warning: that weston branch may get rewritten or deleted without notice. I guess the take-away from this is that DRM overlay planes have not really been considered for use with server nor client software rendering in Weston. Yes, I kinda realize that know. My main goal here is to provide a video player demo application where the primary plane (or an overlay plane) is used to display video player controls (play, pause, ...) and another plane is used to display video content (using gstreamer or any other alternative). This needs to be done using overlays in order to get acceptable performances (avoid software rendering for plane composition), and thus should use drm overlay planes. Oh, a video player! How do you get the video frames? Do you have hardware decoding? Can you perhaps decode straight into dmabufs? If yes, then you could use zlinux_dmabuf to throw those video frames to Weston zero-copy. Then the tricky part is to make Weston cope with those video frame buffers, as if they even attempt to go through the pixman-renderer, Weston will... hm, not sure what it does, but it won't work. So you have to somehow guarantee, that the surface which those buffers are targeting will *always* be assigned to an overlay. Some SoCs have an HW decoder and yes I had dmabuf in mind to provide zero copy from video decoder to DRM device ;-). But I'm not even sure this video decoder is supported in mainline and I'd like to get software decoding working first :-). That may be a fair amount of hacking. Good luck! :-) Yes that's what I'm realizing now. I thought the kernel driver would be the most complicated part, but now that I'm working on user space support I'd say developing the driver was quite easy :-). Thanks for your support. Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel
Re: [Mesa-dev] OpenGL on Wayland
On Wed, Jul 2, 2014 at 6:37 PM, Thomas Daede daede...@umn.edu wrote: What Mesa version are you using? IIRC OpenGL 3.3 is only supported in llvmpipe in mesa 10.3 and newer. Using MESA_GL_VERISON_OVERRIDE just fakes the version string, it doesn't change what functions you can actually link to. Also, that also means for compatibility reasons you might want to request a slightly older OpenGL version, unless you actually use functions provided in OpenGL 3.3 that don't exist in an older version? I'm using a built package of Mesa git from here[1]. I hadn't noticed what you state, because my program is still almost nothing (although it uses shaders with the #version 330 core directive, is it normal that they compile fine?). As for your advice, my program will need OpenGL 3.2 or 3.3 in the future, and it's unlikely that r200 will support it by then :), so I need the extension. FWIW, I have filed a bug report with the 'enhancement' tag, which is hosted here[2]. 1: http://pkgbuild.com/~lcarlier/mesa-git/ 2: https://bugs.freedesktop.org/show_bug.cgi?id=80821 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
problems in compiling wayland
Dear all, I try to build wayland/weston on Ubuntu 14.04 , just following this article http://wayland.freedesktop.org/ubuntu12.04.html (as i cannot find a 14.04-based tip) It went well, but when i tried to build weston, it was stopped by the following message: CC src/weston-compositor.o src/compositor.c: In function ‘surface_set_buffer_transform’: src/compositor.c:2160:4: error: ‘WL_SURFACE_ERROR_INVALID_TRANSFORM’ undeclared (first use in this function) WL_SURFACE_ERROR_INVALID_TRANSFORM, ^ src/compositor.c:2160:4: note: each undeclared identifier is reported only once for each function it appears in src/compositor.c: In function ‘surface_set_buffer_scale’: src/compositor.c:2179:4: error: ‘WL_SURFACE_ERROR_INVALID_SCALE’ undeclared (first use in this function) WL_SURFACE_ERROR_INVALID_SCALE, ^ make[1]: *** [src/weston-compositor.o] Error 1 make[1]: Leaving directory `/home/yeung/weston' make: *** [all] Error 2 Can someone tell me how to solve it? Thanks so much! Best regards, Alex ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: problems in compiling wayland
Weston master requires wayland master. The WL_SURFACE_ERROR_INVALID_TRANSFORM enum was added after wayland 1.5 You need to make sure you build libwayland from git master and then make sure that weston is building against your custom-built libwayland. --Jason Ekstrand On Thu, Jul 3, 2014 at 12:11 PM, pplive p2pne...@gmail.com wrote: Dear all, I try to build wayland/weston on Ubuntu 14.04 , just following this article http://wayland.freedesktop.org/ubuntu12.04.html (as i cannot find a 14.04-based tip) It went well, but when i tried to build weston, it was stopped by the following message: CC src/weston-compositor.o src/compositor.c: In function ‘surface_set_buffer_transform’: src/compositor.c:2160:4: error: ‘WL_SURFACE_ERROR_INVALID_TRANSFORM’ undeclared (first use in this function) WL_SURFACE_ERROR_INVALID_TRANSFORM, ^ src/compositor.c:2160:4: note: each undeclared identifier is reported only once for each function it appears in src/compositor.c: In function ‘surface_set_buffer_scale’: src/compositor.c:2179:4: error: ‘WL_SURFACE_ERROR_INVALID_SCALE’ undeclared (first use in this function) WL_SURFACE_ERROR_INVALID_SCALE, ^ make[1]: *** [src/weston-compositor.o] Error 1 make[1]: Leaving directory `/home/yeung/weston' make: *** [all] Error 2 Can someone tell me how to solve it? Thanks so much! Best regards, Alex ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Window placement
They have fundamentally different needs than the average application Well yes, I'm very aware they are, but when you say DE-component, I see a huge PITA for the developpers who would want to add such features in the desktop. Now, I wouldn't mind some sort of EWMH-like extensions, however, if a developper has to first focus a DE, make a new extension for it, make it accepted in the DE code-base, and then build its app, it's dead from the beginning. So our last hope would be that a DE really exposes a third-party-friendly interface and that others follow... Ubuntu did with their Launcher API, indicators API, etc, and it didn't spread very much. I think if Weston implements an interface it will have a chance though, so I'll still try to push some other ideas on this ML ;-) 2014-07-03 9:03 GMT+02:00 Pekka Paalanen ppaala...@gmail.com: On Wed, 2 Jul 2014 16:16:36 -0700 Jason Gerecke killert...@gmail.com wrote: On Wed, Jul 2, 2014 at 3:33 PM, Fabrice Rey faboune...@gmail.com wrote: The question is: what action triggers it to make this ring of icons appear? A global shortkey (and yes I know it's not yet possible on Wayland, that's another problem on its own). What's the application doing? Does it have keyboard focus but is potentially not under the mouse pointer? Do you have a screenshot or video of this feature you can share? I'm not the developper of it, I actually don't even use it ^^ I was just thinking of it to see how it would fit in Wayland, what's potentially missing now in the protocol. Here is an article about it: http://www.webupd8.org/2011/10/gnome-pie-02-released.html and a video: https://www.youtube.com/watch?v=TFQDyZyMxO4. Basically, it appears under the mouse when you trigger the shortkey, and you can also use the keyboard to navigate in the items. So I see 2 main points here: - it places its window not relatively to a parent (which there is not), but to the mouse - it takes the (keyboard) focus when it appears The second point is not related to this topic, so we can probably think of it later. This reminds me of a something similar[1] that comes with the Wacom drivers on Windows and Mac. Its not a normal application that you would open, interact with, (possibly switch away from temporarily), and close. Rather, the application sits in the background and waits for some button/mouse/hotkey to be pressed before spawning a window under the mouse that you interact with for only a moment before returning to your original task. Right, though on a quick glimpse on that video without really understanding what's going on there, the circular menu seems more like belonging to the image processing application. Fabrice's example OTOH is obviously a DE component, as it is a launcher, window control, and stuff. I do not mean to put words into Pekka's mouth, but I believe what he means when saying that things like this are a DE-component he's speaking conceptually more than anything else. Alternative menu systems like this and desklets essentially exist to augment the desktop itself. Just because they can be written in a DE-agnostic manner and run on GNOME, KDE, or TWM (all hail xeyes?) doesn't change that. They have fundamentally different needs than the average application, and -- at least as far as I understand Wayland -- it makes sense to leave some of these things up to the desktops to define. Quite right. Defining a generic protocol (designed from above, a little like the core Wayland protocol has been done) for adding DE components like pagers, task bars, launcher systems, window management thingies, desklets, etc. is so far an explicit non-goal. On Wayland, desktop environments are intended to be much more tightly integrated than on X11. We are not planning to intentionally design support for custom desktop environment arrangements where you pick the window manager from here, pager from there, a 3rd party task bar, and then a few desklets all from different other DEs. Yes, you can say it is a loss for the people who like to build their own DE from various pieces (I'm one of them, but mostly just because I can't bother learning anything else). However, it should be a great win in freedom of design, stability and usablity for the seriously developed DEs used by the masses. Every DE has its own thing for DE components already. Inventing yet another way that doesn't really fit well for any DE and forcing everyone to support that is not a good plan. Some components in some DEs could be not programs but plugins, some may talk via dbus rather than the display protocol, and so on. Instead, we are trying to allow DEs to define their own interfaces for these DE components, and if there actually emerges some common interfaces that could be standardised, then we can look into it. One hope is, that one DE starts to use a public interface for some DE
Global shortkeys and keyboard focus
Hi all, This topic came up in my previous one about window placement, and I'd like to go further. So currently there is no such thing as Global shortkeys and keyboard focus, however let me present a typical real use-case: I have a dock which is most of the time hidden (because a window is overlaps it) and some applets inside. Using the keyboard is therefore a very convenient a fast way to access the items inside. For instance, ctrl+F1 pops the Applications Menu, which has a text entry inside; the entry takes the focus so I can immediately type some letters, and the menu will only display the relative applications. Down arrow + Enter let select the desired one if it's not already on the first row. I could also pop up the translation dialog with another shortkey, immediately type the word I want to translate, press Enter, and see the result. Now, I've read some vague things about privileged clients, is it still being considered ? Would it be some Android-like capabilities that the user validates on installation or the first time they are required by the application ? What are the plans for these 2 key features ? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: problems in compiling wayland
It sounds like he did build wayland first. For some reason weston is not seeing the new wayland installation. Make sure make install was done in wayland, and that both are using the same --prefix in configure. On 07/03/2014 12:25 PM, Jason Ekstrand wrote: Weston master requires wayland master. The WL_SURFACE_ERROR_INVALID_TRANSFORM enum was added after wayland 1.5 You need to make sure you build libwayland from git master and then make sure that weston is building against your custom-built libwayland. --Jason Ekstrand On Thu, Jul 3, 2014 at 12:11 PM, pplive p2pne...@gmail.com mailto:p2pne...@gmail.com wrote: Dear all, I try to build wayland/weston on Ubuntu 14.04 , just following this article http://wayland.freedesktop.org/ubuntu12.04.html (as i cannot find a 14.04-based tip) It went well, but when i tried to build weston, it was stopped by the following message: CC src/weston-compositor.o src/compositor.c: In function ‘surface_set_buffer_transform’: src/compositor.c:2160:4: error: ‘WL_SURFACE_ERROR_INVALID_TRANSFORM’ undeclared (first use in this function) WL_SURFACE_ERROR_INVALID_TRANSFORM, ^ src/compositor.c:2160:4: note: each undeclared identifier is reported only once for each function it appears in src/compositor.c: In function ‘surface_set_buffer_scale’: src/compositor.c:2179:4: error: ‘WL_SURFACE_ERROR_INVALID_SCALE’ undeclared (first use in this function) WL_SURFACE_ERROR_INVALID_SCALE, ^ make[1]: *** [src/weston-compositor.o] Error 1 make[1]: Leaving directory `/home/yeung/weston' make: *** [all] Error 2 Can someone tell me how to solve it? Thanks so much! Best regards, Alex ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org mailto:wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH V2] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).
On 03.07.2014 21:27, Ander Conselvan de Oliveira wrote:
On 06/25/2014 05:09 PM, Alvaro Fernando García wrote:
Init cursor size to 64x64 if drmGetCap() fails.
Use Mesa GBM_BO_USE_CURSOR define (which removes 64x64 restriction)
Signed-off-by: Alvaro Fernando García alvarofernandogar...@gmail.com
---
src/compositor-drm.c | 43 ---
1 file changed, 36 insertions(+), 7 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 7d514e4..61ddea1 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -55,6 +55,14 @@
#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
#endif
+#ifndef DRM_CAP_CURSOR_WIDTH
+#define DRM_CAP_CURSOR_WIDTH 0x8
+#endif
+
+#ifndef DRM_CAP_CURSOR_HEIGHT
+#define DRM_CAP_CURSOR_HEIGHT 0x9
+#endif
+
static int option_current_mode = 0;
enum output_config {
[...]
@@ -1554,15 +1577,21 @@ drm_output_init_egl(struct drm_output *output,
struct drm_compositor *ec)
return -1;
}
-flags = GBM_BO_USE_CURSOR_64X64 | GBM_BO_USE_WRITE;
+#ifdef GBM_BO_USE_CURSOR
+flags = GBM_BO_USE_CURSOR | GBM_BO_USE_WRITE;
+#else
+flags = GBM_BO_USE_WRITE;
+if (ec-cursor_width == 64 ec-cursor_height == 64)
+flags = GBM_BO_USE_CURSOR_64X64 | flags;
+#endif
Do we really need this? GBM_BO_USE_CURSOR has the same value as the old
_64X64 flag. GBM will check if the dimensions are 64x64 and fail
otherwise.
No, that check was removed when adding GBM_BO_USE_CURSOR.
So this could just be
flags = GBM_BO_USE_CURSOR | GBM_BO_USE_WRITE;
and a
#ifndef GBM_BO_USE_CURSOR
#define GBM_BO_USE_CURSOR GBM_BO_USE_CURSOR_64X64
#endif
earlier in the file.
No, if GBM doesn't define GBM_BO_USE_CURSOR, it will likely fail if the
dimensions are not 64x64.
(I realize that whether or not GBM_BO_USE_CURSOR is defined doesn't
directly say anything about the runtime behaviour, but in practice this
should be good enough)
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
When weston opens a device, why does it use two file descriptors?
Hi, When I start weston in drm backend, I have found weston opens the every device with two fds. I am a little confused by that. For example, for keyboard device /dev/input/event5, in device_added, it will open the device. Found it returns fd 34, however fd 35 is also used by this operation(from the below information). Anyone knows why? Weston process number is 668. root:/quanxian ls -l /proc/668/fd lrwx--. 1 root root 64 Jul 3 19:53 0 - /dev/pts/0 lrwx--. 1 root root 64 Jul 3 19:53 1 - /dev/pts/0 lrwx--. 1 root root 64 Jul 3 19:53 13 - /dev/dri/card0 lrwx--. 1 root root 64 Jul 3 19:53 14 - /dev/dri/card0 lrwx--. 1 root root 64 Jul 3 19:53 15 - socket:[17763] lrwx--. 1 root root 64 Jul 3 19:53 16 - socket:[17763] lrwx--. 1 root root 64 Jul 3 19:53 17 - socket:[17764] lrwx--. 1 root root 64 Jul 3 19:53 18 - socket:[17764] lrwx--. 1 root root 64 Jul 3 19:53 22 - /dev/input/event3 lrwx--. 1 root root 64 Jul 3 19:53 23 - /dev/input/event3 lrwx--. 1 root root 64 Jul 3 19:53 24 - /dev/input/event0 lrwx--. 1 root root 64 Jul 3 19:53 25 - /dev/input/event0 lrwx--. 1 root root 64 Jul 3 19:53 26 - /dev/input/event1 lrwx--. 1 root root 64 Jul 3 19:53 27 - /dev/input/event1 lrwx--. 1 root root 64 Jul 3 19:53 28 - /dev/input/event7 lrwx--. 1 root root 64 Jul 3 19:53 29 - /dev/input/event7 lrwx--. 1 root root 64 Jul 3 19:53 30 - /dev/input/event8 lrwx--. 1 root root 64 Jul 3 19:53 31 - /dev/input/event8 lrwx--. 1 root root 64 Jul 3 19:53 32 - /dev/input/event4 lrwx--. 1 root root 64 Jul 3 19:53 33 - /dev/input/event4 lrwx--. 1 root root 64 Jul 3 19:53 34 - /dev/input/event5 lrwx--. 1 root root 64 Jul 3 19:53 35 - /dev/input/event5 lrwx--. 1 root root 64 Jul 3 19:53 36 - /dev/input/event6 lrwx--. 1 root root 64 Jul 3 19:53 37 - /dev/input/event6 Thanks Regards Quanxian Wang ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
