> > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > b/drivers/gpu/drm/virtio/virtgpu_drv.c
> > index e32e680c7197..71c6ccad4b99 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> > @@ -130,10 +130,10 @@ static void virtio_gpu_remove(struct
Calling drm_dev_unplug() is the drm way to say the device
is gone and can not be accessed any more.
Cc: Michael S. Tsirkin
Signed-off-by: Gerd Hoffmann
Reviewed-by: Eric Auger
Tested-by: Eric Auger
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 8
1 file changed, 4 insertions(+), 4
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > b/drivers/gpu/drm/virtio/virtgpu_drv.c
> > index e32e680c7197..71c6ccad4b99 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> > @@ -130,10 +130,10 @@ static void virtio_gpu_remove(struct
On Tue, Apr 15, 2025 at 10:00:48AM -0400, Michael S. Tsirkin wrote:
> On Tue, Apr 15, 2025 at 01:16:32PM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > +static void virtio_gpu_shutdown(struct virtio_device *vdev)
> > > +{
> > > + /*
> > >
Hi,
> +static void virtio_gpu_shutdown(struct virtio_device *vdev)
> +{
> + /*
> + * drm does its own synchronization on shutdown.
> + * Do nothing here, opt out of device reset.
> + */
I think a call to 'drm_dev_unplug()' is what you need here.
take care,
Gerd
On Tue, Apr 01, 2025 at 04:01:51PM +0300, Dmitry Osipenko wrote:
> I was helping to co-maintain VirtIO-GPU driver in drm-misc with
> permission from Gerd Hoffmann for past 2 years and would like to
> receive new patches directly into my inbox. Add myself as co-maintainer.
>
>
iving a reviewed-by due to not
following drm development very closely any more, so
Acked-by: Gerd Hoffmann
> > Second, because there is no way to communicate the hardware constrains
> > of the cirrus. userspace can query the formats, and userspace can query
> > the resolutions, bu
On Tue, Mar 25, 2025 at 06:12:51PM +0100, Thomas Zimmermann wrote:
> Remove internal adjustments to framebuffer format from cirrus-qemu
> driver. The driver did this to support higher resolutions by reducing
> the per-pixel memory consumption.
>
> DRM has a policy of exporting formats as they are
On Sat, Nov 23, 2024 at 06:28:30PM +0200, Dmitry Baryshkov wrote:
> On Tue, Oct 29, 2024 at 03:34:23PM +0100, Thomas Zimmermann wrote:
> > The cirrus driver only works on emulated Cirrus hardware. Use the
> > correct types for encoder and connector.
> > connector = &cirrus->connector;
> >
On Thu, Nov 21, 2024 at 09:25:11AM +0100, Thomas Zimmermann wrote:
> ping ping
> >drm/cirrus: Use virtual encoder and connector types
> >drm/cirrus: Rename to cirrus-qemu
Hmm, matter of taste. I would not have invested that effort, but I have
no objections either. So:
Hi,
> > +static int virtio_gpu_deferred_create(struct virtio_gpu_object *bo,
> > + struct virtio_gpu_device *vgdev,
> > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > +{
> > + struct virtio_gpu_object_params params = { 0 };
> > +
On Tue, Sep 03, 2024 at 09:48:27AM GMT, Jocelyn Falempe wrote:
> On big endian machine, fbdev wants BGRX, but gnome/wayland wants
> XRGB, which wasn't possible because virtio-gpu could only support
> one format. Now that it's fixed, it can support both.
Reviewed-by: G
return -EINVAL;
}
I think this should not happen, because non-dumb buffers are only
created with virgl being active. Nevertheless we should catch this
case and return an error, maybe even have a WARN_ONCE() there.
Otherwise looks good to me, so with that fixed:
Reviewed-by: Gerd Hoffmann
take care,
Gerd
On Fri, Aug 23, 2024 at 05:35:39PM GMT, Jocelyn Falempe wrote:
> On 23/08/2024 09:04, Gerd Hoffmann wrote:
> > > +static void virtio_gpu_deferred_create(struct virtio_gpu_object *bo,
> > > +struct vir
Hi,
> > So this probably makes sense, but I'd like to see a bit more background
> > information ...
>
> The difference is in damage handling.
>
> The old code had two BOs in video memory and flipped between them. IDK the
> details of the old rendering, but from the massive flickering of the cu
efault display resolution (1280x800). For FullHD vram size should be
doubled (-device VGA,vgamem_mb=32).
Skimmed the other patches, looks sane overall, but I don't follow drm
close enough any more to do an full review. So I leave this here:
Acked-by: Gerd Hoffmann
take care,
Gerd
> +static void virtio_gpu_deferred_create(struct virtio_gpu_object *bo,
> +struct virtio_gpu_device *vgdev,
> +const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + struct virtio_gpu_object_params params = { 0 };
> +
> + pa
odules), that are primary users of udmabuf driver.
>
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Signed-off-by: Vivek Kasireddy
Acked-by: Gerd Hoffmann
On Tue, Aug 20, 2024 at 11:07:40AM GMT, Jocelyn Falempe wrote:
> Mesa doesn't support BGRX, that means most wayland compositors
> don't work on big endian guests.
So you are doing a hard switch from native endian to little endian.
While this should be fine for modern userspace API (aka ADDFB2
On Tue, Aug 20, 2024 at 11:07:41AM GMT, Jocelyn Falempe wrote:
> The colors are inverted when testing a s390x VM on a s390x host.
> Changing the conversion from DRM_FORMAT -> VIRTIO_GPU_FORMAT on big
> endian guests fixes the colors. But it may break big-endian guest on
> little-endian host. In thi
testing the series is easier
that way ...
Acked-by: Gerd Hoffmann
take care,
Gerd
ts for main plane and cursor plane to XR24/BX24 resp.
> AR24/BA24.
>
> Fixes: 6ae2ff23aa43a0c4 ("drm/client: Convert drm_client_buffer_addfb() to
> drm_mode_addfb2()")
> Reported-by: Christian Zigotzky
> Closes:
> https://lore.kernel.org/r/c47fba21-3ae9-4021-9f4a-09c2670eb...@xenosoft.de
> Suggested-by: Gerd Hoffmann
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Gerd Hoffmann
On Wed, Nov 15, 2023 at 09:33:28AM +0100, Geert Uytterhoeven wrote:
> Hi Christian,
>
> CC virtgpu
>
> On Tue, Nov 14, 2023 at 10:45 AM Christian Zigotzky
> wrote:
> > On 13 November 2023 at 01:48 pm, Geert Uytterhoeven wrote:
> > > I can confirm there is no graphics output with m68k/virt, and
>
help with a later removal. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
027784-1-junxiao.ch...@intel.com/
>
> Fixes: 16c243e99d33 ("udmabuf: Add support for mapping hugepages (v4)")
> Cc:
> Signed-off-by: Mike Kravetz
Acked-by: Gerd Hoffmann
On Mon, May 15, 2023 at 10:04:42AM -0700, Mike Kravetz wrote:
> On 05/12/23 16:29, Mike Kravetz wrote:
> > On 05/12/23 14:26, James Houghton wrote:
> > > On Fri, May 12, 2023 at 12:20 AM Junxiao Chang
> > > wrote:
> > >
> > > This alone doesn't fix mapcounting for PTE-mapped HugeTLB pages. You
>
Hi,
> > There is also a direct and hard coded use in cirrus.c which according to
> > the comment is only necessary during resume. Let's just skip this as
> > for example s390 which doesn't have I/O port support also doesen't
> > support suspend/resume.
>
> I think we should consider making cir
Can't spot any issues, but I also don't follow drm close
enough to be able to review the sync object logic in detail.
Acked-by: Gerd Hoffmann
take care,
Gerd
> Don't enable it for the cursor plane, because its .atomic_update callback
> doesn't handle damage clips.
>
> Reported-by: Christian Hergert
> Signed-off-by: Javier Martinez Canillas
Acked-by: Gerd Hoffmann
"has_edid" under the "num_scanouts" condition, like was
> suggested by Gerd Hoffmann.
Acked-by: Gerd Hoffmann
> +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
> @@ -45,9 +45,11 @@ static void virtio_gpu_config_changed_work_func(struct
> work_struct *work)
> if (events_read & VIRTIO_GPU_EVENT_DISPLAY) {
> if (vgdev->has_edid)
> virtio_gpu_cmd_get_edids(vgdev);
> -
ly-out of
> it's init/fini fxns instead
Reviewed-by: Gerd Hoffmann
On Thu, Mar 02, 2023 at 12:39:33AM +0300, Dmitry Osipenko wrote:
> On 3/1/23 21:54, Rob Clark wrote:
> > /* virtgpu_display.c */
> > +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS)
> > int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev);
> > void virtio_gpu_modeset_fini(struct virtio_gpu_device
Hi,
> + if (vgdev->num_scanouts) {
> + ret = virtio_gpu_modeset_init(vgdev);
The call to virtio_gpu_modeset_fini() in the unregister
code path needs this too.
Otherwise the patch looks good to me, so with that fixed:
Acked-by: Gerd Hoffmann
take care,
Gerd
On Wed, Mar 01, 2023 at 03:37:24AM +0300, Dmitry Osipenko wrote:
> On 2/28/23 18:54, Rob Clark wrote:
> > From: Rob Clark
> >
> > Add a build option to disable modesetting support. This is useful in
> > cases where the guest only needs to use the GPU in a headless mode, or
> > (such as in the Cr
Hi,
> + if (!vgdev->num_scanouts) {
> + /*
> + * Having an EDID but no scanouts is non-sensical,
> + * but it is permitted to have no scanouts and no
> + * EDID (in which case DRIVER_MODESET and
> +
On Mon, Feb 27, 2023 at 07:40:11AM -0800, Rob Clark wrote:
> On Sun, Feb 26, 2023 at 10:38 PM Gerd Hoffmann wrote:
> >
> > On Fri, Feb 24, 2023 at 10:02:24AM -0800, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Add a build option to disab
On Fri, Feb 24, 2023 at 10:02:24AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Add a build option to disable modesetting support. This is useful in
> cases where the guest only needs to use the GPU in a headless mode, or
> (such as in the CrOS usage) window surfaces are proxied to a host
> com
On Mon, Feb 20, 2023 at 03:22:03PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 16.02.23 um 12:33 schrieb Gerd Hoffmann:
> > On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote:
> > > Set the VGA bit for unblanking with macro constants instead of magic
>
On Thu, Feb 16, 2023 at 02:52:51PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 16, 2023 at 01:03:02PM +0100, Thomas Zimmermann wrote:
> > Hi,
> >
> > thanks for taking a look at the patches.
> >
> > Am 16.02.23 um 12:33 schrieb Gerd Hoffmann:
> > > On Wed
On Thu, Feb 16, 2023 at 01:03:02PM +0100, Thomas Zimmermann wrote:
> Hi,
>
> thanks for taking a look at the patches.
>
> Am 16.02.23 um 12:33 schrieb Gerd Hoffmann:
> > On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote:
> > > Set the VGA bit for u
On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote:
> Set the VGA bit for unblanking with macro constants instead of magic
> values. No functional changes.
blank/unblank should work simliar to bochs (see commit 250e743915d4),
that is maybe a nice thing to add of you modernize the dr
wo patches that are making minor fixes,
> > for consistency.
>
> Do you have comments on this version? Otherwise ack will be appreciated.
> Thanks in advance!
Don't feel like signing off on the locking changes, I'm not that
familiar with the drm locking rules. So someone else looking at them
would be good. Otherwise the series and specifically the virtio changes
look good to me.
Acked-by: Gerd Hoffmann
take care,
Gerd
On Thu, Jan 26, 2023 at 03:24:30PM +0300, Dmitry Osipenko wrote:
> On 1/26/23 15:17, Gerd Hoffmann wrote:
> > On Mon, Jan 09, 2023 at 12:04:40AM +0300, Dmitry Osipenko wrote:
> >> its own refcounting of vmaps, use it instead of drm-shmem
> >> counting. This change prep
marked BOs on
> OOM, the shrinker will also evict unpurgeable shmem BOs from memory if
> guest supports SWAP file or partition.
>
> Signed-off-by: Daniel Almeida
> Signed-off-by: Dmitry Osipenko
Acked-by: Gerd Hoffmann
On Mon, Jan 09, 2023 at 12:04:40AM +0300, Dmitry Osipenko wrote:
> its own refcounting of vmaps, use it instead of drm-shmem
> counting. This change prepares drm-shmem for addition of memory shrinker
> support where drm-shmem will use a single dma-buf reservation lock for
> all operations performe
On Mon, Jan 09, 2023 at 12:04:39AM +0300, Dmitry Osipenko wrote:
> f a multi-GPU system by using drm_WARN_*() and
> drm_dbg_kms() helpers that print out DRM device name corresponding
> to shmem GEM.
That commit message looks truncated ...
take care,
Gerd
Hi,
> > > I think we need to do a bit of refactoring/documenting here first.
> > [Kasireddy, Vivek] Just for reference, here is Dave's commit that added this
> > property for qxl:
> > commit 4695b03970df378dcb93fe3e7158381f1e980fa2
> > Author: Dave Airlie
> > Date: Fri Oct 11 11:05:00 2013 +1
Hi,
> +static void virtio_gpu_update_output_position(struct virtio_gpu_output
> *output)
> +{
> + struct drm_connector *connector = &output->conn;
> + struct drm_device *dev = connector->dev;
> +
> + drm_object_property_set_value(&connector->base,
> + dev->mode_config.su
On Fri, Jan 06, 2023 at 10:35:15AM +0100, Daniel Vetter wrote:
> On Fri, Jan 06, 2023 at 09:56:40AM +0100, Gerd Hoffmann wrote:
> > On Thu, Nov 17, 2022 at 05:30:54PM -0800, Vivek Kasireddy wrote:
> > > Setting this property will allow the userspace to look for new modes or
&
On Thu, Nov 17, 2022 at 05:30:54PM -0800, Vivek Kasireddy wrote:
> Setting this property will allow the userspace to look for new modes or
> position info when a hotplug event occurs.
This works just fine for modes today.
I assume this is this need to have userspace also check for position
info u
Hi,
> > Supporting 16 bpp in the driver wouldn't be that much of a problem, but
> > processing the framebuffer on the host side when emulating a big endian
> > guest on a little endian host is painful. I think I can't ask pixman to
> > do a conversation from DRM_FORMAT_RGB565 | DRM_FORMAT_BIG_E
Hi,
> > > +#ifdef __BIG_ENDIAN
> >
> > Why do we need the #ifdef here? Iirc some hw has big endian flags in the
> > scanout registers, so could supprt this unconditionally if there's no
> > #ifdef around the format defines. Some drivers might then also want a
> > DRM_FORMAT_FOO_BE define to simp
On Wed, Sep 07, 2022 at 05:44:23PM +0800, Zongmin Zhou wrote:
>
> From: Zongmin Zhou
>
> Details:
> Currently, when trying to suspend and resume with qxl device，
> there are some error messages after resuming,
> eventually caused to black screen and can't be recovered.
[ analysis snipped ]
> L
On Wed, Aug 31, 2022 at 12:06:01PM -0700, Chia-I Wu wrote:
> Without this, the drm core advertises LINEAR modifier which is
> incorrect.
>
> Also userspace virgl does not support modifiers. For example, it causes
> chrome on ozone/drm to fail with "Failed to create scanout buffer".
>
> Fixes: 2a
versions (edk2
fix is on the way too). Doesn't happen in BIOS mode because in that
case the vgabios already flips the bit.
Fixes: 250e743915d4 ("drm/bochs: Add screen blanking support")
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/tiny/bochs.c | 2 ++
1 file changed, 2 insertions(+
ported-by: syzbot+c80e9ef5d8bb45894...@syzkaller.appspotmail.com
> Cc: Gerd Hoffmann
> Signed-off-by: Vivek Kasireddy
Pushed to drm-misc-next.
thanks,
Gerd
On Fri, Aug 12, 2022 at 03:40:00PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> When VIRTGPU_EXECBUF_RING_IDX is used, we should be considering the
> timeline that the EB if running on rather than the global driver fence
> context.
>
> Fixes: 85c83ea915ed ("drm/virtio: implement context init: a
On Wed, Jul 06, 2022 at 10:22:52AM +0300, Dmitry Osipenko wrote:
> On 7/6/22 10:13, Gerd Hoffmann wrote:
> > Hi,
> >
> >> Gerd, thank you very much! It's was indeed unclear to me how to test the
> >> MMIO GPU, but yours variant with microvm works! I was
> > As described above DRM_FORMAT_HOST_RGB565 means bigendian on bigendian
> > hosts and little endian on little endian hosts. Which is not correct
> > when your hardware does big endian no matter what.
>
> But (a) drm_driver_legacy_fb_format() uses DRM_FORMAT_HOST_RGB565
> if quirk_addfb_prefer_
On Tue, Jul 12, 2022 at 10:01:15AM +0200, Geert Uytterhoeven wrote:
> Hi Gerd,
>
> > It IMHO is not applicable to any physical hardware. It's used by
> > virtio-gpu where the supported format depends on the byte order
> > (it is argb in native byte order). Only virtual hardware can
> > have
Hi,
> So adding support for bigendian formats to the driver shouldn't be
> much of a problem. The vram will continue to run in little endian
> RGB565, the shadow will be big endian RGB565, and the driver must
> byteswap when copying.
For completeness: The other obvious option (for fbcon) would
n
> Cc: David Airlie
> Cc: Gerd Hoffmann
> Cc: Gurchetan Singh
> Cc: Chia-I Wu
> Cc: Daniel Vetter
> Cc: virtualizat...@lists.linux-foundation.org
Reviewed-by: Gerd Hoffmann
in
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
Reviewed-by: Gerd Hoffmann
On Mon, Jul 11, 2022 at 05:30:30PM +0200, Geert Uytterhoeven wrote:
> Hi Michel,
>
> > > Cirrus is the only driver setting quirk_addfb_prefer_host_byte_order
> > > and supporting RGB565 or XRGB1555, but no one tried that on big-endian?
> > > Cirrus does not support DRM_FORMAT_RGB565 | DRM_FORMAT_B
Hi,
> Gerd, thank you very much! It's was indeed unclear to me how to test the
> MMIO GPU, but yours variant with microvm works! I was looking for trying
> aarch64 in the past, but it also was unclear how to do it since there is
> no DT support for the VirtIO-GPU, AFAICS.
aarch64 uses acpi by d
Hi,
> > Also note that pci is not the only virtio transport we have.
>
> The VirtIO indeed has other transports, but only PCI is really supported
> in case of the VirtIO-GPU in kernel and in Qemu/crosvm, AFAICT. Hence
> only the PCI transport was tested.
qemu -M microvm \
-global virtio-mmio
Hi,
> - * So for the moment keep things as-is, with a bulky comment
> - * for the next person who feels like removing this
> - * drm_dev_set_unique() quirk.
Dragons lurking here. It's not the first attempt to ditch this, and so
far all have been rolled back due to regressions.
Hi,
> > As Pekka mentionned, I'd also like to have a conversation of how far we
> > want to
> > push virtualized driver features. I think KMS support is a good feature to
> > have
> > to spin up a VM and have all of the basics working. However I don't think
> > it's
> > a good idea to try to
Hi,
> > 4. make sure the hotspot property is only set on VIRTUAL_CURSOR planes
> > and nothing else in the rebased patch series
>
> Simon also mentioned on irc that these special planes must not expose the
> CRTC_X/Y property, since that doesn't really do much at all. Or is our
> understand
On Fri, Jun 03, 2022 at 02:18:49PM -0700, Dongwon Kim wrote:
> Having one fence for a vgfb would cause conflict in case there are
> multiple planes referencing the same vgfb (e.g. Xorg screen covering
> two displays in extended mode) being flushed simultaneously. So it makes
> sence to use a separa
Hi,
> You shouldn't have to copy any of the implementation of the aperture
> helpers.
That comes from the aperture helpers being part of drm ...
> For patch 2, the most trivial workaround is to instanciate struct drm_driver
> here and set the name field to 'vdev->vdev.ops->name'. In the longer
Hi,
> > Typically there is a communication path from guest to host for pointer
> > movements (i.e. crtc_x + crtc_y updates), so the host knows where the
> > guest wants the cursor plane being placed. So in case the pointer is
> > moved by other means (different input device, some application wa
Hi,
> >> But also, this issue isn't something that only affects graphic devices,
> >> right? AFAIU from [1] and [2], the same issue happens if a PCI device
> >> has to be bound to vfio-pci but already was bound to a host driver.
> >
> > Nope. There is a standard procedure to bind and unbind pc
Hi,
> But also, this issue isn't something that only affects graphic devices,
> right? AFAIU from [1] and [2], the same issue happens if a PCI device
> has to be bound to vfio-pci but already was bound to a host driver.
Nope. There is a standard procedure to bind and unbind pci drivers via
sys
> Why are pointer cursors misplaced on paravirtualized drivers?
>
> It is because the paravirtualized drivers or VM viewers do *not* place
> the cursor plane at the CRTC_X, CRTC_Y position in the guest CRTC area.
> This is obvious: if CRTC_X, CRTC_Y were honoured, there would be no
> misplacement.
Hi,
> I don’t think I see how that fixes anything. In particular I don’t see
> a way of fixing the old user space at all. We require hotspot info,
> old user space doesn’t set it because there’s no way of setting it on
> atomic kms. Whether we expose cursor plane or not doesn’t change the
> fact
s to hardcore a list of drivers which require
> hotspots because there's no way to query from drm "does this driver
> require hotspot"
So drivers move from one list to another. Not ideal, but also not worse
than it was before, so:
Acked-by: Gerd Hoffmann
for the qxl a
On Thu, Mar 24, 2022 at 06:34:02PM +0800, liuco...@kylinos.cn wrote:
>ok, thanks, a lot of our customer use qxl on x86 before, so it still need
>to supoort qxl on arm64.
Well, qxl isn't the best choice even on x86. The main advantage it
offers (2d acceleration) is basically useless today
On Thu, Mar 24, 2022 at 10:20:40AM +0100, Christian König wrote:
> Hi Cong,
>
> when I understand Robin correctly all mapping (host, guest, kernel,
> userspace etc..) must have the same caching attributes unless you use the
> S2FWB feature introduced with Armv8.4.
>
> If you don't follow those ru
On Wed, Mar 23, 2022 at 09:45:13AM +, Robin Murphy wrote:
> On 2022-03-23 07:15, Christian König wrote:
> > Am 22.03.22 um 10:34 schrieb Cong Liu:
> > > qxl use ioremap to map ram_header and rom, in the arm64 implementation,
> > > the device is mapped as DEVICE_nGnRE, it can not support unalign
> - for (j = k; j--; ) {
> - shift -= ppw;
> - end_mask = tab[(*src >> shift) & bit_mask];
> - *dst++ = (end_mask & eorx) ^ bgx;
> - if (!shift) {
> - shift = 8;
> -
Hi,
> What I still don't understand: why are you so keen on maintaining an
> interface that only serves the console? Nothing else uses fbdev these days.
> Why not improve DRM/userspace to the point where it fits your requirements?
> Long-term, the latter would make a lot more sense.
And note th
Hi,
> > So if this really has to come back then I think the pragmatic approach is
> > to do it behind a CONFIG_FBCON_ACCEL, default n, and with a huge warning
> > that enabling that shouldn't be done for any distro which only enables
> > firmware and drm fbdev drivers.
>
> Thanks for coming bac
Hi,
> > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > doing it synchronously.
>
> Hopefully only the parts of the screen which need a redraw?
Sure. drm fbdev emulation with shadow framebuffer tracks changes and
only flushes dirty areas to the real framebuffer.
Hi,
> > fbcon/fbdev emulation: RGB332 support must be added I think. But both
> > argb888 and rgb565 are supported today, so it should not be hard to find
> > the places where you have to add some code to handle RGB332 too.
>
> I'd expect that that framework is provided by DRM developers if th
Hi,
> > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > doing it synchronously.
>
> Yeah, and if you use the shadow fb support in drm fbdev helpers,
> that's what you get. Maybe we should just make that the default, since
> that would also greatly simply stuff like
On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> On Mon, 17 Jan 2022 19:47:39 +0100
> Sven Schnelle wrote:
>
> > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > a dmesg with 919 lines one the text console took about 2s to display. In
> > x11, i measur
On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote:
> On 1/18/22 07:29, Gerd Hoffmann wrote:
> >> Please correct me if I'm wrong, but text-console emulation/scrolling on
> >> DRM is
> >> currently unaccelerated and bound to Truecolour modes only,
>
On Thu, Dec 30, 2021 at 05:26:49PM +0300, Pavel Skripkin wrote:
> Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The
> problem was in ubuf->pages == ZERO_PTR.
>
> ubuf->pagecount is calculated from arguments passed from user-space. If
> user creates udmabuf with list.size == 0 then
On Mon, Dec 13, 2021 at 07:31:22PM +0100, Roberto Sassu wrote:
> If virtio_gpu_object_shmem_init() fails (e.g. due to fault injection, as it
> happened in the bug report by syzbot), virtio_gpu_array_put_free() could be
> called with objs equal to NULL.
>
> Ensure that objs is not NULL in virtio_gp
Hi,
> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
> currently unaccelerated and bound to Truecolour modes only,
Yes. Adding support for formats beside argb to the drm fbcon
emulation shouldn't be that much of a problem though.
Acceleration is harder. Th
On Mon, Jan 17, 2022 at 02:29:47PM +0100, Geert Uytterhoeven wrote:
> Hi Gerd,
>
> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann wrote:
> > > b) to include new drivers (for old hardware) if they arrive (probably
> > > happens rarely but there can be).
> > &
Hi,
> b) to include new drivers (for old hardware) if they arrive (probably happens
> rarely but there can be).
>I know of at least one driver which won't be able to support DRM
Hmm? I seriously doubt that. There is always the option to use a
shadow framebuffer, then convert from sta
On Mon, Dec 27, 2021 at 05:43:11PM +0100, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them. There is also a direct and hard coded use in
> cirrus.c which
On Wed, Dec 22, 2021 at 09:28:24AM +0100, Javier Martinez Canillas wrote:
> -static int __init bochs_init(void)
> -{
> - if (drm_firmware_drivers_only() && bochs_modeset == -1)
> - return -EINVAL;
Also cleanup bochs_modeset? I guess its not used any more after this
patch ...
take
On Fri, Dec 10, 2021 at 07:54:34PM -0500, Felix Kuehling wrote:
> Do you actually need to restore the exact boot-up mode? If you have the same
> framebuffer memory layout (width, height, bpp, stride) the precise display
> timing doesn't really matter. So we "just" need to switch to a mode that's
Hi,
> > The drivers are asic and platform specific. E.g., the driver for
> > vangogh is different from renoir is different from skylake, etc. The
> > display programming interfaces are asic specific.
>
> Cool, that makes sense! But if you (or anybody here) know some of these
> GOP drivers, e.
Hi,
> On the series:
>
> Reviewed-by: Daniel Vetter
>
> I'm assuming someone from Google can push this to drm-misc-fixes for you?
Thanks, pushed.
take care,
Gerd
On Thu, Nov 04, 2021 at 02:42:49PM -0700, Vivek Kasireddy wrote:
> When virgl is not enabled, vfpriv pointer would not be allocated.
> Therefore, check for a valid value before dereferencing.
>
> Reported-by: Christian Zigotzky
> Cc: Gurchetan Singh
> Cc: Gerd Hoffmann
>
1 - 100 of 2029 matches
Mail list logo
