From: Thomas Zimmermann <tzimmermann@suse.de> To: Javier Martinez Canillas <javierm@redhat.com>, Geert Uytterhoeven <geert@linux-m68k.org> Cc: daniel.thompson@linaro.org, linux-staging@lists.linux.dev, linux-sh@vger.kernel.org, jingoohan1@gmail.com, deller@gmx.de, lee@kernel.org, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org, sam@ravnborg.org Subject: Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable Date: Fri, 9 Jun 2023 09:09:32 +0200 [thread overview] Message-ID: <77252bc9-e08e-fcee-d140-2b78ab768b42@suse.de> (raw) In-Reply-To: <873532eurg.fsf@minerva.mail-host-address-is-not-set> [-- Attachment #1.1: Type: text/plain, Size: 4991 bytes --] Hi Geert and Javier Am 08.06.23 um 01:07 schrieb Javier Martinez Canillas: > Geert Uytterhoeven <geert@linux-m68k.org> writes: > > Hello Geert and Thomas, > >> Hi Thomas, >> >> On Wed, Jun 7, 2023 at 5:15 PM Thomas Zimmermann <tzimmermann@suse.de> wrote: >>> Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven: >>>> On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>> --- a/drivers/video/fbdev/Kconfig >>>>> +++ b/drivers/video/fbdev/Kconfig >>>>> @@ -57,6 +57,15 @@ config FIRMWARE_EDID >>>>> combination with certain motherboards and monitors are known to >>>>> suffer from this problem. >>>>> >>>>> +config FB_DEVICE >>>>> + bool "Provide legacy /dev/fb* device" >>>> >>>> Perhaps "default y if !DRM", although that does not help for a >>>> mixed drm/fbdev kernel build? >>> >>> We could simply set it to "default y". But OTOH is it worth making it a >>> default? Distributions will set it to the value they need/want. The very >>> few people that build their own kernels to get certain fbdev drivers >>> will certainly be able to enable the option by hand as well. >> >> Defaulting to "n" (the default) means causing regressions when these >> few people use an existing defconfig. >> > > Having "dfault y if !DRM" makes sense to me. I guess is a corner case but > at least it won't silently be disabled for users that only want fbdev as > Geert mentioned. IMHO the rational behind such conditionals are mostly what "we make up here in the discussion", but not something based on real-world feedback. So I'd strongly prefer a clear n or y setting here. > > I wouldn't call it a regression though, because AFAIK the Kconfig options > are not a stable API ? IIRC in the past there have been concerns about changing Kconfig defaults. If we go with "default n", we'd apparently do something similar. > >>>> Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE, >>>> to be selected by both FB and DRM_FBDEV_EMULATION? >>>> Then FB_DEVICE can depend on FB_CORE, and default to y if FB. > > Funny that you mention because it's exactly what I attempted in the past: > > https://lore.kernel.org/all/20210827100531.1578604-1-javierm@redhat.com/T/#u > >>> >>> That wouldn't work. In Tumbleweed, we still have efifb and vesafb >>> enabled under certain conditions; merely for the kernel console. We'd >>> have to enable CONFIG_FB, which would bring back the device. >> >> "Default y" does not mean that you cannot disable FB_DEVICE, so >> you are not forced to bring back the device? >> > > I think we can have both to make the kernel more configurable: > > 1) Allow to only disable fbdev user-space APIs (/dev/fb?, /proc/fb, etc), > which is what the series is doing with the new FB_DEVICE config symbol. > > 2) Allow to disable all "native" fbdev drivers and only keep the DRM fbdev > emulation layer. That's what my series attempted to do with the FB_CORE > Kconfig symbol. > > I believe that there are use cases for both, for example as Thomas' said > many distros are disabling all the fbdev drivers and their user-space only > requires DRM/KMS, so makes sense to not expose any fbdev uAPI at all. > > But may be that other users want the opposite, they have an old user-space > that requires fbdev, but is running on newer hardware that only have a DRM > driver. So they will want DRM fbdev emulation but none fbdev driver at all. > > That's why I think that FB_DEVICE and FB_CORE are complementary and we can > support any combination of the two, if you agree there are uses for either. I still don't understand the value of such an extra compile-time option? Either you have fbdev userspace, then you want the device; or you don't then it's better to disable it entirely. I don't see much of a difference between DRM and fbdev drivers here. I'd also question the argument that there's even fbdev userspace out there. It was never popular in it's heyday and definitely hasn't improved since then. Even the 3 people who still ask for fbdev support here only seem to care about the performance of the framebuffer console, but never about userspace. So I'd like to propose a different solution: on top of the current patchset, let's make an fbdev module option that enables the device. If CONFIG_FB_DEVICE has been enabled, the option would switch the functionality on and off. A Kconfig option would set the default. With such a setup, distributions can disable the fbdev device by default. And the few users with the odd system that has fbdev userspace can still enable the fbdev device at boot time. Best regards Thomas > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Zimmermann <tzimmermann@suse.de> To: Javier Martinez Canillas <javierm@redhat.com>, Geert Uytterhoeven <geert@linux-m68k.org> Cc: daniel.thompson@linaro.org, lee@kernel.org, linux-sh@vger.kernel.org, jingoohan1@gmail.com, deller@gmx.de, linux-staging@lists.linux.dev, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-omap@vger.kernel.org, sam@ravnborg.org Subject: Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable Date: Fri, 9 Jun 2023 09:09:32 +0200 [thread overview] Message-ID: <77252bc9-e08e-fcee-d140-2b78ab768b42@suse.de> (raw) In-Reply-To: <873532eurg.fsf@minerva.mail-host-address-is-not-set> [-- Attachment #1.1: Type: text/plain, Size: 4991 bytes --] Hi Geert and Javier Am 08.06.23 um 01:07 schrieb Javier Martinez Canillas: > Geert Uytterhoeven <geert@linux-m68k.org> writes: > > Hello Geert and Thomas, > >> Hi Thomas, >> >> On Wed, Jun 7, 2023 at 5:15 PM Thomas Zimmermann <tzimmermann@suse.de> wrote: >>> Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven: >>>> On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>> --- a/drivers/video/fbdev/Kconfig >>>>> +++ b/drivers/video/fbdev/Kconfig >>>>> @@ -57,6 +57,15 @@ config FIRMWARE_EDID >>>>> combination with certain motherboards and monitors are known to >>>>> suffer from this problem. >>>>> >>>>> +config FB_DEVICE >>>>> + bool "Provide legacy /dev/fb* device" >>>> >>>> Perhaps "default y if !DRM", although that does not help for a >>>> mixed drm/fbdev kernel build? >>> >>> We could simply set it to "default y". But OTOH is it worth making it a >>> default? Distributions will set it to the value they need/want. The very >>> few people that build their own kernels to get certain fbdev drivers >>> will certainly be able to enable the option by hand as well. >> >> Defaulting to "n" (the default) means causing regressions when these >> few people use an existing defconfig. >> > > Having "dfault y if !DRM" makes sense to me. I guess is a corner case but > at least it won't silently be disabled for users that only want fbdev as > Geert mentioned. IMHO the rational behind such conditionals are mostly what "we make up here in the discussion", but not something based on real-world feedback. So I'd strongly prefer a clear n or y setting here. > > I wouldn't call it a regression though, because AFAIK the Kconfig options > are not a stable API ? IIRC in the past there have been concerns about changing Kconfig defaults. If we go with "default n", we'd apparently do something similar. > >>>> Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE, >>>> to be selected by both FB and DRM_FBDEV_EMULATION? >>>> Then FB_DEVICE can depend on FB_CORE, and default to y if FB. > > Funny that you mention because it's exactly what I attempted in the past: > > https://lore.kernel.org/all/20210827100531.1578604-1-javierm@redhat.com/T/#u > >>> >>> That wouldn't work. In Tumbleweed, we still have efifb and vesafb >>> enabled under certain conditions; merely for the kernel console. We'd >>> have to enable CONFIG_FB, which would bring back the device. >> >> "Default y" does not mean that you cannot disable FB_DEVICE, so >> you are not forced to bring back the device? >> > > I think we can have both to make the kernel more configurable: > > 1) Allow to only disable fbdev user-space APIs (/dev/fb?, /proc/fb, etc), > which is what the series is doing with the new FB_DEVICE config symbol. > > 2) Allow to disable all "native" fbdev drivers and only keep the DRM fbdev > emulation layer. That's what my series attempted to do with the FB_CORE > Kconfig symbol. > > I believe that there are use cases for both, for example as Thomas' said > many distros are disabling all the fbdev drivers and their user-space only > requires DRM/KMS, so makes sense to not expose any fbdev uAPI at all. > > But may be that other users want the opposite, they have an old user-space > that requires fbdev, but is running on newer hardware that only have a DRM > driver. So they will want DRM fbdev emulation but none fbdev driver at all. > > That's why I think that FB_DEVICE and FB_CORE are complementary and we can > support any combination of the two, if you agree there are uses for either. I still don't understand the value of such an extra compile-time option? Either you have fbdev userspace, then you want the device; or you don't then it's better to disable it entirely. I don't see much of a difference between DRM and fbdev drivers here. I'd also question the argument that there's even fbdev userspace out there. It was never popular in it's heyday and definitely hasn't improved since then. Even the 3 people who still ask for fbdev support here only seem to care about the performance of the framebuffer console, but never about userspace. So I'd like to propose a different solution: on top of the current patchset, let's make an fbdev module option that enables the device. If CONFIG_FB_DEVICE has been enabled, the option would switch the functionality on and off. A Kconfig option would set the default. With such a setup, distributions can disable the fbdev device by default. And the few users with the odd system that has fbdev userspace can still enable the fbdev device at boot time. Best regards Thomas > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2023-06-09 7:09 UTC|newest] Thread overview: 190+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-05 14:47 ` [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 7:30 ` Javier Martinez Canillas 2023-06-07 7:30 ` Javier Martinez Canillas 2023-06-07 7:34 ` Javier Martinez Canillas 2023-06-07 7:34 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 02/30] backlight/gpio_backlight: " Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-05 20:19 ` Ruhl, Michael J 2023-06-05 20:23 ` Sam Ravnborg 2023-06-05 20:23 ` Sam Ravnborg 2023-06-05 20:41 ` Ruhl, Michael J 2023-06-05 20:41 ` Ruhl, Michael J 2023-06-06 7:24 ` Thomas Zimmermann 2023-06-06 7:49 ` Dan Carpenter 2023-06-06 7:49 ` Dan Carpenter 2023-06-06 8:05 ` Thomas Zimmermann 2023-06-06 8:05 ` Thomas Zimmermann 2023-06-05 14:47 ` [PATCH 03/30] backlight/lv5207lp: " Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 7:35 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 04/30] fbdev/atyfb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 7:36 ` Javier Martinez Canillas 2023-06-07 7:36 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 05/30] fbdev/atyfb: Use hardware device as backlight parent Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 7:41 ` Javier Martinez Canillas 2023-06-07 7:41 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 06/30] fbdev/aty128fb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 7:42 ` Javier Martinez Canillas 2023-06-07 7:42 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 07/30] fbdev/aty128fb: Use hardware device as backlight parent Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 7:55 ` Javier Martinez Canillas 2023-06-07 7:55 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 08/30] fbdev/broadsheetfb: Call device_remove_file() with hardware device Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 7:55 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 09/30] fbdev/ep93xx-fb: Alloc DMA memory from " Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 8:47 ` Javier Martinez Canillas 2023-06-07 8:47 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 10/30] fbdev/ep93xx-fb: Output messages with fb_info() and fb_err() Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 8:59 ` Javier Martinez Canillas 2023-06-07 8:59 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 11/30] fbdev/ep93xx-fb: Do not assign to struct fb_info.dev Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-06 5:26 ` Dan Carpenter 2023-06-06 5:26 ` Dan Carpenter 2023-06-07 9:00 ` Javier Martinez Canillas 2023-06-07 9:00 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 12/30] fbdev/mb862xxfb: Output messages with fb_dbg() and fb_err() Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 9:00 ` Javier Martinez Canillas 2023-06-07 9:00 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 13/30] fbdev/metronomefb: Use hardware device for dev_err() Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 9:01 ` Javier Martinez Canillas 2023-06-07 9:01 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 14/30] fbdev/nvidiafb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 9:02 ` Javier Martinez Canillas 2023-06-07 9:02 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 15/30] fbdev/nvidiafb: Use hardware device as backlight parent Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 9:02 ` Javier Martinez Canillas 2023-06-07 9:02 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 16/30] fbdev/pxa168fb: Do not assign to struct fb_info.dev Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 9:09 ` Javier Martinez Canillas 2023-06-07 9:09 ` Javier Martinez Canillas 2023-06-05 14:47 ` [PATCH 17/30] fbdev/radeonfb: Reorder backlight and framebuffer cleanup Thomas Zimmermann 2023-06-05 14:47 ` Thomas Zimmermann 2023-06-07 9:09 ` Javier Martinez Canillas 2023-06-07 9:09 ` Javier Martinez Canillas 2023-06-05 14:48 ` [PATCH 18/30] fbdev/radeonfb: Use hardware device as backlight parent Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-06 5:28 ` Dan Carpenter 2023-06-06 5:28 ` Dan Carpenter 2023-06-06 7:30 ` Thomas Zimmermann 2023-06-06 7:30 ` Thomas Zimmermann 2023-06-07 9:10 ` Javier Martinez Canillas 2023-06-07 9:10 ` Javier Martinez Canillas 2023-06-05 14:48 ` [PATCH 19/30] fbdev/rivafb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-07 9:11 ` Javier Martinez Canillas 2023-06-05 14:48 ` [PATCH 20/30] fbdev/rivafb: Use hardware device as backlight parent Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-07 9:11 ` Javier Martinez Canillas 2023-06-07 9:11 ` Javier Martinez Canillas 2023-06-05 14:48 ` [PATCH 21/30] fbdev/sm501fb: Output message with fb_err() Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-07 9:12 ` Javier Martinez Canillas 2023-06-05 14:48 ` [PATCH 22/30] fbdev/smscufx: Detect registered fb_info from refcount Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-07 22:22 ` Javier Martinez Canillas 2023-06-07 22:22 ` Javier Martinez Canillas 2023-06-12 10:19 ` Thomas Zimmermann 2023-06-12 10:40 ` Javier Martinez Canillas 2023-06-05 14:48 ` [PATCH 23/30] fbdev/tdfxfb: Set i2c adapter parent to hardware device Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-07 22:23 ` Javier Martinez Canillas 2023-06-07 22:23 ` Javier Martinez Canillas 2023-06-05 14:48 ` [PATCH 24/30] fbdev/core: Pass Linux device to pm_vt_switch_*() functions Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-07 19:25 ` Sam Ravnborg 2023-06-07 19:25 ` Sam Ravnborg 2023-06-05 14:48 ` [PATCH 25/30] fbdev/core: Move framebuffer and backlight helpers into separate files Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-07 19:38 ` Sam Ravnborg 2023-06-07 19:38 ` Sam Ravnborg 2023-06-09 7:19 ` Thomas Zimmermann 2023-06-09 7:19 ` Thomas Zimmermann 2023-06-05 14:48 ` [PATCH 26/30] fbdev/core: Add fb_device_{create,destroy}() Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-07 19:45 ` Sam Ravnborg 2023-06-07 19:45 ` Sam Ravnborg 2023-06-05 14:48 ` [PATCH 27/30] fbdev/core: Move procfs code to separate file Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-07 20:33 ` Sam Ravnborg 2023-06-07 20:33 ` Sam Ravnborg 2023-06-05 14:48 ` [PATCH 28/30] fbdev/core: Move file-I/O code into " Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-05 21:35 ` kernel test robot 2023-06-05 21:35 ` kernel test robot 2023-06-07 20:48 ` Sam Ravnborg 2023-06-07 20:48 ` Sam Ravnborg 2023-06-12 10:35 ` Thomas Zimmermann 2023-06-12 10:35 ` Thomas Zimmermann 2023-06-07 22:28 ` Javier Martinez Canillas 2023-06-07 22:28 ` Javier Martinez Canillas 2023-06-05 14:48 ` [PATCH 29/30] fbdev/core: Rework fb init code Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-07 20:51 ` Sam Ravnborg 2023-06-07 20:51 ` Sam Ravnborg 2023-06-05 14:48 ` [PATCH 30/30] fbdev: Make support for userspace interfaces configurable Thomas Zimmermann 2023-06-05 14:48 ` Thomas Zimmermann 2023-06-05 15:03 ` Greg KH 2023-06-05 15:03 ` Greg KH 2023-06-05 21:45 ` kernel test robot 2023-06-05 21:45 ` kernel test robot 2023-06-07 8:48 ` Geert Uytterhoeven 2023-06-07 8:48 ` Geert Uytterhoeven 2023-06-07 15:15 ` Thomas Zimmermann 2023-06-07 15:15 ` Thomas Zimmermann 2023-06-07 15:24 ` Geert Uytterhoeven 2023-06-07 15:24 ` Geert Uytterhoeven 2023-06-07 23:07 ` Javier Martinez Canillas 2023-06-07 23:07 ` Javier Martinez Canillas 2023-06-09 7:09 ` Thomas Zimmermann [this message] 2023-06-09 7:09 ` Thomas Zimmermann 2023-06-09 7:29 ` Geert Uytterhoeven 2023-06-09 7:29 ` Geert Uytterhoeven 2023-06-09 8:00 ` Thomas Zimmermann 2023-06-09 8:00 ` Thomas Zimmermann 2023-06-09 9:14 ` Geert Uytterhoeven 2023-06-09 9:14 ` Geert Uytterhoeven 2023-06-09 11:04 ` Thomas Zimmermann 2023-06-09 11:04 ` Thomas Zimmermann 2023-06-09 11:22 ` Geert Uytterhoeven 2023-06-09 11:22 ` Geert Uytterhoeven 2023-06-09 9:59 ` Javier Martinez Canillas 2023-06-09 9:59 ` Javier Martinez Canillas 2023-06-09 10:10 ` Geert Uytterhoeven 2023-06-09 10:10 ` Geert Uytterhoeven 2023-06-09 10:24 ` Javier Martinez Canillas 2023-06-09 10:24 ` Javier Martinez Canillas 2023-06-09 11:27 ` Javier Martinez Canillas 2023-06-09 11:27 ` Javier Martinez Canillas 2023-06-11 16:37 ` Sam Ravnborg 2023-06-11 16:37 ` Sam Ravnborg 2023-06-12 6:47 ` Thomas Zimmermann 2023-06-12 6:47 ` Thomas Zimmermann 2023-06-12 7:00 ` Thomas Zimmermann 2023-06-12 7:00 ` Thomas Zimmermann 2023-06-07 8:35 ` [PATCH 00/30] fbdev: Make userspace interfaces optional Geert Uytterhoeven 2023-06-07 8:35 ` Geert Uytterhoeven 2023-06-12 10:46 ` Thomas Zimmermann 2023-06-12 10:46 ` Thomas Zimmermann 2023-06-07 12:06 ` Markus Elfring 2023-06-07 12:06 ` Markus Elfring 2023-06-07 12:21 ` Thomas Zimmermann 2023-06-07 12:21 ` Thomas Zimmermann 2023-06-07 14:08 ` Markus Elfring 2023-06-07 14:08 ` Markus Elfring
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=77252bc9-e08e-fcee-d140-2b78ab768b42@suse.de \ --to=tzimmermann@suse.de \ --cc=daniel.thompson@linaro.org \ --cc=deller@gmx.de \ --cc=dri-devel@lists.freedesktop.org \ --cc=geert@linux-m68k.org \ --cc=javierm@redhat.com \ --cc=jingoohan1@gmail.com \ --cc=lee@kernel.org \ --cc=linux-fbdev@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=linux-staging@lists.linux.dev \ --cc=sam@ravnborg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.