Re: Things that killed my motivation to play with wayland
On 12/06/2013 02:49, dar...@chaosreigns.com wrote: 1) This mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=61919 make fails without C_INCLUDE_PATH set. It pretty much destroyed my build testing setup (I was build testing 46 related repos every few hours). I never managed to work out the obvious workaround of just setting C_INCLUDE_PATH for mesa builds (which I had working for another repo). I included the commit where the problem started. Three months ago. (Build test script I wrote: http://www.chaosreigns.com/code/buildtest/ ) I provided a patch on this one, and even if I didn’t test it, it should work in your case. If not, I’m willing to help, just ask me for another patch with some relevant logs. 2) The XWayland segfault bug: https://bugs.freedesktop.org/show_bug.cgi?id=59983 This was the reason I stopped using weston as my primary UI at home in September. Tiago said he had a fix for it in one of his branches a long time ago, but I guess it wasn't compatible with the changes made to the plan to handle xwm. Blows my mind that this isn't the top priority of the project. I'm sure there's fine reasons. It would be nice to know what they are. I just rebased the full xwayland branch to xorg-server master, and also the intel and wlshm DDX. http://git.sardemff7.net/wayland/xorg-server/log/?h=xwayland-1.15 http://git.sardemff7.net/wayland/xf86-video-intel/log/?h=xwayland http://git.sardemff7.net/wayland/xf86-video-wlshm/ If Tiago can point me to the fix commit, I can include it in there, so we can start using a new base to hack on. 3) The state of cairo's build testing, particularly this bug: https://bugs.freedesktop.org/show_bug.cgi?id=62375 Cairo has a huge and glorious build test suite. But it looked very much to me like nobody could've gotten it to pass all tests in any subset in years. psychon was very helpful in tracking down and fixing problems. This one last bug was in the way of me being able to get a full subset of tests to pass, so I could automate running them reasonably. The maintainer of cairo, Chris Wilson, included a patch to fix it in a comment to that bug, but we haven't been able to get him to commit it, in three months. (Lots of stuff, including weston and gtk, are heavily dependent on cairo, which tends to break. Which isn't surprising with its unusable build tests. And the fact that the build test instructions specify a method that doesn't allow cairo-gl to be tested.) Tests are good, but if all of them fail badly, you *can* ignore them. In this case, they should be fixed, but that shouldn’t prevent you from using cairo. IMO, you should keep trying to get the tests fixed, without forcing them in your test script. I’ll try to support you and provide patches on cairo too, please point me to the relevant bugs. Cheers, -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Tue, 11 Jun 2013 16:31:59 -0300 Rafael Antognolli wrote: > Starting code here. Following are some comments. > > https://github.com/antognolli/wayland/commits/minimize > https://github.com/antognolli/weston/commits/minimize > > I didn't add code for the events that ask state changes from the > compositor, neither any code related to minimize yet. I tried to first > change the current maximized surface type to be just another state, as > suggested at some point in this thread. > > So, it ended up very hackish IMHO. In order to do that, when the > surface type is set to maximized, I change it to set the maximized > state instead, which is currently working correctly (from my tests). > But when the surface type is set to anything else than maximized, I > have to unset the maximized state, to keep the same behavior as before > these changes. > > I need to know if I should follow this path, in which case I'll > improve the above code (some refactory can take place), or if we > should use another approach. Maybe the minimized state should be in > fact another surface type, and we would only have states for things > like always_on_top and sticky (and any other that may come next). Or > maybe we can keep the same surface types that we had already, and just > add minimized as a state. > > What are your opinions about this? To get the big picture, let me reiterate the surface classification as a whole, the way I see it. Surface roles, exclusive: - cursor - drag icon - shell surface Shell surface types, exclusive: - top-level - transient (umm, what was this for, again?) - popup (menu?) Top-level shell surface states, each more or less toggleable on its own: - maximized - fullscreen - minimized - sticky - always-on-top or some equivalent layer thing ... Does this make sense? That is, only a top-level surface, which we should probably be calling as an application window, can be maximized etc., and I think the discussion was that it can be many things at once, like maximized and minimized. I don't think the states make sense as types, I would prefer the above hierarchy. A shell surface can only have one type at a time, but the states are not that restricted. It gives a nice tree-like hierarchy, instead of a directed graph where several surface types can have the same states. The tiling-WM developers would be concerned only about the top-level shell surface states, and could hopefully support all the shell surface types, which should make the difference between floating and tiling WMs more manageable. Protocol-wise, this means that requests set_maximized and set_fullscreen would be deprecated as is, and replaced with the state setting request. Request set_toplevel would deprecate the part of its behaviour where it changes a surface into normal state. We cannot remove the deprecated functionality, I believe, so it must be kept working, and just plumbed into the new kind of internal state change machinery inside weston. However, it's not that simple. Some states need parameters. Maximized needs an output, and fullscreen a few things more. Always-on-top equivalent might want a layer number or something. Therefore I'm not sure a single set_state request will work. Anyway, that's just what came to my mind now. I don't recall any of the earlier discussions anymore, maybe there were solutions to some of these issues, maybe not. Did we ever discuss the possiblity of fullscreen being a special kind of maximized, btw? If you look at the state list above, everything is orthogonal (toggleable independently) except maximized vs. fullscreen. This is just as a concept, how it maps into protocol is a different matter. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [fbdev_backend]: support of DIRECTCOLOR Frame buffer
It's not broken, it's just 1 value per 65535 unused for red and blue. The
difference between the red 65534 and the red 65535 is insignificant. The
real fix is more significant when we run on target with 126Mb of RAM or
less. Don't forget that on PC Desktop you find very big video card which
runs with A8R8G8B8 pixel format in lot of cases.
2013/6/11 Pekka Paalanen
> On Tue, 11 Jun 2013 16:31:17 +0200
> Marc Chalain wrote:
>
> > Theoretically you have right.
> > But the pixel formats are defined to contains the same amounts of values
> > for each colors except for 16bpp format (r5g6b5 and b5g6r5 one value more
> > for green) and the alpha. My code is optimized for a lot of cases.
> > For the use of rcols instead cols, you have right. It's a mistake.
>
> So, you think it's ok to be presumably broken on 565 formats?
> The fix really is not that hard, and the "optimizations" here are
> totally insignificant.
>
> > Sorry "git send-email" fails on my computer (I think it's come from the
> > proxy).
>
> There are other ways to send email without messing up whitespace,
> any of them will do. Take a look at other people's patch series on
> the mailing list, how they look, and try to replicate that.
>
> Until then, I think I've reviewed enough here for now.
>
> Btw. the idle-time man page patch should be part of the same commit
> as the idle-time config implementation.
>
>
> Thanks,
> pq
>
> > [PATCH] fbdev: directcolor support
> > The backend accepts to use TRUECOLOR and DIRECTCOLOR which are similares.
> > DIRECTCOLOR has better results if the application applies a Colors
> > map before to use it.
> > The colors map is just a list of gradients for each colors and alpha.
> >
> > ---
> > src/compositor-fbdev.c | 43
> ++-
> > 1 file changed, 42 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
> > index 9c3d17e..7a3374e 100644
> > --- a/src/compositor-fbdev.c
> > +++ b/src/compositor-fbdev.c
> > @@ -203,6 +203,43 @@ finish_frame_handler(void *data)
> > return 1;
> > }
> >
> > +static int
> > +set_cmap(int fd, struct fb_var_screeninfo *vinfo)
> > +{
> > +struct fb_cmap cmap;
> > +uint16_t *colors;
> > +int i;
> > +int rcols = 1 << vinfo->red.length;
> > +int gcols = 1 << vinfo->green.length;
> > +int bcols = 1 << vinfo->blue.length;
> > +
> > +memset(&cmap, 0, sizeof(cmap));
> > +
> > +/* Make our palette the length of the deepest color */
> > +int cols = (rcols > gcols ? rcols : gcols);
> > +cols = (cols > bcols ? cols : bcols);
> > +
> > +colors = malloc(sizeof(uint16_t) * cols);
> > +if (!colors) return -1;
> > +
> > +for (i = 0; i < cols; i++)
> > +colors[i] = (UINT16_MAX / (cols - 1)) * i;
> > +
> > +cmap.start = 0;
> > +cmap.len = cols;
> > +cmap.red = colors;
> > +cmap.blue = colors;
> > +cmap.green = colors;
> > +if (vinfo->transp.length)
> > +cmap.transp = colors;
> > +else
> > +cmap.transp = NULL;
> > +ioctl(fd, FBIOPUTCMAP, &cmap);
> > +
> > +free(colors);
> > +return 0;
> > +}
> > +
> > static pixman_format_code_t
> > calculate_pixman_format(struct fb_var_screeninfo *vinfo,
> > struct fb_fix_screeninfo *finfo)
> > @@ -242,7 +279,8 @@ calculate_pixman_format(struct fb_var_screeninfo
> *vinfo,
> > return 0;
> >
> > /* We only handle true-colour frame buffers at the moment. */
> > -if (finfo->visual != FB_VISUAL_TRUECOLOR || vinfo->grayscale != 0)
> > +if (!(finfo->visual == FB_VISUAL_TRUECOLOR || finfo->visual ==
> > FB_VISUAL_DIRECTCOLOR)
> > +|| vinfo->grayscale != 0)
> > return 0;
> >
> > /* We only support formats with MSBs on the left. */
> > @@ -325,6 +363,9 @@ fbdev_query_screen_info(struct fbdev_output *output,
> > int fd,
> > info->pixel_format = calculate_pixman_format(&varinfo, &fixinfo);
> > info->refresh_rate = calculate_refresh_rate(&varinfo);
> >
> > +if (fixinfo.visual == FB_VISUAL_DIRECTCOLOR)
> > +set_cmap(fd, &varinfo);
> > +
> > if (info->pixel_format == 0) {
> > weston_log("Frame buffer uses an unsupported format.\n");
> > return -1;
> > --
> > 1.7.9.5
> >
> >
> >
> >
> > 2013/6/11 Pekka Paalanen
> >
> > > On Tue, 11 Jun 2013 15:15:29 +0200
> > > Marc Chalain wrote:
> > >
> > > > Hello,
> > > > OK this patch now checks FB_VISUAL_DIRECTCOLOR twice but set the cmap
> > > > inside the fbdev_query_screen_info function.
> > > > I use "malloc" instead "table" declaration because it takes less
> memory
> > > and
> > > > it's used only once, it's useless to be faster.
> > > > After I set the same values for each colors, because it's a default
> map.
> > > To
> > > > set more finely we have to know the screen and it's capabilities.
> > >
> > > What I meant is, if rcols = 32 and gcols = 64, you allocate a 64-long
> > > array, and fill it with 64 step values. Does tha
Re: minimized and stick windows
On 12/06/2013 09:57, Pekka Paalanen wrote:
To get the big picture, let me reiterate the surface classification as
a whole, the way I see it.
Surface roles, exclusive:
- cursor
- drag icon
- shell surface
Each role is an interface then? Simple and efficient, I love it.
Shell surface types, exclusive:
- top-level
- transient (umm, what was this for, again?)
- popup (menu?)
Transcient is for dialog (modal?) boxes, isn’t it?
Each type is a one-shot request on a new created surface. Again, simple
and efficient, love it too.
It may be a bit more clear, see below.
Top-level shell surface states, each more or less toggleable on its own:
- maximized
- fullscreen
- minimized
- sticky
- always-on-top or some equivalent layer thing
...
Does this make sense?
Yes.
That is, only a top-level surface, which we should probably be calling
as an application window, can be maximized etc., and I think the
discussion was that it can be many things at once, like maximized and
minimized.
Right, it is useful and not that hard to implement.
I don't think the states make sense as types, I would prefer the above
hierarchy. A shell surface can only have one type at a time, but the
states are not that restricted. It gives a nice tree-like hierarchy,
instead of a directed graph where several surface types can have the
same states. The tiling-WM developers would be concerned only about the
top-level shell surface states, and could hopefully support all the
shell surface types, which should make the difference between floating
and tiling WMs more manageable.
I agree.
Protocol-wise, this means that requests set_maximized and
set_fullscreen would be deprecated as is, and replaced with the state
setting request. Request set_toplevel would deprecate the part of its
behaviour where it changes a surface into normal state.
We cannot remove the deprecated functionality, I believe, so it must be
kept working, and just plumbed into the new kind of internal state
change machinery inside weston.
However, it's not that simple. Some states need parameters. Maximized
needs an output, and fullscreen a few things more. Always-on-top
equivalent might want a layer number or something. Therefore I'm not
sure a single set_state request will work.
At protocol level, we may be better using new interfaces.
wl_shell will gain three requests:
— get_toplevel_surface(class, title): returns a new
wl_shell_toplevel_surface
— get_transcient_surface(wl_shell_toplevel_surface): returns a
transcient one
— get_popup(wl_shell_toplevel_surface): returns a popup surface
That would duplicate some requests between the three interfaces (or
maybe two, if transcient and popup can share one).
Backward-compatibility would be both easier and harder than keeping
wl_shell_surface around, as we have to maintain a compatibility struct
in the compositor, but that would be a simple struct { type; union {
toplevel; transcient; popup; }; }.
That would allow to extend the configure event in a nice fashion, that
tiling WM will love (e.g. for decorations).
Anyway, that's just what came to my mind now. I don't recall any of the
earlier discussions anymore, maybe there were solutions to some of
these issues, maybe not.
Did we ever discuss the possiblity of fullscreen being a special kind
of maximized, btw? If you look at the state list above, everything is
orthogonal (toggleable independently) except maximized vs. fullscreen.
This is just as a concept, how it maps into protocol is a different
matter.
Fullscreen, especially for games, is a completely different thing (e.g.
modesetting). We can have two cases here: “basic” fullscreen, which is
just maximize with panel removed (and the app will use the normal
decoration mechanism here, no fullscreen state), and plain fullscreen,
which would be another surface type.
I *think* most apps (games) already have heavy switching, so destroying
and creating a new surface should not be a problem here, imo.
Cheers,
--
Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, 12 Jun 2013 10:23:33 +0200
sardemff7+wayl...@sardemff7.net wrote:
> On 12/06/2013 09:57, Pekka Paalanen wrote:
> > To get the big picture, let me reiterate the surface classification as
> > a whole, the way I see it.
> >
> > Surface roles, exclusive:
> > - cursor
> > - drag icon
> > - shell surface
>
> Each role is an interface then? Simple and efficient, I love it.
No, a role is just a concept. In protocol it is currently assigned by
passing the wl_surface as an argument for a specific request, that
assigns the role.
Only shell surface has a new interface associated, IIRC.
> > Shell surface types, exclusive:
> > - top-level
> > - transient (umm, what was this for, again?)
> > - popup (menu?)
>
> Transcient is for dialog (modal?) boxes, isn’t it?
Tooltips and alike, rather.
> Each type is a one-shot request on a new created surface. Again, simple
> and efficient, love it too.
> It may be a bit more clear, see below.
>
> > Top-level shell surface states, each more or less toggleable on its own:
> > - maximized
> > - fullscreen
> > - minimized
> > - sticky
> > - always-on-top or some equivalent layer thing
> > ...
>
> > Does this make sense?
>
> Yes.
>
>
> > That is, only a top-level surface, which we should probably be calling
> > as an application window, can be maximized etc., and I think the
> > discussion was that it can be many things at once, like maximized and
> > minimized.
>
> Right, it is useful and not that hard to implement.
>
>
> > I don't think the states make sense as types, I would prefer the above
> > hierarchy. A shell surface can only have one type at a time, but the
> > states are not that restricted. It gives a nice tree-like hierarchy,
> > instead of a directed graph where several surface types can have the
> > same states. The tiling-WM developers would be concerned only about the
> > top-level shell surface states, and could hopefully support all the
> > shell surface types, which should make the difference between floating
> > and tiling WMs more manageable.
>
> I agree.
>
>
> > Protocol-wise, this means that requests set_maximized and
> > set_fullscreen would be deprecated as is, and replaced with the state
> > setting request. Request set_toplevel would deprecate the part of its
> > behaviour where it changes a surface into normal state.
> >
> > We cannot remove the deprecated functionality, I believe, so it must be
> > kept working, and just plumbed into the new kind of internal state
> > change machinery inside weston.
> >
> > However, it's not that simple. Some states need parameters. Maximized
> > needs an output, and fullscreen a few things more. Always-on-top
> > equivalent might want a layer number or something. Therefore I'm not
> > sure a single set_state request will work.
>
> At protocol level, we may be better using new interfaces.
>
> wl_shell will gain three requests:
> — get_toplevel_surface(class, title): returns a new
> wl_shell_toplevel_surface
> — get_transcient_surface(wl_shell_toplevel_surface): returns a
> transcient one
> — get_popup(wl_shell_toplevel_surface): returns a popup surface
>
> That would duplicate some requests between the three interfaces (or
> maybe two, if transcient and popup can share one).
> Backward-compatibility would be both easier and harder than keeping
> wl_shell_surface around, as we have to maintain a compatibility struct
> in the compositor, but that would be a simple struct { type; union {
> toplevel; transcient; popup; }; }.
>
> That would allow to extend the configure event in a nice fashion, that
> tiling WM will love (e.g. for decorations).
That is certainly a novel suggestion. I wonder what toolkit authors
would think.
Uh, I didn't mean to start another bikeshedding party, but I guess I
didn't really understand Rafael's question.
Cheers,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On 12/06/2013 11:18, Pekka Paalanen wrote:
On Wed, 12 Jun 2013 10:23:33 +0200
sardemff7+wayl...@sardemff7.net wrote:
On 12/06/2013 09:57, Pekka Paalanen wrote:
To get the big picture, let me reiterate the surface classification as
a whole, the way I see it.
Surface roles, exclusive:
- cursor
- drag icon
- shell surface
Each role is an interface then? Simple and efficient, I love it.
No, a role is just a concept. In protocol it is currently assigned by
passing the wl_surface as an argument for a specific request, that
assigns the role.
Only shell surface has a new interface associated, IIRC.
That’s fine: if the role is complex enough, put it in an interface.
Shell surface types, exclusive:
- top-level
- transient (umm, what was this for, again?)
- popup (menu?)
Transcient is for dialog (modal?) boxes, isn’t it?
Tooltips and alike, rather.
Ok, so we should add something here for modal dialogs.
[snip]
Protocol-wise, this means that requests set_maximized and
set_fullscreen would be deprecated as is, and replaced with the state
setting request. Request set_toplevel would deprecate the part of its
behaviour where it changes a surface into normal state.
We cannot remove the deprecated functionality, I believe, so it must be
kept working, and just plumbed into the new kind of internal state
change machinery inside weston.
However, it's not that simple. Some states need parameters. Maximized
needs an output, and fullscreen a few things more. Always-on-top
equivalent might want a layer number or something. Therefore I'm not
sure a single set_state request will work.
At protocol level, we may be better using new interfaces.
wl_shell will gain three requests:
— get_toplevel_surface(class, title): returns a new
wl_shell_toplevel_surface
— get_transcient_surface(wl_shell_toplevel_surface): returns a
transcient one
— get_popup(wl_shell_toplevel_surface): returns a popup surface
That would duplicate some requests between the three interfaces (or
maybe two, if transcient and popup can share one).
Backward-compatibility would be both easier and harder than keeping
wl_shell_surface around, as we have to maintain a compatibility struct
in the compositor, but that would be a simple struct { type; union {
toplevel; transcient; popup; }; }.
That would allow to extend the configure event in a nice fashion, that
tiling WM will love (e.g. for decorations).
That is certainly a novel suggestion. I wonder what toolkit authors
would think.
I would probably provide patches for GTK+ at least, to test the stuff,
and the old interface (less powerful) would still be there for a while.
Uh, I didn't mean to start another bikeshedding party, but I guess I
didn't really understand Rafael's question.
Sorry. ^^'
--
Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [fbdev_backend]: support of DIRECTCOLOR Frame buffer
On Wed, 12 Jun 2013 10:07:00 +0200
Marc Chalain wrote:
> It's not broken, it's just 1 value per 65535 unused for red and blue. The
> difference between the red 65534 and the red 65535 is insignificant. The
I have no idea what you are talking about, but lets assume rgb565 and
see what happens.
red.length = 5
green.length = 6
therefore:
rcols = 32
gcols = 64
take the maximum, cols = 64.
Run your loop:
> > > +for (i = 0; i < cols; i++)
> > > +colors[i] = (UINT16_MAX / (cols - 1)) * i;
Now:
colors[0] = 0
...
colors[31] = 32240
...
colors[63] = 65520
(There is a rounding error you could probably correct by multiplying
first and dividing last, but that is not the point.)
Green channel can have indices 0..63, which means it covers values
0..65520.
Red channel can have indices 0..31, which means it covers values
0..32240.
Can you explain to me, why this does not make the red (and blue)
channel have only half of the intensity on screen of what it should
have? What have I misunderstood here?
> real fix is more significant when we run on target with 126Mb of RAM or
> less. Don't forget that on PC Desktop you find very big video card which
> runs with A8R8G8B8 pixel format in lot of cases.
Which real fix? What does the RAM amount have to do with how you
compute the color map?
Let's say you have 8 bits and 4 channels. Even if you made separate
arrays for each channel, you would use only 2 kB of RAM, and only
temporarily when setting the color map. That's hardly relevant if your
system can run a Linux kernel to begin with.
- pq
> 2013/6/11 Pekka Paalanen
>
> > On Tue, 11 Jun 2013 16:31:17 +0200
> > Marc Chalain wrote:
> >
> > > Theoretically you have right.
> > > But the pixel formats are defined to contains the same amounts of values
> > > for each colors except for 16bpp format (r5g6b5 and b5g6r5 one value more
> > > for green) and the alpha. My code is optimized for a lot of cases.
> > > For the use of rcols instead cols, you have right. It's a mistake.
> >
> > So, you think it's ok to be presumably broken on 565 formats?
> > The fix really is not that hard, and the "optimizations" here are
> > totally insignificant.
> >
> > > Sorry "git send-email" fails on my computer (I think it's come from the
> > > proxy).
> >
> > There are other ways to send email without messing up whitespace,
> > any of them will do. Take a look at other people's patch series on
> > the mailing list, how they look, and try to replicate that.
> >
> > Until then, I think I've reviewed enough here for now.
> >
> > Btw. the idle-time man page patch should be part of the same commit
> > as the idle-time config implementation.
> >
> >
> > Thanks,
> > pq
> >
> > > [PATCH] fbdev: directcolor support
> > > The backend accepts to use TRUECOLOR and DIRECTCOLOR which are similares.
> > > DIRECTCOLOR has better results if the application applies a Colors
> > > map before to use it.
> > > The colors map is just a list of gradients for each colors and alpha.
> > >
> > > ---
> > > src/compositor-fbdev.c | 43
> > ++-
> > > 1 file changed, 42 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
> > > index 9c3d17e..7a3374e 100644
> > > --- a/src/compositor-fbdev.c
> > > +++ b/src/compositor-fbdev.c
> > > @@ -203,6 +203,43 @@ finish_frame_handler(void *data)
> > > return 1;
> > > }
> > >
> > > +static int
> > > +set_cmap(int fd, struct fb_var_screeninfo *vinfo)
> > > +{
> > > +struct fb_cmap cmap;
> > > +uint16_t *colors;
> > > +int i;
> > > +int rcols = 1 << vinfo->red.length;
> > > +int gcols = 1 << vinfo->green.length;
> > > +int bcols = 1 << vinfo->blue.length;
> > > +
> > > +memset(&cmap, 0, sizeof(cmap));
> > > +
> > > +/* Make our palette the length of the deepest color */
> > > +int cols = (rcols > gcols ? rcols : gcols);
> > > +cols = (cols > bcols ? cols : bcols);
> > > +
> > > +colors = malloc(sizeof(uint16_t) * cols);
> > > +if (!colors) return -1;
> > > +
> > > +for (i = 0; i < cols; i++)
> > > +colors[i] = (UINT16_MAX / (cols - 1)) * i;
> > > +
> > > +cmap.start = 0;
> > > +cmap.len = cols;
> > > +cmap.red = colors;
> > > +cmap.blue = colors;
> > > +cmap.green = colors;
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The way to use system cursor and custom(client) cursor
On Tue, 11 Jun 2013 12:27:43 -0700 Elvis Lee(이광웅) wrote: > Thanks for your comments. It's really helpful. > I almost understood the Wayland designs for cursor. > Basically, I respect the designs. And possibly my issue can be > handled with dynamic-switching of wayland-cursor. But I'm not sure > yet that it's good approach. > > Here goes *real* use-case, expecting to find a better way. > > There is a compositor which includes UXs like a *launcher*. > From this point, I think it’s going to different way with the Wayland > design. :( As I know, it’s for performance since the UXs have lots of > hovering, animations and images. For those UXs, compositor should > have *system cursor*. Actually that's not problem yet. Because > focuses without client can be handled well on compositor. Ok, but I still don't see the relevance of a system cursor, why do those UI elements want a system cursor instead of setting the same cursor image on their own. I heard rumours that you might have some hardware restriction that makes updating a cursor image expensive. Is there any truth to that? > Also, for system, there is a setting app which can change theme of > system cursor. This is an important point. You have to somehow communicate to all clients, that the default cursor theme has changed, and they need to reload their cursors. This is what we do not have yet. > For example, we can think about SDL game app. > It will use custom cursor for specific game scene. > But it want to use same cursor with system UXs for scenes like a menu > selection. Usually it uses a API to store system cursor. - > SDL_GetCursor -- Get the currently active mouse cursor. But there is > no way to support this API on Wayland. Currently it's not important > to support this API. Because there is no guarantee for that current > cursor is same with system cursor. This I don't understand. SDL_GetCursor returns the cursor that you with SDL_SetCursor or libSDL itself automatically last set, does it not? On Wayland, libSDL internally would just use libwayland-cursor to get the default cursor, and automatically use it. If a client wants to use the "system" cursor theme, it will simply load the cursor theme called "default" via libwayland-cursor. > In case of any app having mouse focus, it will handle pointer_enter. > If the app wants to use same cursor with system UX's *current* one, > it should know about what it is. Because the system cursor is > configurable. Yeah, here's your point: you want to change the default cursor theme at runtime, dynamically. If the default cursor theme stayed the same during a session lifetime, then you would simply load the theme "default" once at the start of each application, and be done with it. > Now I return to the origin point. > According to Wayland design, there might be no way except supporting > dynamic-switching for theme of wayland-cursor. Can I find another > approach? Right, knowing the default cursor theme is not a problem in itself. The problem is that the default (or system) cursor theme changes. This requires a Wayland protocol extension, that will announce the name of the new cursor theme as it changes, I believe. Or, a completely different mechanism, that not only stores settings, but announces their changes runtime. I think both Gnome and KDE or Qt have their own things. Now I at least understand what you really want. :-) What would be the preferred solution, I cannot say. The first question is, do you need the solution in Wayland upstream, or would you be happy with whatever solution you can make up for the project at hand? I guess the question for the Wayland developer community is, do we want such cursor theme settings in the shell protocol, or is that something that should be left for DEs to solve in their own configuration systems? Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/4] input: Add a weston_pointer_output_center
On Tue, Jun 11, 2013 at 03:08:23PM +0300, Pekka Paalanen wrote:
> On Mon, 10 Jun 2013 15:17:29 +0100
> Rob Bradford wrote:
>
> > From: Rob Bradford
> >
> > Centre the pointer on a the provided output. This function provides the
> > basis of ensuring that the pointer starts on the output when we start to
> > constrain a seat to a given output.
> > WL_EXPORT void
> > +weston_pointer_output_center(struct weston_pointer *pointer,
> > +struct weston_output *output)
> > +{
> > + pointer->x = wl_fixed_from_int(output->x + output->width / 2);
> > + pointer->y = wl_fixed_from_int(output->y + output->height / 2);
>
> What about all the processing that happens in input.c notify_motion()
> and move_pointer(), is that really not needed here?
Hi Pekka,
Thanks for highlighting this. I should write this function in terms of
move_pointer().
Rob
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 1/2] build: Fix warning message on syscall failures
From: Rob Bradford
---
configure.ac | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 7f3a694..7ca70da 100644
--- a/configure.ac
+++ b/configure.ac
@@ -42,13 +42,13 @@ AC_SUBST(GCC_CFLAGS)
AC_CHECK_FUNCS([accept4 mkostemp])
AC_CHECK_DECL(SFD_CLOEXEC,[],
- [AC_MSG_ERROR("SFD_CLOEXEC is needed to compile weston")],
+ [AC_MSG_ERROR("SFD_CLOEXEC is needed to compile wayland")],
[[#include ]])
AC_CHECK_DECL(TFD_CLOEXEC,[],
- [AC_MSG_ERROR("TFD_CLOEXEC is needed to compile weston")],
+ [AC_MSG_ERROR("TFD_CLOEXEC is needed to compile wayland")],
[[#include ]])
AC_CHECK_DECL(CLOCK_MONOTONIC,[],
- [AC_MSG_ERROR("CLOCK_MONOTONIC is needed to compile weston")],
+ [AC_MSG_ERROR("CLOCK_MONOTONIC is needed to compile wayland")],
[[#include ]])
AC_CHECK_HEADERS([execinfo.h])
--
1.8.2.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 2/2] protocol: Add missing since attribute for name event on wl_seat
From: Rob Bradford This event was added in version 2 of the protocol. --- protocol/wayland.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index f5d08b5..3d4ec9b 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1234,7 +1234,7 @@ - + In a multiseat configuration this can be used by the client to help identify which physical devices the seat represents. Based on -- 1.8.2.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Things that killed my motivation to play with wayland
On Wed, Jun 12, 2013 at 12:40 AM, wrote: > On 12/06/2013 02:49, dar...@chaosreigns.com wrote: >> >> 1) This mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=61919 >> make fails without C_INCLUDE_PATH set. It pretty much destroyed my build >> testing setup (I was build testing 46 related repos every few hours). >> I never managed to work out the obvious workaround of just setting >> C_INCLUDE_PATH for mesa builds (which I had working for another repo). >> I included the commit where the problem started. Three months ago. >> (Build test script I wrote: http://www.chaosreigns.com/code/buildtest/ ) > > > I provided a patch on this one, and even if I didn’t test it, it should work > in your case. If not, I’m willing to help, just ask me for another patch > with some relevant logs. Indeed. Let me know if the new patch fixes things for you and I'll commit it. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, Jun 12, 2013 at 5:23 AM, wrote:
> On 12/06/2013 09:57, Pekka Paalanen wrote:
>>
>> To get the big picture, let me reiterate the surface classification as
>> a whole, the way I see it.
>>
>> Surface roles, exclusive:
>> - cursor
>> - drag icon
>> - shell surface
>
>
> Each role is an interface then? Simple and efficient, I love it.
>
>
>
>> Shell surface types, exclusive:
>> - top-level
>> - transient (umm, what was this for, again?)
>> - popup (menu?)
>
>
> Transcient is for dialog (modal?) boxes, isn’t it?
> Each type is a one-shot request on a new created surface. Again, simple and
> efficient, love it too.
> It may be a bit more clear, see below.
>
>
>> Top-level shell surface states, each more or less toggleable on its own:
>> - maximized
>> - fullscreen
>> - minimized
>> - sticky
>> - always-on-top or some equivalent layer thing
>> ...
>
>
>> Does this make sense?
>
>
> Yes.
>
>
>
>> That is, only a top-level surface, which we should probably be calling
>> as an application window, can be maximized etc., and I think the
>> discussion was that it can be many things at once, like maximized and
>> minimized.
>
>
> Right, it is useful and not that hard to implement.
>
>
>
>> I don't think the states make sense as types, I would prefer the above
>> hierarchy. A shell surface can only have one type at a time, but the
>> states are not that restricted. It gives a nice tree-like hierarchy,
>> instead of a directed graph where several surface types can have the
>> same states. The tiling-WM developers would be concerned only about the
>> top-level shell surface states, and could hopefully support all the
>> shell surface types, which should make the difference between floating
>> and tiling WMs more manageable.
>
>
> I agree.
>
>
>
>> Protocol-wise, this means that requests set_maximized and
>> set_fullscreen would be deprecated as is, and replaced with the state
>> setting request. Request set_toplevel would deprecate the part of its
>> behaviour where it changes a surface into normal state.
>>
>> We cannot remove the deprecated functionality, I believe, so it must be
>> kept working, and just plumbed into the new kind of internal state
>> change machinery inside weston.
>>
>> However, it's not that simple. Some states need parameters. Maximized
>> needs an output, and fullscreen a few things more. Always-on-top
>> equivalent might want a layer number or something. Therefore I'm not
>> sure a single set_state request will work.
>
>
> At protocol level, we may be better using new interfaces.
>
> wl_shell will gain three requests:
> — get_toplevel_surface(class, title): returns a new
> wl_shell_toplevel_surface
> — get_transcient_surface(wl_shell_toplevel_surface): returns a transcient
> one
> — get_popup(wl_shell_toplevel_surface): returns a popup surface
>
> That would duplicate some requests between the three interfaces (or maybe
> two, if transcient and popup can share one).
> Backward-compatibility would be both easier and harder than keeping
> wl_shell_surface around, as we have to maintain a compatibility struct in
> the compositor, but that would be a simple struct { type; union { toplevel;
> transcient; popup; }; }.
>
> That would allow to extend the configure event in a nice fashion, that
> tiling WM will love (e.g. for decorations).
>
>
>> Anyway, that's just what came to my mind now. I don't recall any of the
>> earlier discussions anymore, maybe there were solutions to some of
>> these issues, maybe not.
>>
>> Did we ever discuss the possiblity of fullscreen being a special kind
>> of maximized, btw? If you look at the state list above, everything is
>> orthogonal (toggleable independently) except maximized vs. fullscreen.
>> This is just as a concept, how it maps into protocol is a different
>> matter.
>
>
> Fullscreen, especially for games, is a completely different thing (e.g.
> modesetting). We can have two cases here: “basic” fullscreen, which is just
> maximize with panel removed (and the app will use the normal decoration
> mechanism here, no fullscreen state), and plain fullscreen, which would be
> another surface type.
> I *think* most apps (games) already have heavy switching, so destroying and
> creating a new surface should not be a problem here, imo.
If I'm not wrong, in the previous discussion we also discussed about
the possibility of leaving fullscreen as a shell surface type itself.
Though I don't have strong opinion about this, just trying to leave
another possibility open.
--
Rafael Antognolli
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, Jun 12, 2013 at 6:25 AM, wrote:
> On 12/06/2013 11:18, Pekka Paalanen wrote:
>>
>> On Wed, 12 Jun 2013 10:23:33 +0200
>> sardemff7+wayl...@sardemff7.net wrote:
>>
>>> On 12/06/2013 09:57, Pekka Paalanen wrote:
To get the big picture, let me reiterate the surface classification as
a whole, the way I see it.
Surface roles, exclusive:
- cursor
- drag icon
- shell surface
>>>
>>>
>>> Each role is an interface then? Simple and efficient, I love it.
>>
>>
>> No, a role is just a concept. In protocol it is currently assigned by
>> passing the wl_surface as an argument for a specific request, that
>> assigns the role.
>>
>> Only shell surface has a new interface associated, IIRC.
>
>
> That’s fine: if the role is complex enough, put it in an interface.
>
>
>
Shell surface types, exclusive:
- top-level
- transient (umm, what was this for, again?)
- popup (menu?)
>>>
>>>
>>> Transcient is for dialog (modal?) boxes, isn’t it?
>>
>>
>> Tooltips and alike, rather.
>
>
> Ok, so we should add something here for modal dialogs.
>
>
> [snip]
>
Protocol-wise, this means that requests set_maximized and
set_fullscreen would be deprecated as is, and replaced with the state
setting request. Request set_toplevel would deprecate the part of its
behaviour where it changes a surface into normal state.
We cannot remove the deprecated functionality, I believe, so it must be
kept working, and just plumbed into the new kind of internal state
change machinery inside weston.
However, it's not that simple. Some states need parameters. Maximized
needs an output, and fullscreen a few things more. Always-on-top
equivalent might want a layer number or something. Therefore I'm not
sure a single set_state request will work.
>>>
>>>
>>> At protocol level, we may be better using new interfaces.
>>>
>>> wl_shell will gain three requests:
>>> — get_toplevel_surface(class, title): returns a new
>>> wl_shell_toplevel_surface
>>> — get_transcient_surface(wl_shell_toplevel_surface): returns a
>>> transcient one
>>> — get_popup(wl_shell_toplevel_surface): returns a popup surface
>>>
>>> That would duplicate some requests between the three interfaces (or
>>> maybe two, if transcient and popup can share one).
>>> Backward-compatibility would be both easier and harder than keeping
>>> wl_shell_surface around, as we have to maintain a compatibility struct
>>> in the compositor, but that would be a simple struct { type; union {
>>> toplevel; transcient; popup; }; }.
>>>
>>> That would allow to extend the configure event in a nice fashion, that
>>> tiling WM will love (e.g. for decorations).
>>
>>
>> That is certainly a novel suggestion. I wonder what toolkit authors
>> would think.
>
>
> I would probably provide patches for GTK+ at least, to test the stuff, and
> the old interface (less powerful) would still be there for a while.
For EFL we are just waiting for the new API and implementation (which
I hope to actually work on it). The idea is to use the new interface
ASAP, but the already released versions would keep the old one, I
guess.
--
Rafael Antognolli
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, Jun 12, 2013 at 5:23 AM, wrote:
> On 12/06/2013 09:57, Pekka Paalanen wrote:
>>
>> To get the big picture, let me reiterate the surface classification as
>> a whole, the way I see it.
>>
>> Surface roles, exclusive:
>> - cursor
>> - drag icon
>> - shell surface
>
>
> Each role is an interface then? Simple and efficient, I love it.
>
>
>
>> Shell surface types, exclusive:
>> - top-level
>> - transient (umm, what was this for, again?)
>> - popup (menu?)
>
>
> Transcient is for dialog (modal?) boxes, isn’t it?
> Each type is a one-shot request on a new created surface. Again, simple and
> efficient, love it too.
> It may be a bit more clear, see below.
>
>
>> Top-level shell surface states, each more or less toggleable on its own:
>> - maximized
>> - fullscreen
>> - minimized
>> - sticky
>> - always-on-top or some equivalent layer thing
>> ...
>
>
>> Does this make sense?
>
>
> Yes.
>
>
>
>> That is, only a top-level surface, which we should probably be calling
>> as an application window, can be maximized etc., and I think the
>> discussion was that it can be many things at once, like maximized and
>> minimized.
>
>
> Right, it is useful and not that hard to implement.
>
>
>
>> I don't think the states make sense as types, I would prefer the above
>> hierarchy. A shell surface can only have one type at a time, but the
>> states are not that restricted. It gives a nice tree-like hierarchy,
>> instead of a directed graph where several surface types can have the
>> same states. The tiling-WM developers would be concerned only about the
>> top-level shell surface states, and could hopefully support all the
>> shell surface types, which should make the difference between floating
>> and tiling WMs more manageable.
>
>
> I agree.
>
>
>
>> Protocol-wise, this means that requests set_maximized and
>> set_fullscreen would be deprecated as is, and replaced with the state
>> setting request. Request set_toplevel would deprecate the part of its
>> behaviour where it changes a surface into normal state.
>>
>> We cannot remove the deprecated functionality, I believe, so it must be
>> kept working, and just plumbed into the new kind of internal state
>> change machinery inside weston.
>>
>> However, it's not that simple. Some states need parameters. Maximized
>> needs an output, and fullscreen a few things more. Always-on-top
>> equivalent might want a layer number or something. Therefore I'm not
>> sure a single set_state request will work.
>
>
> At protocol level, we may be better using new interfaces.
>
> wl_shell will gain three requests:
> — get_toplevel_surface(class, title): returns a new
> wl_shell_toplevel_surface
> — get_transcient_surface(wl_shell_toplevel_surface): returns a transcient
> one
> — get_popup(wl_shell_toplevel_surface): returns a popup surface
>
> That would duplicate some requests between the three interfaces (or maybe
> two, if transcient and popup can share one).
> Backward-compatibility would be both easier and harder than keeping
> wl_shell_surface around, as we have to maintain a compatibility struct in
> the compositor, but that would be a simple struct { type; union { toplevel;
> transcient; popup; }; }.
>
> That would allow to extend the configure event in a nice fashion, that
> tiling WM will love (e.g. for decorations).
>
Hmm... I'm still trying to understand this part, but are these calls
used to create the shell surfaces?
I also don't get exactly what would be the approach for passing
parameters to the "state set" calls. Would we have a custom data field
on the state_set call, or have specialized state set functions, each
with its own set of parameters, like state_maximized_set,
state_minimized_set, etc?
I'll try to summarize things here:
https://github.com/antognolli/wayland/wiki/Surface-States
Feel free to edit it if you want, I think that it's open to anyone to edit.
Regards,
--
Rafael Antognolli
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] xwayland: Forward global position to X
xeyes works as expected now. subwindows are popped also as expected. This
patch should fix the following:
https://bugs.freedesktop.org/show_bug.cgi?id=59983
Signed-off-by: Tiago Vignatti
---
Hey guys,
This fix the problem mentioned above but exposes something that was already
buggy before: XWM (and probably all X clients) is getting wrong EnterNotify,
setting wrong cursor. This happens sometimes only.
To check the problem, I've added a printf in weston_wm_handle_enter and set
WAYLAND_DEBUG=1. You will see that the coordinates wl_pointer_enter comes to
XWayland vary from what it sends along to the X clients. It's not all the
time as I said, so probably there's a race between the two protocols. Another
way to check is clobber one window with another, leaving the cursor right on
the decoration border where it should change the icon if you alternate the
windows with ctrl+tab:
http://i.troll.ws/4c2cbb1b.png
Grab cursor not being set all the times is another way to see the bug.
I hope this help someone else find the problem. I'm not continuing the
investigations here in principle.
Tiago
src/compositor.c |1 +
src/compositor.h |5 +++
src/shell.c | 30 -
src/xwayland/window-manager.c | 73 ++---
src/xwayland/xwayland.h |2 +-
5 files changed, 83 insertions(+), 28 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index 099600d..f019441 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -2777,6 +2777,7 @@ weston_compositor_init(struct weston_compositor *ec,
ec->wl_display = display;
wl_signal_init(&ec->destroy_signal);
wl_signal_init(&ec->activate_signal);
+ wl_signal_init(&ec->position_signal);
wl_signal_init(&ec->kill_signal);
wl_signal_init(&ec->idle_signal);
wl_signal_init(&ec->wake_signal);
diff --git a/src/compositor.h b/src/compositor.h
index 22700b7..bcca468 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -94,6 +94,8 @@ struct weston_shell_interface {
uint32_t method,
uint32_t framerate,
struct weston_output *output);
+ void (*set_xwayland)(struct shell_surface *shsurf,
+ int x, int y, uint32_t flags);
int (*move)(struct shell_surface *shsurf, struct weston_seat *ws);
int (*resize)(struct shell_surface *shsurf,
struct weston_seat *ws, uint32_t edges);
@@ -502,7 +504,10 @@ struct weston_compositor {
struct weston_shell_interface shell_interface;
struct weston_config *config;
+ /* xwayland */
struct wl_signal activate_signal;
+ struct wl_signal position_signal;
+
struct wl_signal kill_signal;
struct wl_signal idle_signal;
struct wl_signal wake_signal;
diff --git a/src/shell.c b/src/shell.c
index 3d10eef..d9038b2 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -171,7 +171,8 @@ enum shell_surface_type {
SHELL_SURFACE_TRANSIENT,
SHELL_SURFACE_FULLSCREEN,
SHELL_SURFACE_MAXIMIZED,
- SHELL_SURFACE_POPUP
+ SHELL_SURFACE_POPUP,
+ SHELL_SURFACE_XWAYLAND
};
struct ping_timer {
@@ -340,9 +341,13 @@ shell_grab_start(struct shell_grab *grab,
static void
shell_grab_end(struct shell_grab *grab)
{
+ struct weston_compositor *compositor =
+ grab->shsurf->surface->compositor;
+
if (grab->shsurf)
wl_list_remove(&grab->shsurf_destroy_listener.link);
+ wl_signal_emit(&compositor->position_signal, grab->shsurf->surface);
weston_pointer_end_grab(grab->pointer);
}
@@ -1581,6 +1586,7 @@ reset_shell_surface_type(struct shell_surface *surface)
case SHELL_SURFACE_TOPLEVEL:
case SHELL_SURFACE_TRANSIENT:
case SHELL_SURFACE_POPUP:
+ case SHELL_SURFACE_XWAYLAND:
break;
}
@@ -1622,6 +1628,11 @@ set_surface_type(struct shell_surface *shsurf)
}
break;
+ case SHELL_SURFACE_XWAYLAND:
+ weston_surface_set_position(surface, shsurf->transient.x,
+ shsurf->transient.y);
+ break;
+
default:
break;
}
@@ -1925,6 +1936,16 @@ shell_surface_set_fullscreen(struct wl_client *client,
set_fullscreen(shsurf, method, framerate, output);
}
+static void
+set_xwayland(struct shell_surface *shsurf, int x, int y, uint32_t flags)
+{
+ /* XXX: using the same fields for transient type */
+ shsurf->transient.x = x;
+ shsurf->transient.y = y;
+ shsurf->transient.flags = flags;
+ shsurf->next_type = SHELL_SURFACE_XWAYLAND;
+}
+
static const struct weston_pointer_grab_interface popup_grab_interface;
static void
@@ -3399,6 +3420,7 @@ map(struct desktop_shell *shell, struct weston_surface
*s
Re: Things that killed my motivation to play with wayland
Hi, On 06/12/2013 04:40 AM, sardemff7+wayl...@sardemff7.net wrote: On 12/06/2013 02:49, dar...@chaosreigns.com wrote: 2) The XWayland segfault bug: https://bugs.freedesktop.org/show_bug.cgi?id=59983 This was the reason I stopped using weston as my primary UI at home in September. Tiago said he had a fix for it in one of his branches a long time ago, but I guess it wasn't compatible with the changes made to the plan to handle xwm. Blows my mind that this isn't the top priority of the project. I'm sure there's fine reasons. It would be nice to know what they are. I just rebased the full xwayland branch to xorg-server master, and also the intel and wlshm DDX. http://git.sardemff7.net/wayland/xorg-server/log/?h=xwayland-1.15 http://git.sardemff7.net/wayland/xf86-video-intel/log/?h=xwayland http://git.sardemff7.net/wayland/xf86-video-wlshm/ If Tiago can point me to the fix commit, I can include it in there, so we can start using a new base to hack on. I just sent the fix to the mailing list. I don't consider that patch enough though cause it exposes now another bug in XWayland infrastructure. Tiago ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
Shell surface types, exclusive: - top-level - transient (umm, what was this for, again?) - popup (menu?) Transcient is for dialog (modal?) boxes, isn’t it? It means "this window stays above another one". Transient cannot be a type, but instead a state of a surface. It has to be done by setting a "parent surface" which means that the compositor keeps the surface above the parent. It does not imply anything else, in particular the client decides whether either surface is currently visible. The client has to be able to arbitrarily rearrange the parent pointers. This means it can set them to null (since otherwise it is not possible to get all rearrangements if the compositor rejects any attempts that make a loop). Therefore a "transient surface" can become a "main surface" and thus they must be the same object. This is a requirement so that non-trivial clients can be written that are not forced to blink the transient windows to change their parenting. Popups are also transient windows (and thus normal windows) but they have some effects on event delivery when they are first mapped. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The way to use system cursor and custom(client) cursor
Pekka Paalanen wrote: I guess the question for the Wayland developer community is, do we want such cursor theme settings in the shell protocol, or is that something that should be left for DEs to solve in their own configuration systems? Any solution should involve everything the user calls "themes". Historically clients that did nothing automatically get the "theme" for the cursor and for the window borders. But they had to write a whole lot of code to change the "theme" for the button widgts. This historical artifact has led to lots of people saying these are somehow special and therefore there must be special api in Wayland for them. But this is illogical, the user sees no difference between them, so any solution must solve the buttons and every other "theme". So there should be no special "this is the cursor theme" api in Wayland. If some genius out there can design a "this is the entire theme" api then maybe Wayland can do that. But I suspect any attempt will by like .Xdefaults and be just as useless. So I suspect leaving it for the DE's to solve would be the right approach. It would be nice if someday if they all agreed on a "theme library" that is not part of a toolkit but that toolkits can use to draw just like they share cairo to draw now. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] text: Fix misleading error message
On 06/07/2013 02:27 AM, Kristian Høgsberg wrote:
> On Thu, Jun 06, 2013 at 10:59:06AM -0300, Eduardo Lima (Etrunko) wrote:
>> Ping?
>
> This never made it to the list, it got stuck in moderation. Normally
> you just subscribe to the list and re-send it, but I found it in the
> moderation queue and let it through.
Thank you, I was wondering if that was the problem. I have tweaked my
git config to send patches with the address that is actually subscribed
to the mailing list.
Regards, Eduardo
>
> Kristian
>
>> On 05/10/2013 05:50 PM, Eduardo Lima (Etrunko) wrote:
>>> From: "Eduardo Lima (Etrunko)"
>>>
>>> This should be "input_method" and not "desktop_shell"
>>>
>>> Signed-off-by: Eduardo Lima (Etrunko)
>>> ---
>>> src/text-backend.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/text-backend.c b/src/text-backend.c
>>> index 92efd9f..d7ce31c 100644
>>> --- a/src/text-backend.c
>>> +++ b/src/text-backend.c
>>> @@ -762,7 +762,7 @@ bind_input_method(struct wl_client *client,
>>>
>>> if (text_backend->input_method.client != client) {
>>> wl_resource_post_error(resource,
>>> WL_DISPLAY_ERROR_INVALID_OBJECT,
>>> - "permission to bind desktop_shell
>>> denied");
>>> + "permission to bind input_method
>>> denied");
>>> wl_resource_destroy(resource);
>>> return;
>>> }
>>>
>>
>>
>> --
>> Eduardo de Barros Lima (Etrunko)
>> Software Engineer, Open Source Technology Center
>> Intel Corporation
>> São Paulo, Brazil
>> eduardo.l...@linux.intel.com
>> ___
>> 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
>
--
Eduardo de Barros Lima (Etrunko)
Software Engineer, Open Source Technology Center
Intel Corporation
São Paulo, Brazil
eduardo.l...@linux.intel.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, Jun 12, 2013 at 4:39 PM, Bill Spitzak wrote: > >>> Shell surface types, exclusive: >>> - top-level >>> - transient (umm, what was this for, again?) >>> - popup (menu?) >> >> >> Transcient is for dialog (modal?) boxes, isn’t it? > > > It means "this window stays above another one". > > Transient cannot be a type, but instead a state of a surface. It has to be > done by setting a "parent surface" which means that the compositor keeps the > surface above the parent. It does not imply anything else, in particular the > client decides whether either surface is currently visible. > > The client has to be able to arbitrarily rearrange the parent pointers. This > means it can set them to null (since otherwise it is not possible to get all > rearrangements if the compositor rejects any attempts that make a loop). > Therefore a "transient surface" can become a "main surface" and thus they > must be the same object. In this case, it's the "transient" state could be set/unset on surfaces that have a parent. However, if the surface has its parent set to NULL, the "transient" state must be automatically unset too, otherwise we would have an inconsistent state. Is this correct? > This is a requirement so that non-trivial clients can be written that are > not forced to blink the transient windows to change their parenting. > > Popups are also transient windows (and thus normal windows) but they have > some effects on event delivery when they are first mapped. So this would be a different state, that has the "transient" state being set as a requirement, or would it be a flag passed to the "transient" state when setting it? (I think the latter makes more sense to me). -- Rafael Antognolli ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, Jun 12, 2013 at 7:39 PM, Rafael Antognolli wrote: > On Wed, Jun 12, 2013 at 4:39 PM, Bill Spitzak wrote: >> Shell surface types, exclusive: - top-level - transient (umm, what was this for, again?) - popup (menu?) >>> >>> >>> Transcient is for dialog (modal?) boxes, isn’t it? >> >> >> It means "this window stays above another one". >> >> Transient cannot be a type, but instead a state of a surface. It has to be >> done by setting a "parent surface" which means that the compositor keeps the >> surface above the parent. It does not imply anything else, in particular the >> client decides whether either surface is currently visible. >> >> The client has to be able to arbitrarily rearrange the parent pointers. This >> means it can set them to null (since otherwise it is not possible to get all >> rearrangements if the compositor rejects any attempts that make a loop). >> Therefore a "transient surface" can become a "main surface" and thus they >> must be the same object. > > In this case, it's the "transient" state could be set/unset on > surfaces that have a parent. However, if the surface has its parent > set to NULL, the "transient" state must be automatically unset too, > otherwise we would have an inconsistent state. Is this correct? > >> This is a requirement so that non-trivial clients can be written that are >> not forced to blink the transient windows to change their parenting. >> >> Popups are also transient windows (and thus normal windows) but they have >> some effects on event delivery when they are first mapped. > > So this would be a different state, that has the "transient" state > being set as a requirement, or would it be a flag passed to the > "transient" state when setting it? (I think the latter makes more > sense to me). > > -- > Rafael Antognolli I've just updated the proposal, considering my last statement. Take a look at it and see if it fits your suggestion. This lets us with 2 surface types (toplevel and fullscreen), and 5 states (maximized, minimized, sticky, always_on_top and transient) and their respective parameters. https://github.com/antognolli/wayland/wiki/Surface-States -- Rafael Antognolli ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
Rafael Antognolli wrote: Rafael Antognolli I've just updated the proposal, considering my last statement. Take a look at it and see if it fits your suggestion. This lets us with 2 surface types (toplevel and fullscreen), and 5 states (maximized, minimized, sticky, always_on_top and transient) and their respective parameters. https://github.com/antognolli/wayland/wiki/Surface-States Possibly, if setting the "transient" state requires also sending the parent as a parameter, and clearing it is how you set it to null? But you need to solve your question about how to give parameters when setting states. I personally feel this api and the subwindow api should be merged as they are extremely similar. The only difference is that the compositor is allowed to insert other surfaces between the transient window and it's parent, but not subwindows and their parent. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
