Re: [PATCH] drm/panic: depends on !VT_CONSOLE
On Thursday, June 13, 2024 11:40:16 AM EDT Jocelyn Falempe wrote: > The race condition between fbcon and drm_panic can only occurs if > VT_CONSOLE is set. So update drm_panic dependency accordingly. > This will make it easier for Linux distributions to enable drm_panic > by disabling VT_CONSOLE, and keeping fbcon terminal. > The only drawback is that fbcon won't display the boot kmsg, so it > should rely on userspace to do that. > At least plymouth already handle this case with > https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/224 Hi An FYI, seeing this and https://fedoraproject.org/wiki/Changes/EnableDrmPanic , there is a slight issue with CONFIG_VT_CONSOLE=n in relation to systemd that was recently discovered outside of virt-manager VMs, (or computers that have no devices connected to the first serial port) This was seen on a full CONFIG_VT=n kernel, but it also happens on kernels with just CONFIG_VT_CONSOLE disabled. When /dev/console is /dev/ttyS0 (as that is the new default without the VT console, and /dev/ttyS0 is not connected to anything, isatty()'s TCGETS ioctl on /dev/console results in an input output error, causing isatty() to return false. Because of this, systemd's status logging then rejects /dev/console as not being a terminal device, and rejects writing status output to it, resulting in a decrease of verbosity available to Plymouth. It at first did not show up in my testing, because all my virt-manager and qemu VMs had serial devices attached, which would cause isatty() to return true on /dev/ttyS0 backed /dev/console, but now I have raised this with linux-serial. Thanks > > Suggested-by: Daniel Vetter > Signed-off-by: Jocelyn Falempe > --- > drivers/gpu/drm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index a9df94291622..f5c989aed7e9 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -107,7 +107,7 @@ config DRM_KMS_HELPER > > config DRM_PANIC > bool "Display a user-friendly message when a kernel panic occurs" > - depends on DRM && !FRAMEBUFFER_CONSOLE > + depends on DRM && !(FRAMEBUFFER_CONSOLE && VT_CONSOLE) > select DRM_KMS_HELPER > select FONT_SUPPORT > help > > base-commit: 2bae076f3e35234e42bd7c90acd8caae8368ba90 >
Re: simpledrm, running display servers, and drivers replacing simpledrm while the display server is running
On Friday, May 10, 2024 9:11:13 AM EDT Jonas Ådahl wrote: > On Fri, May 10, 2024 at 02:45:48PM +0200, Thomas Zimmermann wrote: > > Hi > > > > > (This was discussed on #dri-devel, but I'll reiterate here as well). > > > > > > There are two problems at hand; one is the race condition during boot > > > when the login screen (or whatever display server appears first) is > > > launched with simpledrm, only some moments later having the real GPU > > > driver appear. > > > > > > The other is general purpose GPU hotplugging, including the unplugging > > > the GPU decided by the compositor to be the primary one. > > > > The situation of booting with simpledrm (problem 2) is a special case of > > problem 1. From the kernel's perspective, unloading simpledrm is the same as > > what you call general purpose GPU hotplugging. Even through there is not a > > full GPU, but a trivial scanout buffer. In userspace, you see the same > > sequence of events as in the general case. > > Sure, in a way it is, but the consequence and frequency of occurence is > quite different, so I think it makes sense to think of them as different > problems, since they need different solutions. One is about fixing > userspace components support for arbitrary hotplugging, the other for > mitigating the race condition that caused this discussion to begin with. > > > > > > > > > The latter is something that should be handled in userspace, by > > > compositors, etc, I agree. > > > > > > The former, however, is not properly solved by userspace learning how to > > > deal with primary GPU unplugging and switching to using a real GPU > > > driver, as it'd break the booting and login experience. > > > > > > When it works, i.e. the race condition is not hit, is this: > > > > > > * System boots > > > * Plymouth shows a "splash" screen > > > * The login screen display server is launched with the real GPU driver > > > * The login screen interface is smoothly animating using hardware > > > accelerating, presenting "advanced" graphical content depending on > > > hardware capabilities (e.g. high color bit depth, HDR, and so on) > > > > > > If the race condition is hit, with a compositor supporting primary GPU > > > hotplugging, it'll work like this: > > > > > > * System boots > > > * Plymouth shows a "splash" screen > > > * The login screen display server is launched with simpledrm > > > * Due to using simpldrm, the login screen interface is not animated and > > > just plops up, and no "advanced" graphical content is enabled due to > > > apparent missing hardware capabilities > > > * The real GPU driver appears, the login screen now starts to become > > > animated, and may suddenly change appearance due to capabilties > > > having changed > > > > > > Thus, by just supporting hotplugging the primary GPU in userspace, we'll > > > still end up with a glitchy boot experience, and it forces userspace to > > > add things like sleep(10) to work around this. > > > > > > In other words, fixing userspace is *not* a correct solution to the > > > problem, it's a work around (albeit a behaivor we want for other > > > reasons) for the race condition. > > > > To really fix the flickering, you need to read the old DRM device's atomic > > state and apply it to the new device. Then tell the desktop and applications > > to re-init their rendering stack. > > > > Depending on the DRM driver and its hardware, it might be possible to do > > this without flickering. The key is to not loose the original scanout > > buffer, while not probing the new device driver. But that needs work in each > > individual DRM driver. > > This doesn't sound like it'll fix any flickering as I describe them. > First, the loss of initial animation when the login interface appears is > not something one can "fix", since it has already happened. > I feel like whatever animations that a login screen has though is going to be in the realm of a fade-in animation, or maybe a sliding animation though, or one of those that are more on the simple side. llvmpipe should be good enough for animations like that these days I would think, right? Or is it really bad on very very old CPUs, like say a Pentium III? > Avoiding flickering when switching to the new driver is only possible > if one limits oneself to what simpledrm was capable of doing, i.e. no > HDR signaling etc. > > > > > > > > > Arguably, the only place a more educated guess about whether to wait or > > > not, and if so how long, is the kernel. > > > > As I said before, driver modules come and go and hardware devices come and > > go. > > > > To detect if there might be a native driver waiting to be loaded, you can > > test for > > > > - 'nomodeset' on the command line -> no native driver > > Makes sense to not wait here, and just assume simpledrm forever. > > > - 'systemd-load-modules' not started -> maybe wait > > - look for drivers under /lib/modules//kernel/drivers/gpu/drm/ -> > >
simpledrm, running display servers, and drivers replacing simpledrm while the display server is running
Hi So I have been made aware of an apparent race condition of some drivers taking a bit longer to load, which could lead to a possible race condition of display servers/greeters using the simpledrm device, and then experiencing problems once the real driver loads, the simpledrm device that the display servers are using as their primary GPU goes away. For example Weston crashes, Xorg crashes, wlroots seems to stay running, but doesn't draw anything on the screen, kwin aborts, This is if you boot on a QEMU machine with the virtio card, with modprobe.blacklist=virtio_gpu, and then, when the display server is running, run sudo modprobe virtio-gpu Namely, it's been recently reported here: https://github.com/sddm/sddm/issues/1917[1] and here https://github.com/systemd/systemd/issues/32509[2] My thinking: Instead of simpledrm's /dev/dri/card0 device going away when the real driver loads, is it possible for simpledrm to instead simulate an unplug of the fake display/CRTC? That way in theory, the simpledrm device will now be useless for drawing for drawing to the screen at that point, since the real driver is now taken over, but this way here, at least the display server doesn't lose its handles to the /dev/dri/card0 device, (and then maybe only remove itself once the final handle to it closes?) Is something like this possible to do with the way simpledrm works with the low level video memory? Or is this not possible? Thanks [1] https://github.com/sddm/sddm/issues/1917 [2] https://github.com/systemd/systemd/issues/32509
Re: [PATCH v11 1/9] drm/panic: Add drm panic locking
On Thursday, March 28, 2024 8:03:43 AM EDT Jocelyn Falempe wrote:
> From: Daniel Vetter
>
> Rough sketch for the locking of drm panic printing code. The upshot of
> this approach is that we can pretty much entirely rely on the atomic
> commit flow, with the pair of raw_spin_lock/unlock providing any
> barriers we need, without having to create really big critical
> sections in code.
>
> This also avoids the need that drivers must explicitly update the
> panic handler state, which they might forget to do, or not do
> consistently, and then we blow up in the worst possible times.
>
> It is somewhat racy against a concurrent atomic update, and we might
> write into a buffer which the hardware will never display. But there's
> fundamentally no way to avoid that - if we do the panic state update
> explicitly after writing to the hardware, we might instead write to an
> old buffer that the user will barely ever see.
>
> Note that an rcu protected deference of plane->state would give us the
> the same guarantees, but it has the downside that we then need to
> protect the plane state freeing functions with call_rcu too. Which
> would very widely impact a lot of code and therefore doesn't seem
> worth the complexity compared to a raw spinlock with very tiny
> critical sections. Plus rcu cannot be used to protect access to
> peek/poke registers anyway, so we'd still need it for those cases.
>
> Peek/poke registers for vram access (or a gart pte reserved just for
> panic code) are also the reason I've gone with a per-device and not
> per-plane spinlock, since usually these things are global for the
> entire display. Going with per-plane locks would mean drivers for such
> hardware would need additional locks, which we don't want, since it
> deviates from the per-console takeoverlocks design.
>
> Longer term it might be useful if the panic notifiers grow a bit more
> structure than just the absolute bare
> EXPORT_SYMBOL(panic_notifier_list) - somewhat aside, why is that not
> EXPORT_SYMBOL_GPL ... If panic notifiers would be more like console
> drivers with proper register/unregister interfaces we could perhaps
> reuse the very fancy console lock with all it's check and takeover
> semantics that John Ogness is developing to fix the console_lock mess.
> But for the initial cut of a drm panic printing support I don't think
> we need that, because the critical sections are extremely small and
> only happen once per display refresh. So generally just 60 tiny locked
> sections per second, which is nothing compared to a serial console
> running a 115kbaud doing really slow mmio writes for each byte. So for
> now the raw spintrylock in drm panic notifier callback should be good
> enough.
>
> Another benefit of making panic notifiers more like full blown
> consoles (that are used in panics only) would be that we get the two
> stage design, where first all the safe outputs are used. And then the
> dangerous takeover tricks are deployed (where for display drivers we
> also might try to intercept any in-flight display buffer flips, which
> if we race and misprogram fifos and watermarks can hang the memory
> controller on some hw).
>
> For context the actual implementation on the drm side is by Jocelyn
> and this patch is meant to be combined with the overall approach in
> v7 (v8 is a bit less flexible, which I think is the wrong direction):
>
> https://lore.kernel.org/dri-devel/20240104160301.185915-1-jfale...@redhat.com/
>
> Note that the locking is very much not correct there, hence this
> separate rfc.
>
> v2:
> - fix authorship, this was all my typing
> - some typo oopsies
> - link to the drm panic work by Jocelyn for context
>
> v10:
> - Use spinlock_irqsave/restore (John Ogness)
>
> v11:
> - Use macro instead of inline functions for drm_panic_lock/unlock (John
> Ogness)
>
> Signed-off-by: Daniel Vetter
> Cc: Jocelyn Falempe
> Cc: Andrew Morton
> Cc: "Peter Zijlstra (Intel)"
> Cc: Lukas Wunner
> Cc: Petr Mladek
> Cc: Steven Rostedt
> Cc: John Ogness
> Cc: Sergey Senozhatsky
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Jocelyn Falempe
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 4 ++
> drivers/gpu/drm/drm_drv.c | 1 +
> include/drm/drm_mode_config.h | 10 +++
> include/drm/drm_panic.h | 100
> 4 files changed, 115 insertions(+)
> create mode 100644 include/drm/drm_panic.h
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 39ef0a6addeb..fb97b51b38f1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -38,6 +38,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -3016,6 +3017,7 @@ int drm_atomic_helper_swap_state(struct
> drm_atomic_state *state,
>bool stall)
> {
> int i, ret;
> +
Re: [RFC][PATCH v5 0/6] drm/panic: Add a drm panic handler
On Friday, November 3, 2023 10:53:24 AM EST Jocelyn Falempe wrote: > This introduces a new drm panic handler, which displays a message when a > panic occurs. > So when fbcon is disabled, you can still see a kernel panic. > > This is one of the missing feature, when disabling VT/fbcon in the kernel: > https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/ > Fbcon can be replaced by a userspace kms console, but the panic screen must > be done in the kernel. > > This is a proof of concept, and works with simpledrm and mgag200, using a new > get_scanout_buffer() api > > To test it, make sure you're using the simpledrm driver, and trigger a panic: > echo c > /proc/sysrq-trigger > > v2: > * Use get_scanout_buffer() instead of the drm client API. (Thomas Zimmermann) > * Add the panic reason to the panic message (Nerdopolis) > * Add an exclamation mark (Nerdopolis) > > v3: > * Rework the drawing functions, to write the pixels line by line and > to use the drm conversion helper to support other formats. > (Thomas Zimmermann) > > v4: > * Fully support all simpledrm formats using drm conversion helpers > * Rename dpanic_* to drm_panic_*, and have more coherent function name. >(Thomas Zimmermann) > * Use drm_fb_r1_to_32bit for fonts (Thomas Zimmermann) > * Remove the default y to DRM_PANIC config option (Thomas Zimmermann) > * Add foreground/background color config option > * Fix the bottom lines not painted if the framebuffer height >is not a multiple of the font height. > * Automatically register the driver to drm_panic, if the function >get_scanout_buffer() exists. (Thomas Zimmermann) > * Add mgag200 support. > > v5: > * Change the drawing API, use drm_fb_blit_from_r1() to draw the font. >(Thomas Zimmermann) > * Also add drm_fb_fill() to fill area with background color. > * Add draw_pixel_xy() API for drivers that can't provide a linear buffer. > * Add a flush() callback for drivers that needs to synchronize the buffer. > * Add a void *private field, so drivers can pass private data to >draw_pixel_xy() and flush(). > * Add ast support. > * Add experimental imx/ipuv3 support, to test on an ARM hw. (Maxime Ripard) > > > With mgag200 support, I was able to test that the xrgb to rgb565 > conversion is working. > I am unable to test with that hardware, but I am able to test with simpledrm, and it works pretty good > IMX/IPUV3 support is not complete, I wasn't able to have etnaviv working on > my board. > But it shows that it can still work on ARM with DMA buffer in this case. > > Best regards, > > > Jocelyn Falempe (6): > drm/format-helper: Add drm_fb_blit_from_r1 and drm_fb_fill > drm/panic: Add a drm panic handler > drm/simpledrm: Add drm_panic support > drm/mgag200: Add drm_panic support > drm/ast: Add drm_panic support > drm/imx: Add drm_panic support > > drivers/gpu/drm/Kconfig | 22 ++ > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/ast/ast_drv.c| 4 +- > drivers/gpu/drm/ast/ast_drv.h| 3 + > drivers/gpu/drm/ast/ast_mode.c | 26 ++ > drivers/gpu/drm/drm_drv.c| 8 + > drivers/gpu/drm/drm_format_helper.c | 421 ++- > drivers/gpu/drm/drm_panic.c | 368 > drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 30 ++ > drivers/gpu/drm/mgag200/mgag200_drv.c| 25 ++ > drivers/gpu/drm/tiny/simpledrm.c | 15 + > include/drm/drm_drv.h| 21 ++ > include/drm/drm_format_helper.h | 9 + > include/drm/drm_panic.h | 96 ++ > 14 files changed, 966 insertions(+), 83 deletions(-) > create mode 100644 drivers/gpu/drm/drm_panic.c > create mode 100644 include/drm/drm_panic.h > > > base-commit: ffc253263a1375a65fa6c9f62a893e9767fbebfa >
Re: [PATCH v4 1/4] drm/format-helper: Export line conversion helper for drm_panic
On Tuesday, October 3, 2023 10:22:44 AM EDT Jocelyn Falempe wrote:
> drm_panic will need the low-level drm_fb__line functions.
> Also add drm_fb_r1_to_xrgb to render the fonts.
>
> Signed-off-by: Jocelyn Falempe
> ---
> drivers/gpu/drm/drm_format_helper.c | 88 ++---
> include/drm/drm_format_helper.h | 9 +++
> 2 files changed, 89 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index f93a4efcee90..c238e5d84f1f 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -270,7 +270,30 @@ void drm_fb_swab(struct iosys_map *dst, const unsigned
> int *dst_pitch,
>
> drm_fb_xfrm(dst, dst_pitch, , src, fb, clip, cached, swab_line);
> }
> -EXPORT_SYMBOL(drm_fb_swab);
I had to add this line back to get it to build, but once I did, it worked.
> +
> +/**
> + * drm_fb_r1_to_32bit_line - Convert one line from monochrome to any 32bit
> pixel format
> + * @dbuf: Pointer to the destination line (in any 32bit format)
> + * @sbuf: Pointer to the source line (in monochrome)
> + * @pixels: Number of pixels to convert.
> + * @fg_color: Foreground color, applied when R1 is 1
> + * @bg_color: Background color, applied when R1 is 0
> + *
> + * Convert monochrome to any format with 32bit pixel.
> + * There is a limitation, as sbuf is a pointer, it can only points to a
> multiple
> + * of 8 pixels in the source buffer.
> + */
> +void drm_fb_r1_to_32bit_line(void *dbuf, const void *sbuf, unsigned int
> pixels,
> + u32 fg_color, u32 bg_color)
> +{
> + unsigned int x;
> + const u8 *sbuf8 = sbuf;
> + u32 *dubf32 = dbuf;
> +
> + for (x = 0; x < pixels; x++)
> + dubf32[x] = (sbuf8[x / 8] & (0x80 >> (x % 8))) ? fg_color :
> bg_color;
> +}
> +EXPORT_SYMBOL(drm_fb_r1_to_32bit_line);
>
> static void drm_fb_xrgb_to_rgb332_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> {
> @@ -320,7 +343,13 @@ void drm_fb_xrgb_to_rgb332(struct iosys_map *dst,
> const unsigned int *dst_pi
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_rgb332);
>
> -static void drm_fb_xrgb_to_rgb565_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> +/**
> + * drm_fb_xrgb_to_rgb565_line - Convert one line from XRGB to RGB565
> + * @dbuf: Pointer to the destination line (in RGB565)
> + * @sbuf: Pointer to the source line (in XRGB)
> + * @pixels: Number of pixels to convert.
> + */
> +void drm_fb_xrgb_to_rgb565_line(void *dbuf, const void *sbuf, unsigned
> int pixels)
> {
> __le16 *dbuf16 = dbuf;
> const __le32 *sbuf32 = sbuf;
> @@ -336,6 +365,7 @@ static void drm_fb_xrgb_to_rgb565_line(void *dbuf,
> const void *sbuf, unsigne
> dbuf16[x] = cpu_to_le16(val16);
> }
> }
> +EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565_line);
>
> /* TODO: implement this helper as conversion to RGB565|BIG_ENDIAN */
> static void drm_fb_xrgb_to_rgb565_swab_line(void *dbuf, const void *sbuf,
> @@ -396,7 +426,13 @@ void drm_fb_xrgb_to_rgb565(struct iosys_map *dst,
> const unsigned int *dst_pi
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
>
> -static void drm_fb_xrgb_to_xrgb1555_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> +/**
> + * drm_fb_xrgb_to_rgb565_line - Convert one line from XRGB to
> XRGB1555
> + * @dbuf: Pointer to the destination line (in XRGB1555)
> + * @sbuf: Pointer to the source line (in XRGB)
> + * @pixels: Number of pixels to convert.
> + */
> +void drm_fb_xrgb_to_xrgb1555_line(void *dbuf, const void *sbuf, unsigned
> int pixels)
> {
> __le16 *dbuf16 = dbuf;
> const __le32 *sbuf32 = sbuf;
> @@ -412,6 +448,7 @@ static void drm_fb_xrgb_to_xrgb1555_line(void *dbuf,
> const void *sbuf, unsig
> dbuf16[x] = cpu_to_le16(val16);
> }
> }
> +EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb1555_line);
>
> /**
> * drm_fb_xrgb_to_xrgb1555 - Convert XRGB to XRGB1555 clip buffer
> @@ -447,7 +484,13 @@ void drm_fb_xrgb_to_xrgb1555(struct iosys_map *dst,
> const unsigned int *dst_
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb1555);
>
> -static void drm_fb_xrgb_to_argb1555_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> +/**
> + * drm_fb_xrgb_to_rgb565_line - Convert one line from XRGB to
> ARGB1555
> + * @dbuf: Pointer to the destination line (in ARGB1555)
> + * @sbuf: Pointer to the source line (in XRGB)
> + * @pixels: Number of pixels to convert.
> + */
> +void drm_fb_xrgb_to_argb1555_line(void *dbuf, const void *sbuf, unsigned
> int pixels)
> {
> __le16 *dbuf16 = dbuf;
> const __le32 *sbuf32 = sbuf;
> @@ -464,6 +507,7 @@ static void drm_fb_xrgb_to_argb1555_line(void *dbuf,
> const void *sbuf, unsig
> dbuf16[x] = cpu_to_le16(val16);
> }
> }
> +EXPORT_SYMBOL(drm_fb_xrgb_to_argb1555_line);
>
> /**
> *
Re: [RFC][PATCH v2 0/2] drm/panic: Add a drm panic handler
On Friday, September 15, 2023 4:28:20 AM EDT Jocelyn Falempe wrote: > This introduces a new drm panic handler, which displays a message when a > panic occurs. > So when fbcon is disabled, you can still see a kernel panic. > > This is one of the missing feature, when disabling VT/fbcon in the kernel: > https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/ > Fbcon can be replaced by a userspace kms console, but the panic screen must > be done in the kernel. > > This is a proof of concept, and works only with simpledrm, using a new > get_scanout_buffer() api > > To test it, make sure you're using the simpledrm driver, and trigger a panic: > echo c > /proc/sysrq-trigger > This seems to work pretty good! With this one, I don't need to have Weston (or another display server) running for it to work this time. The panic reason works, which is pretty sweet. FYI: I do get a hunk that fails to apply in simpledrm_remove in drivers/gpu/drm/tiny/simpledrm.c Seems to be a change in a recentish commit https://github.com/torvalds/linux/commit/84e6da7ad5537826343636b846530ec2167d4a19 Thanks! > v2 > * Use get_scanout_buffer() instead of the drm client API. (Thomas Zimmermann) > * Add the panic reason to the panic message (Nerdopolis) > * Add an exclamation mark (Nerdopolis) > > I didn't reuse the fbdev functions yet, that would need some fbdev > refactoring, because they rely on struct fb_info, and struct vc_data (for > font/console). But I still plan to at least try it for v3. > > A few more though: > 1) what about gpu with multiple monitor connected ? > maybe get_scanout_buffer() could return a list of scanout buffers ? > 2) I think for some GPU drivers, there might need a flush_scanout_buffer() > function, that should be called after the scanout buffer has been filled ? > > Best regards, > > Jocelyn Falempe (2): > drm/panic: Add a drm panic handler > drm/simpledrm: Add drm_panic support > > drivers/gpu/drm/Kconfig | 11 ++ > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/drm_drv.c| 3 + > drivers/gpu/drm/drm_panic.c | 270 +++ > drivers/gpu/drm/tiny/simpledrm.c | 17 ++ > include/drm/drm_drv.h| 14 ++ > include/drm/drm_panic.h | 41 + > 7 files changed, 357 insertions(+) > create mode 100644 drivers/gpu/drm/drm_panic.c > create mode 100644 include/drm/drm_panic.h > > > base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c >
Re: [RFC][PATCH 0/2] drm/panic: Add a drm panic handler
On Monday, August 21, 2023 9:34:52 AM EDT Jocelyn Falempe wrote: > On 13/08/2023 04:20, nerdopolis wrote: > > On Wednesday, August 9, 2023 3:17:27 PM EDT Jocelyn Falempe wrote: > >> This introduces a new drm panic handler, which displays a message when a > >> panic occurs. > >> So when fbcon is disabled, you can still see a kernel panic. > >> > >> This is one of the missing feature, when disabling VT/fbcon in the kernel: > >> https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/ > >> Fbcon can be replaced by a userspace kms console, but the panic screen > >> must be done in the kernel. > >> > >> This is a proof of concept, and works only with simpledrm, using the > >> drm_client API. > >> This implementation with the drm client API, allocates new framebuffers, > >> and looks a bit too complex to run in a panic handler. > >> Maybe we should add an API to "steal" the current framebuffer instead, > >> because in a panic handler user-space is already stopped. > >> > >> To test it, make sure you're using the simpledrm driver, and trigger a > >> panic: > >> echo c > /proc/sysrq-trigger > >> > >> There is one thing I don't know how to do, is to unregister the drm_panic > >> when the graphic driver is unloaded. > >> drm_client_register() says it will automatically unregister on driver > >> unload. But then I don't know how to remove it from my linked list, and > >> free the drm_client_dev struct. > >> > >> This is a first draft, so let me know what do you think about it. > > Hi, > > > > Oh wow, that's my post. I'm sorry about the late reply, I only saw this > > late yesterday, and I wanted to test it first. > > I had to edit my test QEMU script a bit to use TianoCore for virtual UEFI > > boot as there is no gfxmode=keep for SimpleDRM to work otherwise when > > specifying -kernel to qemu AFAIK > > > > I tested it, and it works! That's pretty cool, although is it possible to > > show the message, such as "attempted to kill init"? > > Thanks for taking time to test it. Yes it's possible to show the panic > reason, as it's a parameter in the panic callback. > > > > I like the little ASCII Tux. Maybe an ASCII /!\ or [X] on the belly would > > make it more obvious to users that it is an error condition. > > Especially for non-English speaking users > > That's a good idea. It's also probably possible to re-use the tux boot > logo, but I didn't try it yet. > > But currently, my priority is to see if it can get accepted, and if it > can work with a wide range of drivers. > Alright, that makes sense. I don't have a huge variety of hardware, but I have a udl (displaylink 2) device that can be tested once ready > > > > > > I will tweak my script a bit so I can test it more quickly in the future > > too. > > > Best Regards, > > > > > Thanks! > >> > >> Best regards, > >> > >> > >> > >> > >> Jocelyn Falempe (2): > >>drm/panic: Add a drm panic handler > >>drm/simpledrm: Add drm_panic support > >> > >> drivers/gpu/drm/Kconfig | 11 ++ > >> drivers/gpu/drm/Makefile | 1 + > >> drivers/gpu/drm/drm_drv.c| 3 + > >> drivers/gpu/drm/drm_panic.c | 286 +++ > >> drivers/gpu/drm/tiny/simpledrm.c | 2 + > >> include/drm/drm_panic.h | 26 +++ > >> 6 files changed, 329 insertions(+) > >> create mode 100644 drivers/gpu/drm/drm_panic.c > >> create mode 100644 include/drm/drm_panic.h > >> > >> > >> base-commit: 6995e2de6891c724bfeb2db33d7b87775f913ad1 > >> > > > > > > > > > > >
Re: [RFC][PATCH 0/2] drm/panic: Add a drm panic handler
On Wednesday, August 9, 2023 3:17:27 PM EDT Jocelyn Falempe wrote: > This introduces a new drm panic handler, which displays a message when a > panic occurs. > So when fbcon is disabled, you can still see a kernel panic. > > This is one of the missing feature, when disabling VT/fbcon in the kernel: > https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/ > Fbcon can be replaced by a userspace kms console, but the panic screen must > be done in the kernel. > > This is a proof of concept, and works only with simpledrm, using the > drm_client API. > This implementation with the drm client API, allocates new framebuffers, and > looks a bit too complex to run in a panic handler. > Maybe we should add an API to "steal" the current framebuffer instead, > because in a panic handler user-space is already stopped. > > To test it, make sure you're using the simpledrm driver, and trigger a panic: > echo c > /proc/sysrq-trigger > > There is one thing I don't know how to do, is to unregister the drm_panic > when the graphic driver is unloaded. > drm_client_register() says it will automatically unregister on driver unload. > But then I don't know how to remove it from my linked list, and free the > drm_client_dev struct. > > This is a first draft, so let me know what do you think about it. Hi, Oh wow, that's my post. I'm sorry about the late reply, I only saw this late yesterday, and I wanted to test it first. I had to edit my test QEMU script a bit to use TianoCore for virtual UEFI boot as there is no gfxmode=keep for SimpleDRM to work otherwise when specifying -kernel to qemu AFAIK I tested it, and it works! That's pretty cool, although is it possible to show the message, such as "attempted to kill init"? I like the little ASCII Tux. Maybe an ASCII /!\ or [X] on the belly would make it more obvious to users that it is an error condition. Especially for non-English speaking users I will tweak my script a bit so I can test it more quickly in the future too. Thanks! > > Best regards, > > > > > Jocelyn Falempe (2): > drm/panic: Add a drm panic handler > drm/simpledrm: Add drm_panic support > > drivers/gpu/drm/Kconfig | 11 ++ > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/drm_drv.c| 3 + > drivers/gpu/drm/drm_panic.c | 286 +++ > drivers/gpu/drm/tiny/simpledrm.c | 2 + > include/drm/drm_panic.h | 26 +++ > 6 files changed, 329 insertions(+) > create mode 100644 drivers/gpu/drm/drm_panic.c > create mode 100644 include/drm/drm_panic.h > > > base-commit: 6995e2de6891c724bfeb2db33d7b87775f913ad1 >
Re: [PATCH v2 00/10] drm: Support simple-framebuffer devices and firmware fbs
On Thursday, March 18, 2021 6:29:11 AM EDT Thomas Zimmermann wrote: > This patchset adds support for simple-framebuffer platform devices and > a handover mechanism for native drivers to take-over control of the > hardware. > > The new driver, called simpledrm, binds to a simple-frambuffer platform > device. The kernel's boot code creates such devices for firmware-provided > framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot > loader sets up the framebuffers. Description via device tree is also an > option. > > Simpledrm is small enough to be linked into the kernel. The driver's main > purpose is to provide graphical output during the early phases of the boot > process, before the native DRM drivers are available. Native drivers are > typically loaded from an initrd ram disk. Occationally simpledrm can also > serve as interim solution on graphics hardware without native DRM driver. > > So far distributions rely on fbdev drivers, such as efifb, vesafb or > simplefb, for early-boot graphical output. However fbdev is deprecated and > the drivers do not provide DRM interfaces for modern userspace. > > Patches 1 and 2 prepare the DRM format helpers for simpledrm. > > Patches 3 and 4 add a hand-over mechanism. Simpledrm acquires it's > framebuffer's I/O-memory range and provides a callback function to be > removed by a native driver. The native driver will remove simpledrm before > taking over the hardware. The removal is integrated into existing helpers, > so drivers use it automatically. > > Patches 5 to 10 add the simpledrm driver. It's build on simple DRM helpers > and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During > pageflips, SHMEM buffers are copied into the framebuffer memory, similar > to cirrus or mgag200. The code in patches 8 and 9 handles clocks and > regulators. It's based on the simplefb drivers, but has been modified for > DRM. > > I've also been working on fastboot support (i.e., flicker-free booting). > This requires state-readout from simpledrm via generic interfaces, as > outlined in [1]. I do have some prototype code, but it will take a while > to get this ready. Simpledrm will then support it. > > I've tested simpledrm with x86 EFI and VESA framebuffers, which both work > reliably. The fbdev console and Weston work automatically. Xorg requires > manual configuration of the device. Xorgs current modesetting driver does > not work with both, platform and PCI device, for the same physical > hardware. Once configured, X11 works. I looked into X11, but couldn't see > an easy way of fixing the problem. With the push towards Wayland+Xwayland > I expect the problem to become a non-issue soon. Additional testing has > been reported at [2]. > > One cosmetical issue is that simpledrm's device file is card0 and the > native driver's device file is card1. After simpledrm has been kicked out, > only card1 is left. This does not seem to be a practical problem however. > > TODO/IDEAS: > > * provide deferred takeover > * provide bootsplash DRM client > * make simplekms usable with ARM-EFI fbs > > v2: > * rename to simpledrm, aperture helpers > * reorganized patches > * use hotplug helpers for removal (Daniel) > * added DT match tables (Rob) > * use shadow-plane helpers > * lots of minor cleanups > > [1] > https://lore.kernel.org/dri-devel/CAKMK7uHtqHy_oz4W7F+hmp9iqp7W5Ra8CxPvJ=9bwmvfu-o...@mail.gmail.com/ > [2] https://lore.kernel.org/dri-devel/1761762.3HQLrFs1K7@nerdopolis/ > > Thomas Zimmermann (10): > drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip() > drm/format-helper: Add blitter functions > drm/aperture: Move fbdev conflict helpers into drm_aperture.h > drm/aperture: Add infrastructure for aperture ownership > drm: Add simpledrm driver > drm/simpledrm: Add fbdev emulation > drm/simpledrm: Initialize framebuffer data from device-tree node > drm/simpledrm: Acquire clocks from DT device node > drm/simpledrm: Acquire regulators from DT device node > drm/simpledrm: Acquire memory aperture for framebuffer > > Documentation/gpu/drm-internals.rst| 12 + > MAINTAINERS| 7 + > drivers/gpu/drm/Kconfig| 7 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/drm_aperture.c | 287 > drivers/gpu/drm/drm_format_helper.c| 96 ++- > drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- > drivers/gpu/drm/tiny/Kconfig | 17 + > drivers/gpu/drm/tiny/Makefile | 1 + > drivers/gpu/drm/tiny/cirrus.c | 2 +- > drivers/gpu/drm/tiny/simpledrm.c | 932 ++
Re: [PATCH v5 0/7] drm: add simpledrm driver
On Friday, March 12, 2021 3:03:46 AM EST Thomas Zimmermann wrote: > Hi > > Am 12.03.21 um 04:49 schrieb nerdopolis: > > On Wednesday, March 10, 2021 4:10:35 AM EST Thomas Zimmermann wrote: > >> Hi > >> > >> Am 10.03.21 um 03:50 schrieb nerdopolis: > >>> On Friday, September 2, 2016 4:22:38 AM EST David Herrmann wrote: > >>>> Hey > >>>> > >>>> On request of Noralf, I picked up the patches and prepared v5. Works > >>>> fine with > >>>> Xorg, if configured according to: > >>>> > >>>> https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html > >>>> If anyone knows how to make Xorg pick it up dynamically without such a > >>>> static > >>>> configuration, please let me know. > >>>> > >>>> > >>>> > >>> Hi > >>> > >>> I am kind of curious as I do have interest in seeing this merged as well. > >> > >> Please take a look at [1]. It's not the same driver, but something to > >> the same effect. I know it's been almost a year, but I do work on this > >> and intend to come back with a new version during 2021. > >> > >> I currently work on fastboot support for the new driver. But it's a > >> complicated matter and takes time. If there's interest, we could talk > >> about merging what's already there. > >> > >> Best regards > >> Thomas > >> > >> [1] > >> https://lore.kernel.org/dri-devel/20200625120011.16168-1-tzimmerm...@suse.de/ > >> > >>> > >>> There is an email in this thread from 2018, but when I tried to import an > >>> mbox > >>> file from the whole month for August 2018, for some reason, kmail doesn't > >>> see > >>> the sender and mailing list recipient in that one, so I will reply to > >>> this one, > >>> because I was able to import this into my mail client. > >>> https://www.spinics.net/lists/dri-devel/msg185519.html > >>> > >>> I was able to get this to build against Linux 4.8, but not against a newer > >>> version, some headers seem to have been split, and some things are off by > >>> 8 > >>> and other things. I could NOT find a git repo, but I was able to find the > >>> newest patches I could find, and import those with git am against 4.8 with > >>> some tweaks. If that is needed, I can link it, but only if you want. > >>> > >>> However in QEMU I wasn't able to figure out how to make it create a > >>> /dev/dri/card0 device, even after blacklisting the other modules for qxl, > >>> cirrus, etc, and then modprobe-ing simpledrm > >>> > >>> In my view something like this is would be useful. There still could be > >>> hardware devices that don't have modesetting support (like vmvga in > >>> qemu/virt-manager as an example). And most wayland servers need a > >>> /dev/dri/card0 device as well as a potential user-mode TTY replacement > >>> would > >>> also need /dev/dri/card0 > >>> > >>> I will admit I unfortunately failed to get it to build against master. I > >>> couldn't figure out some of the changes, where some new structs were off > >>> by > >>> a factor of 8. > >>> > >>> > >>> Thanks > >>> > >>> > >>> > >>> ___ > >>> dri-devel mailing list > >>> dri-devel@lists.freedesktop.org > >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >>> > >> > >> > > Hi > > > > I tried simplekms against v5.9, and it built, and it runs, and is pretty > > neat. > > > > I tried using the qxl, cirrus, and vmware card in QEMU. Weston starts on all > > of them. And I did ensure that the simplekms driver was being used > > Cool! Thanks a lot. When I submit the next patchset can I add > > Tested-by: nerdopolis > > to the tags? > Sure! > > > > That is, it works after adding GRUB_GFXPAYLOAD_LINUX=keep , to avoid having > > to > > set a VGA option. (although not sure the equivalent in syslinux yet) > > Yeah, it's a known 'limitation.' (1) But it's usually something that > Linux distributions take care of. > > The rsp kernel feature needs a set up from the firmware/bootloader/etc. > Once the driver has been merged, added other generic drivers (EFI, VESA, > etc) should be a lot easier. Those would maybe not require the firmware > setup. > > Best regards > Thomas > > (1) Well, it's the way it's supposed to work. > > > > > > > Thanks. > > > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] drm: add simpledrm driver
On Wednesday, March 10, 2021 4:10:35 AM EST Thomas Zimmermann wrote: > Hi > > Am 10.03.21 um 03:50 schrieb nerdopolis: > > On Friday, September 2, 2016 4:22:38 AM EST David Herrmann wrote: > >> Hey > >> > >> On request of Noralf, I picked up the patches and prepared v5. Works fine > >> with > >> Xorg, if configured according to: > >> > >> https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html > >> If anyone knows how to make Xorg pick it up dynamically without such a > >> static > >> configuration, please let me know. > >> > >> > >> > > Hi > > > > I am kind of curious as I do have interest in seeing this merged as well. > > Please take a look at [1]. It's not the same driver, but something to > the same effect. I know it's been almost a year, but I do work on this > and intend to come back with a new version during 2021. > > I currently work on fastboot support for the new driver. But it's a > complicated matter and takes time. If there's interest, we could talk > about merging what's already there. > > Best regards > Thomas > > [1] > https://lore.kernel.org/dri-devel/20200625120011.16168-1-tzimmerm...@suse.de/ > > > > > There is an email in this thread from 2018, but when I tried to import an > > mbox > > file from the whole month for August 2018, for some reason, kmail doesn't > > see > > the sender and mailing list recipient in that one, so I will reply to this > > one, > > because I was able to import this into my mail client. > > https://www.spinics.net/lists/dri-devel/msg185519.html > > > > I was able to get this to build against Linux 4.8, but not against a newer > > version, some headers seem to have been split, and some things are off by 8 > > and other things. I could NOT find a git repo, but I was able to find the > > newest patches I could find, and import those with git am against 4.8 with > > some tweaks. If that is needed, I can link it, but only if you want. > > > > However in QEMU I wasn't able to figure out how to make it create a > > /dev/dri/card0 device, even after blacklisting the other modules for qxl, > > cirrus, etc, and then modprobe-ing simpledrm > > > > In my view something like this is would be useful. There still could be > > hardware devices that don't have modesetting support (like vmvga in > > qemu/virt-manager as an example). And most wayland servers need a > > /dev/dri/card0 device as well as a potential user-mode TTY replacement would > > also need /dev/dri/card0 > > > > I will admit I unfortunately failed to get it to build against master. I > > couldn't figure out some of the changes, where some new structs were off by > > a factor of 8. > > > > > > Thanks > > > > > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > Hi I tried simplekms against v5.9, and it built, and it runs, and is pretty neat. I tried using the qxl, cirrus, and vmware card in QEMU. Weston starts on all of them. And I did ensure that the simplekms driver was being used That is, it works after adding GRUB_GFXPAYLOAD_LINUX=keep , to avoid having to set a VGA option. (although not sure the equivalent in syslinux yet) Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] drm: add simpledrm driver
On Wednesday, March 10, 2021 4:10:35 AM EST Thomas Zimmermann wrote: > Hi > > Am 10.03.21 um 03:50 schrieb nerdopolis: > > On Friday, September 2, 2016 4:22:38 AM EST David Herrmann wrote: > >> Hey > >> > >> On request of Noralf, I picked up the patches and prepared v5. Works fine > >> with > >> Xorg, if configured according to: > >> > >> https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html > >> If anyone knows how to make Xorg pick it up dynamically without such a > >> static > >> configuration, please let me know. > >> > >> > >> > > Hi > > > > I am kind of curious as I do have interest in seeing this merged as well. > > Please take a look at [1]. It's not the same driver, but something to > the same effect. I know it's been almost a year, but I do work on this > and intend to come back with a new version during 2021. > Thanks, I'll try that out > I currently work on fastboot support for the new driver. But it's a > complicated matter and takes time. If there's interest, we could talk > about merging what's already there. > > Best regards > Thomas > > [1] > https://lore.kernel.org/dri-devel/20200625120011.16168-1-tzimmerm...@suse.de/ > > > > > There is an email in this thread from 2018, but when I tried to import an > > mbox > > file from the whole month for August 2018, for some reason, kmail doesn't > > see > > the sender and mailing list recipient in that one, so I will reply to this > > one, > > because I was able to import this into my mail client. > > https://www.spinics.net/lists/dri-devel/msg185519.html > > > > I was able to get this to build against Linux 4.8, but not against a newer > > version, some headers seem to have been split, and some things are off by 8 > > and other things. I could NOT find a git repo, but I was able to find the > > newest patches I could find, and import those with git am against 4.8 with > > some tweaks. If that is needed, I can link it, but only if you want. > > > > However in QEMU I wasn't able to figure out how to make it create a > > /dev/dri/card0 device, even after blacklisting the other modules for qxl, > > cirrus, etc, and then modprobe-ing simpledrm > > > > In my view something like this is would be useful. There still could be > > hardware devices that don't have modesetting support (like vmvga in > > qemu/virt-manager as an example). And most wayland servers need a > > /dev/dri/card0 device as well as a potential user-mode TTY replacement would > > also need /dev/dri/card0 > > > > I will admit I unfortunately failed to get it to build against master. I > > couldn't figure out some of the changes, where some new structs were off by > > a factor of 8. > > > > > > Thanks > > > > > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] drm: add simpledrm driver
On Friday, September 2, 2016 4:22:38 AM EST David Herrmann wrote: > Hey > > On request of Noralf, I picked up the patches and prepared v5. Works fine with > Xorg, if configured according to: > https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html > If anyone knows how to make Xorg pick it up dynamically without such a static > configuration, please let me know. > > Thanks > David > > David Herrmann (7): > x86/sysfb: add support for 64bit EFI lfb_base > x86/sysfb: fix lfb_size calculation > of/platform: expose of_platform_device_destroy() > video: add generic framebuffer eviction > drm: switch to sysfb_evict_conflicts() > drm: add SimpleDRM driver > drm/simpledrm: add fbdev fallback support > > MAINTAINERS | 6 + > arch/x86/kernel/sysfb_simplefb.c | 39 ++- > drivers/gpu/drm/Kconfig | 3 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 24 +- > drivers/gpu/drm/bochs/bochs_drv.c| 19 +- > drivers/gpu/drm/i915/i915_drv.c | 73 +--- > drivers/gpu/drm/mgag200/mgag200_drv.c| 27 +- > drivers/gpu/drm/mgag200/mgag200_main.c | 9 - > drivers/gpu/drm/nouveau/nouveau_drm.c| 33 +- > drivers/gpu/drm/radeon/radeon_drv.c | 24 +- > drivers/gpu/drm/simpledrm/Kconfig| 19 ++ > drivers/gpu/drm/simpledrm/Makefile | 9 + > drivers/gpu/drm/simpledrm/simpledrm.h| 91 + > drivers/gpu/drm/simpledrm/simpledrm_damage.c | 194 +++ > drivers/gpu/drm/simpledrm/simpledrm_drv.c| 477 > +++ > drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 143 > drivers/gpu/drm/simpledrm/simpledrm_gem.c| 109 ++ > drivers/gpu/drm/simpledrm/simpledrm_kms.c| 270 +++ > drivers/gpu/drm/simpledrm/simpledrm_of.c | 265 +++ > drivers/gpu/drm/sun4i/sun4i_drv.c| 24 +- > drivers/gpu/drm/vc4/vc4_drv.c| 25 +- > drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 +- > drivers/of/platform.c| 35 +- > drivers/video/Kconfig| 4 + > drivers/video/Makefile | 1 + > drivers/video/sysfb.c| 327 ++ > include/linux/of_platform.h | 1 + > include/linux/sysfb.h| 34 ++ > 29 files changed, 2054 insertions(+), 256 deletions(-) > create mode 100644 drivers/gpu/drm/simpledrm/Kconfig > create mode 100644 drivers/gpu/drm/simpledrm/Makefile > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_damage.c > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_gem.c > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_kms.c > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_of.c > create mode 100644 drivers/video/sysfb.c > create mode 100644 include/linux/sysfb.h > > Hi I am kind of curious as I do have interest in seeing this merged as well. There is an email in this thread from 2018, but when I tried to import an mbox file from the whole month for August 2018, for some reason, kmail doesn't see the sender and mailing list recipient in that one, so I will reply to this one, because I was able to import this into my mail client. https://www.spinics.net/lists/dri-devel/msg185519.html I was able to get this to build against Linux 4.8, but not against a newer version, some headers seem to have been split, and some things are off by 8 and other things. I could NOT find a git repo, but I was able to find the newest patches I could find, and import those with git am against 4.8 with some tweaks. If that is needed, I can link it, but only if you want. However in QEMU I wasn't able to figure out how to make it create a /dev/dri/card0 device, even after blacklisting the other modules for qxl, cirrus, etc, and then modprobe-ing simpledrm In my view something like this is would be useful. There still could be hardware devices that don't have modesetting support (like vmvga in qemu/virt-manager as an example). And most wayland servers need a /dev/dri/card0 device as well as a potential user-mode TTY replacement would also need /dev/dri/card0 I will admit I unfortunately failed to get it to build against master. I couldn't figure out some of the changes, where some new structs were off by a factor of 8. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
