Jonathan Dieter posted a few patches to do this inside the Xorg
server but it makes no sense to do it there, just have the code
we use to probe the device list at startup check seat assignments
using the same code we check at hotplug time.
Bugilla: https://bugzilla.redhat.com/show_bug.cgi?id=1183654
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Jonathan Dieter <jdieter@lesbg.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
If the user wants to set one of the slave devices as
the primary output, we shouldn't fail to do so,
we were returning BadMatch which was tripping up
gnome-settings-daemon and bad things ensues.
Fix all the places we use primaryOutput to work
out primaryCrtc and take it into a/c when slave
gpus are in use.
v2: review from Aaron, fix indent, unhide has_primary from
macro. I left the int vs Bool alone to be consistent with
code below, a future patch could fix both.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Currently when the ddx does not set any driver name we set DRI2 driver but
not the VDPAU driver name. The result is that VDPAU drivers will not get found
by libvdpau when the modesetting driver is being used.
Just assume that the VDPAU driver matches the DRI2 driver name, this is true
for nouveau, r300, r600 and radeonsi i.e all VDPAU drivers currently supported
by mesa.
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
All of our checks for what crtc we are on take rotation into account so we
select the correct crtc. The only problem is that we weren't returning it
we were rotated. This caused X to think DRI3 apps were not on any crtc and
limit them to 1 FPS.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This replaces the stubs for shadow buffer creation/allocation with actual
functions and adds a shadow_destroy function. With this, we actually get
shadow buffers and RandR now works properly. Most of this is copied from
the xf86-video-intel driver and modified for modesetting.
v2 Jason Ekstrand <jason.ekstrand@intel.com>:
- Fix build with --disable-glamor
- Set the pixel data pointer in the pixmap header for dumb shadow bo's
- Call drmmode_create_bo with the right bpp
v2 Jason Ekstrand <jason.ekstrand@intel.com>:
- Make shadow buffers per-crtc and leave shadow_enable alone
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The original drmmode_glamor_new_screen_pixmap function was specific to the
primary screen pixmap. This commit pulls the guts out into a new, more
general, drmmode_set_pixmap_bo function for setting a buffer on a pixmap.
The new function also properly tears down the glamor bits if the buffer
being set is NULL. The drmmode_glamor_new_screen_pixmap function is now
just a 3-line wrapper around drmmode_set_pixmap_bo.
v2 Jason Ekstrand <jason.ekstrand@intel.com>:
- Re-arranged code in drmmode_set_pixmap_bo and
drmmode_glamor_handle_new_screen_pixmap so that glamor_set_screen_pixmap
only gets called for the screen pixmap
- Guard the call to glamor_set_screen_pixmapa with a drmmode->glamor check
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The CVE fix in:
commit 97015a07b9
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date: Wed Jan 22 22:37:15 2014 -0800
dix: integer overflow in RegionSizeof() [CVE-2014-8092 3/4]
offended the C++ demons:
../../include/regionstr.h:147:45: error: invalid conversion from 'void*' to
'pixman_region16_data_t* {aka pixman_region16_data*}' [-fpermissive]
Normally this isn't a problem, because around here we have the sense and
common decency to not use C++, but this does make tigervnc fail to build,
which is a little rude of us.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
As a DDX may declare offload support without supporting DRI2
(because it is using an alternative acceleration mechanism like DRI3),
when iterating the list of offload_source Screens to find a matching
DRI2 provider we need to check before assuming it is DRI2 capable.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88514
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Carlos Olmedo Escobar <carlos.olmedo.e@gmail.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88614
Signed-off-by: Carlos Sánchez de La Lama <csanchezdll@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
If the BlockHandler chain is modified while it is active, we need to
re-fetch the current value and store it in our private for use the
next time through.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This adds glamor into the block handler call chain
in the correct place.
This should fix interactions between glamor and drivers
requiring damage from glamor.
v2: okay don't consolidate, just leave things wierd for now
remove blcokhandler in screen close.
v3: block handler wrapping the right way.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
glEGLImageTargetTexture2DOES only set the first level.
Mesa handles this new texture as incomplete and renders a black screen.
We also want to prevent linear filtering.
https://bugs.freedesktop.org/show_bug.cgi?id=81800
Signed-off-by: Markus Wick <markus@selfnet.de>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
In the new KMS APIs, the legacy drmModeSetCursor ioctl actually waits
for a vblank after changing the cursor image before returning, meaning
that the X server, in attempting to hide the cursor before updating
its image, actually makes that hide *visible* for a full vblank.
It's unknown why the X server does this by default, but turn it off.
If we're with a legacy driver that doesn't support the modern
drmModeSetCursor by waiting for a vblank before returning, we're going
to get a tiny bit of tearing on the cursor plane. But between tearing
with a new cursor image and tearing with a blank cursor image, I'd
rather the former.
The only proper solution to this is an atomic ioctl that page flips
all planes, including the cursor plane, at vblank time and at the same
time.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
In Xnest or Xephyr, pressing CapsLock when focus is on another
window does not update the state in the nested X server.
This is because when synchronizing the lock modifier, sending a
keypress or a key release only is not sufficient to toggle the state,
unlike regular modifiers, one has to emulate a full press/release
to lock or unlock the modifier.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reported-by: Adam Greenblatt <adam.greenblatt@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This reduces the build log spam while still preserving the xmlto
status to catch build failures correctly.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Xwayland Makefile explicitely set its dependencies on
WAYLAND_LIBS. If the ibrairies are installed in a non-standard
path, WAYLAND_LIBS contains '-L/path/to/the/lib' which will fail
at build time with:
"No rule to make target '-L/path/to/the/lib', needed by 'Xwayland'.
Stop"
Remove that explicit dependency to avoid the problem (LDADD ought
to be enough to get the right libraries linked).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
If the suid wrapper is enabled, /usr/bin/Xorg is just a shell script that
execs either /usr/libexec/Xorg.bin directly or the Xorg.wrap binary which then
execve's /usr/libexec/Xorg.bin.
Either way, we end up with Xorg.bin, which is problematic for two reasons:
* ps shows the command as Xorg.bin
* _COMM and _EXE in systemd's journal will both show Xorg.bin as well
There's not much we can do about the path, but having the actual command stay
as Xorg means better compatibility to existing scripts. And, the reason for
this path: the command
journalctl _COMM=Xorg
works universally, regardless of whether the wrapper is used or not.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
For two ScreenRecs abs pointer positioning was working fine, but touch events
stuck to the lower/right edge on any screen but the one with a 0/0 origin.
Cause is a missing offset by the screen coordinates, causing the root
coordinates in the event to desktop-wide, not screen-wide.
Offset properly, just like we do for pointer events.
X.Org Bug 86655 <http://bugs.freedesktop.org/show_bug.cgi?id=86655>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The length checking code validates PutImage height and byte width by
making sure that byte-width >= INT32_MAX / height. If height is zero,
this generates a divide by zero exception. Allow zero height requests
explicitly, bypassing the INT32_MAX check.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Xephyr's pseudocolor emulation added in:
commit 81a3b6fe27
Author: Matthew Allum <breakfast@10.am>
Date: Mon Nov 8 22:39:47 2004 +0000
Add support to Xephyr for lower depths than hosts
only tracks one global colormap for the whole (Xephyr) display. Move
this to per-screen state so each screen's colormap can be correct.
[ajax: rebased to 1.17, cleaned up commit message]
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michele Baldessari <michele@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
I'm interested in copying this code to the mesa project, but before
doing that it seems prudent to have the license and copyright
attributions in place before copying that. To get this list of names I
went through:
git log -- os/xsha1.c
and:
git log -- render/glyph.c
Signed-off-by: Keith Packard <keithp@keithp.com>
present.c: In function 'ms_present_flush':
present.c:204:9: error: implicit declaration of function
'glamor_block_handler'
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87858
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The number of lines of video to update in the texture needs to be
computed from the height of the updated source, not the full height of
the source.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
modesetting hooked up vblank support for DRI2, but was missing support
for vblanks in Present.
This is mostly copy and pasted from Keith's code in the intel driver.
v2: Use ms_crtc_msc_to_kernel_msc in ms_present_queue_vblank to hook
up the vblank_offset workaround for bogus MSC values (which the
DRI2 code already did).
Also simplify the ms_present_get_crtc function. vblank.c already
implements the functionality; we just need to convert types.
v3: Fix ms_flush_drm_events return code. I'd copied code where 0 meant
success into a function that returned a boolean, so the return code
was always backwards.
Also add DebugPresent calls in ms_present_vblank_{handler,abort}.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We basically want it throughout the driver.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
crtc->enabled is insufficient; we should also make sure DPMS is on.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We don't want to try to vblank synchronize to monitors which are off.
In order to handle that properly, we need to know the CRTC's DPMS mode.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Previously, if present_queue_vblank() failed, we simply dropped the
present request on the floor, and returned an error. This was rather
mean to clients - after presenting, they wait for a PresentComplete
event to come back. But since the present never happens, they end up
waiting forever, and lock up in poll().
This patch falls back to present_execute if present_queue_vblank fails.
We still print a debugging message to warn when queueing fails, which
allows us to continue debugging problems, but makes Present robust
enough to not lock up people's compositing manager when vblank bugs
happen.
v2: Don't do present_queue_vblank() /and/ present_execute() (a bug that
snuck in during last minute tidying).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Currently, the indexes are off by 4 because of the scroll buttons.
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
_glamor_upload_bits_to_pixmap_texture currently ignores the stride
parameter, but __glamor_upload_pixmap_to_texture uses 4-byte alignment
via glPixelStorei(GL_UNPACK_ALIGNMENT, 4).
Also fix up the stride argument passed in though, in case it starts
being used properly in the future.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87455
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Only called from glamor_fbo.c now.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Calling glamor_purge_fbo directly was incorrect for large pixmaps.
Fixes use-after free with large pixmaps:
==2029== Invalid write of size 8 ~
==2029== at 0x85F93AD: __xorg_list_del (list.h:184)
==2029== by 0x85F93AD: xorg_list_del (list.h:204)
==2029== by 0x85F93AD: glamor_fbo_expire (glamor_fbo.c:280)
==2029== by 0x85F95CA: glamor_pixmap_fbo_cache_put (glamor_fbo.c:159)
==2029== by 0x85D7AB5: glamor_destroy_textured_pixmap (glamor.c:228)
==2029== by 0xC1BDDC4: radeon_glamor_destroy_pixmap (radeon_glamor.c:272)
==2029== by 0x519D00: damageDestroyPixmap (damage.c:1473)
==2029== by 0x4DD307: XvDestroyPixmap (xvmain.c:370)
==2029== by 0x4DB975: ShmDestroyPixmap (shm.c:258)
==2029== by 0x5098F6: FreePicture (picture.c:1425)
==2029== by 0x85E678E: glamor_composite_clipped_region (glamor_render.c:1558)
==2029== by 0x85F763A: glamor_composite_largepixmap_region (glamor_largepixmap.c:1347)
==2029== by 0x85E7964: _glamor_composite (glamor_render.c:1679)
==2029== by 0x85E7A38: glamor_composite (glamor_render.c:1758)
==2029== Address 0x1141d3c0 is 0 bytes inside a block of size 64 free'd
==2029== at 0x4C29E90: free (vg_replace_malloc.c:473)
==2029== by 0x85D7167: glamor_set_pixmap_private (glamor.c:570)
==2029== by 0xC1BDDC4: radeon_glamor_destroy_pixmap (radeon_glamor.c:272)
==2029== by 0x519D00: damageDestroyPixmap (damage.c:1473)
==2029== by 0x4DD307: XvDestroyPixmap (xvmain.c:370)
==2029== by 0x4DB975: ShmDestroyPixmap (shm.c:258)
==2029== by 0x45B246: doFreeResource (resource.c:875)
==2029== by 0x45BD5E: FreeResource (resource.c:905)
==2029== by 0x43444B: ProcFreePixmap (dispatch.c:1422)
==2029== by 0x43856E: Dispatch (dispatch.c:432)
==2029== by 0x43C96F: dix_main (main.c:298)
==2029== by 0x6CFAB44: (below main) (libc-start.c:287)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Call drmModeDirtyFB and check the return value to detect whether the
driver support for damage tracking is present, only initialize it in
that case.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
dispatch_dirty_region was only returning -EINVAL error codes,
otherwise it would return 0. The kernel returns -ENOSYS when the
driver doesn't support damage tracking, so dispatch_dirty would never
see the error and never disable damage tracking.
Pass all errors back from dispatch_dirty_region and let dispatch_dirty
deal with them.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Gets rid of gcc 4.8 warnings:
xf86AutoConfig.c:211:9: warning: nested extern declaration of
'xf86SolarisFbDev' [-Wnested-externs]
sun_VTsw.c:44:1: warning: no previous prototype for 'xf86VTRelease'
[-Wmissing-prototypes]
sun_VTsw.c:59:1: warning: no previous prototype for 'xf86VTAcquire'
[-Wmissing-prototypes]
and ensures caller & definition stay in sync.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Gets rid of gcc 4.8 warning:
osinit.c:211:9: warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement]
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This just calls the existing function to create the relevant Xv
adaptor and hook it up.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Hidden cursors also have their image updated; re-enabling the cursor
each time the image is set will cause it to re-appear.
* Unifies the code that was in drmmode_load_cursor_argb and
drm_mode_show_cursor and moves it to a new drmmode_set_cursor
* Add a new boolean, 'cursor_up', to the per-crtc
private data to track whether the cursor should be displayed.
* Call drmmode_set_cursor from drm_mode_show_cursor and, if
the cursor should be displayed, from drm_mode_load_cursor_argb.
v2: Call drmModeSetCursor2 when loading a new cursor image if the
cursor should be displayed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The other way around fails to destroy the screen pixmap EGL image:
==1782== 80 (32 direct, 48 indirect) bytes in 1 blocks are definitely lost in loss record 981 of 2,171
==1782== at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==1782== by 0xF9D4BD2: dri2_create_image_from_dri (egl_dri2.c:1264)
==1782== by 0xF9D4BD2: dri2_create_image_dma_buf (egl_dri2.c:1764)
==1782== by 0xF9D4BD2: dri2_create_image_khr (egl_dri2.c:1798)
==1782== by 0xF9C7937: eglCreateImageKHR (eglapi.c:1494)
==1782== by 0x85D5655: _glamor_egl_create_image (glamor_egl.c:134)
==1782== by 0x85D5655: glamor_egl_create_textured_pixmap (glamor_egl.c:302)
==1782== by 0x85D579B: glamor_egl_create_textured_screen (glamor_egl.c:225)
==1782== by 0xC1BE05D: radeon_glamor_create_screen_resources (radeon_glamor.c:67)
==1782== by 0xC1B6153: RADEONCreateScreenResources_KMS (radeon_kms.c:258)
==1782== by 0x4B2105: xf86CrtcCreateScreenResources (xf86Crtc.c:709)
==1782== by 0x43C823: dix_main (main.c:223)
==1782== by 0x6CFAB44: (below main) (libc-start.c:287)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
For robustness against drivers which may call both
glamor_(egl_)destroy_textured_pixmap and glamor_destroy_pixmap.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Keith Packard
Dave Airlie
Adel Gadllah
Nikhil Mahale
Jason Ekstrand
Adam Jackson
Chris Wilson
Carlos Olmedo Escobar
Carlos Sánchez de La Lama
Markus Wick
Jasper St. Pierre
Olivier Fourdan
Olivier Fourdan
Peter Hutterer
Michele Baldessari
Carl Worth
Kenneth Graunke
Dima Ryazanov
Michel Dänzer
Alan Coopersmith