Re: [RFC 0/1] Color manager calibration protocol v1
On Wed, 1 May 2019 at 13:00, Graeme Gill wrote: > > Erwin Burema wrote: > > Hi, > > > 1) Will always be a single solid color, so no need for the full > > wl_buffer/wl_surface interface > > you don't know that, as it's up to the calibration and profiling > application. It may well want to paint guide graphics for the positioning > of the instrument. It could want to output a dithered color image. > That is a good point, hadn't thought about that > Typically a calibration and profiling application would > position the test patch in the middle of a physical display, > but this depends on the function being requested by the user. > They may be wanting to check display uniformity for instance, > in which case the test patch would be positioned at a number > of physical locations on the display. The size will depend > on the aperture size of the instrument, as well as the > display type (i.e. OLED's and HDR displays may need to > limit the test patch size to avoid auto dimming effects, etc.) > And with this it does sounds like we need to "grab" the full screen to be able to do everything described above. Still it feels somehow wrong and ripe for abuse since it will need to be able to bypass certain limitations that are normally expected of wayland (AFAICT) but since there is already a full screen calibration protocol accepted I can look into how they worked to mitigate the risks.[1] > > 2) Will need to be displayed above anything else, anywhere on the > > specified screen (for normal surface this might be a problem for > > tiling window managers) > > And not be interrupted by a "screen saver" or "power saver". > Yes of course! (I would allow a compositor to lock the screen underneath the calibration surface so long as it doesn't draw anything above it. > > 5) Preferably need to be in display color depth (especially for calibration) > > For accurate measurement any quantization of the color values > needs to be known, as well as the effective display depth. > Was almost wanting to design out the display event but seems like I should keep it, although probably need to rename it > The effective display depth may be different to the frame buffer > depth if the frame buffer output passes through per channel > lookup tables. Ideally the measurement would be at the > pixel depth resolution of the output of the per channel tables. > Naturally to make use of this, access to the per channel > tables contents is necessary, to setup the mapping > from the frame buffer value to the value sent to the > display. > So that would be framebuffer depth, display depth, and size and depth of any channel curves/tables. Added to that a way to set the curves/tables, I assume these are normally the video card LUTs? > Cheers, > Graeme Gill. Thanks for your response! [1] The risk as I see it are that it is a surface that will be displayed above anything else where even the compositor can't really draw anything over it (in contrast with a "normal" full screen window) and since alt-tabbing away will screw with the calibration we either need an event to tell this to the calibration SW or disallow it (which would be a bad idea for obvious reasons) making things more complex. If this is not implemented correctly it can be used for DoS style attacks (IMHO) Regards, Erwin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: xwayland display variable
Thanks Simon, Ditto. On Wed, May 1, 2019 at 3:00 PM Simon McVittie wrote: > > On Wed, 01 May 2019 at 14:30:52 +0300, Damian Ivanov wrote: > > export WAYLAND_DISPLAY=wayland-1 > > GDK_BACKEND=x11 gedit //starts on wayland-0 > > If you are using GDK_BACKEND=x11, then gedit is not acting as a native > Wayland app, so it will not look at WAYLAND_DISPLAY. Instead, it will be > acting as an X11 app, which obeys the traditional X11 DISPLAY environment > variable (and in your case it happens to connect to an Xwayland instance > that is already associated with one of the Wayland displays, but the X11 > backend in GTK has no knowledge of Wayland, so it can't know that). > > If you want an application to appear on one of your Wayland displays, > irrespective of whether that application is using native Wayland or > X11 via Xwayland, then you need to put a matching pair of WAYLAND_DISPLAY > and DISPLAY in its environment. > > Alternatively, if you let gedit use native Wayland (stop using > GDK_BACKEND=x11) it will respect WAYLAND_DISPLAY. > > smcv > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Fwd: xwayland display variable
Thank you for the great explanation Scott! I needed to change: DISPLAY=:2 to connect to wayland-1, DISPLAY=:1 was connecting to wayland-0 and DISPLAY=:0 to nothing On Wed, May 1, 2019 at 2:59 PM Scott Anderson wrote: > > On 1/05/19 11:30 pm, Damian Ivanov wrote: > > Hello, > > > > Is it somewhere documented how Xwayland applications are choosing > > which compositor to display on? e.g 2 compostiors (1 nested or on > > another VT) > > wayland-0 and wayland-1 > > export WAYLAND_DISPLAY=wayland-1 > > GDK_BACKEND=x11 gedit //starts on wayland-0 > > > > If it's not documented how to do it? > > Thank you in advance! > > > > Damian > > Hi, > > X programs running through Xwayland connect to it with the exact same > mechanism they use for connecting to a normal X server, which usually > means looking at the DISPLAY environment variable. > > Each Wayland compositor would start and manage their own separate > Xwayland server, and would take their own DISPLAY values (e.g. > DISPLAY=:0, DISPLAY=:1). > > In the case of the WAYLAND_DISPLAY=wayland-1 compositor's X server takes > DISPLAY=:1, you'd run that command like: > >GDK_BACKEND=x11 DISPLAY=:1 gedit > > So setting WAYLAND_DISPLAY isn't technically needed, but it's still a > good idea to set it too, because it can have an effect on other > processes which your command can start. > > Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: xwayland display variable
On Wed, 01 May 2019 at 14:30:52 +0300, Damian Ivanov wrote: > export WAYLAND_DISPLAY=wayland-1 > GDK_BACKEND=x11 gedit //starts on wayland-0 If you are using GDK_BACKEND=x11, then gedit is not acting as a native Wayland app, so it will not look at WAYLAND_DISPLAY. Instead, it will be acting as an X11 app, which obeys the traditional X11 DISPLAY environment variable (and in your case it happens to connect to an Xwayland instance that is already associated with one of the Wayland displays, but the X11 backend in GTK has no knowledge of Wayland, so it can't know that). If you want an application to appear on one of your Wayland displays, irrespective of whether that application is using native Wayland or X11 via Xwayland, then you need to put a matching pair of WAYLAND_DISPLAY and DISPLAY in its environment. Alternatively, if you let gedit use native Wayland (stop using GDK_BACKEND=x11) it will respect WAYLAND_DISPLAY. smcv ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: xwayland display variable
On 1/05/19 11:30 pm, Damian Ivanov wrote: Hello, Is it somewhere documented how Xwayland applications are choosing which compositor to display on? e.g 2 compostiors (1 nested or on another VT) wayland-0 and wayland-1 export WAYLAND_DISPLAY=wayland-1 GDK_BACKEND=x11 gedit //starts on wayland-0 If it's not documented how to do it? Thank you in advance! Damian Hi, X programs running through Xwayland connect to it with the exact same mechanism they use for connecting to a normal X server, which usually means looking at the DISPLAY environment variable. Each Wayland compositor would start and manage their own separate Xwayland server, and would take their own DISPLAY values (e.g. DISPLAY=:0, DISPLAY=:1). In the case of the WAYLAND_DISPLAY=wayland-1 compositor's X server takes DISPLAY=:1, you'd run that command like: GDK_BACKEND=x11 DISPLAY=:1 gedit So setting WAYLAND_DISPLAY isn't technically needed, but it's still a good idea to set it too, because it can have an effect on other processes which your command can start. Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
xwayland display variable
Hello, Is it somewhere documented how Xwayland applications are choosing which compositor to display on? e.g 2 compostiors (1 nested or on another VT) wayland-0 and wayland-1 export WAYLAND_DISPLAY=wayland-1 GDK_BACKEND=x11 gedit //starts on wayland-0 If it's not documented how to do it? Thank you in advance! Damian ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC 0/1] Color manager calibration protocol v1
Erwin Burema wrote: Hi, > 1) Will always be a single solid color, so no need for the full > wl_buffer/wl_surface interface you don't know that, as it's up to the calibration and profiling application. It may well want to paint guide graphics for the positioning of the instrument. It could want to output a dithered color image. Typically a calibration and profiling application would position the test patch in the middle of a physical display, but this depends on the function being requested by the user. They may be wanting to check display uniformity for instance, in which case the test patch would be positioned at a number of physical locations on the display. The size will depend on the aperture size of the instrument, as well as the display type (i.e. OLED's and HDR displays may need to limit the test patch size to avoid auto dimming effects, etc.) > 2) Will need to be displayed above anything else, anywhere on the > specified screen (for normal surface this might be a problem for > tiling window managers) And not be interrupted by a "screen saver" or "power saver". > 5) Preferably need to be in display color depth (especially for calibration) For accurate measurement any quantization of the color values needs to be known, as well as the effective display depth. The effective display depth may be different to the frame buffer depth if the frame buffer output passes through per channel lookup tables. Ideally the measurement would be at the pixel depth resolution of the output of the per channel tables. Naturally to make use of this, access to the per channel tables contents is necessary, to setup the mapping from the frame buffer value to the value sent to the display. Cheers, Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
On Wed, 1 May 2019 03:24:04 +0100
adlo wrote:
> > On 29 Oct 2018, at 09:33, Pekka Paalanen wrote:
> >
> > the only opinionated advice I can give you is don't do it. Instead, put
> > the GTK stuff in a separate process, let your compositor fork & exec
> > it, and talk to it through your own private protocol extension for the
> > special bits you need.
>
> What are the basics for creating a private protocol extension, i.e. what's
> the minimum boilerplate code needed? What's a simple example of how to
> implement a request between the two processes? The Weston source code is
> difficult to follow.
>
> How do I allow the child process to call functions and pass data to the
> parent and vice versa?
Hi adlo,
it is all just the normal Wayland protocol exchange but with a new
interface of your own design. I'm not sure if there is a really
minimal example, but I'll list at least some.
One example of such private protocol extension is
https://gitlab.freedesktop.org/wayland/weston/blob/master/protocol/weston-desktop-shell.xml
The server-side implementation of it is in shell.c and the
entrypoint to that is
https://gitlab.freedesktop.org/wayland/weston/blob/master/desktop-shell/shell.c#L5143
wl_global_create(ec->wl_display,
_desktop_shell_interface, 1,
shell, bind_desktop_shell)
which installs the protocol extension in the compositor. You can
see everything about the implementation by following all callbacks
that get registered, starting with bind_desktop_shell().
The privacy of the protocol extension, the installed wayland global
really, is achieved in
https://gitlab.freedesktop.org/wayland/weston/blob/master/desktop-shell/shell.c#L4366
shell->child.client = weston_client_start(shell->compositor,
shell->client);
which creates the Wayland connection before forking the child
process and bind_desktop_shell() then verifying the client trying
to bind to the global is the client that was forked.
The client-side implementation is in desktop-shell.c with the entry
point at
https://gitlab.freedesktop.org/wayland/weston/blob/master/clients/desktop-shell.c#L1392
if (!strcmp(interface, "weston_desktop_shell")) {
desktop->shell = display_bind(desktop->display,
id,
_desktop_shell_interface,
1);
weston_desktop_shell_add_listener(desktop->shell,
,
desktop);
https://gitlab.freedesktop.org/wayland/weston/blob/master/protocol/weston-touch-calibration.xml
is another example of a custom protocol extension (not for a shell
helper client though), with implementations in
https://gitlab.freedesktop.org/wayland/weston/blob/master/libweston/touch-calibration.c
and
https://gitlab.freedesktop.org/wayland/weston/blob/master/clients/touch-calibrator.c
Again, you can find the entry points with wl_global_create() and
display_bind(), respectively.
There is also
https://gitlab.freedesktop.org/wayland/weston/blob/master/protocol/weston-test.xml
used by the test suite exclusively, implemented in
https://gitlab.freedesktop.org/wayland/weston/blob/master/tests/weston-test.c
and
https://gitlab.freedesktop.org/wayland/weston/blob/master/tests/weston-test-client-helper.c
this time using wl_global_create() and wl_registry_bind().
Yet another external example is
https://github.com/raspberrypi/maynard/ which contains its own
additional protocol extensions and both a weston plugin and a
GTK-based helper client. Unfortunately it hasn't been touched in a
few years, so it probably won't work with a recent Weston.
Hope this helps.
Thanks,
pq
pgpT776R0dqa3.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
PATCH wayland-protocols
--- unstable/xdg-output/xdg-output-unstable-v1.xml | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml b/unstable/xdg-output/xdg-output-unstable-v1.xml index ccbfe1c..3176520 100644 --- a/unstable/xdg-output/xdg-output-unstable-v1.xml +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml @@ -94,17 +94,17 @@ - The position event describes the location of the wl_output within - the global compositor space. + The position event describes the location of the top-left corner + of the wl_output within the global compositor space. The logical_position event is sent after creating an xdg_output (see xdg_output_manager.get_xdg_output) and whenever the location of the output changes within the global compositor space. + summary="x position of the output's left edge within the global compositor space"/> + summary="y position of the output's top edge within the global compositor space"/> -- 2.20.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v4] linux-dmabuf: clarify DRM_FORMAT_MOD_INVALID
On Wed, 24 Apr 2019 10:07:47 -0700 Chia-I Wu wrote: > Hi, > > Can you commit this patch for me, if all looks good? Hi Chia-I, I was almost already pushing this, but Daniel said he wants to have a good look first. Thanks, pq > On Wed, Apr 17, 2019 at 9:41 AM Chia-I Wu wrote: > > > > I hope this captures the discussion: clarify DRM_FORMAT_MOD_INVALID and a > > note > > > > On Wed, Apr 17, 2019 at 9:40 AM Chia-I Wu wrote: > > > > > > DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf. > > > It provides legacy support and makes it easier to replace wl_drm. > > > > > > v3: DRM_FORMAT_MOD_INVALID must be advertised to be supported (which > > > requires a version bump) > > > v4: no version bump, but a note for now > > > > > > Signed-off-by: Chia-I Wu > > > Reviewed-by: Pekka Paalanen > > > Reviewed-by: Simon Ser > > > --- > > > .../linux-dmabuf/linux-dmabuf-unstable-v1.xml| 16 +++- > > > 1 file changed, 15 insertions(+), 1 deletion(-) > > > > > > diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > > > b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > > > index 154afe2..b43e81c 100644 > > > --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > > > +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > > > @@ -28,6 +28,7 @@ > > > > > >Following the interfaces from: > > > > > > https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt > > > + > > > https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt > > >and the Linux DRM sub-system's AddFb2 ioctl. > > > > > >This interface offers ways to create generic dmabuf-based > > > @@ -129,8 +130,16 @@ > > > binds to this interface. A roundtrip after binding guarantees > > > that > > > the client has received all supported format-modifier pairs. > > > > > > +For legacy support, DRM_FORMAT_MOD_INVALID (that is, modifier_hi > > > == > > > +0x00ff and modifier_lo == 0x) is allowed in this > > > event. > > > +It indicates that the server can support the format with an > > > implicit > > > +modifier. When a plane has DRM_FORMAT_MOD_INVALID as its > > > modifier, it > > > +is as if no explicit modifier is specified. The effective > > > modifier > > > +will be derived from the dmabuf. > > > + > > > For the definition of the format and modifier codes, see the > > > -zwp_linux_buffer_params_v1::create request. > > > +zwp_linux_buffer_params_v1::create and > > > zwp_linux_buffer_params_v1::add > > > +requests. > > > > > > > > > > > @@ -197,6 +206,11 @@ > > > compression, etc. driver-specific modifications to the base > > > format > > > defined by the DRM fourcc code. > > > > > > +Warning: It should be an error if the format/modifier pair was > > > not > > > +advertised with the modifier event. This is not enforced yet > > > because > > > +some implementations always accept DRM_FORMAT_MOD_INVALID. Also > > > +version 2 of this protocol does not have the modifier event. > > > + > > > This request raises the PLANE_IDX error if plane_idx is too > > > large. > > > The error PLANE_SET is raised if attempting to set a plane that > > > was already set. > > > -- > > > 2.21.0.392.gf8f6787159e-goog > > > pgpd75gdtOxUo.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
