Re: [PATCH] drm: Remove DRIVER_DATE and CORE_DATE

between nouveau/linux-2.6 and upstream kernel trees is a burden. Is there a better way to add revision information to an out-of-tree built kernel module? Or maybe this is not useful at all? Cheers. -- Pekka Paalanen http://www.iki.fi/pq/ ___ dri-devel

Re: [PATCH 1/7] ttm/radeon/nouveau: Check the DMA address from TTM against known value.

) */ + if (rdev-pdev, dma_addr[i] != 0) { The same question for this condition. -- Pekka Paalanen http://www.iki.fi/pq/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] Android support

On Fri, 12 Oct 2012 15:27:27 -0700 Eric Anholt e...@anholt.net wrote: Negreanu Marius gro...@gmail.com writes: On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli tapani.pa...@intel.com wrote: On 10/10/2012 08:05 PM, Chad Versace wrote: On 10/07/2012 10:50 PM, Tapani Pälli wrote:

[PATCH 6/6] drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2

On Tue, 16 Aug 2016 10:46:13 +0900 Michel Dänzer wrote: > On 16/08/16 10:32 AM, Mario Kleiner wrote: > > Cc'ing Daniel Stone and Pekka Paalanen, because this relates to wayland. > > > > Wrt. having a new pageflip parameter struct, i wonder if it wouldn't > > make se

[Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

On Thu, 16 Jun 2016 10:40:51 -0400 Rob Clark wrote: > So, if we wanted to extend this to support the fourcc-modifiers that > we have on the kernel side for compressed/tiled/etc formats, what > would be the right approach? > > A new version of the existing extension or a new >

[Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

On Fri, 17 Jun 2016 08:26:04 -0400 Rob Clark wrote: > On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen > wrote: > > On Thu, 16 Jun 2016 10:40:51 -0400 > > Rob Clark wrote: > > > >> So, if we wanted to extend this to support the fourcc-modifiers tha

[Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

On Fri, 17 Jun 2016 11:44:34 -0400 Rob Clark wrote: > On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen > wrote: > > On Fri, 17 Jun 2016 08:26:04 -0400 > > Rob Clark wrote: > > > >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen > >> wrote:

[Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

On Fri, 17 Jun 2016 11:44:34 -0400 Rob Clark wrote: > On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen > wrote: > > On Fri, 17 Jun 2016 08:26:04 -0400 > > Rob Clark wrote: > > > >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen > >> wrote:

[Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

On Mon, 20 Jun 2016 09:45:26 -0400 Rob Clark wrote: > On Mon, Jun 20, 2016 at 8:37 AM, Pekka Paalanen > wrote: > > On Fri, 17 Jun 2016 11:44:34 -0400 > > Rob Clark wrote: > > > >> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen > >> wrote:

[PATCH] Add virtio gpu driver.

On Tue, 31 May 2016 08:29:20 +0200 Gerd Hoffmann wrote: > Hi, > > > > Why attach the hotspot to the plane? Wouldn't it make more sense to > > > make it a framebuffer property? > > > > We don't have properties on the framebuffer. I guess you /could/ just add > > it internally to struct

enable display using drm

On Tue, 1 Mar 2016 12:47:57 +0100 Alex Vazquez wrote: > Hi. I want to know if it's possible (enable/disable) the display using some > function of drm. I have looking for but I don't find nothing about this. Hi, it's possible only if the code doing that is the display server or equivalent.

[PATCH] wayland-drm: add a description for every item.

capability". > > > > > - > > - > - > - > - > - > - > - > - > - > - > - > + > + Create a wayland buffer for the prime fd. > + > +Use for regular and planar buffers. Pass 0 for offset and > +stride for unused planes. > + > + + summary="wl_buffer assigned to this drm buffer"/> > + I'm not really sure what a "prime fd" is, care to explain it in the description? Is it a dmabuf fd? Any additional semantics or constraints? > + > + > + > + > + > + > + > + > + > > > I don't mind if you don't add the extra information I asked for. So, if you put the "bitmask" back, then this would be: Revieved-by: Pekka Paalanen Thanks, pq PS. the proper mailing lists would be mesa-dev and wayland-devel. dri-devel is more for the kernel stuff.

[PATCH] modesetting: Support native primary plane rotation

On Wed, 9 Jul 2014 08:00:21 +0100 Chris Wilson wrote: > With the advent of universal drm planes and the introduction of generic > plane properties for rotations, we can query and program the hardware > for native rotation support. > > NOTE: this depends upon the next release of libdrm to

[PATCH] modesetting: Support native primary plane rotation

lease of libdrm to remove one > opencoded define. > > v2: Use enum to determine primary plane, suggested by Pekka Paalanen. > Use libobj for replacement ffs(), suggested by walter harms > > Signed-off-by: Chris Wilson > Cc: Pekka Paalanen > Cc: walter harms My concerns h

[PATCH] modesetting: Support native primary plane rotation

On Wed, 9 Jul 2014 11:02:59 +0100 Chris Wilson wrote: > On Wed, Jul 09, 2014 at 12:57:12PM +0300, Pekka Paalanen wrote: > > On Wed, 9 Jul 2014 09:19:08 +0100 > > Chris Wilson wrote: > > > > > With the advent of universal drm planes and the introduction of

[PATCH weston 1/1] compositor: Abort on bad page flip timestamps

On Thu, 06 Nov 2014 16:08:56 +0900 Michel Dänzer wrote: > On 06.11.2014 03:06, Frederic Plourde wrote: > > Many features, like animations, hardly depend on page flip timestamps > > to work properly, but some DRM drivers do not correctly support page flip > > timestamps (or not at all) and in

[PATCH weston 1/1] compositor: Abort on bad page flip timestamps

On Fri, 07 Nov 2014 07:04:16 +0100 Mario Kleiner wrote: > On 06/11/14 17:42, Pekka Paalanen wrote: > > On Thu, 06 Nov 2014 16:08:56 +0900 > > Michel Dänzer wrote: > > > >> On 06.11.2014 03:06, Frederic Plourde wrote: > >>> Many features, like animati

[PATCH 13/13] RFC: drm: Atomic modeset ioctl

On Wed, 17 Dec 2014 11:48:51 +0900 Michel Dänzer wrote: > On 17.12.2014 08:05, Rob Clark wrote: > > The atomic modeset ioctl can be used to push any number of new values > > for object properties. The driver can then check the full device > > configuration as single unit, and try to apply the

[PATCH] Prevent zero sized wl_egl_window

On Wed, 12 Feb 2014 16:21:11 -0800 Sinclair Yeh wrote: > It is illegal to create or resize a window to zero (or negative) width > and/or height. This patch prevents such a request from happening. > --- > src/egl/wayland/wayland-egl/wayland-egl.c | 6 ++ > 1 file changed, 6 insertions(+) >

[PATCH] Prevent zero sized wl_egl_window

On Thu, 13 Feb 2014 18:18:23 + "Yeh, Sinclair" wrote: > > The below seems fine, but I wonder if we could make this one cause an > > error to be returned later where we can, rather than silently ignoring. > > I'm not sure where or how, though. > > Would it make sense to change

How to design a DRM KMS driver exposing 2D compositing?

Hi, there is some hardware than can do 2D compositing with an arbitrary number of planes. I'm not sure what the absolute maximum number of planes is, but for the discussion, let's say it is 100. There are many complicated, dynamic constraints on how many, what size, etc. planes can be used at

How to design a DRM KMS driver exposing 2D compositing?

On Mon, 11 Aug 2014 11:57:10 +0100 Damien Lespiau wrote: > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote: > > Hi, > > Hi, > > > there is some hardware than can do 2D compositing with an arbitrary > > number of planes. I'm not sure what the absolut

How to design a DRM KMS driver exposing 2D compositing?

Hi Daniel, you make perfect sense as usual. :-) Comments below. On Mon, 11 Aug 2014 14:06:36 +0200 Daniel Vetter wrote: > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote: > > Hi, > > > > there is some hardware than can do 2D compositing with an arbitrary

How to design a DRM KMS driver exposing 2D compositing?

On Mon, 11 Aug 2014 14:14:56 +0100 Damien Lespiau wrote: > On Mon, Aug 11, 2014 at 03:07:33PM +0300, Pekka Paalanen wrote: > > > > there is some hardware than can do 2D compositing with an arbitrary > > > > number of planes. I'm not sure what the absolute maxim

How to design a DRM KMS driver exposing 2D compositing?

On Mon, 11 Aug 2014 17:35:31 +0200 Daniel Vetter wrote: > Well for other drivers/stacks we'd fall back to GL compositing. pixman > would obviously be terribly. Curious question: Can you provoke the > hw/firmware to render into abitrary buffers or does it only work together > with real display

How to design a DRM KMS driver exposing 2D compositing?

On Mon, 11 Aug 2014 09:32:32 -0400 Rob Clark wrote: > On Mon, Aug 11, 2014 at 8:06 AM, Daniel Vetter wrote: > > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote: > >> What if I cannot even pick a maximum number of planes, but wanted to > >> (as the

How to design a DRM KMS driver exposing 2D compositing?

On Mon, 11 Aug 2014 07:37:18 -0700 Matt Roper wrote: > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote: > > Hi, > > > > there is some hardware than can do 2D compositing with an arbitrary > > number of planes. I'm not sure what the absolute m

How to design a DRM KMS driver exposing 2D compositing?

On Mon, 11 Aug 2014 19:27:45 +0200 Daniel Vetter wrote: > On Mon, Aug 11, 2014 at 10:16:24AM -0700, Eric Anholt wrote: > > Daniel Vetter writes: > > > > > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote: > > >> Hi, > > >> > >

How to design a DRM KMS driver exposing 2D compositing?

On Tue, 12 Aug 2014 09:10:47 -0700 Eric Anholt wrote: > Pekka Paalanen writes: > > > On Mon, 11 Aug 2014 19:27:45 +0200 > > Daniel Vetter wrote: > > > >> On Mon, Aug 11, 2014 at 10:16:24AM -0700, Eric Anholt wrote: > >> > Daniel Vetter writes: &

[PATCH 2/6] xf86drmMode: separate drmModeAtomicCommit() and drmModeAtomicCleanup()

On Fri, 21 Aug 2015 13:54:49 +0900 Hyungwon Hwang wrote: > Hi Emil, > > On Thu, 20 Aug 2015 17:17:27 +0100 > Emil Velikov wrote: > > > Hi Hyungwon, > > > > On 19 August 2015 at 01:58, Hyungwon Hwang > > wrote: > > > This patch seprates the code, which sorts proprty sets and > > > eliminates

[PATCH 3/6] xf86drmMode: Make atomic request structures visible

On Fri, 21 Aug 2015 15:06:58 +0900 Hyungwon Hwang wrote: > Hi Emil, > > On Thu, 20 Aug 2015 17:23:09 +0100 > Emil Velikov wrote: > > > On 19 August 2015 at 01:58, Hyungwon Hwang > > wrote: > > > This patch makes 'struct _drmModeAtomicReqItem' and 'struct > > > _drmModeAtomicReq' visible from

[PATCH 2/6] xf86drmMode: separate drmModeAtomicCommit() and drmModeAtomicCleanup()

On Fri, 21 Aug 2015 16:18:59 +0900 Hyungwon Hwang wrote: > Hi Pekka, > > On Fri, 21 Aug 2015 09:42:26 +0300 > Pekka Paalanen wrote: > > > On Fri, 21 Aug 2015 13:54:49 +0900 > > Hyungwon Hwang wrote: > > > > > Hi Emil, > > > > > >

[PATCH 0/3] Android support

On Fri, 12 Oct 2012 15:27:27 -0700 Eric Anholt wrote: > Negreanu Marius writes: > > > On Thu, Oct 11, 2012 at 12:39 PM, Tapani P?lli > > wrote: > >> On 10/10/2012 08:05 PM, Chad Versace wrote: > >>> On 10/07/2012 10:50 PM, Tapani P?lli wrote: > Upstreaming old set of patches here to

MmioTrace: Using the Instruction Decoder, etc.

On Mon, 14 Oct 2013 22:45:09 +0400 Eugene Shatokhin wrote: > Hi, > > There is an interesting TODO item on MmioTraceDeveloper page: > "kprobes has a generic instruction decoding facility, use that instead of > homebrewn (or KVM), and use emulation instead of page faulting" > > Actually, I have

MmioTrace: Using the Instruction Decoder, etc.

in the kernel and usually frowned upon so I opted not > to handle them so far in KernelStrider. I don't really know. I guess everything could be possible in proprietary drivers, but you can look at the instruction decoding code in mmiotrace, which digs up the type and size of access and t

MmioTrace: Using the Instruction Decoder, etc.

On Sat, 19 Oct 2013 17:12:20 +0400 Eugene Shatokhin wrote: > Hi, > > > Ah, you are not using the ftrace framework nor relayfs? Mmiotrace > used to be relayfs at one point and then converted to ftrace. > > Yes, I considered these when I started working on KernelStrider but finally > borrowed

MmioTrace: Using the Instruction Decoder, etc.

On Fri, 25 Oct 2013 17:19:56 +0400 Eugene Shatokhin wrote: > Hi, > > 2013/10/25 Pekka Paalanen > ... > > We could use some comments from the real reverse-engineers. I used > > to be mostly a tool writer. > > > > Yes, if some experts could share their

The least I need to draw with OpenGL.

Looks pretty much like kmscube is what > > I've been looking for :) > > > > Thanks again! > > > > > > On Mon, Dec 9, 2013 at 2:46 PM, Pekka Paalanen > > wrote: > > > >> On Mon, 9 Dec 2013 14:15:16 +0300 > >> Artsiom Anikeyenka wrote: > >&g

Wayland and GLES1 (Re: R200 DRM/KMS)

On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury wrote: > Would gles1 be sufficient to run a Wayland compositor, I'm > guessing probably not..? If you can find a Wayland compositor that is written to composite with GLES1, that's all you need from the "Wayland side". (Yeah, this has nothing to

[PATCH] drm/fourcc: Add formats R8, RG88, GR88

:8 little endian */ > + > /* 8 bpp RGB */ > #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B > 3:3:2 */ > #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R > 2:3:3 */ Reviewed-by: Pekka Paalanen Thanks, pq

[PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation

On Thu, 16 Jul 2015 20:20:39 +0800 John Hunter wrote: > From: Zhao Junwang > > This supports the asynchronous commits, required for page-flipping > Since it's virtual hw it's ok to commit async stuff right away, we > never have to wait for vblank. Hi, in theory, yes. This is what a patch to

[PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation

On Sun, 19 Jul 2015 17:20:32 -0700 Stéphane Marchesin wrote: > On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen > wrote: > > > > On Thu, 16 Jul 2015 20:20:39 +0800 > > John Hunter wrote: > > > > > From: Zhao Junwang > > > > > >

KMS timings (Re: [PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation)

On Mon, 20 Jul 2015 01:58:33 -0700 Stéphane Marchesin wrote: > On Mon, Jul 20, 2015 at 12:46 AM, Pekka Paalanen > wrote: > > On Sun, 19 Jul 2015 17:20:32 -0700 > > Stéphane Marchesin wrote: > > > >> On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen > &g

KMS timings (Re: [PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation)

On Mon, 20 Jul 2015 10:32:31 -0700 Stéphane Marchesin wrote: > On Mon, Jul 20, 2015 at 7:21 AM, Daniel Vetter wrote: > > On Mon, Jul 20, 2015 at 12:35:48PM +0300, Pekka Paalanen wrote: > >> On Mon, 20 Jul 2015 01:58:33 -0700 > >> Stéphane Marchesin wrote: >

KMS timings (Re: [PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation)

On Tue, 21 Jul 2015 11:02:58 +0200 Daniel Vetter wrote: > On Tue, Jul 21, 2015 at 10:06:09AM +0300, Pekka Paalanen wrote: > > On Mon, 20 Jul 2015 10:32:31 -0700 > > Stéphane Marchesin wrote: > > > > > On Mon, Jul 20, 2015 at 7:21 AM, Daniel Vetter wrote: > &g

[PATCH] drm/plane-helper: Adapt cursor hack to transitional helpers

; atomic (like i915). > > Reported-by: Pekka Paalanen > Cc: Pekka Paalanen > Cc: stable at vger.kernel.org > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_plane_helper.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_

[PATCH 1/7] ttm/radeon/nouveau: Check the DMA address from TTM against known value.

a_addr in TTM > for now but this > - * code stops building on alpha so just comment > it out for now */ > - if (0) { /*dma_addr[i] != DMA_ERROR_CODE) */ > + if (rdev->pdev, dma_addr[i] != 0) { The same question for this condition. -- Pekka Paalanen http://www.iki.fi/pq/

[PATCH] drm: Remove DRIVER_DATE and CORE_DATE

out-of-tree building. I didn't check if this patch has been accepted, but I believe maintaining differences between nouveau/linux-2.6 and upstream kernel trees is a burden. Is there a better way to add revision information to an out-of-tree built kernel module? Or maybe this is not useful at all? Cheers. -- Pekka Paalanen http://www.iki.fi/pq/

Re: [PATCH libdrm 2/2] Add CRTC ID to vblank event

On Tue, 4 Apr 2017 17:52:20 +0100 Daniel Stone wrote: > From: Ander Conselvan de Oliveira > > When using the atomic API, one request can span multiple CRTCs, however > one event is generated per CRTC. As we cannot disambiguate the

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

On Thu, 06 Apr 2017 20:02:23 -0700 Keith Packard wrote: > Michel Dänzer writes: > > > When no such special client (Steam?) is running, the desktop environment > > will try to use the HMD anyway, right? So the expected use case would be > > for the user to

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

On Sun, 09 Apr 2017 10:27:31 -0700 Keith Packard <kei...@keithp.com> wrote: > Pekka Paalanen <ppaala...@gmail.com> writes: > > > we need some kind of a database to recognize HMDs in any case, right? > > It would be best if the database was shared, so that everyon

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, 10 Apr 2017 12:12:01 +0200 Gerd Hoffmann wrote: > Ok, this is really a kickstart for a discussion. While working on > graphics support for virtual machines on ppc64 (which exists in both > little and big endian variants) I've figured the comments in the header > file

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, 10 Apr 2017 12:10:14 -0400 Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > > I also wonder if a real BE machine could have different results than > > the virtual machine. >

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, 10 Apr 2017 16:17:27 +0200 Gerd Hoffmann wrote: > Hi, > > > which software have you used as representative of "reality"? > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

yuv formats as-is. I have no idea if and how those are used > on bigendian machines. > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> > Cc: Daniel Vetter <daniel.vet...@intel.com> > Cc: Pekka Paalanen <ppaala...@gmail.com> > Cc: Ilia Mirkin <i

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, 21 Apr 2017 14:08:04 +0300 Ville Syrjälä wrote: > On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: > > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: > > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: > > > >

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, 11 Apr 2017 13:23:53 +0200 Gerd Hoffmann wrote: > Hi, > > > > Just let know what you need tested, I should be able to turn it around > > > within a couple of days. > > > > That's part of my problem. I don't really know what should be tested. > > What do people do

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, 18 Apr 2017 15:39:53 +0200 Gerd Hoffmann wrote: > Hi, > > > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest > > > here, it drives the qemu stdvga with offb, not bochs-drm. > > > > I suppose this proves the virtual machine itself is

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, 18 Apr 2017 12:00:17 +0200 Gerd Hoffmann wrote: > Hi, > > > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > > > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and > > > only format supported by bochs-drm), and we

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Wed, 19 Apr 2017 10:01:47 +0900 Michel Dänzer wrote: > On 18/04/17 07:14 PM, Gerd Hoffmann wrote: > > Hi, > > > >>> Quite true that this proves nothing. However one should note that > >>> fbcon -> fbdev works, > >> > >> BTW, this supports Gerd's patch, since the KMS

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

On Mon, 08 May 2017 08:29:30 -0700 Keith Packard <kei...@keithp.com> wrote: > Pekka Paalanen <ppaala...@gmail.com> writes: > > > Thinking again, I believe we have to have a way to override > > database entries somehow. If we ship catch-all entries for, say, > &g

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

On Wed, 03 May 2017 19:04:38 -0700 Keith Packard <kei...@keithp.com> wrote: > Pekka Paalanen <ppaala...@gmail.com> writes: > > > do you mean to list all kinds of display devices in the database? I was > > assuming it would list only HMDs, so not in database would i

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

On Sat, 6 May 2017 13:34:44 +0200 Mario Kleiner wrote: > Just please make sure that one (user configurable/opt-in if necessary) > policy from the beginning is to allow leasing out any output to > applications, not just HMDs. My type of scientific/medical

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

On Fri, 05 May 2017 07:25:14 -0700 Keith Packard <kei...@keithp.com> wrote: > Pekka Paalanen <ppaala...@gmail.com> writes: > > > I disagree on the details, more below. > > > Such a RandR request is something I would not like to have to replicate > >

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

On Fri, 28 Apr 2017 15:03:17 -0700 Keith Packard <kei...@keithp.com> wrote: > Pekka Paalanen <ppaala...@gmail.com> writes: > > > IMHO, if nothing is providing a picture intended for the HMD, the HMD > > should be off. There is no use in showing an arbitrary imag

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

On Tue, 02 May 2017 07:45:25 -0700 Keith Packard <kei...@keithp.com> wrote: > Pekka Paalanen <ppaala...@gmail.com> writes: > > I presume that if "desktop" is set to "true", it implies that the HMD > > is capable of showing a simple 2D can

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

On Thu, 04 May 2017 11:02:44 -0700 Keith Packard <kei...@keithp.com> wrote: > Pekka Paalanen <ppaala...@gmail.com> writes: > > > That means you need an explicit key to denote HMDs. More below. > > I don't think so. Presumably the VR system will have a

Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN

On Tue, 2 May 2017 14:53:43 +0100 Emil Velikov wrote: > Hi Gerd, > > I did not have the change to follow through the discussion. > Pardon if my suggestion have already been discussed. > > On 2 May 2017 at 14:34, Gerd Hoffmann wrote: > > It's

Re: [RFC 0/7] drm/omap: Module parameter for display order configuration

On Tue, 29 Aug 2017 10:32:11 +0300 Peter Ujfalusi wrote: > Hi > > The series adds support for changing the order of the displays defined by DT > display aliases. > > The motivation to do such a thing is that for example the fb emulation is > treating the first

Re: [RFC 0/7] drm/omap: Module parameter for display order configuration

On Thu, 5 Oct 2017 13:01:50 +0300 Tomi Valkeinen <tomi.valkei...@ti.com> wrote: > Hi, > > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 05/10/17 12:56, Pekka Paalanen w

Re: [RFC 0/7] drm/omap: Module parameter for display order configuration

On Thu, 5 Oct 2017 14:24:27 +0300 Tomi Valkeinen <tomi.valkei...@ti.com> wrote: >  > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 05/10/17 13:43, Pekka Paalanen wrote: > &g

Re: RFC: page-flip with damage?

On Tue, 26 Sep 2017 09:07:45 -0700 Thomas Hellstrom wrote: > On 09/26/2017 01:18 AM, Daniel Vetter wrote: > > On Sun, Sep 24, 2017 at 07:41:45PM +0200, Thomas Hellstrom wrote: > >> Hi, list! > >> > >> Page flips, while efficient on real hardware, aren't that efficient in

Re: RFC: page-flip with damage?

On Thu, 12 Oct 2017 10:51:22 -0400 Sean Paul <seanp...@chromium.org> wrote: > On Thu, Oct 12, 2017 at 01:55:40PM +0300, Pekka Paalanen wrote: > > On Tue, 26 Sep 2017 09:07:45 -0700 > > Thomas Hellstrom <thellst...@vmware.com> wrote: > > > > > O

Re: [PATCH v2 0/6] drm/omap: Module parameter for display order configuration

On Wed, 21 Mar 2018 12:08:25 +0200 Peter Ujfalusi wrote: > Hi, > > Changes since v1: > - rebased it on drm-next > - Dropped the devm_kzalloc conversion patch > > Changes since RFC: > - Comments from Laurent have been addressed: > - Get alias ID once and store it for

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On Mon, 5 Feb 2018 17:03:22 +0100 Gerd Hoffmann wrote: > On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote: > > On 02/05/2018 01:20 PM, Gerd Hoffmann wrote: > > >Hi, > > > > > Hmm. I allways assumed the wayland client allocates the buffers, not > the

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On Mon, 12 Feb 2018 12:45:40 +0100 Gerd Hoffmann wrote: > Hi, > > > >(a) software rendering: client allocates shared memory buffer, renders > > >into it, then passes a file handle for that shmem block together > > >with some meta data (size, format, ...)

Re: [PATCH 01/14] drm: add new plane property FB_DAMAGE_CLIPS to send damage during plane update

On Thu, 6 Sep 2018 21:36:51 + Deepak Singh Rawat wrote: > > > > - Why no input validation on the damage clips against the framebuffer > > size? Ime not validating just leads to funny driver bugs down the road, > > so what's the use-case you have in mind here? > > My motivation behind

Re: [PATCH 1/3] vulkan: Define new VK_MESA_query_timestamp extension [v2]

On Sat, 23 Jun 2018 12:13:53 -0500 Jason Ekstrand wrote: > I haven't thought through this comment all that hard but would it make > sense to have three timestamps, CPU, GPU, CPU so that you have error bars > on the GPU timestamp? At the very least, two timestamps would be better > than one

Re: [PATCH 1/3] vulkan: Define new VK_MESA_query_timestamp extension [v2]

On Tue, 10 Jul 2018 11:02:23 -0700 "Keith Packard" wrote: > Pekka Paalanen writes: > > > On Sat, 23 Jun 2018 12:13:53 -0500 > > Jason Ekstrand wrote: > > > >> I haven't thought through this comment all that hard but would it make > >&

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On Fri, 12 Oct 2018 07:35:57 + "Koenig, Christian" wrote: > Am 12.10.2018 um 09:23 schrieb Pekka Paalanen: > > On Wed, 10 Oct 2018 09:35:50 -0400 > > "Kazlauskas, Nicholas" wrote: > > > >> The patches I've put out target this use case m

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On Fri, 12 Oct 2018 08:58:23 -0400 "Kazlauskas, Nicholas" wrote: > On 10/12/2018 07:20 AM, Koenig, Christian wrote: > > Am 12.10.2018 um 11:21 schrieb Pekka Paalanen: > >> On Fri, 12 Oct 2018 07:35:57 + > >> "Koenig, Christian" wrote: &g

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On Wed, 10 Oct 2018 09:35:50 -0400 "Kazlauskas, Nicholas" wrote: > The patches I've put out target this use case mostly because of the > benefit for a relatively simple interface. VRR can and has been used in > more ways that this, however. > > An example usecase that differs from this would

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On Mon, 15 Oct 2018 12:02:14 -0400 "Kazlauskas, Nicholas" wrote: > On 10/15/2018 09:57 AM, Pekka Paalanen wrote: > > On Fri, 12 Oct 2018 08:58:23 -0400 > > "Kazlauskas, Nicholas" wrote: > > > >> On 10/12/2018 07:20 AM, Koenig, Christian w

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On Thu, 11 Oct 2018 12:39:41 -0400 Nicholas Kazlauskas wrote: > These include the drm_connector 'vrr_capable' and the drm_crtc > 'vrr_enabled' properties. > > Signed-off-by: Nicholas Kazlauskas > --- > Documentation/gpu/drm-kms.rst | 7 +++ > drivers/gpu/drm/drm_connector.c | 22

Re: [PATCH v5 2/4] drm: Add vrr_enabled property to drm CRTC

On Mon, 15 Oct 2018 12:06:52 +0200 Michel Dänzer wrote: > On 2018-10-15 11:47 a.m., Christian König wrote: > > Am 15.10.2018 um 11:40 schrieb Michel Dänzer: > >> On 2018-10-13 7:38 p.m., Christian König wrote: > >>> Am 12.10.2018 um 18:44 schrieb Nicholas Kazlauskas: > This patch

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On Fri, 26 Oct 2018 17:34:15 + "Kazlauskas, Nicholas" wrote: > On 10/26/18 10:53 AM, Ville Syrjälä wrote: > > On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote: > >> On 10/26/18 7:37 AM, Pekka Paalanen wrote: > >>> Hi

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On Wed, 31 Oct 2018 17:54:34 + "Kazlauskas, Nicholas" wrote: > On 10/31/18 12:20 PM, Michel Dänzer wrote: > > On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote: > >> On 10/31/18 10:12 AM, Michel Dänzer wrote: > >>> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote: > On

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

Hi, I have a somewhat of my own view on what would be involved with VRR, and I'd like to hear what you think of it. Comments inline. On Tue, 25 Sep 2018 09:51:37 -0400 "Kazlauskas, Nicholas" wrote: > On 09/24/2018 04:26 PM, Ville Syrjälä wrote: > > On Mon, Sep 24, 2018 at 03:06:02PM -0400,

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On Fri, 5 Oct 2018 12:21:20 -0400 "Kazlauskas, Nicholas" wrote: > On 10/05/2018 04:10 AM, Pekka Paalanen wrote: > > Hi, > > > > I have a somewhat of my own view on what would be involved with VRR, > > and I'd like to hear what you think of it. Comments inli

Re: Expose more EDID fields to userspace

On Mon, 7 Jan 2019 17:07:09 + Brian Starkey wrote: > On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote: > > Daniel Vetter writes: > > > > > Best to pull in some other compositor people and get them to agree. From a > > > kernel pov I'm fine with whatever userspace preferes.

Re: [PATCH v6 3/5] drm: Document variable refresh properties

t; 'vrr_enabled' properties. > >> > >> Signed-off-by: Nicholas Kazlauskas > >> Cc: Harry Wentland > >> Cc: Manasi Navare > >> Cc: Pekka Paalanen > >> Cc: Ville Syrjälä > >> Cc: Michel Dänzer > >> --- > >> Docu

Re: [PATCH v7 09/11] drm: uevent for connector status change

On Thu, 16 May 2019 14:24:55 +0200 Daniel Vetter wrote: > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote: > > On Wed, 15 May 2019 10:24:49 +0200 > > Daniel Vetter wrote: > > > > > On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote:

Re: [PATCH] drm/docs: More links for implicit/explicit fencing.

On Mon, 3 Jun 2019 16:28:48 +0200 Daniel Vetter wrote: > drm_atomic_set_fence_for_plane() contains the main discussion from a > driver pov, link to that from more places. > > Cc: Pekka Paalanen > Signed-off-by: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Maxime Ripard

Re: [PATCH v7 09/11] drm: uevent for connector status change

On Mon, 3 Jun 2019 15:19:13 + "Ser, Simon" wrote: > On Mon, 2019-06-03 at 17:08 +0200, Daniel Vetter wrote: > > It's definitely a very suboptimal situation. Not sure there's a good way > > out. The trouble here is that i915 ended up configuring crtc/connectors > > differently than

Re: dpms mode change with wayland on iMX.6

On Mon, 27 May 2019 12:41:43 +0530 Pintu Agarwal wrote: > Dear All, > > I have a iMX.6 (arm 32) board with Linux Kernel 3.10 and debian > platform running. > The board is connected to one LCD screen and one HDMI monitor. > It have DRM + Wayland setup for display. > Also, I noticed that it have

Re: [PATCH v7 09/11] drm: uevent for connector status change

On Mon, 13 May 2019 11:34:58 +0200 Daniel Vetter wrote: > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski > wrote: > > > > Hi, > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote: > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski > > > wrote: > > > > Hi, > > > > > > > >

Re: [PATCH v7 09/11] drm: uevent for connector status change

On Tue, 14 May 2019 16:34:01 +0200 Daniel Vetter wrote: > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen wrote: > > > > On Tue, 14 May 2019 13:02:09 +0200 > > Daniel Vetter wrote: > > > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon wrote: > &g

Re: [PATCH v7 09/11] drm: uevent for connector status change

On Mon, 20 May 2019 18:11:07 +0200 Daniel Vetter wrote: > On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote: > > On Thu, 16 May 2019 14:24:55 +0200 > > Daniel Vetter wrote: > > > > > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote:

Re: [PATCH] drm/doc: More fine-tuning on userspace review requirements

PI. > > there's been concerns raised that we expect userspace people to do > in-depth kernel patch review. That's not reasonable, same way kernel > people can't review all the userspace we have. Try to clarify > expectations a bit more. > > Cc: Eric Anholt > Cc: Pekka Paalane

Re: [PATCH 2/2] drm/doc: Document expectation that userspace review looks at kernel uAPI.

On Wed, 24 Apr 2019 21:36:36 +0200 Daniel Vetter wrote: > On Wed, Apr 24, 2019 at 11:56:17AM -0700, Eric Anholt wrote: > > The point of this review process is that userspace using the new uAPI > > can actually live with the uAPI being provided, and it's hard to know > > that without having

  1   2   3   4   5   6   7   8   9   10   >