Geert Uytterhoeven writes:
> Hi Javier,
>
> On Mon, Jul 17, 2023 at 11:33 AM Javier Martinez Canillas
> wrote:
>> Geert Uytterhoeven writes:
>> >> >> penguin in test004 is not displayed correctly. I was expecting that to
>> >> >> be
>
versations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
t check for minimum num_colors and skip that test then?
>
> The test still works (you did see an ugly black-and-white penguin), doesn't
> it?
>
Fair enough. But when it defaulted to XRGB, it looked better. So I
thought that it was a regression. No strong opinion though if the test
should be skipped or not.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Geert Uytterhoeven writes:
Hello Geert,
> Hi Javier,
>
> On Sun, Jul 16, 2023 at 3:30 PM Javier Martinez Canillas
> wrote:
>> Geert Uytterhoeven writes:
>> > The native display format of ssd1306 OLED displays is monochrome
>> > light-on-dark (R1). This
Thomas Zimmermann writes:
Hello Thomas,
> Hi
>
> Am 13.07.23 um 18:32 schrieb Javier Martinez Canillas:
[...]
>>
>> +static const struct drm_mode_config_helper_funcs
>> ssd130x_mode_config_helpers = {
>> +.atomic_commit_tail = drm_atomic_helper_commi
YPanStep: 1
YWrapStep : 0
LineLength : 16
Accelerator : No
Maybe I'm doing something wrong or misunderstading about how should work?
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
CONFIG_FB to be disabled (and automatically disabling all the
fbdev drivers).
Nothing from fb_backlight.o and fbmon.o is used by the DRM fbdev emulation
layer so these two objects can be compiled out when CONFIG_FB is disabled.
Signed-off-by: Javier Martinez Canillas
---
Changes in v5:
- Fix ifdef
.
Signed-off-by: Javier Martinez Canillas
---
(no changes since v3)
Changes in v3:
- Make the DRM symbol to select FB_CORE if DRM_FBDEV_EMULATION is
enabled (Arnd Bergmann).
- Also make DRM select FB_SYS_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
- Make DRM_FBDEV_EMULATION to depend on DRM instead
-by: Arnd Bergmann
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
drivers/video/fbdev/Kconfig | 203 +--
drivers/video/fbdev/core/Kconfig | 202 ++
2 files changed, 204 insertions(+), 201 deletions(-)
create mode 100644
The drivers in this subsystem are for character-based LCD displays, which
can fall into the same category of the DRM/KMS and fbdev drivers that are
located under the "Graphics support" menu. Add auxdisplay there as well.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martine
ect FB_CORE (Thomas Zimmermann).
Javier Martinez Canillas (4):
video: Add auxiliary display drivers to Graphics support menu
fbdev: Move core fbdev symbols to a separate Kconfig file
fbdev: Split frame buffer support in FB and FB_CORE symbols
drm: Make FB_CORE to be selected if DRM fbdev
the shadow buffer -> native buffer copy, I thought
of it as if as a user-visible (well, user-accessible I guess) but you are
correct that's not and trying to write to the device will fail anyways.
So devm_* should be enough indeed and if there are problems with that, it
would be a different bug in the driver to fix.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Geert Uytterhoeven writes:
Hello Geert,
> Hi Javier,
>
> On Fri, Jul 14, 2023 at 12:14 PM Javier Martinez Canillas
> wrote:
>> Geert Uytterhoeven writes:
>> Thanks a lot for your patch, this has been on my TODO for some time!
>>
>> > The native display
> ---
Reviewed-by: Javier Martinez Canillas
Thanks again for the series!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
lper_find_format() is modified to try to fall back to R1 if C1
> is not supported.
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
this will be useful, maybe
do it as a separate patch ?
The rest of the patch looks good to me though.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
orth between buffer
> format and bpp/depth, and the function can just call drm_mode_addfb2()
> directly instead.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/gpu/drm/drm_client.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
Nice cleanup!
R
t attempt
to update planes for disabled CRTCs ?
It's OK for me to be paranoid though, specially after the other issue that
you found. So I'll let you decide if you think is worth to keep the check.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
ate+0x26c/0x284
> drm_atomic_helper_commit_planes+0xfc/0x27c
>
> Work around that by checking if data_array is valid.
>
> Obviously this needs a better fix...
>
This should be fixed by [0] so we can drop this patch from the set.
[0]: https://lists.freedesktop.org/archives/dri-devel/2023-July/413630.html
-
MAX / args->width)
> return -EINVAL;
> - stride = cpp * args->width;
> + stride = DIV_ROUND_UP(args->bpp * args->width, 8);
> if (args->height > U32_MAX / stride)
> return -EINVAL;
>
Good catch.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Geert Uytterhoeven writes:
> Hi Javier,
>
> On Fri, Jul 14, 2023 at 11:34 AM Javier Martinez Canillas
> wrote:
>> Geert Uytterhoeven writes:
>> > The page height must be taken into account only for vertical coordinates
>> > and heights, not f
rm_rect_width(rect), 2) instead since the width is
not 8 in that case.
So I would prefer to skip this patch from your set, because otherwise
we will need to revert it when adding support for SSD132x controllers.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Geert Uytterhoeven writes:
Hello Geert,
> Hi Javier,
>
> On Thu, Jul 13, 2023 at 6:32 PM Javier Martinez Canillas
> wrote:
>> Geert reports that the following NULL pointer dereference happens for him
>> after commit 49d7d581ceaf ("drm/ssd130x: Don't allocate bu
merged in
drm-misc-next works. Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
epth = 24;
>> drm->mode_config.funcs = _mode_config_funcs;
>> + drm->mode_config.helper_private = _mode_config_helpers;
>>
>> /* Primary plane */
>>
>
> Thanks, that works!
>
Thanks for testing! Proper patch sent:
https://lists.freedesktop.org/archives/dri-devel/2023-July/413630.html
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
ut instead the drm_atomic_helper_commit_tail_rpm() function that doesn't
attempt to commit the atomic state for planes related to inactive CRTCs.
Reported-by: Geert Uytterhoeven
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x.c | 5 +
1 file changed, 5 insertions(+)
Maxime Ripard writes:
> On Thu, Jul 13, 2023 at 04:10:23PM +0200, Uwe Kleine-König wrote:
[...]
>> - Javier Martinez Canillas
>>Generally in favour (also via irc)
>>Wants a single patch
>>naming: drm > drm_dev > dev
>
> drm-misc driver ma
Geert Uytterhoeven writes:
Hello Geert,
> Hi Javier,
>
> On Thu, Jul 13, 2023 at 3:21 PM Javier Martinez Canillas
> wrote:
>> Geert Uytterhoeven writes:
>> > On Fri, Jun 9, 2023 at 7:09 PM Javier Martinez Canillas
>> > wrote:
>> >> The re
Geert Uytterhoeven writes:
Hello Geert,
> Hi Javier,
>
> On Fri, Jun 9, 2023 at 7:09 PM Javier Martinez Canillas
> wrote:
>> The resolutions for these panels are fixed and defined in the Device Tree,
>> so there's no point to allocate the buffers on each plane upd
Thomas Zimmermann writes:
> Am 13.07.23 um 10:58 schrieb Javier Martinez Canillas:
>> The commit e254b584dbc0 ("drm/ssd130x: Remove hardcoded bits-per-pixel in
>> ssd130x_buf_alloc()") used a pixel format info instead of a hardcoded bpp
>> to calculate the size o
ld be used.
Suggested-by: Geert Uytterhoeven
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index b3dc1ca9dc10..afb08a8aa
gt; > > detect.
>> >
>> > Really?
>>
>> FWIW, I agree with Christian here.
>>
FWIW I agree with Christian and Maxime as well. It's easier to review and
merge as a single patch, and also makes the resulting git history better.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
> kthread+0x29f/0x340
> ret_from_fork+0x1f/0x30
>
> cc:
> Reported-by: Zhang Yi
> Signed-off-by: Jocelyn Falempe
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
8d770833>] ret_from_fork+0x1f/0x30
> unreferenced object 0xff11000333089a00 (size 128):
>
> cc:
> Fixes: 1d42bbc8f7f9 ("drm/fbdev: fix cloning on fbcon")
> Reported-by: Zhang Yi
> Signed-off-by: Jocelyn Falempe
> ---
The patch looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Liviu Dudau writes:
Hello Liviu,
> On Tue, Jul 04, 2023 at 01:05:27AM +0200, Javier Martinez Canillas wrote:
>> Otherwise if CONFIG_DRM is disabled, menuconfig will show an empty menu.
>>
>> Signed-off-by: Javier Martinez Canillas
>
> Acked-by: Liviu Dudau
>
T
separately built
>>> without any issue, the tidss functionality will break if only the bridge
>>> patches get picked up, and not the tidss.
>>>
>>> Would it be possible for you to pick all the patches together once Tomi
>>> acks the tidss patch?
>>
>> Sure
>
> I think this looks fine. For the series:
>
> Reviewed-by: Tomi Valkeinen
>
It seems this series fell through the cracks? Since you both already
reviewed the patches, I've just pushed all the set to drm-misc-next.
Thanks all!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
l client")
> Fixes: 9e69bcd88e45 ("drm/omapdrm: Implement fbdev emulation as in-kernel
> client")
> Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation")
> Fixes: 71ec16f45ef8 ("drm/tegra: Implement fbdev emulation as in-kernel
>
")
> Signed-off-by: Thomas Zimmermann
> Cc: "K. Y. Srinivasan" (supporter:Hyper-V/Azure CORE AND
> DRIVERS)
> Cc: Haiyang Zhang (supporter:Hyper-V/Azure CORE AND
> DRIVERS)
> Cc: Wei Liu (supporter:Hyper-V/Azure CORE AND DRIVERS)
> Cc: Dexuan Cui (supporter:Hype
"Arnd Bergmann" writes:
> On Fri, Jul 7, 2023, at 15:40, Javier Martinez Canillas wrote:
[...]
>> And this is only used by mdacon (not supported by ia64), vgacon and
>> vga16fb (not supported by ia64 either).
>>
>> So this could just be guarded just by CO
gt; console driver in an allmodconfig build.
>
> Now that vgacon no longer builds on these architectures, remove the
> stale definitions.
>
> Signed-off-by: Arnd Bergmann
> ---
Nice cleanup!
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
o limit the amount of surprises on Arm, change the Kconfig default
> to the previously used 80x30 setting instead of the usual 80x25.
>
> Signed-off-by: Arnd Bergmann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
ot;[IA64-SGI] pcdp: add PCDP pci interface support") ?
> unsigned long vga_console_membase;
And this is only used by mdacon (not supported by ia64), vgacon and
vga16fb (not supported by ia64 either).
So this could just be guarded just by CONFIG_VGA_CONSOLE for ia64 ?
The rest of the patch looks g
d parts of the x86 system architecture.
>
> Signed-off-by: Arnd Bergmann
> ---
Both our explanation and changes look good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
ding
> Signed-off-by: Thomas Zimmermann
> Cc: Thierry Reding
> Cc: Mikko Perttunen
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
Hello Thomas,
> Make the comments for I/O, system and DMA memory say the same.
> Makes the header file's structure more obvious.
>
> Signed-off-by: Thomas Zimmermann
> Suggested-by: Javier Martinez Canillas
> ---
Looks good to me. Thanks!
R
Thomas Zimmermann writes:
> Hi
>
> Am 05.07.23 um 10:49 schrieb Javier Martinez Canillas:
[...]
>>
>> The #define FBINFO_FLAG_DEFAULT FBINFO_DEFAULT seems to be there since
>> the
>> original v2.6.12-rc2 git import in commit 1da177e4c3f4, so is h
ARN_ONCE if the _READS_FAST flag has not been set.
>
Agreed. Maybe you could add those warn (or at least info or debug?) even
if not all drivers have been annotated correctly. That way people can be
aware that is missing and fix if there are remaining drivers.
> Best regards
> Thomas
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
> Sure, I had the same thought. I think I'll rather change the existing
> comments a bit.
>
Yes, that works for me too. Thanks!
> Best regards
> Thomas
>
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> Remove the initializer macro FB_DEFAULT_SYS_OPS and its helper macro
> __FB_DEFAULT_SYS_OPS_MMAP. There are no users.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Helge Deller (maintainer:FRAMEBUFFER LAYER)
> ---
Reviewed-by: Javier Martinez C
Thomas Zimmermann writes:
> Set fbdev default flags FBNFO_DEFAULT and mark the framebuffer with
FBINFO_DEFAULT. I noticed that the same typo is in patch 04/10 as well.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
alkeinen
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
t(>vma_node);
> vma_set_file(vma, obj->filp);
>
> vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> }
>
> + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
> +
> return 0;
> }
>
I think
t;flags = FBINFO_FLAG_DEFAULT;
The #define FBINFO_FLAG_DEFAULT FBINFO_DEFAULT seems to be there since the
original v2.6.12-rc2 git import in commit 1da177e4c3f4, so is hard to know
why was introduced. FBINFO_DEFAULT is more used, I will just stick to that:
$ git grep FBINFO_DEFAULT | wc -l
92
$
? I would just drop it, since it might confuse
the different kernel stable scripts that attempt to backport by looking at
this tag.
As you said, it has been present from the beginning of this driver.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
uess you are doing in two assignments to be consistent with drm_fbdev_dma.c ?
I was just curious about the rationale for setting the flags in two steps.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
d-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> Use fbdev's DMA helpers for fbdev-dma. They are equivalent to the
> previously used system-memory helpers, so no functional changes here.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Ma
ULT_DMA_OPS_DRAW \
> + .fb_fillrect= sys_fillrect, \
> + .fb_copyarea= sys_copyarea, \
> + .fb_imageblit = sys_imageblit
> +
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
enough and the check is redundant.
Still, I think that this change should be documented in your commit
message.
With that change,
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> Fix coding style. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Kirill A. Shutemov"
> Cc: Anshuman Khandual
> Cc: Niklas Schnelle
> Cc: Zi Yan
> Cc: "Mike Rapoport (IBM)"
> Cc: Peter Zijlstra
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> The sm750fb driver does not need anything from .
> Remove the include statements.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Sudip Mukherjee
> Cc: Teddy Wang
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Ca
Thomas Zimmermann writes:
> The header file does not need anything from
> . Declare struct screen_info and remove
> the include statements.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Ard Biesheuvel
> Cc: Hans de Goede
> Cc: Javier Martinez Canillas
> ---
R
Sudip Mukherjee
> Cc: Teddy Wang
> Cc: Helge Deller
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
heuvel
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
rce outside of the if block, are you OK with this patch?
>>
>> I think Thomas is correct and would make sense to put the character-based
>> drivers next to the DRM and fbdev drivers since all these are for display.
>
> Yes, makes sense to me.
>
Good to know. Thanks!
> Gr{oetje,eeting}s,
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Andy Shevchenko writes:
> On Tue, Jul 04, 2023 at 01:05:26AM +0200, Javier Martinez Canillas wrote:
>> The drivers/video/fbdev/Kconfig defines both symbols for fbdev drivers and
>> core fbdev symbols, that can be enabled independently of the fbdev drivers.
>>
>> Sp
Hello Andy,
Andy Shevchenko writes:
> On Tue, Jul 04, 2023 at 01:05:28AM +0200, Javier Martinez Canillas wrote:
>> Currently the CONFIG_FB option has to be enabled even if no legacy fbdev
>> drivers are needed (e.g: only to have support for framebuffer consoles).
>>
>
Geert Uytterhoeven writes:
Hello Geert,
> Hi Javier,
>
> On Tue, Jul 4, 2023 at 1:05 AM Javier Martinez Canillas
> wrote:
>> The drivers in this subsystem are for character-based LCD displays, which
>> can fall into the same category of the DRM/KMS and fbdev drivers t
.
Signed-off-by: Javier Martinez Canillas
---
(no changes since v3)
Changes in v3:
- Make the DRM symbol to select FB_CORE if DRM_FBDEV_EMULATION is
enabled (Arnd Bergmann).
- Also make DRM select FB_SYS_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
- Make DRM_FBDEV_EMULATION to depend on DRM instead
-by: Arnd Bergmann
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
drivers/video/fbdev/Kconfig | 203 +--
drivers/video/fbdev/core/Kconfig | 202 ++
2 files changed, 204 insertions(+), 201 deletions(-)
create mode 100644
The drivers in this subsystem are for character-based LCD displays, which
can fall into the same category of the DRM/KMS and fbdev drivers that are
located under the "Graphics support" menu. Add auxdisplay there as well.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martine
CONFIG_FB to be disabled (and automatically disabling all the
fbdev drivers).
Nothing from fb_backlight.o and fbmon.o is used by the DRM fbdev emulation
layer so these two objects can be compiled out when CONFIG_FB is disabled.
Signed-off-by: Javier Martinez Canillas
---
Changes in v4:
- Fix menuconfig
Otherwise if CONFIG_DRM is disabled, menuconfig will show an empty menu.
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
drivers/gpu/drm/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index
ake CONFIG_DRM_FBDEV_EMULATION to select FB_CORE (Thomas Zimmermann).
Javier Martinez Canillas (5):
video: Add auxiliary display drivers to Graphics support menu
fbdev: Move core fbdev symbols to a separate Kconfig file
drm/arm: Make ARM devices menu depend on DRM
fbdev: Split frame buffer sup
Thomas Zimmermann writes:
> Hi Javier
>
> Am 02.07.23 um 21:15 schrieb Javier Martinez Canillas:
[...]
>> - Kernel-level support for the Direct Rendering Infrastructure (DRI)
>> - introduced in XFree86 4.0. If you say Y here, you need to select
>> -
e
menuconfig ends broken (no sub-level for fbdev drivers anymore).
I was talking with Arnd and Geert about this. I think that will pause this
series and instead first focus on cleaning up the fbdev Kconfig, then it
should be easier to add the FB_CORE on top of that.
> Best regards
> Thomas
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Andy Shevchenko writes:
> On Fri, Jun 30, 2023 at 10:29:20PM +0200, Javier Martinez Canillas wrote:
>> Andy Shevchenko writes:
>> > On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
>> >> Andy Shevchenko writes:
>> >> > On
Thomas Zimmermann writes:
Hello Thomas,
Thanks for your review.
> Hi
>
> Am 01.07.23 um 23:44 schrieb Javier Martinez Canillas:
[...]
>>
>> +menuconfig FB_CORE
>> +tristate "Core support for frame buffer devices"
>
> With the text,
.
Signed-off-by: Javier Martinez Canillas
---
Changes in v3:
- Make the DRM symbol to select FB_CORE if DRM_FBDEV_EMULATION is
enabled (Arnd Bergmann).
- Also make DRM select FB_SYS_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
- Make DRM_FBDEV_EMULATION to depend on DRM instead of DRM_KMS_HELPER.
Changes
CONFIG_FB to be disabled (and automatically disabling all the
fbdev drivers).
Nothing from fb_backlight.o and fbmon.o is used by the DRM fbdev emulation
layer so these two objects can be compiled out when CONFIG_FB is disabled.
Signed-off-by: Javier Martinez Canillas
---
Changes in v3:
- Really make
The current text were not changed since the original Linux-2.6.12-rc2 git
import. Let's improve it and make that more aligned with the DRM/KMS docs.
Suggested-by: Geert Uytterhoeven
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
drivers/gpu/drm/Kconfig | 22
lect FB_CORE (Thomas Zimmermann).
Javier Martinez Canillas (3):
drm: Improve Kconfig symbol prompt and help texts
fbdev: Split frame buffer support in FB and FB_CORE symbols
drm: Make FB_CORE to be selected if DRM fbdev emulation is enabled
arch/x86/Makefile | 2 +-
arc
it may be a possible combination. Not sure how useful what would
be in practice but we shouldn't restrict that IMO.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Geert Uytterhoeven writes:
> Hi Arnd,
>
> On Sun, Jul 2, 2023 at 12:07 AM Arnd Bergmann wrote:
>> On Sat, Jul 1, 2023, at 23:44, Javier Martinez Canillas wrote:
>> > Now that the fbdev core has been split in FB_CORE and FB, make DRM fbdev
>> > emulatio
Now that the fbdev core has been split in FB_CORE and FB, make DRM fbdev
emulation layer to just select the former.
This allows to disable the CONFIG_FB option if is not needed, which will
avoid the need to explicitly disable each of the legacy fbdev drivers.
Signed-off-by: Javier Martinez
RE (Thomas Zimmermann).
Javier Martinez Canillas (2):
fbdev: Split frame buffer support in FB and FB_CORE symbols
drm: Make fbdev emulation select FB_CORE instead of depends on FB
arch/x86/Makefile | 2 +-
arch/x86/video/Makefile | 2 +-
drivers/gpu/drm/Kconfig
CONFIG_FB to be disabled (and automatically disabling all the
fbdev drivers).
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Keep "depends on FB" for FB_DDC, FB_HECUBA, FB_SVGALIB, FB_MACMODES,
FB_BACKLIGHT, FB_MODE_HELPERS and FB_TILEBLITTING (Arnd Bergmann).
- Don't chang
Andy Shevchenko writes:
> On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
>> Andy Shevchenko writes:
>> > On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
>> >> This patch series splits the fbdev core su
Andy Shevchenko writes:
Hello Andy,
> On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
>> This patch series splits the fbdev core support in two different Kconfig
>> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
>> be
Thomas Zimmermann writes:
Hello Thomas,
Thanks a lot for your review.
> Hi Javier
>
> Am 30.06.23 um 00:51 schrieb Javier Martinez Canillas:
>> This patch series splits the fbdev core support in two different Kconfig
>> symbols: FB and FB_CORE. The motivation for this
"Arnd Bergmann" writes:
> On Fri, Jun 30, 2023, at 12:51, Javier Martinez Canillas wrote:
>> "Arnd Bergmann" writes:
>>
>>>> @@ -59,7 +71,7 @@ config FIRMWARE_EDID
>>>>
>>>> config FB_DEVICE
>>>>boo
"Arnd Bergmann" writes:
Hello Arnd,
Thanks for your review!
> On Fri, Jun 30, 2023, at 00:51, Javier Martinez Canillas wrote:
>> Currently the CONFIG_FB option has to be enabled even if no legacy fbdev
>> drivers are needed (e.g: only to have support for framebuffer
to be disabled (and automatically disabling all fbdev drivers).
Signed-off-by: Javier Martinez Canillas
---
arch/x86/Makefile | 2 +-
arch/x86/video/Makefile | 2 +-
drivers/video/console/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 62
Now that the fbdev core has been split in FB_CORE and FB, make DRM fbdev
emulation layer to just depend on the former.
This allows to disable the CONFIG_FB option if is not needed, which will
avoid the need to explicitly disable each of the legacy fbdev drivers.
Signed-off-by: Javier Martinez
on the new FB_CORE symbol instead of FB.
Javier Martinez Canillas (2):
fbdev: Split frame buffer support in FB and FB_CORE symbols
drm: Make fbdev emulation depend on FB_CORE instead of FB
arch/x86/Makefile | 2 +-
arch/x86/video/Makefile | 2 +-
drivers/gpu/drm
ling atomic modesetting for virtualized
>> > drivers in the userspace.
>> >
>> > Signed-off-by: Zack Rusin
>> > Cc: Maarten Lankhorst
>> > Cc: Maxime Ripard
>> > Cc: Thomas Zimmermann
>> > Cc: David Airlie
>> > Cc: Daniel Vetter
Pekka Paalanen writes:
> On Tue, 27 Jun 2023 10:56:39 +0200
> Javier Martinez Canillas wrote:
>
[...]
>> > Hi Zack,
>> >
>> > where is the UAPI documentation for these new properties? I mean
>> > something ending up in the HTML docs like what o
dealing with those extra restrictions.
>
> To do that introduce DRM_CLIENT_CAP_VIRTUALIZED_CURSOR_PLANE which
I agree with Pekka that DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT is a better
name for this capability. I don't have a strong opinion though so I am
also OK with the chosen name.
Reviewed-by:
n
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane.c | 3 ---
> include/drm/drm_framebuffer.h | 12
> 2 files changed, 15 deletions(-)
>
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
501 - 600 of 2249 matches
Mail list logo
