Re: Protocol backwards compatibility requirements?
On Mon, 2020-04-20 at 15:05 +0300, Pekka Paalanen wrote: > On Thu, 16 Apr 2020 17:47:56 +1000 > Christopher James Halse Rogers wrote: > > > On Wed, Apr 15, 2020 at 14:27, Simon Ser wrote: > > > Hi, > > > > > > On Monday, April 13, 2020 1:59 AM, Peter Hutterer > > > wrote: > > > > Hi all, > > > > > > > > This is request for comments on the exact requirements for protocol > > > > backwards compatibility for clients binding to new versions of an > > > > interface. > > > > Reason for this are the high-resolution wheel scrolling patches: > > > > https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72 > > > > > > > > Specifically, the question is: do we **change** protocol elements or > > > > behaviour as the interface versions increase? A few random examples: > > > > > > What we can't do is: > > > > > > - Change existing messages' signature > > > - Completely remove a message > > Indeed. > > > It should be relatively easy to modify wayland-scanner to support both > > of these things, *if* we decide that it's a reasonable thing to do. > > (You'd do something like add support for > removed_in="5"/> and the like) > > How would that work, given the version is negotiated at runtime? > > The message signature structs are now ABI as well, and we have no room > for alternate signatures, do we? > > > > > > > > - event wl_foo.bar introduced in version N sends a wl_fixed in > > > >surface coordinates. version N+1 changes this to a normalized > > > >[-1, +1] range. > > > > > > Argument types can't be changed. This would be a breaking change for > > > the > > > generated code, we can't do that. > > > > But this isn't changing the argument type; it's changing the > > interpretation of the argument. > > In both cases the type is wl_fixed; in the first you interpret this > > wl_fixed as being in surface coordinates, in the second you interpret > > it differently. > > > > This doesn't require any changes to code generation; I don't think this > > is (in principle) any more disruptive than changing “wl_foo.baz is > > sent exactly once” to “wl_foo.baz is sent zero or more times”, > > which you're happy with. > > Something we rarely consider is if you pass Wayland protocol objects > into a library without negotiating the object version with the library > first. For example, we pass wl_surface into the EGL Wayland wrapper > library. If wl_surface would get a version bump breaking backwards > compatibility, meaning that version N+1 changes something that existed > in version N, the library handling only version N would fall apart. > > I sincerely hope this is the only case of a library taking a ready-made > Wayland object in. Getting the version negotiation right needs > inconvenient additions to the library API that I don't think many would > bother or even realize it's needed. > > You can query the version of a wl_proxy, sure, but that does not help > you if it returns a number larger than what your code knows about. > > Btw. this is also a problem in the opposite direction. Let's say you > use a toolkit and the toolkit allows you access to the Wayland protocol > objects. Then the toolkit gains support for new interface versions and > uses them, but your app code is not updated. If the protocol change is > backwards incompatible, your app code may break even if only behaviour > changes and not signatures. Yeah, pretty sure we hit this more than once with XI2. X11 has this property too, the client is not monolithic and different parts of it expect different protocol versions and want their own interaction with the protocol stream. If that includes event delivery you suddenly need to be very careful that the app doesn't deselect the events you need... I believe some protocols address this by putting a "channel" abstraction just beneath the client: one socket connection, N channels, each channel has its own ID space, you can share resources among compatible channels but it's an explicit import operation. In X11 terms you could have the GL driver select for the Present / MIT-SHM completion event in its own channel without stomping on the client's main loop state. Of course, for things like XI2, if you have two channels demanding different visible behaviour, you're still up a creek. But you would at least have the possibility that the client could get it right. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > > pre-merge CI. > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > I wouldn't mind manually triggering pipelines, but unless there is > some trick I'm not realizing, it is super cumbersome. Ie. you have to > click first the container jobs.. then wait.. then the build jobs.. > then wait some more.. and then finally the actual runners. That would > be a real step back in terms of usefulness of CI.. one might call it a > regression :-( I think that's mostly a complaint about the conditionals we've written so far, tbh. As I commented on the bug, when I clicked the container job (which the rules happen to have evaluated to being "manual"), every job (recursively) downstream of it got enqueued, which isn't what you're describing. So I think if you can describe the UX you'd like we can write rules to make that reality. But I don't really know which jobs are most expensive in terms of bandwidth, or storage, or CPUs, and even if I knew those I don't know how to map those to currency. So I'm not sure if the UI we'd like would minimize the cost the way we'd like. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On Tue, 2020-03-17 at 10:12 -0700, Jacob Lifshay wrote: > One related issue with explicit sync using sync_file is that combined > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the > rendering in userspace (like llvmpipe but for Vulkan and with extra > instructions for GPU tasks) but need to synchronize with other > drivers/processes is that there should be some way to create an > explicit fence/semaphore from userspace and later signal it. This > seems to conflict with the requirement for a sync_file to complete in > finite time, since the user process could be stopped or killed. DRI3 (okay, libxshmfence specifically) uses futexes for this. Would that work for you? IIRC the semantics there are that if the process dies the futex is treated as triggered, which seems like the only sensible thing to do. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
On Wed, 2020-03-11 at 12:31 -0500, Jason Ekstrand wrote: > - X11: With present, it has these "explicit" fence objects but > they're always a shmfence which lets the X server and client do a > userspace CPU-side hand-off without going over the socket (and > round-tripping through the kernel). However, the only thing that > fence does is order the OpenGL API calls in the client and server and > the real synchronization is still implicit. I'm pretty sure "the only thing that fence does" is an implementation detail. PresentPixmap blocks until the wait-fence signals, but when and how it signals are properties of the fence itself. You could have drm give the client back a fence fd, pass that to xserver to create a fence object, and name that in the PresentPixmap request, and then drm can do whatever it wants to signal the fence. > From my perspective, as a Vulkan driver developer, I have to deal with > the fact that Vulkan is an explicit sync API but Wayland and X11 > aren't. I'm quite sure we can give you an explicit-sync X11 API. I think you may already have one. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compositor crashes when switching tty
On Tue, 2019-05-28 at 08:26 +0100, adlo wrote: > When switching tty, my compositor crashes with error messages such as > > free (): invalid size Aborted (core dumped) > or > malloc (): invalid chunk size This means something is corrupting the malloc arena metadata. Run your compositor under valgrind and fix what it complains about. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Xwayland component in bugzilla
On Fri, 2019-05-10 at 11:09 +0200, Olivier Fourdan wrote: > Hi, > > On Fri, May 10, 2019 at 10:45 AM Jonas Ådahl wrote: > > On Fri, May 10, 2019 at 11:29:50AM +0300, Pekka Paalanen wrote: > > > On Thu, 09 May 2019 14:03:52 -0400 > > > Adam Jackson wrote: > > > > > > > The Xwayland component of the Wayland product in bugzilla is still open > > > > for bug entry. Does anyone actually want this? I'm happy to migrate the > > > > remaining open bugs into xserver's gitlab issues where they belong, but > > > > I wanted to make sure nobody's still relying on bugzilla for this. > > > > > > Hi Adam, > > > > > > I don't recall why that even existed in the first place... maybe it was > > > from the time when xwayland was still a DDX module for Xorg? > > Yeap, IIRC this was the reason. > > But, as far as I am concerned, I prefer to have Xwayland in the > Xserver domain, it's just more logical to me (many of the issues with > Xwayland nowadays are not strictly Xwayland or Wayland related, but > rather Present, glamor, etc.) Agreed. Based on all this feedback I've migrated the remaining Xwayland bugs to xserver's gitlab. The 'wayland' product in bz is now completely closed. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Xwayland component in bugzilla
The Xwayland component of the Wayland product in bugzilla is still open for bug entry. Does anyone actually want this? I'm happy to migrate the remaining open bugs into xserver's gitlab issues where they belong, but I wanted to make sure nobody's still relying on bugzilla for this. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols v2 0/1] Color Management Protocol
On Wed, 2019-03-06 at 18:09 +0100, Sebastian Wick wrote: > 2. How exactly should the client be informed of the "prefered" color >spaces? >IMO there are a few requirements: >* the client should know when the prefered color space changes >* the client should know when multiple color spaces are involved >* the priority of those color spaces >The single "prefered" color space that can be requested doesn't meet >those requirements, neither does the wl_output.enter/leave (missing >priority) nor does my protocol (moving the surface to another output >will not trigger any new events). >Another point here is that wl_output actually doesn't map to a single >but multiple color spaces (e.g. cloned display). >Better ideas are very welcome! The proposed DEEPCOLOR extension to X11 expresses this as a dynamic list of priorities, which seems like a pretty decent idea. The most recent draft is here (grep for "Full text"): https://lists.x.org/archives/xorg-devel/2017-November/055250.html - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: HDR support in Wayland/Weston
On Wed, 2019-03-06 at 15:52 +1100, Graeme Gill wrote: > Adam Jackson wrote: > > > X kinda has three mechanisms for this. The first one, that nobody > > really uses, is setting the colormap for a DirectColor visual. > > Actually this is something I check and set to linear before > calibration & profiling in the ArgyllCMS tools. Yeah, I was corrected about this on IRC as well. Apparently DirectColor really is a thing people use. > > The second, which games typically use, is setting per-channel gamma > > (implicitly for the whole screen) as single floating-point values with > > the xf86vidmode extension. > > Typically this is too crude a control for color management use. > My assumption (which could be wrong) is that this is overridden > by the per-crtc LUT. Technically I think what happens is the vidmode gamma is applied to RANDR's "compat" output, which is chosen by some handwavey heuristic. > > All of these are effectively the program specifying its transformation > > to what it hopes is linear in device space. The sample server happens > > to implement all three as global state, but that's an implementation > > detail. It would be straightforward to give each Xwayland client the > > illusion of complete control if we wanted. > > For the purposes of setting the display global color calibration state, > then this is not desirable. Sure, but one would not expect to control the display's global calibration state from an X client in this model, for broadly the same reasons that RANDR under Xwayland is read-only. The wayland server owns that state, the Xwayland server is simply a very demanding wayland client. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: HDR support in Wayland/Weston
On Fri, 2019-03-01 at 12:10 +0200, Pekka Paalanen wrote: > On Thu, 28 Feb 2019 18:28:33 -0700 > Chris Murphy wrote: > > > I'm curious how legacy applications including games used to manipulate > > actual hardware LUT in a video card, if the application asked the > > client to do it, in which case it still could do that? > > Hi Chris, > > right now, in no case. > > It would probably be possible to enhance Xwayland (the X server) to > implement whatever X11 offers as protocol for LUT manipulation, and > forward that to a Wayland display server (compositor) using a new > Wayland protocol extension where Xwayland attached that LUT to all > Xwayland wl_surfaces. Then the Wayland compositor would apply the LUT > per wl_surface. X kinda has three mechanisms for this. The first one, that nobody really uses, is setting the colormap for a DirectColor visual. The second, which games typically use, is setting per-channel gamma (implicitly for the whole screen) as single floating-point values with the xf86vidmode extension. The third, which desktop environments sometimes use to try to make distinct displays look similar, is setting per-crtc gamma as 256 (or whatever) stops per channel with the RANDR extension. All of these are effectively the program specifying its transformation to what it hopes is linear in device space. The sample server happens to implement all three as global state, but that's an implementation detail. It would be straightforward to give each Xwayland client the illusion of complete control if we wanted. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: HDR support in Wayland/Weston
On Wed, 2019-02-27 at 13:47 -0700, Chris Murphy wrote: > On Wed, Feb 27, 2019 at 5:27 AM Pekka Paalanen wrote: > > there is a single, unambiguous answer on Wayland: the compositor owns > > the pipeline. Therefore we won't have the kind of problems you describe > > above. > > > > These are the very reasons I am against adding any kind of protocol > > extension that would allow a client to directly touch the pipeline or > > to bypass the compositor. > > Well you need a client to do display calibration which necessarily > means altering the video LUT (to linear) in order to do the > measurements from which a correction curve is computed, and then that > client needs to install that curve into the video LUT. Now, colord > clearly has such capability, as it's applying vcgt tags in ICC > profiles now. If colord can do it, then what prevents other clients > from doing it? The wayland server is capable of knowing the process on the other end of the socket, and only exposing the color management control protocol to specifically blessed clients. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Limiting Xwayland to only one screen
On Tue, 2019-02-05 at 19:51 +, Singh, Satyeshwar wrote: > Hi, > I have a 2 screen configuration running Weston. When I run XWayland > on top, it initially shows a black screen on both the screens. I am > wondering if there is a way to limit XWayland to only using one > screen? Is there a config file or command line option that allows me > to do so? There is not an Xwayland option for this yet. Wouldn't be hard to add though, patches would be gratefully accepted. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Fbdev-backend removal from Weston (Re: Upcoming release)
On Tue, 2019-01-22 at 22:46 -0500, nerdopolis wrote: > Well, TBH, It's just my quazi-distribution Live CD that I still maintain... > It falls back to the Framebuffer on systems (or seats) that don't have > Kernel Mode Setting. The number of users now probably is low... I think the biggest class of fbdev users on reasonably modern hardware are people who've said nomodeset to avoid a drm driver bug and so fall down to efifb. I wonder if it's worth making a trivial efikms driver for that case. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: HDR support in Wayland/Weston
On Tue, 2019-01-15 at 11:30 +0200, Pekka Paalanen wrote: > On Tue, 15 Jan 2019 13:47:07 +1100 > Graeme Gill wrote: > > > If done in the composer, it would need to render the graphic elements to > > the output DPI / convert the source colorspace to the output colorspace. > > But the composer would need the code to do rendering / convert colorspaces > > (as well as being told what the graphic elements / source colorspace is), > > and this is not the role Wayland has - that's the responsibility of the > > client, so instead Wayland makes it possible for the client to know what DPI > > it is rendering to. The analogous facility for CM is for the client to know > > what output colorspace it is rendering for. > > Yes and no. Yes, we do and should let clients know what kind of outputs > their contents will be shown on. However, we will in any case need the > compositor to be able to do the full and correct conversion from what > ever the client has submitted to what is correct for a specific output, > because nothing guarantees that those two would always match. This isn't necessarily true. The server is free to just draw a black rectangle (or nothing) instead if the image doesn't match the target colorspace. If you want to handle the case of cloned outputs or crossing output borders, let the client attach one image per output colorspace if it wants, and let the server send the client events to indicate when it should start or stop drawing to a particular colorspace. You need that complexity in the client's renderer anyway, why add it to the server's? > One wl_surface on multiple outputs is an obvious case where one buffer > rendered by a client cannot match all the outputs it is shown on. The > other case is transitions between outputs, where we cannot have the > compositor wait for the client to re-draw with new color parameters. Honestly I think of this as an implementation issue? If we take the above multiple-images approach, then if it's my compositor I just omit drawing actors onto any output where there isn't an image for that colorspace, because I am comfortable saying any further latency is the client's renderer's problem. Someone else's compositor might try to bend the existing image to the output colorspace until the client has caught up, believing close-but-wrong color is better than visible absence of color. I could see an argument for either implementation depending on the environment, and I don't really see why the protocol spec should require one or the other. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [v2, weston] gl-renderer.c: Use gr->egl_config to create pbuffer surface
On Thu, 2018-08-02 at 17:21 -0700, Madhurkiran Harikrishnan wrote:
> The original implementation always chose first egl config for pbuffer
> surface type, however the returned configs are implementation specific
> and egl config may not always match between ctx and surface. Hence,
> use gr->egl_config which already has the matching config but ensure that
> windows and pbuffer bit are set for the surface type.
Does this make pbuffer surface support mandatory? (Or, is it mandatory
already.) If so it might make more sense to just do:
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 2c50d2da..97a8ef6a 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -3263,7 +3263,7 @@ gl_renderer_setup_egl_extensions(struct weston_compositor
*ec)
}
static const EGLint gl_renderer_opaque_attribs[] = {
- EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
+ EGL_SURFACE_TYPE, EGL_WINDOW_BIT | EGL_PBUFFER_BIT,
EGL_RED_SIZE, 1,
EGL_GREEN_SIZE, 1,
EGL_BLUE_SIZE, 1,
@@ -3273,7 +3273,7 @@ static const EGLint gl_renderer_opaque_attribs[] = {
};
static const EGLint gl_renderer_alpha_attribs[] = {
- EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
+ EGL_SURFACE_TYPE, EGL_WINDOW_BIT | EGL_PBUFFER_BIT,
EGL_RED_SIZE, 1,
EGL_GREEN_SIZE, 1,
EGL_BLUE_SIZE, 1,
As that way you'll always pick an EGLConfig with pbuffer support.
- ajax
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC][PATCH xserver] Multi-buffered flips on subsurfaces seg fault in Mesa
On Mon, 2018-01-29 at 17:54 +0100, Roman Gilg wrote: > The above patch series only allows flips on a child window with the same > dimensions as its parent xwl_window. For flips on child windows (for example > the video view port of a video player in windowed mode, see here: > http://www.subdiff.de/assets/images/2017-07-28-a-new-beginning.jpg) I wanted > to use Wayland subsurfaces as in the attached patch. > > The flipping itself works well on Weston and on KWin. But when shutting down > KWin in the end I get always a segmentation fault in Mesa when cleaning up EGL > via eglTerminate(EGLDisplay) through libepoxy. > > I pinpointed the seg fault to be a missing destroyImage function pointer here: > https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/egl_dri2.c#n2685 Pretty sure that can't be the problem. Every DRI driver implements that function, as far as I can tell. Possibly what's really happening is by the time you get to that crash the dri2_egl_display has already been torn down, ie that dri2_dpy is NULL, not the destroyImage hook. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH xserver] xwayland: remove dirty window unconditionally on unrealize
On Thu, 2018-01-25 at 12:52 +, Daniel Stone wrote: > Hi Olivier, > > On 24 January 2018 at 16:45, Olivier Fourdan wrote: > > Signed-off-by: Olivier Fourdan > > This is also: > Reviewed-by: Daniel Stone Merged both: remote: I: patch #200439 updated using rev 3362422e8413dd9f231cfac50ce0a0862525b1bf. remote: I: patch #200643 updated using rev fc8b7d05e74a6351df56ad8b17216aeb0dcc016b. remote: I: 2 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 29a5423abd..fc8b7d05e7 master -> master - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3 xserver 1/2] xwayland: Add optional xdg-output support
On Wed, 2018-01-24 at 11:31 +0100, Olivier Fourdan wrote: > Small bump, would need to land this patch for 1.20 so we can continue > with fixing mutter once this is available in an Xwayland release :) Thanks for the poke. This didn't quite build with meson, needed to generate the new client header there too. Fixed that and some comment typos, and merged: remote: E: failed to find patch for rev da8de2a7f6ab52ef52039b0dc9978260232a34a6. remote: I: 0 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 75408f53d4..da8de2a7f6 master -> master - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH xserver] xwayland: avoid a crash with empty window pixmaps
On Wed, 2018-01-24 at 11:36 +0100, Olivier Fourdan wrote: > So basically, just remove the “if > (RegionNotEmpty(DamageRegion(xwl_window->damage)))” would suffice? Worth a try anyway. I'm still just guessing at the root cause. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH xserver] xwayland: avoid a crash with empty window pixmaps
On Tue, 2018-01-23 at 10:15 +, Daniel Stone wrote: > Ooh. serialNumber == 1 means it's the root pixmap, which will actually > be uselessly empty. It would be interesting to see how we've ended up > here: it would have to be a top-level window which a) was manually > redirected by the WM when it was created, b) had damage posted on it, > and c) was unredirected (in that order). I can't think of how that > would happen; Map / draw / unmap without hitting BlockHandler? I think xwl_unrealize_window() might be broken for that case: /* ... */ wl_surface_destroy(xwl_window->surface); if (RegionNotEmpty(DamageRegion(xwl_window->damage))) xorg_list_del(&xwl_window->link_damage); DamageUnregister(xwl_window->damage); DamageDestroy(xwl_window->damage); /* ... */ If (for whatever reason) the damage region wasn't empty, we'd never unlink this window from the dirty list. Should probably just unlink it unconditionally. If this is indeed what's happening, then the window being updated in xwl_window_post_damage() would have ->mapped = 0, and would be not the root window itself. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH xserver] xwayland: avoid a crash with empty window pixmaps
On Thu, 2018-01-18 at 11:41 +0100, Olivier Fourdan wrote: > This is a rare occurrence of a crash in Xwayland for which I don't have > the reproducing steps, just a core file. > > The backtrace looks as follow: > > #0 raise () from /usr/lib64/libc.so.6 > #1 abort () from /usr/lib64/libc.so.6 > #2 OsAbort () at utils.c:1361 > #3 AbortServer () at log.c:877 > #4 FatalError () at log.c:1015 > #5 OsSigHandler () at osinit.c:154 > #6 > #7 xwl_glamor_pixmap_get_wl_buffer () at xwayland-glamor.c:162 > #8 xwl_screen_post_damage () at xwayland.c:514 > #9 block_handler () at xwayland.c:665 > #10 BlockHandler () at dixutils.c:388 > #11 WaitForSomething () at WaitFor.c:219 > #12 Dispatch () at dispatch.c:422 > #13 dix_main () at main.c:287 > > The crash is caused by dereferencing “xwl_pixmap->buffer” in > xwl_glamor_pixmap_get_wl_buffer() because “xwl_pixmap” is NULL. > > Reason for this is because the corresponding pixmap has a size of 0×0 > and no xwl_pixmap is created for pixmaps of size 0×0. That can't really be the problem. X drawables are never 0x0. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH xserver] xwayland: Give up “cleanly“ on Wayland socket errors
On Tue, 2017-11-21 at 14:45 +0100, Olivier Fourdan wrote: > Xwayland is a pretty standard Wayland client, we want to be able to > capture core dumps on crashes. > > Yet using "-core" causes any FatalError() to generate a core dump, > meaning that we would get a core file for all Wayland server crashes, > which would generate a lot of false positives. > > Instead of using FatalError() on Wayland socket errors, give up > cleanly > to avoid dumping core files when "-core" is used. > > See also: https://bugzilla.gnome.org/show_bug.cgi?id=790502 > and: https://bugzilla.gnome.org/show_bug.cgi?id=789086 > > Signed-off-by: Olivier Fourdan remote: I: patch #189529 updated using rev fe46cbea0f19959d469ca4d1f09be379dc7b1e45. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 6883ae43eb..fe46cbea0f master -> master - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH xserver] xwayland: Fix non-argb cursor conversion
On Tue, 2017-12-05 at 10:51 +, Daniel Stone wrote: > On 27 September 2017 at 17:01, Olivier Fourdan > wrote: > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=103012 > > Signed-off-by: Olivier Fourdan > > Reviewed-by: Daniel Stone remote: I: patch #179214 updated using rev 97ac59b1ed3624f7c04e54dd3e3dadfa46a8f170. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver a4c1e29082..97ac59b1ed master -> master - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH xserver v2] xwayland: add envvar XWAYLAND_NO_GLAMOR
On Thu, 2017-03-02 at 11:03 +0100, Olivier Fourdan wrote: > Not all compositors allow for customizing the Xwayland command line, > gnome-shell/mutter for example have the command line and path to > Xwayland binary hardcoded, which makes it harder for users to disable > glamor acceleration in Xwayland (glamor being used by default). > > Add an environment variable XWAYLAND_NO_GLAMOR to disable glamor support > in Xwayland. > > Signed-off-by: Olivier Fourdan > Reviewed-by: Eric Engestrom remote: I: patch #141495 updated using rev 1089d5d518a315963a8cda6c7d47a0ce09de0979. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 5abaa50b29..1089d5d518 master -> master - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How to support mixed DPI in Xwayland?
On Tue, 2017-09-12 at 19:34 +0200, Joseph Burt wrote: > On Mon, Sep 11, 2017 at 3:44 PM, Adam Jackson wrote: > > > > Root window size is only ever sent during the initial connection > > handshake, and the client extension libraries don't update it when the > > root window is reconfigured [2]. So we have a bootstrapping problem: > > how is the X server supposed to know which set of lies to give the > > client when it connects? If you have multiple displays (either logical > > views or whole processes) then you decide this when you connect, and > > remote X apps [3] have an obvious way to pick the right one. > > Could this be done with one server listening on two sockets? This > could work for X servers in general, has it been discussed in that > context? "Two sockets" is what I meant by "logical views", there. Depending which socket you connect to, you'd get different connection handshake data and different coordinate scalings, but would otherwise interact with the same set of objects. Again, easy enough to describe, not so easy to actually implement. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How to support mixed DPI in Xwayland?
On Sun, 2017-09-10 at 22:25 +0200, Joseph Burt wrote: > What about always running the X server at hardware resolution, This isn't a fixed number. Outputs can be hotplugged. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How to support mixed DPI in Xwayland?
On Thu, 2017-09-07 at 12:17 -0400, Olivier Fourdan wrote: > But we dismissed that solution, having different X11 screens is not very > practical, mutter does not support multiple screens for a start, and > things like drag'n drop, copy/paste, root properties, etc. all would > become quite complicated very quickly when dealing with multiple screens... metacity certainly used to support multiple screens, so having taken a feature out and then thinking it too hard to put back in is perhaps a self-inflicted injury. One possibility could be to expose the hi- and lo-dpi root windows as different _displays_, listening on different sockets, and rewriting geometry depending which one you're on (while otherwise having the same set of windows, properties, devices...). Keith wrote a pseudo-root extension along similar lines long ago [1], though that didn't make any effort at rescaling, just subsetting. One other problem with rescaling is what to do if graphics commands cross logical displays. If I GetImage from a hidpi window on a lodpi client, who's going to do the downscaling? Another possibility could be just running more than one Xwayland server, each with different DPI configurations; the compositor is going to handle final presentation anyway, so this requires many fewer server changes. But, a window manager that can't even deal with multiple screens is probably also going to have problems with multiple displays, and the wayland half of its brain would need to handle proxying clipboard and friends between both servers. > The other solution would be to have the same screen, but have Xwayland to > give different scaling conversions for root window size, screen size, events > coordinates, etc. depending on the client, if it's HiDPI aware or not, > some sort of a "hidden" screen. Root window size is only ever sent during the initial connection handshake, and the client extension libraries don't update it when the root window is reconfigured [2]. So we have a bootstrapping problem: how is the X server supposed to know which set of lies to give the client when it connects? If you have multiple displays (either logical views or whole processes) then you decide this when you connect, and remote X apps [3] have an obvious way to pick the right one. One more possibility would be bumping the X protocol itself so the client can express this kind of preference in the connection handshake [4]. Doing that requires that you upgrade your clients (or at least your toolkits) to do additional setup before connecting, or use an API other than XOpenDisplay. It'll be a decent amount of work any way you slice it, tbh. One thing I've never really been thrilled with about the Xwayland design is that the wayland compositor wants also to be the X window manager, and that all the related state about window position and whatnot is just internal to the compositor. xwin and xquartz don't have this problem, you can run twm as your window manager and still move windows, but in xwayland that doesn't work because wayland refuses to allow you to position your own window for (what I consider) essentially religious reasons [5]. And as a result the compositor gets a lot more complicated and you _still_ need to change the X server to get things to work. What I'd have preferred is a wl_x11_interop protocol that Xwayland could use to send this kind of advisory state, which mutter could optionally only expose to Xwayland if it really wanted to be less functional than X. [1] - https://keithp.com/~keithp/talks/proot.tar.gz [2] - Even if they did, because libX11 is some of 1988's finest engineering, things like DisplayWidth() are just macros that dereference fields in the Display*, so updating them dynamically would be hoping that the compiler didn't optimize away multiple loads of the same field, and that the toolkit/app haven't cached them anywhere. We could try anyway, and maybe that'd be good enough for xterm... [3] - Still a thing! But even neglecting that, you have to set $DISPLAY to something to get apps to launch from the command line; gnome-shell is not going to be the only thing that starts clients, so inspecting .desktop files or the link map of the binary is not going to be sufficient in general. [4] - I think you could get away with simply adding more authentication class data before you get to the MIT-MAGIC-COOKIE bit, and have that class always succeed and just record client capabilities, rather than trying to define version 11.1 of the protocol. Which is good, because 11.1 would require you to update libX11/libxcb to make it work, and that'd make it tough to upscale that old copy of Netscape running on your IRIX machine. [5] - They'd be hints in any case, the wayland server is entirely free to ignore them. They're already hints in X because windows are managed, so that's not actually different. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.f
Re: Override redirect windows with keyboard grabs on Xwayland
On Mon, 2016-07-04 at 03:10 -0400, Olivier Fourdan wrote: > That mechanism would probably not work as is with O-R windows for a > couple of reasons: Your descriptions here seem to assume the inability to fix the compositor, which to me seems... insane? _Nothing_ xserver can do in this situation is going to make this be handled reasonably all on its own, we have to assume a cooperative compositor. So... > - the WM is not supposed to manage O-R windows (well, a compositor > has of course, but the WM doesn't get a MapRequest and most WM will > do as little as possible with O-R). Yes, a traditional X window manager will mostly ignore o-r windows. But a compositor has to draw them, and under xwayland must also route input to them. Which means the compositor has the opportunity to _not_ draw them and _not_ route input to them. > - O-R are not listed in the window list so even if the compositor > would have set the demand attention flag, the shell would probably > ignore it. Again: that it is not in the window list does not mean it could not be in the window list. > Besides, what happens here is that O-R is already covering the entire > screen (thus most likely cover any shell notification as well), and > it feels natural for the user to start typing as the screen is > covered and a nice text input is displayed :) Again: that it is painted and responds to input is not mandatory. The conditions described here (o-r, the size of an output, etc) are things the compositor is aware of before it decides to map the wayland surface. X can give it more information (GrabNotify or whatever), but X can only request politely that wl behave nicely. > We do (well, in gtk-shell no not strictly standard) have a "present" > protocol that allows a Wayland client to ask the compositor to raise > and focus a surface, we could use this with Xwayland to achieve that, > but I suspect mutter would most likely deny such request on O-R (and > being gtk-shell, that wouldn't work with any other compositor). Sure, I wouldn't want to depend on gtk_shell either. Perhaps a better idea is to write our own x11_compatibility protocol and use it if it's there. The compositor would of course be free to honor that protocol only for Xwayland servers it happens to be managing, or to not implement it at all if it doesn't care about mixed x11 and native wayland surfaces. > Thing is, weston seems to do this right so there should be a way to > achieve that in mutter as well. > > The approach I took in my patch for GNOME bug https://bugzilla.gnome. > org/show_bug.cgi?id=752956 is to not deny focus for O-R that are > fullscreen (either on a single monitor or the whole screen): > > https://bugzilla.gnome.org/attachment.cgi?id=330053&action=diff > > It does fix the issue, but I am not sure this can be acceptable in > GNOME. If gnome considers purity of essence to be more important than correct functionality, well, that's an opinion they can have I guess. I'm happy to see X extended to give the compositor more information and better control. But I don't see a reasonable way of fixing this entirely within xserver. The compositor has to want to get this right. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Override redirect windows with keyboard grabs on Xwayland
On Fri, 2016-06-17 at 03:49 -0400, Olivier Fourdan wrote: > Hi all, > > First of all, sorry for cross posting, but I am not really sure where > the issue is to be addressed... > > I am looking into https://bugs.freedesktop.org/show_bug.cgi?id=96547 > and concluded this is actually the same as https://bugzilla.gnome.or > g/show_bug.cgi?id=752956 > > Basically, long story short, we have clients in X that map a full- > screen override redirect window with a keyboard/mouse active grab for > the user to enter a password. > > Because override redirect windows are not managed by X11 window > managers, these won't focus the O-R window by themselves but that's > not a problem on X11 thanks to the active grab. > > Things get more complicated with those clients on Xwayland, because > the X11 active grab cannot be honoured in Wayland, and therefore the > window may or may not get focused automatically, depending on the > compositor/WM. In the worst case, the user might type his/her > password in some other (focused but hidden underneath) window without > even knowing it! This feels a lot like any other "app wants attention" case where you should just get a pulsing button or bouncing icon in the taskbar. The o-r window might be mapped and focused from Xwayland's perspective but there's nothing compelling wayland to actually show or focus it promptly, you know it's o-r, you know it's full-screen sized, and you have control of the display so when you _do_ put it up you can vignette it and add a Get Me Out Of Here checkbox in the upper-right or whatever. I guess the thing you don't really get is a GrabNotify to let the wm know what's going on, though maybe you could infer it from FocusOut. There also appears to be no "wants attention" request in any wayland protocol, which is perhaps suboptimal. But if we had that, xserver could just emit that when an active grab fires, and then once the window gets focus the grab works just as well as it ever would. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] xwayland: Clear pending cursor frame callbacks on pointer enter
On Fri, 2016-02-05 at 07:54 +0800, Jonas Ådahl wrote: > > On Feb 5, 2016 12:53 AM, "Rui Matos" wrote: > > > > The last cursor frame we commited before the pointer left one of our > > surfaces might not have been shown. In that case we'll have a cursor > > surface frame callback pending which we need to clear so that we can > > continue submitting new cursor frames. > > > > Signed-off-by: Rui Matos > > Reviewed-by: Daniel Stone > Reviewed-by: Jonas Ådahl To ssh://git.freedesktop.org/git/xorg/xserver b7d3929..87d5534 master -> master - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] xwayland: Adjust screen size with rotation
On Sat, 2015-10-03 at 09:46 +1000, Dave Airlie wrote: > On 23 September 2015 at 23:35, Olivier Fourdan > wrote: > > bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92076 > > Signed-off-by: Olivier Fourdan > > Seems sane, > > Reviewed-by: Dave Airlie Merged: remote: I: patch #60158 updated using rev e31fe8115ee080b58b2e96a5106f38e64944ce5e. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver f6ce23f..e31fe81 master -> master - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
