From: Daniel Vetter <daniel@ffwll.ch>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: "paul.kocialkowski@bootlin.com" <paul.kocialkowski@bootlin.com>,
"thomas.petazzoni@bootlin.com" <thomas.petazzoni@bootlin.com>,
"maxime.ripard@bootlin.com" <maxime.ripard@bootlin.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Ser, Simon" <simon.ser@intel.com>,
"airlied@linux.ie" <airlied@linux.ie>,
Pekka Paalanen <ppaalanen@gmail.com>,
"Vetter, Daniel" <daniel.vetter@intel.com>
Subject: Re: [PATCH v7 09/11] drm: uevent for connector status change
Date: Mon, 3 Jun 2019 17:08:35 +0200 [thread overview]
Message-ID: <20190603150834.GL21222@phenom.ffwll.local> (raw)
In-Reply-To: <9953e1fa-dafa-21c1-9604-50ed1e9fecaf@daenzer.net>
On Mon, Jun 03, 2019 at 11:50:53AM +0200, Michel Dänzer wrote:
> On 2019-05-21 9:52 a.m., Daniel Vetter wrote:
> > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >> On Mon, 20 May 2019 18:11:07 +0200
> >> Daniel Vetter <daniel@ffwll.ch> wrote:
> >>
> >>> There's also a fairly easy fix for that -modesetting issue: We don't
> >>> expose atomic if the compositor has a process name of "Xserver". Brutal,
> >>> but gets the job done. Once X is fixed, we can give a new "I'm not totally
> >>> broken anymore" interface to get back at atomic.
> >>
> >> You mean "Xorg". Or maybe "X". Or maybe the setuid helper? Wait, do you
> >> check against the process issuing ioctl by ioctl, or the process that
> >> opened the device? Which would be logind? What about DRM leasing? ...
> >
> > In the Get/SetCaps ioctl we can do the check, which is called from X,
> > not logind. We just need some way to tell -modesetting apart from
> > everything else, and luckily there's not any other atomic X drivers.
>
> Not yet...
>
> As for a "I'm not totally broken anymore" interface, we did something
> like that (though kind of in the other direction) with
> RADEON_INFO_ACCEL_WORKING, but later RADEON_INFO_ACCEL_WORKING2 had to
> be added, because the former claimed acceleration was "working" in cases
> where it really wasn't... That kind of thing could become ugly in the
> long run if other Xorg driver start using atomic, and they'll inevitably
> be broken in different ways.
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 -modesetting (to allow fastboot, which I think is still
i915 exclusive). This then highlighted that modesetting can't do atomic
modesets if you try to reassign connectors.
One idea I have is that vgms would help compositors to play out a bunch of
standard scenarios, even automated. But that's not there yet, and every
compositor project needs to care beyond "boots on my laptop, ship it". No
idea that's even possible.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-06-03 15:08 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-07 16:27 [PATCH v7 00/11] HDCP2.2 Phase II Ramalingam C
2019-05-07 16:27 ` [PATCH v7 01/11] drm: move content protection property to mode_config Ramalingam C
2019-05-07 16:27 ` [PATCH v7 02/11] drm/i915: debugfs: HDCP2.2 capability read Ramalingam C
2019-05-07 16:27 ` [PATCH v7 03/11] drm: generic fn converting be24 to cpu and vice versa Ramalingam C
2019-05-07 16:27 ` [PATCH v7 04/11] drm: revocation check at drm subsystem Ramalingam C
2019-07-04 10:53 ` Pekka Paalanen
2019-09-12 0:15 ` Harry Wentland
2019-09-12 1:14 ` Deucher, Alexander
2019-09-12 6:54 ` Ramalingam C
2019-09-12 15:49 ` Harry Wentland
2019-05-07 16:27 ` [PATCH v7 05/11] drm/i915: SRM revocation check for HDCP1.4 and 2.2 Ramalingam C
2019-05-07 16:27 ` [PATCH v7 06/11] drm/hdcp: gathering hdcp related code into drm_hdcp.c Ramalingam C
2019-05-07 16:27 ` [PATCH v7 07/11] drm: Add Content protection type property Ramalingam C
2019-07-04 11:11 ` Pekka Paalanen
2019-07-04 10:36 ` Ramalingam C
2019-07-05 13:00 ` Pekka Paalanen
2019-07-05 6:33 ` Ramalingam C
2019-07-05 14:12 ` Pekka Paalanen
2019-05-07 16:27 ` [PATCH v7 08/11] drm/i915: Attach content " Ramalingam C
2019-05-07 16:27 ` [PATCH v7 09/11] drm: uevent for connector status change Ramalingam C
2019-05-10 12:12 ` Paul Kocialkowski
2019-05-10 14:54 ` Daniel Vetter
2019-05-13 9:02 ` Paul Kocialkowski
2019-05-13 9:34 ` Daniel Vetter
2019-05-13 10:11 ` Ser, Simon
2019-05-13 15:04 ` Daniel Vetter
2019-05-14 6:18 ` Ser, Simon
2019-05-13 17:14 ` Paul Kocialkowski
2019-05-14 11:09 ` Daniel Vetter
2019-05-14 14:12 ` Paul Kocialkowski
2019-05-14 14:28 ` Daniel Vetter
2019-05-15 7:43 ` Paul Kocialkowski
2019-05-15 7:48 ` Daniel Vetter
2019-05-14 8:02 ` Pekka Paalanen
2019-05-14 8:18 ` Ser, Simon
2019-05-14 11:02 ` Daniel Vetter
2019-05-14 13:36 ` Pekka Paalanen
2019-05-14 13:58 ` Paul Kocialkowski
2019-05-14 14:34 ` Daniel Vetter
2019-05-15 7:37 ` Pekka Paalanen
2019-05-15 7:49 ` Paul Kocialkowski
2019-05-15 8:24 ` Daniel Vetter
2019-05-16 8:22 ` Pekka Paalanen
2019-05-16 12:24 ` Daniel Vetter
2019-05-17 10:08 ` Pekka Paalanen
2019-05-20 16:11 ` Daniel Vetter
2019-05-20 16:24 ` Paul Kocialkowski
2019-05-21 6:55 ` Pekka Paalanen
2019-05-21 7:52 ` Daniel Vetter
2019-05-21 9:01 ` Pekka Paalanen
2019-05-21 9:42 ` Daniel Vetter
2019-06-03 9:50 ` Michel Dänzer
2019-06-03 15:08 ` Daniel Vetter [this message]
2019-06-03 15:19 ` Ser, Simon
2019-06-04 7:06 ` Pekka Paalanen
2019-05-13 21:20 ` Lyude Paul
2019-05-14 11:12 ` Daniel Vetter
2019-07-04 11:12 ` Pekka Paalanen
2019-07-04 10:42 ` Ramalingam C
2019-07-05 13:36 ` Pekka Paalanen
2019-05-07 16:27 ` [PATCH v7 10/11] drm/hdcp: update content protection property with uevent Ramalingam C
2019-07-04 11:14 ` Pekka Paalanen
2019-07-04 11:11 ` Ramalingam C
2019-07-05 13:59 ` Pekka Paalanen
2019-07-04 23:51 ` Ramalingam C
2019-05-07 16:27 ` [PATCH v7 11/11] drm/i915: update the hdcp state " Ramalingam C
2019-05-07 16:45 ` ✗ Fi.CI.CHECKPATCH: warning for HDCP2.2 Phase II (rev9) Patchwork
2019-05-07 16:52 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-05-07 17:37 ` ✓ Fi.CI.BAT: success " Patchwork
2019-05-08 0:41 ` ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190603150834.GL21222@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maxime.ripard@bootlin.com \
--cc=michel@daenzer.net \
--cc=paul.kocialkowski@bootlin.com \
--cc=ppaalanen@gmail.com \
--cc=simon.ser@intel.com \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.