On Friday, October 9, 2020 12:25 PM, Brian Starkey
wrote:
> I assume that this is so that the kernel can apply quirks/limits in
> cases where it knows it needs to? I think it would be nice to put at
> least a few words indicating "why", otherwise this feels like an
> arbitrary commandment with
On 2020-10-21 10:35 a.m., Ville Syrjälä wrote:
On Tue, Oct 20, 2020 at 09:46:30PM -0400, Vitaly Prosyak wrote:
On 2020-10-20 11:04 a.m., Ville Syrjälä wrote:
On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
On Fri, 16 Oct 2020
On Tue, Oct 20, 2020 at 09:46:30PM -0400, Vitaly Prosyak wrote:
>
> On 2020-10-20 11:04 a.m., Ville Syrjälä wrote:
> > On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
> >> On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
> >>> On Fri, 16 Oct 2020 16:50:16 +0300
> >>> Ville Syrjälä
On 2020-10-20 11:04 a.m., Ville Syrjälä wrote:
On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
On Fri, 16 Oct 2020 16:50:16 +0300
Ville Syrjälä wrote:
On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
On Fri, 9
On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
>
> On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
> > On Fri, 16 Oct 2020 16:50:16 +0300
> > Ville Syrjälä wrote:
> >
> >> On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
> >>> On Fri, 9 Oct 2020 17:20:18 +0300
>
On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
On Fri, 16 Oct 2020 16:50:16 +0300
Ville Syrjälä wrote:
On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
On Fri, 9 Oct 2020 17:20:18 +0300
Ville Syrjälä wrote:
On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
On Fri, 16 Oct 2020 16:50:16 +0300
Ville Syrjälä wrote:
> On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
> > On Fri, 9 Oct 2020 17:20:18 +0300
> > Ville Syrjälä wrote:
> >
> > > On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
> > > > On Fri, 9 Oct 2020
On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
> On Fri, 9 Oct 2020 17:20:18 +0300
> Ville Syrjälä wrote:
>
> > On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
> > > On Fri, 9 Oct 2020 16:10:25 +0300
> > > Ville Syrjälä wrote:
> > >
> > > > On Fri, Oct 09,
On Fri, 9 Oct 2020 17:20:18 +0300
Ville Syrjälä wrote:
> On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
> > On Fri, 9 Oct 2020 16:10:25 +0300
> > Ville Syrjälä wrote:
> >
> > > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
> > > > Hi,
> > > >
> > > > On
On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
> On Fri, 9 Oct 2020 16:10:25 +0300
> Ville Syrjälä wrote:
>
> > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
> > > Hi,
> > >
> > > On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote:
> > > > User-space should avoid
On Fri, 9 Oct 2020 16:10:25 +0300
Ville Syrjälä wrote:
> On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
> > Hi,
> >
> > On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote:
> > > User-space should avoid parsing EDIDs for metadata already exposed via
> > > other KMS interfaces and
On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
> Hi,
>
> On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote:
> > User-space should avoid parsing EDIDs for metadata already exposed via
> > other KMS interfaces and properties. For instance, user-space should not
> > try to extract a list
Hi,
On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because
On Fri, 9 Oct 2020 11:48:44 +0200
Thomas Zimmermann wrote:
> Hi
>
> Am 09.10.20 um 11:24 schrieb Simon Ser:
> > User-space should avoid parsing EDIDs for metadata already exposed via
> > other KMS interfaces and properties. For instance, user-space should not
> > try to extract a list of modes
On Fri, Oct 09, 2020 at 09:24:01AM +, Simon Ser wrote:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list
Hi
Am 09.10.20 um 11:48 schrieb Thomas Zimmermann:
> Hi
>
> Am 09.10.20 um 11:24 schrieb Simon Ser:
>> User-space should avoid parsing EDIDs for metadata already exposed via
>> other KMS interfaces and properties. For instance, user-space should not
>> try to extract a list of modes from the
Hi
Am 09.10.20 um 11:24 schrieb Simon Ser:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of link
On Fri, Oct 9, 2020 at 11:24 AM Simon Ser wrote:
>
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because
User-space should avoid parsing EDIDs for metadata already exposed via
other KMS interfaces and properties. For instance, user-space should not
try to extract a list of modes from the EDID: the kernel might mutate
the mode list (because of link capabilities or quirks for instance).
Other metadata
19 matches
Mail list logo
