- Aug 09, 2018
-
-
This makes us match the featureset of autotools, and also fixes the non-Linux default value to match. Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Ported from automake. Signed-off-by:
-
Signed-off-by:
-
Signed-off-by:
-
Nothing in tree references the flag. Signed-off-by:
-
- Aug 02, 2018
-
-
I don't have a BSD to test on, but this should do the same as what autotools did. Signed-off-by:
-
We already have pm_noop.c being built most of the time for the no-OS-PM case, so just switch to always using it. Signed-off-by:
-
This is already included in ephyr (the only kdrive server left) Signed-off-by:
-
Instead of having every video driver loop over any pending leases to free them during CloseScreen, do this up in the DIX layer by terminating leases when a leased CRTC or Output is destroyed and (just to make sure), also terminating leases in RRCloseScreen. The latter should "never" get invoked as any lease should be associated with a resource which was destroyed. This is required as by the time the driver's CloseScreen function is invoked, we've already freed all of the DIX randr structures and no longer have any way to reference the leases Signed-off-by:
Keith Packard <keithp@keithp.com> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960 Cc: Thomas Hellstrom <thellstrom@vmware.com>
-
- Jul 25, 2018
-
-
The recent rewrite of modesetting driver broke the 24bpp support. As typically found on cirrus KMS, it leads to a blank screen, spewing the error like: failed to add fb -22 (EE) modeset(0): failed to set mode: Invalid argument The culript is that the wrong bpp value of the front buffer is passed to drmModeAddFB(). Fix it by replacing with the back buffer bpp, drmmode->kbpp. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Tested-by:
Stefan Dirsch <sndirsch@suse.de> Reviewed-by:
Adam Jackson <ajax@redhat.com>
-
glamor_fds_from_pixmap() will bail out early if DRI3 is not enabled, unfortunately Xwayland's glamor code would not set it as enabled which would lead to blank pixmaps when using texture from pixmap. Make sure to mark DRI3 as enabled from glamor_egl_screen_init() in Xwayland. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107287 Fixes: c8c276c9 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap") Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com>
-
The logical size is the size of the output in the global compositor space. The mode width/height should be scaled as in the logical size, but shouldn't be transformed. Thus we need to rotate back the logical size to be able to use it as the mode width/height. This fixes issues with pointer input on transformed outputs. Signed-Off-By:
Simon Ser <contact@emersion.fr> Reviewed-by:
-
- Jul 10, 2018
-
-
When setting DefaultDepth to 16 in the Screen section, the current code requests a 32 bpp framebuffer, however the X-Server seems to assumes 16 bpp. Fixes commit 21217d02 ("modesetting: Implement 32->24 bpp conversion in shadow update") Reviewed-by:
Stefan Agner <stefan@agner.ch>
-
- Jul 03, 2018
-
-
If we're using atomic modesetting, then we're also using universal planes, and so the lease we create needs to include the plane. Signed-off-by:
Daniel Stone <daniels@collabora.com>
-
We don't want universal_planes unless we're using atomic APIs for modesetting, and the kernel already enables universal_planes automatically when atomic is enabled. If we enable universal_planes when we're not using atomic, then we won't have selected a plane for each crtc, and this will break lease creation which requires planes for each output when universal_planes is enabled. Signed-off-by:
-
- Jul 02, 2018
-
-
Before DIX structures are allocated for crtcs and outputs, we don't want to call DIX randr code with NULL pointers. This can happen if the driver sets video modes early in server initialization, which Nouveau does in zaphod mode. Cc: thellstrom@vmware.com Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106772 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960 Reviewed-by:
-
The DIX crtc and output structures are freed when their resources are destroyed, which happens before CloseScreen is called. As a result, we know these pointers are invalid and referencing them during any of the remaining CloseScreen sequence will be bad. Reviewed-by:
-
- Jun 29, 2018
-
-
Keith Packard authored
This lets an application open a suitable DRM device and pass the file descriptor to the mode setting driver through an X server command line option, '-masterfd'. There's a companion application, xlease, which creates a DRM master by leasing an output from another X server. That is available at git clone git://people.freedesktop.org/~keithp/xlease v2: Always print usage, but note that it can't be used if setuid/gid Suggested-by:
Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
-
- Jun 28, 2018
-
-
Lyude Paul authoredThis really sucked to find out :( Signed-off-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: 
Karol Herbst <kherbst@redhat.com>
-
- Jun 27, 2018
-
-
Lyude Paul authored
When support for allocating GBM BOs with modifiers was added, glamor_fd_from_pixmap() was changed so that it would return an error if it got a bo with modifiers set from glamor_fds_from_pixmap(). The problem is that on systems that support BOs with modifiers, glamor_fds_from_pixmap() will always return BOs with modifiers. This means that glamor_fd_from_pixmap() was broken entirely, which broke a number of other things including glamor_shareable_fd_from_pixmap(), which meant that modesetting using multiple GPUs with the modesetting DDX was also broken. Easy reproducer: - Find a laptop with DRI prime that has outputs connected to the dedicated GPU and integrated GPU - Try to enable one display on each using the modesetting DDX - Fail Since there isn't a way to ask for no modifiers from glamor_fds_from_pixmap, we create a shared _glamor_fds_from_pixmap() function used by both glamor_fds_from_pixmap() and glamor_fd_from_pixmap() that calls down to the appropriate glamor_egl_fd*_from_pixmap() function. Signed-off-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com> Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Fixes: c8c276c9 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
-
So, this did actually work on older kernels at one point in time, however it seems that this working was a result of some of the Linux kernel's atomic modesetting helpers not preserving the CRTC's enabled state in the right spots. This was fixed in: 846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2") As a result, atomic commits which simply disassociate a DRM connector with it's CRTC while leaving the CRTC in an enabled state aren't enough to disable the CRTC, and result in the atomic commit failing. This currently can cause issues with MST hotplugging where X will end up failing to disable the MST outputs after they've left the system. A simple reproducer: - Start up Xorg - Connect an MST hub with displays connected to it - Remove the hub - Now there should be CRTCs stuck on the orphaned MST connectors, and X won't be able to reclaim them. Signed-off-by:Lyude Paul <lyude@redhat.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: -
drmmode_shadow_allocate() still uses drmModeAddFB() which may fail if the format is not as expected, preventing from using a rotated output. Change it to use the new function drmmode_bo_import() which takes care of calling the drmModeAddFB2() API. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106715 Signed-off-by:
Tomas Pelka <tpelka@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com>
-
- Jun 21, 2018
-
-
The API init_wl_registry() and has_wl_interfaces() are marked as being optional, but both GBM And EGLStream backends implement them so there is point in keeping those optional. Suggested-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
-
When retrieving the Wayland buffer from a pixmap, if the buffer already exists, the GBM backend will return that existing buffer. However, as seen with the Present issues, if the call had previously passed a wrong size, that buffer will remain at the wrong size for as long as the buffer exists, which is error prone. Considering that the width/height passed to get_wl_buffer() is always the actual pixmap drawable size, and considering that the EGLStream backend makes no use of the size either, there is really no point in passing the width/height around. Simplify the xwl_glamor_pixmap_get_wl_buffer() and EGL backends API by removing the pixmap size, and use the drawable size instead. Signed-off-by: -
xwl_glamor_eglstream_init_egl() uses "EGL_IMG_context_priority" extension, make sure it's actually available before using it. Suggested-by:
-
Now that we have separate backends for EGLStream and GBM, we can explicitly check for the EGLStream backend to disable present support in that case. Signed-off-by:
-
To be able to check for availability of the Wayland interfaces required to run a given EGL backend (either GBM or EGLStream for now), we need to have each backend structures and vfuncs in place before we enter the Wayland registry dance. That basically means that we should init all backends at first, connect to the Wayland compositor and query the available interfaces and then decide which backend is available and should be used (or none if either the Wayland interfaces or the EGL extensions are not available). For this purpose, hold an egl_backend struct for each backend we are to consider prior to connect to the Wayland display so that, when we get to query the Wayland interfaces, everything is in place for each backend to handle the various Wayland interfaces. Eventually, when we need to chose which EGL backend to use for glamor, the available Wayland interfaces and EGL extensions available are all known to Xwayland. Signed-off-by:
-
Move EGL backends initialization to its own function in xwayland-glamor.c Signed-off-by:
-
Introduces a new egl_backend function to let the EGL backend check for the presence of the required Wayland interfaces. Signed-off-by:
-
EGL backend availability requires both EGL extensions and Wayland interfaces to be present, so we will need to consider multiple backends during initialization. As a preliminary work, move the egl_backend to its own struct so that we can have more than one backend at any given time. Signed-off-by:
-
If using a render node, we can skip DRM authentication. Suggested-by:
-
Surely, we should fail to init GBM backend if "GL_OES_EGL_image" is missing. This seems to have been lost with commit 1545e2db ("xwayland: Decouple GBM from glamor"). Suggested-by:
-
Both xwl_glamor_init_wl_registry() and the Wayland global registry handler use the interface id/name in that order, using name/id in the egl_backend vfunc makes things confusing and error prone. Signed-off-by:
-
Functions such as: xwl_glamor_egl_supports_device_probing() xwl_glamor_egl_get_devices() xwl_glamor_egl_device_has_egl_extensions() Are of no use outside of EGLStream support, move them to the relevant source file. Similarly, the other glamor functions such as: xwl_glamor_init() xwl_screen_set_drm_interface() xwl_screen_set_dmabuf_interface() xwl_glamor_pixmap_get_wl_buffer() xwl_glamor_init_wl_registry() xwl_glamor_post_damage() xwl_glamor_allow_commits() xwl_glamor_egl_make_current() Are useless without glamor support enabled, move those within a a "#ifdef XWL_HAS_GLAMOR" in xwayland.h Signed-off-by:
-
Make xwl_output_get_xdg_output() private, it doesn't need to be available elsewhere. Signed-off-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: -
EGLStream requires glamor, but the opposite is not true. So if someone passes "-eglstream" with a GPU which does not support EGLStream, we could maybe still try GBM and be lucky. That allows Wayland compositors to pass "-eglstream" regardless of the actual hardware, if they want to enable EGLStream on GPU which support it. Signed-off-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: -
When we're done adding a new screen, we need to process any pending Wayland events again. Hence we don't end up processing xdg_output events unexpectedly when glamor is disabled. Be that because "-shm" was passed or "-eglstream" has failed. Failing to do that could lead to a crash at startup: Xwayland: dixGetPrivateAddr: Assertion `key->initialized' failed. (EE) (EE) Backtrace: (EE) 0: Xwayland (OsSigHandler) (EE) 1: libpthread.so.0 (funlockfile) (EE) 2: libc.so.6 (gsignal) (EE) 3: libc.so.6 (abort) (EE) 4: libc.so.6 (?+0x0) (EE) 5: libc.so.6 (__assert_fail) (EE) 6: Xwayland (dixGetPrivateAddr) (EE) 7: Xwayland (_fbGetWindowPixmap) (EE) 8: Xwayland (getDrawableDamageRef) (EE) 9: Xwayland (damageRegionProcessPending) (EE) 10: Xwayland (damagePolyFillRect) (EE) 11: Xwayland (miPaintWindow) (EE) 12: Xwayland (miWindowExposures) (EE) 13: Xwayland (miHandleValidateExposures) (EE) 14: Xwayland (SetRootClip) (EE) 15: Xwayland (update_screen_size) (EE) 16: Xwayland (apply_output_change) (EE) 17: libffi.so.6 (ffi_call_unix64) (EE) 18: libffi.so.6 (ffi_call) (EE) 19: libwayland-client.so.0 (wl_log_set_handler_client) (EE) 20: libwayland-client.so.0 (_init) (EE) 21: libwayland-client.so.0 (wl_display_dispatch_queue_pending) (EE) 22: libwayland-client.so.0 (wl_display_roundtrip_queue) (EE) 23: Xwayland (InitInput) (EE) 24: Xwayland (dix_main) (EE) 25: libc.so.6 (__libc_start_main) (EE) 26: Xwayland (_start) (EE) (EE) Fatal server error: (EE) Caught signal 6 (Aborted). Server aborting (EE) Aborted (core dumped) Signed-off-by:Lyude Paul <lyude@redhat.com>
Reviewed-by: -
eglQueryDevicesEXT() would abort if the required extensions are not available, meaning that enabling “-eglstream” on a non-EGLStream capable hardware would lead to an abort(). Check that "EGL_EXT_device_base" extension is available and bail out early if not, so we don't abort() later in eglQueryDevicesEXT(). Signed-off-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: -
The command line option "-eglstream" used to enable EGLStream support for NVidia GPU was made available only when Xwayland was built with EGLStream support enabled. Wayland compositors who spawn Xwayland have no easy way to tell whether or not Xwayland was built with EGLStream support enabled, and adding "-eglstream" command line option to Xwayland when it wasn't built with EGLStream support would prevent Xwayland from starting (“Unrecognized option” error). Make sure we support the command line option "-eglstream" regardless of EGLStream support in Xwayland. Obviously, if Xwayland was built without EGLStream support, this has no effect. Signed-off-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by:
-
- Jun 17, 2018
-
-
Peter Hutterer authored
Changes the device name from "xwayland-stylus" to "xwayland-tablet stylus". This doesn't fully address #26 but it goes a little step into making it more human-readable. wayland/wayland#26 Signed-off-by:
-
