- Oct 25, 2018
-
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
CVE-2018-14665 also made it possible to exploit this to access memory. With -logfile forbidden when running with elevated privileges this is no longer an issue. Signed-off-by: Matthieu Herrb <matthieu@herrb.eu> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 248d164e)
-
Could cause privilege elevation and/or arbitrary files overwrite, when the X server is running with elevated privileges (ie when Xorg is installed with the setuid bit set and started by a non-root user). CVE-2018-14665 Issue reported by Narendra Shinde and Red Hat. Signed-off-by: Matthieu Herrb <matthieu@herrb.eu> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 50c0cf88)
-
- Oct 16, 2018
-
-
Misplaced parenthesis caused us to compare the sizeof, not the readlink return value. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit bd5fe759)
-
- Oct 15, 2018
-
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
- Oct 12, 2018
-
-
Adam Jackson authored
Fixes: xorg/driver/xf86-video-fbdev#9 Signed-off-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit fc78bcca)
-
Adam Jackson authored
0a9415cf apparently can tickle bugs in the GL stack where glGetString returns NULL, presumably because the eglMakeCurrent() didn't manage to actually install a dispatch table and you're hitting a stub function. That's clearly not our bug, but if it happens we should at least not crash. Notice this case and fail gently. Signed-off-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit af151895)
-
Adam Jackson authored
Mesa started supporting GL_OES_EGL_image on llvmpipe in 17.3, after this commit: commit bbdeddd5fd0b797e1e281f058338b3da4d98029d Author: Gurchetan Singh <gurchetansingh@chromium.org> Date: Tue Aug 1 14:49:33 2017 -0700 st/dri: add drisw image extension That's pretty cool, but it means glamor now thinks it can initialize on llvmpipe. This is almost certainly not what anyone wants, as glamor on llvmpipe is pretty much uniformly slower than fb. This fixes both Xorg and Xwayland to refuse glamor in such a setup. Xephyr is left alone, both because glamor is not the default there and because Xephyr+glamor+llvmpipe is one of the easier ways to get xts to exercise glamor. The (very small) downside of this change is that you lose DRI3 support. This wouldn't have helped you very much (since an lp glamor blit is slower than a pixman blit), but it would eliminate the PutImage overhead for llvmpipe's glXSwapBuffers. A future change should add DRI3 support for the fb-only case. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 0a9415cf)
-
- Oct 05, 2018
-
-
xdmcpSocket survives during the reset, there is no need to create a new one. This commit restores logic that was broken by 49c0f241 in Xorg 1.19. Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru> (cherry picked from commit 32677ce0)
-
It is currently (ab)using the screen BlockHandler callback to do this. But this can cause problems with other extension as their block handlers might have executed before Composite's. And the operations Composite does might result in them wanting to change timeouts. Practically this caused problems for TigerVNC's VNC extension which failed to send out updates for Composite's screen updates. (cherry picked from commit 1bd5d0a5)
-
The destination is always either on the stack or in the middle of some struct. Signed-off-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 43a0f9a5)
-
- Oct 04, 2018
-
-
The mode (CoordModeOrigin or CoordModePrevious) was not taken into account when computing the box. The result was a bad drawing of points in some situations (on my hardware/software configuration, calling XDrawString followed by XDrawPoints in the mode CoordModePrevious). Signed-off-by: Cedric Roux <sed@free.fr> Signed-off-by: Eric Anholt <eric@anholt.net> (cherry picked from commit bc36594e)
-
Olivier Fourdan authored
So we do not lose subpixel precision in Xwayland. Suggested-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Closes: libinput/libinput#138 (cherry picked from commit 734b2d69)
-
The old code would not in fact validate the option value, though it might complain about it in the log. It also didn't let you set some legal values that the -maxclients command line option would. Signed-off-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 7d689f04)
-
Coverity complains about a use after free in here after the freeing, I can't follow the linked list so well, but whot says the device can only be on one list once, so break should fix it. Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit ba0f5d85)
-
Pointed out by coverity. Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit c4591ea1)
-
Pointed out by coverity. Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 75839395)
-
Pointed out by coverity. Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit cad3a1a8)
-
This saves us having to make sure we clean it up. Pointed out by coverity. Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit b6c29a88)
-
This is created using XNFstrdup, so it needs to be freed. Pointed out by coverity. Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit f0a5c0d1)
-
Avoids having to free the malloced object. Pointed out by coverity. Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit c7fa6a0a)
-
Pointed out by coverity. v2: set modifies_failed to NULL at start (whot) Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 51ae6126)
-
Otherwise if the VERIFY_SHMSIZE macro fails we leak the drawables we allocated earlier. Noticed by coverity scan. Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 3439929c)
-
Signed-off-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit c4f3e42f)
-
We don't support 8bpp, and we do have acceleration. Signed-off-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 0dc2c419)
-
Olivier Fourdan authored
Xwayland's `xwl_destroy_window()` invokes `xwl_present_cleanup()` before the common `DestroyWindow()`. But then `DestroyWindow()` calls `present_destroy_window()` which will possibly end up in `xwl_present_abort_vblank()` which will try to access data that was previously freed by `xwl_present_cleanup()`: Invalid read of size 8 at 0x434184: xwl_present_abort_vblank (xwayland-present.c:378) by 0x53785B: present_wnmd_abort_vblank (present_wnmd.c:651) by 0x53695A: present_free_window_vblank (present_screen.c:87) by 0x53695A: present_destroy_window (present_screen.c:152) by 0x42A90D: xwl_destroy_window (xwayland.c:653) by 0x584298: compDestroyWindow (compwindow.c:613) by 0x53CEE3: damageDestroyWindow (damage.c:1570) by 0x4F1BB8: DbeDestroyWindow (dbe.c:1326) by 0x46F7F6: FreeWindowResources (window.c:1031) by 0x472847: DeleteWindow (window.c:1099) by 0x46B54C: doFreeResource (resource.c:880) by 0x46C706: FreeClientResources (resource.c:1146) by 0x446ADE: CloseDownClient (dispatch.c:3473) Address 0x182abde0 is 80 bytes inside a block of size 112 free'd at 0x4C2FDAC: free (vg_replace_malloc.c:530) by 0x42A937: xwl_destroy_window (xwayland.c:647) by 0x584298: compDestroyWindow (compwindow.c:613) by 0x53CEE3: damageDestroyWindow (damage.c:1570) by 0x4F1BB8: DbeDestroyWindow (dbe.c:1326) by 0x46F7F6: FreeWindowResources (window.c:1031) by 0x472847: DeleteWindow (window.c:1099) by 0x46B54C: doFreeResource (resource.c:880) by 0x46C706: FreeClientResources (resource.c:1146) by 0x446ADE: CloseDownClient (dispatch.c:3473) by 0x446DA5: ProcKillClient (dispatch.c:3279) by 0x4476AF: Dispatch (dispatch.c:479) Block was alloc'd at at 0x4C30B06: calloc (vg_replace_malloc.c:711) by 0x433F46: xwl_present_window_get_priv (xwayland-present.c:54) by 0x434228: xwl_present_get_crtc (xwayland-present.c:302) by 0x539728: proc_present_query_capabilities (present_request.c:227) by 0x4476AF: Dispatch (dispatch.c:479) by 0x44B5B5: dix_main (main.c:276) by 0x75F611A: (below main) (libc-start.c:308) This is because `xwl_present_cleanup()` frees the memory but does not remove it from the window's privates, and `xwl_present_abort_vblank()` will still find it and hence try to access that freed memory... Remove `xwl_present_window` from window's privates on cleanup so that no other function can find and reuse that data once it's freed. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1616269 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 3f31f569)
-
xwl_output->randr_crtc is used in the update_screen_size() function : ==5331== Invalid read of size 4 ==5331== at 0x15263D: update_screen_size (xwayland-output.c:190) ==5331== by 0x152C48: xwl_output_remove (xwayland-output.c:413) ==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4) ==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4) ==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814) ==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651) ==5331== by 0x2A5322: WaitForSomething (WaitFor.c:208) ==5331== by 0x27574B: Dispatch (dispatch.c:421) ==5331== by 0x279945: dix_main (main.c:276) ==5331== Address 0x1aacb5f4 is 36 bytes inside a block of size 154 free'd ==5331== at 0x48369EB: free (vg_replace_malloc.c:530) ==5331== by 0x1F8AE8: RROutputDestroyResource (rroutput.c:421) ==5331== by 0x29A2AC: doFreeResource (resource.c:880) ==5331== by 0x29AE5B: FreeResource (resource.c:910) ==5331== by 0x152BE0: xwl_output_remove (xwayland-output.c:408) ==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4) ==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4) ==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814) ==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651) ==5331== Block was alloc'd at ==5331== at 0x48357BF: malloc (vg_replace_malloc.c:299) ==5331== by 0x1F93E0: RROutputCreate (rroutput.c:83) ==5331== by 0x152A75: xwl_output_create (xwayland-output.c:361) ==5331== by 0x14BE59: registry_global (xwayland.c:764) ==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4) ==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4) ==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814) ==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651) ==5331== by 0x2A5322: WaitForSomething (WaitFor.c:208) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> (cherry picked from commit 53ce2ba0)
-
Olivier Fourdan authored
Commit 99f0365b "Add a command line argument for disabling indirect GLX" added a test to check if indirect context are enabled in `DoCreateContext()` but `__glXDisp_CreateContextAttribsARB()` doesn't use `DoCreateContext()` and doesn't check if indirect context is enabled. As a result, clients can still manage to create indirect contexts using `glXCreateContextAttribsARB()` even if indirect contexts are disabled, which can possibly crash Xservers such as Xwayland or Xephyr when the context is destroyed. To avoid the issue, check for `enableIndirectGLX` in `__glXDisp_CreateContextAttribsARB()` as well. Fixes: 99f0365b "Add a command line argument for disabling indirect GLX" Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107508 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 75448671)
-
When a vblank has been marked as aborted, it's going to be free in the flip_notify function when stopped. We can't notify it after it's stopped because the pointer is invalid. Valgrind backtrace: ==5331== Invalid read of size 8 ==5331== at 0x212B4D: present_vblank_notify (present_vblank.c:34) ==5331== by 0x21439B: present_wnmd_flip_notify (present_wnmd.c:194) ==5331== by 0x21439B: present_wnmd_event_notify (present_wnmd.c:228) ==5331== by 0x156216: xwl_present_sync_callback (xwayland-present.c:282) ==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4) ==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4) ==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814) ==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651) ==5331== by 0x2A5322: WaitForSomething (WaitFor.c:208) ==5331== by 0x27574B: Dispatch (dispatch.c:421) ==5331== Address 0x1b44dc98 is 40 bytes inside a block of size 184 free'd ==5331== at 0x48369EB: free (vg_replace_malloc.c:530) ==5331== by 0x213B0A: present_wnmd_free_idle_vblanks (present_wnmd.c:118) ==5331== by 0x213B0A: present_wnmd_flips_stop (present_wnmd.c:161) ==5331== by 0x2143EF: present_wnmd_flip_notify (present_wnmd.c:192) ==5331== by 0x2143EF: present_wnmd_event_notify (present_wnmd.c:228) ==5331== by 0x156216: xwl_present_sync_callback (xwayland-present.c:282) ==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4) ==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4) ==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0) ==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814) ==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651) ==5331== by 0x2A5322: WaitForSomething (WaitFor.c:208) ==5331== Block was alloc'd at ==5331== at 0x48377D5: calloc (vg_replace_malloc.c:711) ==5331== by 0x212D9F: present_vblank_create (present_vblank.c:69) ==5331== by 0x214014: present_wnmd_pixmap (present_wnmd.c:610) ==5331== by 0x21576C: proc_present_pixmap (present_request.c:150) ==5331== by 0x27599D: Dispatch (dispatch.c:479) ==5331== by 0x279945: dix_main (main.c:276) ==5331== by 0x633AB16: (below main) (libc-start.c:310) v2: Still notify aborted flips (Roman) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107314 Reviewed-by: Roman Gilg <subdiff@gmail.com> Tested-by: Roman Gilg <subdiff@gmail.com> (cherry picked from commit ce271535)
-
This prevents multiple scroll events happening for wayland compositors which send axis values other than 10. For example, libinput will typically return 15 for each scroll wheel step, and if a wayland compositor sends those to xwayland without normalising them, 2 scroll wheel steps will end up as 3 xorg scroll events. By listening for the discrete_axis event, this will now correctly send only 2 xorg scroll events. The wayland protocol gurantees that there will always be an axis event following an axis_discrete event. However, it does not gurantee that other events (including other axis_discrete+axis pairs) will not happen in between them. So we must keep a list of outstanding axis_discrete events. Signed-off-by: Scott Anderson <scott@anderso.nz> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit cd285922)
-
The X will be crashed on the system with other DDX driver, such as amdgpu. show the log like: randr: falling back to unsynchronized pixmap sharing (EE) (EE) Backtrace: (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4e) (EE) 1: /usr/lib/xorg/Xorg (0x55cb0151a000+0x1b5ce9) (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1587a1d000+0x11390) (EE) (EE) Segmentation fault at address 0x0 (EE) The issue is that modesetting as the master, and amdgpu as the slave. Thus, when the master attempts to access pSlavePixPriv in ms_dirty_update(), problems result due to the fact that it's accessing AMD's 'ppriv' using the modesetting structure definition. Apart from fixing crash issue, the patch fix other issue in master interface in which driver should refer to master pixmap. Signed-off-by: Jim Qu <Jim.Qu@amd.com> Reviewed-by: Alex Goins <agoins@nvidia.com> (cherry picked from commit f79e5368)
-
The purpose of rrCheckPixmapBounding() is to make sure that the fb is large enough to accommodate the region scanned out by a GPU screen. Currently, however, it will actually shrink the fb if it's larger than it needs to be. This is a problem when combining PRIME output slaving with arbitrary transforms with xrandr. Although arbitrary transforms are not supposed to constrain the size of the fb (https://lists.freedesktop.org/archives/xorg-devel/2018-January/055563.html ), xrandr will use RRSetScreenSize to resize the desktop to accommodate scaling transforms, e.g. scaling a 1920x1080 display to 3840x2160 will result in a desktop size of 3840x2160. In the case of PRIME, rrCheckPixmapBounding() will be called after RRSetScreenSize() and it will resize the fb back down to what it would be without the scaling transform, e.g. 1920x1080. This represents divergence in behavior between PRIME and non-PRIME outputs. I had originally made rrCheckPixmapBounding() account for arbitrary transforms, but realized that the fb being large enough to accommodate arbitrary transforms is not a hard requirement enforced in the server. Instead, this change simply makes it so that rrCheckPixmapBounding() will only resize the fb to be larger than it already is, preventing it from stepping on prior requests to increase the size of the fb. Signed-off-by: Alex Goins <agoins@nvidia.com> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (cherry picked from commit a90f3372)
-
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: Adam Jackson <ajax@redhat.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com> (cherry picked from commit 4fe02b8d)
-
- Aug 07, 2018
-
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
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> (cherry picked from commit 1ef7aed3)
-
- Aug 02, 2018
-
-
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: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com> (cherry picked from commit 93cafb08)
-
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: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit ce2dde9e)
-
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> (cherry picked from commit cdec2b3c)
-
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> (cherry picked from commit d625e169)
-
- Aug 01, 2018
-
-
In commit 9db2af6f (xfree86: Remove xf86{Map,Unmap}VidMem) we somehow stopped exporting xf86{Read,Write}Mmio{8,16,32}. Since the function pointer indirection was intended to support dense vs sparse and sparse support is now gone, we can just make the functions static inline in compiler.h and avoid all of this. Bugzilla: https://bugs.gentoo.org/548906 Tested-by: Christopher May-Townsend <chris@maytownsend.co.uk> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 166ac294)
-