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
> Cc: David Airlie
> Cc: Gurchetan Singh
> Cc: Chia-I Wu
> Cc: Daniel Vetter
> Cc: virtualizat...@lists.linux-foundation.org
> ---
> drivers/gpu/drm/virtio/virtgpu_plane.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
Reviewed-by: Javier Martinez Canillas
Airlie
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/vboxvideo/vbox_mode.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
: Dave Airlie
> Cc: Daniel Vetter
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
Reviewed-by: Javier Martinez Canillas
ombasawala
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
ve in
> e.g.
> https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#plane-composition-properties
>
> Otherwise looks fine to me. Could drm_plane_create_hotspot_properties()
> perhaps assert that the plane type is CURSOR?
>
I thought the same when reviewing but then I noticed this function is only
called from __drm_universal_plane_init() if type is DRM_PLANE_TYPE_CURSOR.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
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
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
, disable cursor planes
> + * because they'll be broken due to missing cursor
> + * hotspot info.
> + */
> + if (plane->type == DRM_PLANE_TYPE_CURSOR &&
> + drm_core_check_feature(dev, DRIVER_CURSOR_HOTSPOT) &&
Nit: you have a tab instead of an space before && but this can just be
fixed when applying.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
rm-misc (drm-misc-next). Thanks!
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König|
> Industrial Linux Solutions | https://www.pengutronix.de/ |
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Zack Rusin writes:
[adding Aleix Pol from KDE/kwin to Cc list]
Hello Zack,
> On Wed, 2023-06-21 at 09:10 +0200, Javier Martinez Canillas wrote:
[...]
>> >
>> > Hi all,
>> >
>> > We have been testing the v2 of this patch and it works corre
dded an IGT test as suggested above:
> https://gitlab.freedesktop.org/aesteve/igt-gpu-tools/-/compare/master...modeset-cursor-hotspot-test?from_project_id=1274
>
> I could post the IGT patch upstream once Zack's patches land.
>
Zack, are you planning to re-spin the series soon? Otherwise Albert could
continue working on that if you prefer.
> Hope that helps!
>
> -Albert
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Javier Martinez Canillas writes:
> Hello,
>
> While working on adding support for the SSD132X family of 4-bit grayscale
> Solomon OLED panel controllers, I noticed a few things in the driver that
> can be improved and make extending to support other chip families easier.
Conor Dooley writes:
> On Mon, Jun 12, 2023 at 09:47:12AM +0200, Thomas Zimmermann wrote:
>> Am 11.06.23 um 01:18 schrieb Javier Martinez Canillas:
>
>> > But I will be OK to drop the "solomon,ssd130?fb-i2c" compatible strings
>> > from the DRM driver
lse needs to provide review here.
>
And same for these.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
Hello Thomas,
> Hi Javier
>
> Am 08.06.23 um 00:22 schrieb Javier Martinez Canillas:
>> Thomas Zimmermann writes:
>>
>>> Detect registered instances of fb_info by reading the reference
>>> counter from struct fb_inf
convert back to (the new) .probe() to be able to eventually drop
> .probe_new() from struct i2c_driver.
>
> Signed-off-by: Uwe Kleine-König
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Conor Dooley writes:
> On Sat, Jun 10, 2023 at 07:51:35PM +0200, Javier Martinez Canillas wrote:
>> Conor Dooley writes:
>>
>> > On Fri, Jun 09, 2023 at 07:09:37PM +0200, Javier Martinez Canillas wrote:
>> >> A default resolution in the ssd130x dr
Conor Dooley writes:
> On Fri, Jun 09, 2023 at 07:09:37PM +0200, Javier Martinez Canillas wrote:
>> A default resolution in the ssd130x driver isn't set to an arbitrary 96x16
>> anymore. Instead is set to a width and height that's controller dependent.
>
> Did that change to
to
compute the size of the buffer, used to store the pixels in native format.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
---
(no changes since v1)
drivers/gpu/drm/solomon/ssd130x.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers
and teardown operations are done.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
---
(no changes since v1)
drivers/gpu/drm/solomon/ssd130x.c | 88 +++
drivers/gpu/drm/solomon/ssd130x.h | 3 ++
2 files changed, 56 insertions(+), 35 deletions(-)
diff
Matrix OLED/PLED
- SSD1306: 128 x 64 Dot Matrix OLED/PLED
- SSD1307: 128 x 39 Dot Matrix OLED/PLED
- SSD1309: 128 x 64 Dot Matrix OLED/PLED
Update DT schema to reflect what the driver does and make its users aware.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
---
Changes
The driver only supports OLED controllers that have a page height of 8 but
there are devices that have different page heights. So it is better to not
hardcode this value and instead have it as a per controller data value.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
- SSD1306: 128 x 64 Dot Matrix OLED/PLED
- SSD1307: 128 x 39 Dot Matrix OLED/PLED
- SSD1309: 128 x 64 Dot Matrix OLED/PLED
Add this information to the devices' info structures, and use it set as a
default if not defined in DT rather than hardcoding to an arbitrary value.
Signed-off-by: Javier Martinez
the actual
SSD132X support as a separate patch-set once this one is merged.
Best regards,
Javier
Changes in v2:
- List per controller default width/height values in DT schema (Maxime Ripard).
Javier Martinez Canillas (5):
drm/ssd130x: Make default width and height to be controller dependent
dt
ONFIG_FB_DEVICE. I think that there's value
on a FB_CORE option to allow disabling all the fbdev drivers with a single
option but still keep DRM_FBDEV_EMULATION enabled.
But I can repost my old series on top of this patch-set once it lands.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
RM drivers,
fbdev drivers, DRM emulation for fbcon and emulation for fbdev user-space.
And I think that Thomas' series + a FB_CORE as you suggested and done in
my old series should be enough to have that.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
ojects I will probably keep it enabled.
That's why I think that we should support the following combinations:
* fbdev drivers + DRM fbdev emulation + fbdev user-space
* only DRM drivers without fbdev emulation nor fbdev user-space (your series)
* only DRM fbdev emulation + fbdev user-space enabled (FB_CORE)
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
e 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.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
vers/video/fbdev/core/fb_devfs.c:183:9: error: unknown type name
'compat_caddr_t'
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
n
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
is
change is for an old fbdev driver anyways.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> Fix case were dev_err() is being called with struct fb_info.dev.
> Use fb_err() instead.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
c: Antonino Daplas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Antonino Daplas
> ---
Reviewed-by: Javier Martine
amin Herrenschmidt
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
amin Herrenschmidt
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> Do not assign the hardware device to struct fb_info.dev. The
> field references the fbdev software device, which is unrelated.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martine
c: Antonino Daplas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Antonino Daplas
> ---
Reviewed-by: Javier Martine
rm() with the rest of the driver and
> prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> Fix cases were output helpers are called with struct fb_info.dev.
> Use fb_dbg() and fb_err() instead. Prepares fbdev for making struct
> fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
device's reference counter and leaks the fbdev device.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> Fix cases were output helpers are called with struct fb_info.dev.
> Use fb_info() and fb_err() instead.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
eviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
n
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
y: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards
y: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards
ng to struct fb_info.device.
>
> Fixes a bug in the backlight driver and prepares fbdev for making
> struct fb_info.dev optional.
>
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
the check fix and rename
could be split in separate patches to make it easier to understand what
is changed. Regardless, feel free to add:
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
_info.device.
>
> Fixes a bug in the backlight driver and prepares fbdev for making
> struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> ---
Reviewed-by: Javier Martinez Canillas
--
Best
,
the issue is already present in the driver. We could fix it as follow-up.
> Best regards
> Thomas
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
on name.
>
> Signed-off-by: Maíra Canal
> ---
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
Maxime Ripard writes:
Hello Maxime,
Thanks for your feedback.
> Hi,
>
> On Mon, Jun 05, 2023 at 09:47:50AM +0200, Javier Martinez Canillas wrote:
[...]
>>solomon,width:
>> $ref: /schemas/types.yaml#/definitions/uint32
>> -default: 96
>> desc
to
compute the size of the buffer, used to store the pixels in native format.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon
and teardown operations are done.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x.c | 88 +++
drivers/gpu/drm/solomon/ssd130x.h | 3 ++
2 files changed, 56 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers
- SSD1307: 128 x 39 Dot Matrix OLED/PLED
- SSD1309: 128 x 64 Dot Matrix OLED/PLED
Add this information to the devices' info structures, and use it set as a
default if not defined in DT rather than hardcoding to an arbitrary value.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon
The driver only supports OLED controllers that have a page height of 8 but
there are devices that have different page heights. So it is better to not
hardcode this value and instead have it as a per controller data value.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon
A default resolution in the ssd130x driver isn't set to an arbitrary 96x16
anymore. Instead is set to a width and height that's controller dependent.
Update DT schema to reflect what the driver does and make its users aware.
Signed-off-by: Javier Martinez Canillas
---
.../devicetree/bindings
the actual
SSD132X support as a separate patch-set once this one is merged.
Best regards,
Javier
Javier Martinez Canillas (5):
drm/ssd130x: Make default width and height to be controller dependent
dt-bindings: display: ssd1307fb: Remove default width and height
values
drm/ssd130x: Set
[1] and all you need is a GPU for a
> non-converted driver (again virtual HW drivers for KVM are still all
> -suitable).
Are any of the virtual drivers not yet ported to atomic? This sentence
seems to be outdated and maybe you could remove it on a following patch?
Reviewed-by: Javier Martinez C
I strongly second what Kieran just said. I was also involved in the commit
mentioned and it is so great to see your efforts to finish that change.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
n
> assignment (different address spaces)
> ../drivers/gpu/drm/msm/msm_fbdev.c:124:26:expected char [noderef] __iomem
> *screen_base
> ../drivers/gpu/drm/msm/msm_fbdev.c:124:26:got void *
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Hello Sui,
I would still add something to the commit description even when your
changes are trivial.
Sui Jingfeng writes:
> Signed-off-by: Sui Jingfeng
> ---
The fixes look good to me though
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Pla
Sui Jingfeng <15330273...@189.cn> writes:
> Reviewed-by: Sui Jingfeng
>
>
Pushed to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
this one.
Pushed to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
This is a leftover from an early iteration of the driver when it was still
named ssd1307 instead of ssd130x. Change it for consistency with the rest.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
Maíra Canal writes:
> I've been contributing to VKMS with improvements, reviews, testing and
> debugging. Therefore, add myself as a co-maintainer of the VKMS driver.
>
> Signed-off-by: Maíra Canal
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martine
Zack Rusin writes:
> On Tue, 2023-05-02 at 11:32 +0200, Javier Martinez Canillas wrote:
>> !! External Email
>>
>> Daniel Vetter writes:
>>
>> > On Mon, Jul 11, 2022 at 11:32:39PM -0400, Zack Rusin wrote:
>> > > From: Zack Rusin
>>
derstanding the above it the preferred way to do it.
>
> Where did youher this? I only know about this in the case of asm/io.h
> vs. linux/io.h.
>
I understand that's the case too. I believe even checkpatch.pl complains
about it? (not that the script always get right, but just as an example).
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
dom pile of midlayer-mistake driver flags" would be a lot better.
>
> Otherwise I think the series looks roughly how I'd expect it to look.
> -Daniel
>
AFAICT this is the only remaining thing to be addressed for this series ?
Zack, are you planning to re-spin a v3 of this patch-set? Asking because
we want to take virtio-gpu out of the atomic KMS deny list in mutter, but
first need this to land.
If you think that won't be able to do it in the short term, Bilal (Cc'ed)
or me would be glad to help with that.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
framebuffer is stored in I/O memory,
> or info->screen_buffer if the framebuffer is stored in system memory.
>
> As the driver operates on the latter address space, it is wrong to use
> .screen_base and .screen_buffer must be used instead.
>
> Signed-off-by: Thomas Zimmermann
&g
due to not using the correct data type.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
due to not using the correct data type.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
framebuffer is stored in I/O memory,
> or info->screen_buffer if the framebuffer is stored in system memory.
>
> As the driver operates on the latter address space, it is wrong to use
> .screen_base and .screen_buffer must be used instead.
>
> Signed-off-by: Thomas Zimmermann
&g
due to not using the correct data type.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
due to not using the correct data type.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
due to not using the correct data type.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
due to not using the correct data type.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
due to not using the correct data type.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
due to not using the correct data type.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
due to not using the correct data type.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
due to not using the correct data type.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
due to not using the correct data type.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
---
> 1 file changed, 4 insertions(+), 170 deletions(-)
>
Very nice cleanup!
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
I guess you are doing this because is going to be used
in DRM but still would be good to explain it in the commit message.
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
een_buffer must be used
instead. This also get rids of all the casting needed due not using the
correct data type."
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tests/fbdev.c
> # 1
> ---
The patch looks good to me and indeed the correct semantics AFAICT.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Maxime Ripard writes:
> Hi Javier,
>
> On Sat, Apr 22, 2023 at 07:26:13AM +0200, Javier Martinez Canillas wrote:
>> Maxime Ripard writes:
>> > container_of_const() allows to preserve the pointer constness and is
>> > thus more flexible than inline function
es from Greg all over the kernel
that do exactly this, dropping static inline functions in favor of using
container_of_const() directly. So it seems the convention is what you do.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
selection")
> Signed-off-by: Pierre Asselin
> ---
[...]
> + bits_per_pixel= max(bits_per_pixel, (u32)si->lfb_depth);
You are missing a space here.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
rmada. If the fbdev framebuffer
> has been fully set up, struct fb_ops.fb_destroy implements the
> release. For partially initialized emulation, the fbdev client
> reverts the initial setup.
>
> Signed-off-by: Thomas Zimmermann
> ---
>
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
with the system framebuffer. Messing with the
> stride would break them.
>
I see, is not that simple then. Thanks a lot for the clarification.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
cualted. That's why I mentioned that we need Pierre's fix +
my patch [1] that did:
stride = DIV_ROUND_UP(si->lfb_width * bits_per_pixel, 8)
But calculating a BPP yet blindly using linelength doens't make sense to me.
[1]: https://lists.freedesktop.org/archives/dri-devel/2023-April/399963.html
[2]:
https://lore.kernel.org/dri-devel/dfb4f25ca8dfb0d81d778d6315f104ad.squir...@mail.panix.com/
[3]: https://lists.freedesktop.org/archives/dri-devel/2023-April/400088.html
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
601 - 700 of 2250 matches
Mail list logo
