search for: syrj

On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrj?l? > <ville.syrjala at linux.intel.com> wrote: > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > I have long suspected that a whole bunch of the "simple" displays > > > are not simple but contains a display controller and memor...

On Mon, 2020-09-28 at 16:01 +0300, Ville Syrj?l? wrote: > On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote: > > While I thought I had this correct (since it actually did reject modes > > like I expected during testing), Ville Syrjala from Intel pointed out > > that the logic here isn't correct. max_clock refe...

Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh Message-ID: <20200226115708.GH13686 at intel.com> References: <20200219203544.31013-1-ville.syrjala at linux.intel.com> <CGME20200219203620eucas1p24b4990a91e758dbcf3e9b943669b0c8f at eucas1p2.samsung.com> <20200219203544.31013-5-ville.syrjala at linux.intel.com> <0f278771-79ce-fe23-e72c-3935dbe82d24 at samsung.com> <20200225112114.GA13686 at intel.com> <3ca78...

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> I really just wanted to fix i915 to re-enable its planes afer load detection (a two line patch). This is what I actually ended up with after I ran into a framebuffer refcount leak with said two line patch. I've tested this on a few i915 boxes and so...

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> I really just wanted to fix i915 to re-enable its planes afer load detection (a two line patch). This is what I actually ended up with after I ran into a framebuffer refcount leak with said two line patch. I've tested this on a few i915 boxes and so...

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> We want to get rid of plane->crtc on atomic drivers. Stop setting it. v2: s/fb/crtc/ in the commit message (Gerd) Cc: David Airlie <airlied at linux.ie> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundatio...

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> Here are again the last (?) bits of eliminating the plane->fb/crtc usage for atomic drivers. I've pushed everything else (thanks to everyone who reviewed them). Deepak said he'd tested the vmwgfx stuff, so I think it should be safe to land....

On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote: > On 25.02.2020 12:21, Ville Syrj?l? wrote: > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: > >> On 19.02.2020 21:35, Ville Syrjala wrote: > >>> From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > >>> > >>> Get rid of mode->vrefresh and just calcula...

When we use virtio-vga with a big-endian guest, the mouse pointer disappears. To fix that, on big-endian use DRM_FORMAT_BGRA8888 instead of DRM_FORMAT_ARGB8888. Signed-off-by: Laurent Vivier <lvivier at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c

When we use virtio-vga with a big-endian guest, the mouse pointer disappears. To fix that, on big-endian use DRM_FORMAT_BGRA8888 instead of DRM_FORMAT_ARGB8888. Signed-off-by: Laurent Vivier <lvivier at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c

While I thought I had this correct (since it actually did reject modes like I expected during testing), Ville Syrjala from Intel pointed out that the logic here isn't correct. max_clock refers to the max symbol rate supported by the encoder, so limiting clock to ds_clock using max() doesn't make sense. Additionally, we want to check against 6bpc for the time being since that's the minimum possible b...

...eems not be used anywhere in the > code base (except in some format printing debug code ...). That's because either no one has big endian display hardware or they do but just didn't read the docs and cargo culted the format handling from some driver for little endian display. -- Ville Syrj?l? Intel OTC

...eems not be used anywhere in the > code base (except in some format printing debug code ...). That's because either no one has big endian display hardware or they do but just didn't read the docs and cargo culted the format handling from some driver for little endian display. -- Ville Syrj?l? Intel OTC

On Tue, Sep 29, 2020 at 01:54:13PM -0400, Lyude Paul wrote: > On Mon, 2020-09-28 at 16:01 +0300, Ville Syrj?l? wrote: > > On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote: > > > While I thought I had this correct (since it actually did reject modes > > > like I expected during testing), Ville Syrjala from Intel pointed out > > > that the logic here isn't cor...

On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote: > On Thu, 2020-03-05 at 15:11 +0200, Ville Syrj?l? wrote: > > On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote: > > > It's next to impossible for us to do connector probing on topologies > > > without occasionally racing with userspace, since creating a connector > > > itself causes a hotplug event...

On Thu, Apr 06, 2017 at 08:27:47PM +0300, Ville Syrj?l? wrote: > On Thu, Apr 06, 2017 at 10:29:43AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > > static const uint32_t virtio_gpu_cursor_formats[] = { > > > > +#ifdef __BIG_ENDIAN > > > > + DRM_FORMAT_BGRA8888, > > > > +#else > &gt...

On Thu, Apr 06, 2017 at 08:27:47PM +0300, Ville Syrj?l? wrote: > On Thu, Apr 06, 2017 at 10:29:43AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > > static const uint32_t virtio_gpu_cursor_formats[] = { > > > > +#ifdef __BIG_ENDIAN > > > > + DRM_FORMAT_BGRA8888, > > > > +#else > &gt...

Hi Am 16.02.23 um 13:52 schrieb Ville Syrj?l?: > 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: >>&...

...0 > > > > > take care, > > Gerd > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 N?rnberg, Germany > (HRB 36809, AG N?rnberg) > Gesch?ftsf?hrer: Ivo Totev -- Ville Syrj?l? Intel

Hi, > > static const uint32_t virtio_gpu_cursor_formats[] = { > > +#ifdef __BIG_ENDIAN > > + DRM_FORMAT_BGRA8888, > > +#else > > DRM_FORMAT_ARGB8888, > > +#endif > > DRM formats are supposed to be little endian, so this isn't really > correct. Well, maybe they where *intended* to be little endian at some point in the past. The actual code