We probably don't want a fake crtc to be visible to clients, and we
definitely don't want to generate events every time we create such a
fake (which would happen as a side effect from RRCrtcCreate hitting
RRTellChanged). As it happens we're not actually using that crtc for
anything because xwayland doesn't store any state on the crtc object,
so it suffices to use the real crtc for the screen.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
We were mixing stdint and CARD* types, causing compiler warnings on
32-bit. Just switch over to stdint, which is what we'd like the server
to be using long term, anyway.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Instead of reusing xwl_window introduce a persistent window struct for every
window, that asks for Present flips.
This struct saves all relevant data and is only freed on window destroy.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
The old 32-Bit wraparound handling didn't actually work, due to some
integer casting bug, and the mapping was ill equipped to deal with input
from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's
introduced in Linux 4.15.
For 32-Bit truncated input from pageflip events and old vblank events
and old drmWaitVblank ioctl, implement new wraparound handling, which
also allows to deal with wraparound in the other direction, e.g., if a
32-Bit truncated sequence value is passed in, whose true 64-Bit
in-kernel hw value is within 2^30 counts of the previous processed
value, but whose 32-bit truncated sequence value happens to lie just
above or below a 2^32 boundary, iow. one of the two values 'sequence'
vs. 'msc_prev' lies above a 2^32 border, the other one below it.
The method is directly translated from Mesa's proven implementation of
the INTEL_swap_events extension, where a true underlying 64-Bit wide
swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB
truncated SBC transported over the X11 protocol wire. Same conditions
apply, ie. successive true 64-Bit SBC values are close to each other,
but don't always get received in strictly monotonically increasing
order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx:
Handle out-of-sequence swap completion events correctly. (v2)") for
explanation.
Additionally add a separate path for true 64-bit msc input originating
from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and
corresponding 64-bit vblank events. True 64-bit msc's don't need
remapping and must be passed through.
As a reliability bonus, they are also used here to update the tracking
values msc_prev and ms_high with perfect 64-Bit ground truth as baseline
for mapping msc from pageflip completion events, because pageflip events
are always 32-bit wide, even when the new kernel api's are used. Because
each pageflip(-event) is always preceeded close in time (and vblank
count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence
query as part of DRI2 or DRI3+Present swap scheduling, we can be certain
that each pageflip event will get its truncated 32-bit msc remapped
reliably to the true 64-bit msc of flip completion whenever the sequence
api is available, ie. on Linux 4.15 or later.
Note: In principle at least the 32-bit mapping path could also be
backported to earlier server branches, as this seems to be broken for at
least server 1.16 to 1.19.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Cc: Keith Packard <keithp@keithp.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
The function is ported from intel-ddx uxa backend around 2013, where its
stated purpose was to apply a vblank_offset to msc values to correct for
problems with those kernel provided msc values. Some (somewhat magic and
puzzling to myself) heuristic tried to guess if provided values were
unreasonable and tried to adapt the corrective vblank_offset to account
for that.
Except: It wasn't applied to kernel provided msc values, but the values
delivered by clients via DRI2 or Present, so valid client targetmsc
values, e.g., requesting a vblank event > 1000 vblanks in the future,
triggered the offset correction in arbitrarily wrong ways, leading to
wrong msc values being returned and thereby vblank events queued to the
kernel for the wrong time. This causes glXSwapBuffersMscOML and
glXWaitForMscOML to swap / return immediately whenever a swap/wait in >
1000 vblanks is requested.
The original code was also written to only deal with 32 bit mscs, but
server 1.20 modesetting ddx can now use new Linux 4.15+ kernel vblank
api to process true 64 bit msc's, which may confuse the heuristic even
more due to 32 bit integer truncation/wrapping.
This code caused various problems in the intel-ddx in the past since
year 2013, and was removed there in 2015 by Chris Wilson in commit
42ebe2ef9646be5c4586868cf332b4cd79bb4618:
" uxa: Remove the filtering of bogus Present MSC values
If the intention was to filter the return values from the kernel, the
filtering would have been applied to the kernel values and not to the
incoming values from Present. This filtering introduces crazy integer
promotion and truncation bugs all because Present feeds garbage into its
vblank requests.
"
Indeed, i found a Mesa bug yesterday which can cause Mesa's
PresentPixmap request to spuriously feed garbage targetMSC's into the
driver under some conditions. However, while other video drivers seem to
cope relatively well with that, modesetting ddx causes KDE-5's
plasmashell to lock up badly quite frequently, and my suspicion is that
the code removed in this commit is one major source of the extra
fragility.
Also my own tests fail for any swap scheduled more than 1000 vblanks
into the future, which is not uncommon for some scientific applications.
Iow. modesetting's swap scheduling seems to be more robust without this
function afaics.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Copied from Mesa with no modifications.
Gives us Cofeelake platform names updates and sync on Kaby Lake,
Ice Lake PCI IDs.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Clean up only if the request points to the presenting window or its top
parent window.
Since in this case all events are removed unconditionally, always stop
the timer.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Roman Gilg <subdiff@gmail.com>
There's no real point - if we don't have EGL then the extension check is
also going to fail - and the entrypoint is new in 1.5.0, which we don't
need to require yet.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
GBM objects were never destroyed after looking for format and
modifier compatibility when deciding whether flipping or copying
a presented pixmap.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106106
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
This adds initial support for displaying Xwayland applications through
the use of EGLStreams and nvidia's custom wayland protocol by adding
another egl_backend driver. This also adds some additional egl_backend
hooks that are required to make things work properly.
EGLStreams work a lot differently then the traditional way of handling
buffers with wayland. Unfortunately, there are also a LOT of various
pitfalls baked into it's design that need to be explained.
This has a very large and unfortunate implication: direct rendering is,
for the time being at least, impossible to do through EGLStreams. The
main reason being that the EGLStream spec mandates that we lose the
entire color buffer contents with each eglSwapBuffers(), which goes
against X's requirement of not losing data with pixmaps. no way to use
an allocated EGLSurface as the storage for glamor rendering like we do
with GBM, we have to rely on blitting each pixmap to it's respective
EGLSurface producer each frame. In order to pull this off, we add two
different additional egl_backend hooks that GBM opts out of
implementing:
- egl_backend.allow_commits for holding off displaying any EGLStream
backed pixmaps until the point where it's stream is completely
initialized and ready for use
- egl_backend.post_damage for blitting the content of the EGLStream
surface producer before Xwayland actually damages and commits the
wl_surface to the screen.
The other big pitfall here is that using nvidia's wayland-eglstreams
helper library is also not possible for the most part. All of it's API
for creating and destroying streams rely on being able to perform a
roundtrip in order to bring each stream to completion since the wayland
compositor must perform it's job of connecting a consumer to each
EGLstream. Because Xwayland has to potentially handle both responding to
the wayland compositor and it's own X clients, the situation of the
wayland compositor being one of our X clients must be considered. If we
perform a roundtrip with the Wayland compositor, it's possible that the
wayland compositor might currently be connected to us as an X client and
thus hang while both Xwayland and the wayland compositor await responses
from eachother. To avoid this, we work directly with the wayland
protocol and use wl_display_sync() events along with release() events to
set up and destroy EGLStreams asynchronously alongside handling X
clients.
Additionally, since setting up EGLStreams is not an atomic operation we
have to take into consideration the fact that an EGLStream can
potentially be created in response to a window resize, then immediately
deleted due to another pending window resize in the same X client's
pending reqests before Xwayland hits the part of it's event loop where
we read from the wayland compositor. To make this even more painful, we
also have to take into consideration that since EGLStreams are not
atomic that it's possible we could delete wayland resources for an
EGLStream before the compositor even finishes using them and thus run
into errors. So, we use quite a bit of tracking logic to keep EGLStream
objects alive until we know the compositor isn't using them (even if
this means the stream outlives the pixmap it backed).
While the default backend for glamor remains GBM, this patch exists for
users who have had to deal with the reprecussion of their GPU
manufacturers ignoring the advice of upstream and the standardization of
GBM across most major GPU manufacturers. It is not intended to be a
final solution to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream backend.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Just a small autogenerated header that will soon contain more then just
one macro.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This takes all of the gbm related code in wayland-glamor.c and moves it
into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
Additionally, we add the egl_backend struct into xwl_screen in order to
provide hooks for alternative EGL backends such as nvidia's EGLStreams.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
32 is not a valid depth, and the default is now 24 not 8.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Kludge sdksyms.c generator to not fail on GetClientPid.
It returns pid_t which on NetBSD is #define pid_t __pid_t
This slightly alters the GCC preprocessor output which this fragile
code could not deal with when using GCC 5+
Signed-off-by: Adam Jackson <ajax@redhat.com>
Use the DRM_CAP_ADDFB2_MODIFIERS query to make sure the kms
driver supports modifiers in the addfb2 ioctl, and fall back
to addfb ioctl without modifiers if modifiers are unsupported.
E.g., as of Linux 4.17, nouveau-kms so far does not suppport
modifiers and gets angry if drmModeAddFB2WithModifiers() is
called (-> failure to set a video mode -> blank screen), but
Mesa's nvc0+ gallium driver causes gbm_bo_get_modifier() to
return a valid modifier by translating the default tiling of
bo's created via gbm_bo_create() into a modifier other than
DRM_FORMAT_MOD_INVALID (see Mesa's nvc0_miptree_get_modifier()).
Testing for != DRM_FORMAT_MOD_INVALID is apparently not
sufficient for safe use of drmModeAddFB2WithModifiers.
Bonus: Handle potential failure of populate_format_modifiers().
The required DRM_CAP is defined since libdrm v2.4.65, and we
require v2.4.89+ for the server, so we can use it unconditionally.
Tested on intel-kms, radeon-kms, nouveau-kms. Fixes failure on
NVidia Pascal.
Fixes: 2f807c2324 ("modesetting: Add support for multi-plane pixmaps when page-flipping")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Regardless of the order we un-realize windows.
Suggested-by: Roman Gilg <subdiff@gmail.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
xwl_unrealize_window() would use freed xwl_window which can lead to
various memory corruption and crashes, as reported by valgrind:
Invalid read of size 8
at 0x42C802: xwl_present_cleanup (xwayland-present.c:84)
by 0x42BA67: xwl_unrealize_window (xwayland.c:601)
by 0x541EE9: compUnrealizeWindow (compwindow.c:285)
by 0x57E1FA: UnrealizeTree (window.c:2816)
by 0x581189: UnmapWindow (window.c:2874)
by 0x54EB26: ProcUnmapWindow (dispatch.c:879)
by 0x554B7D: Dispatch (dispatch.c:479)
by 0x558BE5: dix_main (main.c:276)
by 0x7C4B1BA: (below main) (libc-start.c:308)
Address 0xf520f60 is 96 bytes inside a block of size 184 free'd
at 0x4C2EDAC: free (vg_replace_malloc.c:530)
by 0x42B9FB: xwl_unrealize_window (xwayland.c:624)
by 0x541EE9: compUnrealizeWindow (compwindow.c:285)
by 0x57E1FA: UnrealizeTree (window.c:2816)
by 0x581189: UnmapWindow (window.c:2874)
by 0x54EB26: ProcUnmapWindow (dispatch.c:879)
by 0x554B7D: Dispatch (dispatch.c:479)
by 0x558BE5: dix_main (main.c:276)
by 0x7C4B1BA: (below main) (libc-start.c:308)
Block was alloc'd at
at 0x4C2FB06: calloc (vg_replace_malloc.c:711)
by 0x42B307: xwl_realize_window (xwayland.c:488)
by 0x541E59: compRealizeWindow (compwindow.c:268)
by 0x57DA40: RealizeTree (window.c:2617)
by 0x580B28: MapWindow (window.c:2694)
by 0x54EA2A: ProcMapWindow (dispatch.c:845)
by 0x554B7D: Dispatch (dispatch.c:479)
by 0x558BE5: dix_main (main.c:276)
by 0x7C4B1BA: (below main) (libc-start.c:308)
This is because UnrealizeTree() traverses the tree from top to bottom,
which invalidates the assumption that if the Window doesn't feature an
xwl_window on its own, it's the xwl_window of its first ancestor with
one.
This reverts commit 82df2ce3
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
ms_queue_vblank() returns false on failure.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Present support in Xwayland relies on glamor, make sure Xwayland can
be built without glamor by moving references to Present code inside
the conditional GLAMOR_HAS_GBM.
Reported-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Turns out that's legal, and xts exercises it, and we crash:
Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault.
dixGetPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20) at ../../include/privates.h:122
122 return (char *) (*privates) + key->offset;
(gdb) bt
#0 dixGetPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20) at ../../include/privates.h:122
#1 dixLookupPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20) at ../../include/privates.h:166
#2 xwl_window_of_top (window=0x0) at xwayland.c:128
#3 xwl_cursor_warped_to (device=<optimized out>, screen=0x268b6e0, client=<optimized out>, window=0x0, sprite=0x300bb30,
x=2400, y=1350) at xwayland.c:292
#4 0x00000000005622ec in ProcWarpPointer (client=0x32755d0) at events.c:3618
In this case, x/y are the screen-space coordinates where the pointer
ends up, and we need to look up the (X) window there.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Apparently on NetBSD we can hit failures like this:
sdksyms.c:1773:15: error: expected expression before ',' token
(void *) &, /* ../../dri3/dri3.h:110 */
I've been unable to reproduce that locally (even in a NetBSD vm), but
an obvious workaround might be to just notice empty symbol names and
ignore them rather than emit invalid C code.
Tested-by: Thomas Klausner <wiz@netbsd.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The caller may ignore the return value (will be addressed with later
commit) so simply zero the count from the get-go. We're pretty much do
so, in all cases but one :-\
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The caller may ignore the return value (will be addressed with later
commit) so simply zero the count from the get-go. We're pretty much do
so, in all cases but one :-\
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
It makes it perfectly clear that we should not be modifying them.
Should help highlight issues like the one fixed with previous commit.
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The glamor_pixmap_from_fds error path erroneously closes the fds.
We don't own them, plus the caller closes them after the function in
called.
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
dri3_screen_info is the user provide dispatch. Something that we do
not and should not change.
When using the _ptr typecast + const the compiler barfs at us
(rightfully so), so use the _rec one.
[Silence a new const mismatch warning too - ajax]
Fixes: 5631382988 ("dri3: Add DRI3 extension")
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
4b0a3cba fixed leaking of GLX fbconfigs, so now xwin needs to allocate them
correctly (individually, rather than all at once), so they can be freed
successfully.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
This was never merged upstream. It was a Fedora kernel patch but dropped from
Fedora in 2013 with kernel 3.12.
The reason for the KDSKBMUTE proposal has been fixed in systemd in Feb 2013,
systemd 198.
https://lists.freedesktop.org/archives/systemd-devel/2013-February/008795.html
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
[735/786] Generating 'hw/xwayland/Xwayland@exe/relative-pointer-unstable-v1-protocol.c'.
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
Use private-code if wayland-scanner is new enough.
Signed-off-by: Adam Jackson <ajax@redhat.com>
../hw/dmx/config/dmxparse.c: In function ‘dmxConfigCreateOption’:
../hw/dmx/config/dmxparse.c:385:13: warning: ‘strncpy’ output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]
strncpy(option->string + offset, p->string, len);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../hw/dmx/config/dmxparse.c:383:23: note: length computed here
int len = strlen(p->string);
^~~~~~~~~~~~~~~~~
The thing it's warning about is intentional, the surrounding code does
its own nul-termination. Make that obvious by using memcpy instead.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
This threw:
../hw/dmx/input/dmxarg.c: In function ‘dmxArgParse’:
../hw/dmx/input/dmxarg.c:128:5: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
strncpy(tmp, string, len);
^~~~~~~~~~~~~~~~~~~~~~~~~
../hw/dmx/input/dmxarg.c:126:11: note: length computed here
len = strlen(string) + 2;
^~~~~~~~~~~~~~
This code predates xstrtokenize, but that's no excuse.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
../hw/dmx/dmxpixmap.c: In function ‘dmxBitmapToRegion’:
../include/regionstr.h:174:22: warning: ‘Box.x1’ may be used uninitialized in this function [-Wmaybe-uninitialized]
(_pReg)->extents = *(_pBox);
~~~~~~~~~~~~~~~~~^~~~~~~~~~
../hw/dmx/dmxpixmap.c:208:12: note: ‘Box.x1’ was declared here
BoxRec Box;
^~~
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
snprintf doesn't terminate the string if it truncates, so things like
this are lurking crashers:
../hw/dmx/dmxprop.c: In function ‘dmxPropertyIdentifier.part.0’:
../hw/dmx/dmxprop.c:94:36: warning: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 123 [-Wformat-truncation=]
snprintf(buf, sizeof(buf), "%s:%s:%s", DMX_IDENT, hostname, display);
^~ ~~~~~~~~
../hw/dmx/dmxprop.c:94:5: note: ‘snprintf’ output 7 or more bytes (assuming 262) into a destination of size 128
snprintf(buf, sizeof(buf), "%s:%s:%s", DMX_IDENT, hostname, display);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../hw/dmx/dmxprop.c: In function ‘dmxPropertyWindow’:
../hw/dmx/dmxprop.c:372:36: warning: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 127 [-Wformat-truncation=]
snprintf(buf, sizeof(buf), "%s,%d", id, dmxScreen->index);
^~
../hw/dmx/dmxprop.c:372:5: note: ‘snprintf’ output between 3 and 140 bytes into a destination of size 128
snprintf(buf, sizeof(buf), "%s,%d", id, dmxScreen->index);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We could be more precise about termination, but meh.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
../hw/xfree86/utils/gtf/gtf.c: In function ‘print_fb_mode’:
../hw/xfree86/utils/gtf/gtf.c:241:50: warning: cast from function call of type ‘double’ to non-matching type ‘int’ [-Wbad-function-cast]
printf(" timings %d %d %d %d %d %d %d\n", (int) rint(1000000.0 / m->pclk), /* pixclock in picoseconds */
That's pretty nitpicky of you, gcc, but at least it's easy to fix.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
We would fail to get the FB ID if it wasn't already imported, since we
were checking to see if the pointer was NULL (it never was) rather than
if the content of the pointer was 0.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
drmmode_crtc_set_mode has a loop nested inside another loop, where both
of them were using 'i' as the loop iterator. Rename it to avoid an
infinite loop.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Non-atomic kms drivers like radeon-kms (or nouveau-kms with
default setting of "atomic ioctl disabled") don't export
any formats, so num_formats == 0.
Some atomic drivers (nouveau-kms with boot param nouveau.atomic=1,
or intel-kms on, e.g., Linux 4.13) expose num_formats == 0, or
don't expose any modifiers, so num_modifiers == 0.
Let the drmmode_is_format_supported() check pass in these cases
to allow page flipping, as it works just fine.
Tested on NV-96 for nouveau, HD-5770 for radeon, Intel Ivybridge
with Linux 4.13 and drm-next to fix page flipping.
Fixes: 9d147305b4 ("modesetting: Check if buffer format is supported when flipping")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
We need to make sure that the atomic commit are consistent
or else the kernel will reject it. For example, when moving
a CRTC from one output to another one, the first output CRTC_ID
property needs to be reset. Also if the second output was using
another CRTC beforehands, it needs to be disabled to avoid an
inconsistent state.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Tested-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
CRTCs and outputs needs to be enabled/disabled when the current
DPMS mode is changed. We also try to do it in an atomic commit
when possible.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Tested-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Keep track of whether or not we fed modifiers into GBM when we allocated
a BO. We'll use this later inside Glamor, to reallocate buffer storage
if we allocate buffer storage using modifiers, and a non-modifier-aware
client requests an export of that pixmap.
This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Keep track of whether or not we fed modifiers into GBM when we allocated
a BO. We'll use this later inside Glamor, to reallocate buffer storage
if we allocate buffer storage using modifiers, and a non-modifier-aware
client requests an export of that pixmap.
This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The newline before the protocl version got lost in commit
6cbefc3e0a. Prior to that commit, the
release date printed a newline at the end:
X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.14.12-1-ARCH x86_64
Now, that string gets run together with the version:
X.Org X Server 1.19.99.903 (1.20.0 RC 3)X Protocol Version 11, Revision 0
Build Operating System: Linux
Since the version string printing has a variety of #ifdefs in it, just
add the newline to the begining of the protocol version string.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The framebuffer can include multiple CRTCs in multi-monitors
setup. So we shouldn't use the buffer size but the CRTC size
instead. Rotated displays are shadowed, so we don't need to
worry about it there.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Fixes a regression caused by modifiers support. For some hw to
continue working even if not supporting ARGB8888 and ARGB2101010
formats, we assume that all imported BOs are opaque.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Otherwise the same content is shown on all outputs.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.comM>
The respective ISA functions were dropped back in 2008
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Install missing headers to the SDK directory to allow external modules
to properly build against the SDK. After this commit, the list of files
installed in the SDK include directory is the same as the list of files
installed by the autotools-based build.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
