or test-merge if you want.
>
Thanks a lot Dave and Daniel!
> And since Dave has given a blanket cheque for handling fallout he'll deal
> with the need for fixups too if there's any.
I also plan to look at any regression that might had been introduced by these.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Thomas,
On 7/20/21 8:38 PM, Thomas Zimmermann wrote:
> Am 20.07.21 um 15:59 schrieb Daniel Vetter:
>> On Tue, Jul 20, 2021 at 03:42:45PM +0200, Javier Martinez Canillas wrote:
>>> On 7/20/21 3:01 PM, Daniel Vetter wrote:
>>>> On Mon, Jul 19, 2021 at 09:10:52
On 7/21/21 12:07 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 21.07.21 um 07:09 schrieb Javier Martinez Canillas:
> ...
>>>
>>> Can I simply put the patches in to drm-misc-next? There was some talk
>>> about a topic branch?
>>>
>>
>> .
his is defined).
Reported-by: kernel test robot
Signed-off-by: Javier Martinez Canillas
---
drivers/firmware/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index af6719cc576..897f5f25c64 100644
--- a/drivers/firmware/K
fers
> support")
>
Yes, this was already reported by the kernel test robot and posted a fix
a few days ago: https://lore.kernel.org/patchwork/patch/1465623/
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
‘sysfb_apply_efi_quirks’ was here
> static inline void sysfb_apply_efi_quirks(struct platform_device *pd)
> ^~
>
> Signed-off-by: Randy Dunlap
> Cc: Ard Biesheuvel
> Cc: linux-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
&
is was defined).
Fixes: d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers
support")
Reported-by: kernel test robot
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Add a Fixes tag to the changelog.
drivers/firmware/Kconfig | 2 +-
1 file changed, 1 in
gic used to be in drivers/firmware/efi/efi-init.c, that's built
in if CONFIG_EFI is enabled. We just consolidated both X86 and EFI:
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8633ef82f101
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
; in if CONFIG_EFI is enabled. We just consolidated both X86 and EFI:
>>
>> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8633ef82f101
>
> Thanks, I'm aware of that commit, as I was just about to reply to it,
> when I saw the patch is this thread ;-)
>
Ok :)
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
more sense to what I did in v1.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_kms_helper_common.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_kms_helper_common.c
b/drivers/gpu/drm/drm_kms_helper_common.c
index f933da1656eb..47e92400548d 100644
--- a/drive
is
also included in this series.
Best regards,
Javier
Javier Martinez Canillas (4):
fbdev: Rename fb_*_device() functions names to match what they do
fbdev: Move framebuffer_{alloc,release}() functions to fbmem.c
fbdev: Split frame buffer support in FB and FB_CORE symbols
drm: Make fbdev e
fs
registration, so move it to the do_register_framebuffer() function which
is where the device is created.
Signed-off-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/fbmem.c | 8 +---
drivers/video/fbdev/core/fbsysfs.c | 6 ++
include/linux/fb.h | 4 ++--
3 f
The framebuffer_alloc() and framebuffer_release() functions are much more
related with the functions in drivers/fbdev/core/fbmem.c than the ones in
drivers/fbdev/core/fbsysfs.c, that are only to manage sysfs attributes.
Signed-off-by: Javier Martinez Canillas
---
drivers/video/fbdev/core
disabled (and automatically disabling all fbdev drivers).
The fbsysfs.o object is left out of fb_core.o, because that's not needed
for KMS drivers and the DRM fbdev emulation layer.
Signed-off-by: Javier Martinez Canillas
---
arch/x86/Makefile | 2 +-
arch/x86/video/Mak
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 all the legacy fbdev drivers.
Signed-off-by: Javier Martinez
ff-by: Javier Martinez Canillas
---
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
index 2fdc455c4ad..e3e5b63fdcc 100644
--- a/drivers/gp
avier Martinez Canillas
---
Changes in v2:
- Move drm_aperture_remove_framebuffers() call to .bind callback (tzimmermann).
- Adapt subject line, commit message, etc accordingly.
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gp
Hello Thomas,
On 5/16/21 12:30 PM, Thomas Zimmermann wrote:
>
>
> Am 16.05.21 um 09:48 schrieb Javier Martinez Canillas:
>> There are drivers that register framebuffer devices very early in the boot
>> process and make use of the existing framebuffer as setup by the firm
On 6/25/21 3:09 PM, Javier Martinez Canillas wrote:
> The simplefb and simpledrm drivers match against a "simple-framebuffer"
> device, but for aarch64 this is only registered when using Device Trees
> and there's a node with a "simple-framebuffer" compatibl
ON_ONCE() message ?
Regardless, the patch looks good to me:
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
list, lru) {
> + list_for_each_entry(pageref, pagelist, list) {
> + struct page *page = pageref->page;
Same here and the other drivers. You only need the page for the index AFAICT.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
s of mmap'ed framebuffer
> memory.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
/O from each other.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
goto err_delete;
>
> @@ -402,6 +406,7 @@ static int drm_client_buffer_addfb(struct
> drm_client_buffer *buffer,
> * @width: Framebuffer width
> * @height: Framebuffer height
> * @format: Buffer format
> + * @fbdev: True if the client provides an fbdev device, or false otherwise
> *
An emulated fbdev device ?
Other than those small nit,
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 3/3/22 21:58, Thomas Zimmermann wrote:
> Add drm_fb_helper_vm_page_mkwrite(), a helper to track pages written
> by fbdev userspace. DRM drivers should use this function to implement
> fbdev deferred I/O.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier
true, args);
> +#else
> + return -ENOSYS;
> +#endif
> +}
I believe the correct errno code here should be -ENOTSUPP.
[snip]
> + /* We don't use vmf->pgoff since that has the fake offset */
> + page_offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
I s
optimize the if branch.
[snip]
> +}
> +#else
> +struct drm_gem_object *virtio_gpu_create_object_fbdev(struct drm_device *dev,
> + size_t size)
> +{
> + return ERR_PTR(-ENOSYS);
> +}
As mentioned, I believe this should be
32e80867 ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: Chen-Yu Tsai
> ---
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
gt; Fixes: a61732e80867 ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: Chen-Yu Tsai
> ---
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ink it's worth
> it, I'd change the drivers as well.
>
Thanks for the explanation. No, I don't think is worth it or at least as
as part of this series.
> Best regards
> Thomas
>
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
acks. AFAICT we never call pin, unpin or get_sg_table.
>
Yeah, that's true too. It was just a suggestion, I'm OK with patch as is.
> Best regards
> Thomas
>
>>
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
https://www.cs.helsinki.fi/linux/linux-kernel/2002-30/1135.html
>
Thanks for the link. It would be good to have an authoritative guideline
about this in the kernel documentation (and make checkpatch.pl aware).
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
)
>> + dst_pitch = DIV_ROUND_UP(linepixels, 8);
>
> This is not correct when clip->x1 is not a multiple of 8 pixels.
> Should be:
>
> DIV_ROUND_UP(linepixels + clip->x1 % 8, 8);
>
Agreed.
>> +
>> + drm_WARN_ONCE(dev, dst_pitch % 8 != 0, "dst_pitch is not a multiple
>> of 8\n");
>
> This triggers for me: dst_pitch = 1.
> Which is perfectly fine, when flashing an 8-pixel wide cursor ;-)
>
Indeed. I think we should just drop that warn.
Do you want me to post patches for all these or would you do it
when simplifying the drm_fb_gray8_to_mono_reversed_line() logic ?
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 3/8/22 17:30, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Mon, Feb 14, 2022 at 2:37 PM Javier Martinez Canillas
> wrote:
>> This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
>> OLED display controllers.
>>
>> It's only the c
h looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ts.
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
>
> Reduce memory consumption by using the actual number of bits per pixel
> instead.
>
> Signed-off-by: Geert Uytterhoeven
> Acked-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ber of bits per pixel instead.
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
rely on proper
> block handling for the calculation of bits per pixel and pitch.
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
_TRUECOLOR;
Other than that the patch looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Signed-off-by: Geert Uytterhoeven
> ---
> RFC, as this code path was untested.
>
Looks good to me but haven't tested either.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
: Geert Uytterhoeven
> ---
Yes, I learned that "Red" actually meant just a color channel
that may not be red in one of the thread about fourcc formats.
So I agree that would be good to have a comment about this.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ion of bits per pixel and pitch.
>
> Signed-off-by: Geert Uytterhoeven
> ---
IIRC the agreement was that it was worth to have both Cx and Rx fourcc
formats separately, so this patch makes sense to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
or 256 darkness levels.
>
> As the number of bits per pixel may be less than eight, some of these
> formats rely on proper block handling for the calculation of bits per
> pixel and pitch.
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Javier Martinez Canillas
--
Bes
Hello Geert,
On 3/9/22 13:56, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Wed, Mar 9, 2022 at 1:14 PM Javier Martinez Canillas
> wrote:
>> On 3/8/22 17:30, Geert Uytterhoeven wrote:
>>> Unfortunately a regression was introduced since your v3: printed
>>> t
splays")
>> Signed-off-by: Chen-Yu Tsai
>
> Thanks, this fixes the vertically-mirrored display on my Adafruit
> FeatherWing 128x32 OLED.
> Tested-by: Geert Uytterhoeven
> Reviewed-by: Geert Uytterhoeven
>
Thanks for the testing and review. I've pushed both patches to drm-misc-next.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ixes...
>
Right, I believe this is a consequence of introducing shadow buffers at
some point and not adjusting the logic in this function.
Thanks a lot for tracking down the issues and working on fixes for them!
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Geert,
On 3/14/22 14:40, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas
> wrote:
>> Add support to convert 8-bit grayscale to reversed monochrome for drivers
>> that control monochromatic displays, that only ha
&& HAS_IOMEM [=y] && DRM [=m]
>
> DRM_GEM_SHMEM_HELPER depends on MMU, DRM_SSD130X should also depends on MMU.
>
> Fixes: a61732e80867 ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: YueHaibing
> ---
Indeed. All the DRM drivers that select
med that the destination
buffer for the OLED panels were also monochrome reversed.
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
e operation.
>
> Update the comments accordingly.
>
> Fixes: bcf8b616deb87941 ("drm/format-helper: Add
> drm_fb_xrgb_to_mono_reversed()")
> Signed-off-by: Geert Uytterhoeven
> ---
Acked-by: Javier Martinez Canillas
I just have a small comment b
> Remove the correction for an unaligned y1 from
> ssd130x_update_rect(), and add a check to make sure y1 is aligned.
>
> Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: Geert Uytterhoeven
> ---
Thanks for fixing
Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: Geert Uytterhoeven
> ---
Indeed. I haven't noticed that got the calculation wrong until you pointed out.
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
888 to
> monochrome conversion")
> Signed-off-by: Geert Uytterhoeven
> ---
> Untested due to lack of hardware.
>
Patch looks good to me but I also don't have this hardware.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 3/15/22 10:18, Javier Martinez Canillas wrote:
> Hello YueHaibing,
>
> Thanks for the patch.
>
> On 3/12/22 07:34, YueHaibing wrote:
>> WARNING: unmet direct dependencies detected for DRM_GEM_SHMEM_HELPER
>> Depends on [n]: HAS_IOMEM [=y] && DRM [
ately. The performance improvements in the original commit do not
> regress by this change.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 6f29e04938bf ("fbdev: Improve performance of sys_imageblit()")
> Cc: Thomas Zimmermann
> Cc: Javier Martinez Canillas
> Cc:
rformance improvements in the original commit do not
> regress by this change.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 0d03011894d2 ("fbdev: Improve performance of cfb_imageblit()")
> Reported-by: Marek Szyprowski
> Cc: Thomas Zimmermann
> Cc: Javier Mart
ut also avoids INIT_LIST_HEAD()
> redundantly.
>
> Fixes: 105a940416fc ("fbdev/defio: Early-out if page is already
> enlisted")
> Cc: Thomas Zimmermann
> Signed-off-by: Chuansheng Liu
> ---
This makes sense to me. If you address Geert comment and post a v2,
feel free to add:
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
m-misc-next) but left patch 5 since
would like to give Noralf the opportunity to review/test before pushing.
By the way, you should probably request commit access to the drm-misc tree:
https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
insertions(+)
>
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Thomas,
On 3/22/22 20:27, Thomas Zimmermann wrote:
> Give the Makefile a bit more structure by putting rules for core,
> helpers, drivers, etc next to each other.
>
> Signed-off-by: Thomas Zimmermann
> ---
This is a nice cleanup.
Reviewed-by: Javier Martinez Canillas
-
y putting code for video-output standards into a local display/
> directory. The new directory's name is aligned with that policy.
>
It is really a policy or just a convention ?
> Signed-off-by: Thomas Zimmermann
> ---
>
Reviewed-by: Javier Martinez Canillas
--
Best re
dp_aux_i2c_transfer_size
I don't know whether those are considered a kernel ABI or not though, and
some already changed when the DP helpers were moved from drm_kms_helper.ko
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
*dst++ = pat;
> - *dst++ = pat;
> - *dst++ = pat;
> - n -= 8;
> - }
> - while (n--)
> - *dst++ = pat;
> + memset_l(dst, pat, n);
> +
Signed-off-by: Thomas Zimmermann
> ---
This patch looks good to me as well.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
sted in the quirk table,
> to make the fbcon (and aware userspace apps) rotate the image to
> display properly.
>
> Cc: Javier Martinez Canillas
> Signed-off-by: Hans de Goede
> ---
The patch looks good to me. Thanks a lot for fixing this
Reviewed-by: Javier Martinez Canillas
vers/gpu/drm/drm_modeset_helper.c or a drm_modeset_quirks.c
like we have for drivers/gpu/drm/drm_panel_orientation_quirks.c ?
The patch looks good to me, regardless where you decide to add it.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
t; so the quirk handling uses the display resolution to detect the model.
>
> Signed-off-by: Hans de Goede
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
confusing
and probably we should change it at some point...
Patch itself looks good to me though.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
plefb in legacy BIOS boot mode" and that isn't
accurate AFAIU (unless you meant sysfb instead).
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 2/23/22 17:54, Javier Martinez Canillas wrote:
> On 2/23/22 17:45, Michal Suchánek wrote:
>
> [snip]
>
>>>>
>>>> To enable use of VESA modes with simplefb in legacy BIOS boot mode drop
>>>
>>> I think you meant "VESA modes with the sy
On 2/23/22 18:12, Michal Suchánek wrote:
> On Wed, Feb 23, 2022 at 05:54:54PM +0100, Javier Martinez Canillas wrote:
[snip]
>>
>> Yes, that's what I tried to say. But your commit message says "To enable
>> use of VESA modes with simplefb in legacy BIOS boot mode&qu
since
a "simple-framebuffer" platform device could be registered by OF if a
Device Tree node with compatible "simple-framebuffer" exists).
Best regards, --
Javier Martinez Canillas
Linux Engineering
Red Hat
There is now a drm_fb_xrgb_to_mono_reversed() helper function to do
format conversion from XRGB to reversed monochrome.
Use that helper and remove the open coded version in the repaper driver.
Signed-off-by: Javier Martinez Canillas
---
This was only built tested because I don't
On 2/23/22 20:38, Thomas Zimmermann wrote:
> Fix coding style. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
imized case, cfb_imageblit() is now ~2x faster than before.
>
> v3:
> * fix commit description (Pekka)
>
> Signed-off-by: Thomas Zimmermann
> ---
Makes sense, improves perf and makes the two more consistent as you mention.
Reviewed-by: Javier Martinez Canillas
Best re
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
[0]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Daniel,
On 2/24/22 13:59, Daniel Vetter wrote:
> Some things changed, and add two useful links.
>
> Cc: Javier Martinez Canillas
> Cc: Pekka Paalanen
> Cc: gpicc...@igalia.com
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 21 +--
Hello Noralf,
On 2/24/22 15:04, Noralf Trønnes wrote:
>
>
> Den 23.02.2022 20.37, skrev Javier Martinez Canillas:
>> There is now a drm_fb_xrgb_to_mono_reversed() helper function to do
>> format conversion from XRGB to reversed monochrome.
>>
>> Use that
tions(+)
>
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
f-by: Michal Suchanek
> ---
Thanks for the patch. This makes much more sense to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
on it.
>
> The BOOT_VESA_SUPPORT is not specific to framebuffer but rather to x86
> platform, move it from fbdev to x86 Kconfig.
>
> Fixes: e3263ab389a7 ("x86: provide platform-devices for boot-framebuffers")
> Signed-off-by: Michal Suchanek
> Acked-by: Borislav
On 2/25/22 21:51, Michal Suchanek wrote:
> efifb is the only user of efifb_setup_from_dmi which is provided by
> sysfb which is selected by efifb. That makes the stub redundant.
>
> Signed-off-by: Michal Suchanek
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Hello Colin,
Thanks for the patch.
On Wed, Mar 2, 2022 at 6:53 PM Colin Ian King wrote:
>
> Pointer mode is being assigned a value that is never read, it is
> being re-assigned later with a new value. The initialization is
> redundant and can be removed.
>
Indeed.
Acked-by:
merge.
>
The v4 patches looks good to me and have provided my Reviewed-by to all of them.
> Thanks
>
> Michal
>
>>
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 3/2/22 19:29, Javier Martinez Canillas wrote:
> Hello Colin,
>
> Thanks for the patch.
>
> On Wed, Mar 2, 2022 at 6:53 PM Colin Ian King wrote:
>>
>> Pointer mode is being assigned a value that is never read, it is
>> being re-assigned later with a
> Thomas
>
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 3/4/22 21:47, Javier Martinez Canillas wrote:
> Hello Thomas,
>
> On 3/4/22 21:00, Thomas Zimmermann wrote:
>> Hi,
>>
>> I've merged the patches into drm-misc-fixes. Thanks a lot to both of you.
>>
>
> Ard already picked these through the efi tre
o displaying
> on the screen. Watching a video on the fbdev console felt smoother and
> had less flickering.
>
Awesome. And you also answered here the question I had above.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
?
Anyway, just wanted to mention in case I forget later.
Your patch looks good to me and I think it could be pushed
without waiting for the other patches in the series.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 3/8/22 10:56, Thomas Zimmermann wrote:
> Hi
>
> Am 08.03.22 um 10:31 schrieb Javier Martinez Canillas:
>> On 3/3/22 21:58, Thomas Zimmermann wrote:
>>> Don't select shadow buffering for the fbdev console explicitly. The
>>> fbdev emulation's heuris
Hello Daniel and Thomas,
On 8/27/21 10:20 PM, Daniel Vetter wrote:
> On Fri, Aug 27, 2021 at 07:50:23PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 27.08.21 um 12:00 schrieb Javier Martinez Canillas:
>>> This patch series splits the fbdev core support in two dif
On 8/31/21 2:35 PM, Daniel Vetter wrote:
> On Sat, Aug 28, 2021 at 12:02:21AM +0200, Javier Martinez Canillas wrote:
[snip]
>>
>> We talked about a drmcon with Peter Robinson as well but then decided that a
>> way to disable CONFIG_FB but still having the DRM fbdev
query that information and so broke after the mentioned commit. Since
the names in /proc/fb are used programs that consider it an ABI, let's
restore the old names even when this lead to silly naming like the one
mentioned above as an example.
Reported-by: Johannes Stezenbach
Signed-off-by: Javier Ma
...
>
Sure, I'll do that and send a v2.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
ulation device names")
Reported-by: Johannes Stezenbach
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Ville Syrjälä
---
Changes in v2:
- Add a comment explaining that the current /proc/fb names are an uAPI.
- Add a Fixes: tag so it can be cherry-picked by stable kernels.
- Add Ville
this could be implemented.
Suggested-by: Neal Gompa
Signed-off-by: Javier Martinez Canillas
---
Hello,
I'm sending this as an RFC because I wasn't sure about the correct name for
this module parameter, and also if 'remove_fb=0' is intitutive or instead a
parameter th
Hello Neal,
Thanks for your feedback.
On 10/22/21 16:56, Neal Gompa wrote:
> On Fri, Oct 22, 2021 at 10:40 AM Javier Martinez Canillas
> wrote:
>>
>> The simpledrm driver allows to use the frame buffer that was set-up by the
>> firmware. This gives early video output
1 - 100 of 2365 matches
Mail list logo
