- Aug 27, 2018
-
-
Keith Packard authored
This ensures that present clients generate output suitable for the size of the presented area. Signed-off-by:Keith Packard <keithp@keithp.com>
-
Keith Packard authored
Output scaling: * Changes to mivaltree to reset window clip to owner window size instead of server window size when compositing * Allocate owner window size pixmap for composite pixmap * Paint scaled image for automatic compositing * Report owner window size in events to the window owner. * Scale exposure damage in compSetRedirectBorderClip from current size to owner size to make sure the correct parts of the window are repainted. Input scaling: * Change miSpriteTrace to scale cursor coordinates when transiting an owner-sized window. Do all computations in double to handle multiple such transitions without losing bits * Add ScaleRootCoordinate in events.c. This function takes a window and a root x/y and walks up the tree scaling each time there is an owner size set. * Use ScaleRootCoordinate in FixUpEventFromWindow. * Wrap event delivery in DeliverEvent in new SaveEventRootCoord/RestoreEventRootCoord functions so that different windows receiving the same event will all receive the correct coordinates. Composite events: * Deliver CompositePixmapNotify events from compSetPixmapVisitWindow so that applications will be notified each time the pixmap changes. * Deliver CompositeOwnerWindowSizeNotify events when owner window size is set. Signed-off-by:
-
- Aug 25, 2018
-
-
Keith Packard authored
Allows constant strings to be passed to these functions without generating a compiler warning. Signed-off-by:
-
- Aug 09, 2018
-
-
This enables Xtrans's systemd socket activation. Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
The client ID is only needed for XRes, and autotools build ignores the --clientids= arg if xres is disabled. We haven't made a meson option for disabling tracking client ids (is it actually worth a build option?), so just make this depend on xres. Signed-off-by:
-
Ported from autotools. Signed-off-by:
-
This makes us match the featureset of autotools, and also fixes the non-Linux default value to match. Signed-off-by:
-
This is silly to have optional based on detection of the protocol headers, particularly now that we have a single protocol header repo to install. Reviewed-by:
-
Ported from automake. Signed-off-by:
-
Signed-off-by:
-
Signed-off-by:
-
Nothing in tree references the flag. Signed-off-by:
-
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107521 Fixes: 72683945 (autotools: Derive xkb configuration from xkbcomp.pc) Reviewed-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
vadym.shovkoplias <vadym.shovkoplias@globallogic.com>
-
- Aug 08, 2018
-
-
Not sure what if anything calls XSetDeviceModifierMapping() but this would've failed all the time. check_modmap_change() returns Success but we were treating it like a boolean. Fix this. Reported-by:
-
- Aug 02, 2018
-
-
Signed-off-by:
-
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:
-
CONFIG_UDEV and CONFIG_UDEV_KMS are the actual defines that are used in the C code. Signed-off-by:
-
The SCM_RIGHTS flag seems to be the thing that xtrans depends on, and meson makes the check easy without needing a build option. 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:
-
- 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:
-
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 19, 2018
-
-
Peter Hutterer authored
Control flow is: PanoramiXMaybeAddDepth() allocates an array size 240 (pDepth->numVisuals) PanoramiXMaybeAddVisual() finds up to 270 matches (pScreen->numVisuals) and writes those into the previously allocated array. This caused invalid reads/writes followed by eventually a double-free abort. Reproduced with xorg-integration-tests server test XineramaTest.ScreenCrossing/* (and a bunch of others). Signed-off-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
-
-
Currently our meson.build just makes the assumption that the libc is going to provide RPC functions. This doesn't actually seem to be the case on Fedora, which causes compilation to fail unexpectedly: ../../Projects/xserver/os/rpcauth.c:47:10: fatal error: rpc/rpc.h: No such file or directory #include <rpc/rpc.h> ^~~~~~~~~~~ compilation terminated. So, in the event that we can't use libtirpc ensure that we actually check whether or not the libc provides rpc/rpc.h. If it doesn't, raise an error. Reviewed-by:
Lyude Paul <lyude@redhat.com> -
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:
-
- Jul 01, 2018
-
-
paths returned by get_option('foodir') are potentially relative to prefix Noticed when comparing manpages generated by a meson build with those generated by an autotools build Signed-off-by:Jon Turney <jon.turney@dronecode.org.uk> 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
-
-
bugzilla: https://bugs.kde.org/show_bug.cgi?id=395419 bugzilla: https://bugs.archlinux.org/task/59025 Signed-off-by:
Laurent Carlier <lordheavym@gmail.com> Reviewed-by:
Aaron Plattner <aplattner@nvidia.com> Signed-off-by:
-
Lyude Paul authored
This really sucked to find out :( Signed-off-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: 
Karol Herbst <kherbst@redhat.com>
-
- Jun 27, 2018
-
-
KMS drivers are not required to support GEM. In particular, vmwgfx doesn't support flink and handles and names are identical. Getting a bo name should really be part of a lower level API, if needed, but in the mean time work around this by setting the name identical to the handle if GEM isn't supported. This fixes modesetting driver dri2 on vmwgfx. Reviewed-by:
Deepak Rawat <drawat@vmware.com> Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com>
-
Lyude Paul authored
This seems like a problem worth screaming about. Signed-off-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
-
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: -
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: -
This isn't used for anything, which is just as well, because /etc/xorg.conf is not in fact a path xserver will try to use. Bugzilla: https://bugs.freedesktop.org/8890 Signed-off-by:
-
