Re: [PATCH v2 xserver] os,dix: rename *.O to *.a

2017-02-13 Thread Alan Coopersmith 

On 02/11/17 09:31 PM, Alan Coopersmith wrote:

Sorry, this patch breaks the generation of the dtrace objects
on Solaris, and results in the Xorg binary failing to link with:


BTW, I should mention that this was an incorrect assumption:


On 02/ 9/17 09:47 PM, Mihail Konev wrote:

Libtool was moving the *.O libraries in front of all others on
the gcc command line, which was necessiating "ld -r"
(so that symbols from now-moved os.O are visible from the following
libs), which, in turn, was altering the linker behaviour against os/
and dix/ between with-/usr/bin/dtrace and --with-dtrace=no builds.


ld -r was used not because of libtool, but because the dtrace data in the
ELF files gets properly included in a relocatable object, but not a static
library.  (This is probably because of a misuse of ELF by dtrace, but that's
the way it works, and has for over a decade.)

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

2017-02-13 Thread Manasi Navare 
On Mon, Feb 13, 2017 at 01:05:17PM -0800, Eric Anholt wrote:
> Martin Peres  writes:
> 
> > On 06/02/17 17:50, Martin Peres wrote:
> >> On 03/02/17 10:04, Daniel Vetter wrote:
> >>> On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
>  On 01/02/17 22:05, Manasi Navare wrote:
> > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> >> Jani Nikula  writes:
> >>
> >>> On Tue, 31 Jan 2017, Eric Anholt  wrote:
>  Martin Peres  writes:
> 
> > Despite all the careful planing of the kernel, a link may become
> > insufficient to handle the currently-set mode. At this point, the
> > kernel should mark this particular configuration as being broken
> > and potentially prune the mode before setting the offending
> > connector's
> > link-status to BAD and send the userspace a hotplug event. This may
> > happen right after a modeset or later on.
> >
> > When available, we should use the link-status information to reset
> > the wanted mode.
> >
> > Signed-off-by: Martin Peres 
>  If I understand this right, there are two failure modes being
>  handled:
> 
>  1) A mode that won't actually work because the link isn't good
>  enough.
> 
>  2) A mode that should work, but link parameters were too
>  optimistic and
>  if we just ask the kernel to set the mode again it'll use more
>  conservative parameters that work.
> 
>  This patch seems good for 2).  For 1), the drmmode_set_mode_major is
>  going to set our old mode back.  Won't the modeset then fail to link
>  train again, and bring us back into this loop?  The only escape
>  that I
>  see would be some other userspace responding to the advertised
>  mode list
>  changing, and then asking X to modeset to something new.
> 
>  To avoid that failure busy loop, should we re-fetching modes at this
>  point, and only re-setting if our mode still exists?
> >>> Disclaimer: I don't know anything about the internals of the
> >>> modesetting
> >>> driver.
> >>>
> >>> Perhaps we can identify the two cases now, but I'd put this more
> >>> generally: if the link status has gone bad, it's an indicator to
> >>> userspace that the circumstances may have changed, and userspace
> >>> should
> >>> query the kernel for the list of available modes again. It should no
> >>> longer trust information obtained prior to getting the bad link
> >>> status,
> >>> including the current mode.
> >>>
> >>> But specifically, I think you're right, and AFAICT asking for the
> >>> list
> >>> of modes again is the only way for the userspace to distinguish
> >>> between
> >>> the two cases. I don't think there's a shortcut for deciding the
> >>> current
> >>> mode is still valid.
> >> To avoid the busy-loop problem, I think I'd like this patch to
> >> re-query
> >> the kernel to ask about the current mode list, and only try to re-set
> >> the mode if our mode is still there.
> >>
> >> If the mode isn't there, then it's up to the DE to take action in
> >> response to the notification of new modes.  If you don't have a DE to
> >> take appropriate action, you're kind of out of luck.
> >>
> >> As far as the ABI goes, this seems fine to me.  The only concern I had
> >> about ABI was having to walk all the connectors on every uevent to see
> >> if any had gone bad -- couldn't we have a flag of some sort about what
> >> the uevent indicates?  But uevents should be super rare, so I'd say
> >> the
> >> kernel could go ahead with the current plan.
> > Yes I agree. The kernel sets the link status BAD as soona s link
> > training fails
> > but does not prune the modes until a new modelist is requested by
> > the userspace.
> > So this patch should re query the mode list as soon as it sees the
> > link status
> > BAD in order for the kernel to validate the modes again based on new
> > link
> > paarmeters and send a new mode list back.
>  Seems like a bad behaviour from the kernel, isn't it? It should return
>  immediatly
>  if the mode is gonna be pruned :s
> >>> The mode list pruning isn't relevant for modeesets, the kernel doesn't
> >>> validate requested modes against that. The mode list is purely for
> >>> userspace's information. Which means updating it only when userspace asks
> >>> for it is fine.
> >>
> >> Hmm, ok. Fair enough!
> >>
> >>> I also thought some more about the loop when we're stuck on BAD, and I
> >>> think it shouldn't happen: When the link goes BAD we update the link
>

Re: [PATCH xserver] glamor: Paint first and last pixel of lines

2017-02-13 Thread Adam Jackson 
On Mon, 2017-02-13 at 14:54 -0800, Keith Packard wrote:

> X doesn't put any hard requirements on 0-width lines though; why do
> we think we can't use whatever GL does for this?

fb has been the only extant renderer for nearly nine years. Clearly
there exists code that expects it. I'm not convinced that pushing back
on that expectation is a good move, technically correct though it may
be.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] glamor: Paint first and last pixel of lines

2017-02-13 Thread Keith Packard 
Eric Anholt  writes:

> Yeah, I basically think that using GL lines ever is a mistake.  They're
> simple, fast, and wrong.  You wish the hardware did the thing you think
> is sensible, but it doesn't.

X doesn't put any hard requirements on 0-width lines though; why do we
think we can't use whatever GL does for this?

> I think one of our rendering requirements is that GXcopy and then
> GXinvert of that line erases it, which means we can't even do this just
> for GXcopy.

Yeah, we do need to use the same code for all rasterops (and dashing).

> Alternative: Could we draw a short line into a little pixmap at startup,
> and decide if the hardware renders things well enough that our current
> line code is usable?

maybe?

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] glamor: Paint first and last pixel of lines

2017-02-13 Thread Keith Packard 
Adam Jackson  writes:

> Is there some reason you believe GL's rasterisation rules for lines
> match fb's zero-width lines? Section 14.5.1 of the 4.5 spec looks quite
> a bit looser than fb to me.

I think they're 'good enough'; there aren't any rules requiring
particular rasterization for either, the only thing X requests is that
'not last' cap mode not draw the last pixel. afaict, GL suggests 'not
last' as the only option. It sounds like some drivers are doing both
'not last' and 'not first' though?

The more serious problem is that dashing isn't working, and that's just
bugs (either driver or glamor) as dashing is done in the fragment
shader.

I guess we could just run some tests at server startup to see what kind
of rasterization the driver was performing and compensate? Do a survey
of current results and try to come up with some bright-line tests to
distinguish between them, maybe bailing to MI if we get inconsistent results?

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] glamor: Paint first and last pixel of lines

2017-02-13 Thread Eric Anholt 
Adam Jackson  writes:

> On Mon, 2017-02-13 at 09:42 -0800, Keith Packard wrote:
>> Max Staudt  writes:
>> 
>> > Okay, so do you think we can take the patch for the GXcopy case,
>> > and fall back to mi otherwise?
>> 
>> We shouldn't mask driver bugs like this; is there some reason you
>> believe we can't actually go get the GL drivers to work right?
>
> Is there some reason you believe GL's rasterisation rules for lines
> match fb's zero-width lines? Section 14.5.1 of the 4.5 spec looks quite
> a bit looser than fb to me.

Yeah, I basically think that using GL lines ever is a mistake.  They're
simple, fast, and wrong.  You wish the hardware did the thing you think
is sensible, but it doesn't.

I think one of our rendering requirements is that GXcopy and then
GXinvert of that line erases it, which means we can't even do this just
for GXcopy.  If so, the only answer I see is to punt to mi (sadly) until
we write the fb rasterization in a fragment shader.

Alternative: Could we draw a short line into a little pixmap at startup,
and decide if the hardware renders things well enough that our current
line code is usable?


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

2017-02-13 Thread Eric Anholt 
Martin Peres  writes:

> On 06/02/17 17:50, Martin Peres wrote:
>> On 03/02/17 10:04, Daniel Vetter wrote:
>>> On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
 On 01/02/17 22:05, Manasi Navare wrote:
> On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
>> Jani Nikula  writes:
>>
>>> On Tue, 31 Jan 2017, Eric Anholt  wrote:
 Martin Peres  writes:

> Despite all the careful planing of the kernel, a link may become
> insufficient to handle the currently-set mode. At this point, the
> kernel should mark this particular configuration as being broken
> and potentially prune the mode before setting the offending
> connector's
> link-status to BAD and send the userspace a hotplug event. This may
> happen right after a modeset or later on.
>
> When available, we should use the link-status information to reset
> the wanted mode.
>
> Signed-off-by: Martin Peres 
 If I understand this right, there are two failure modes being
 handled:

 1) A mode that won't actually work because the link isn't good
 enough.

 2) A mode that should work, but link parameters were too
 optimistic and
 if we just ask the kernel to set the mode again it'll use more
 conservative parameters that work.

 This patch seems good for 2).  For 1), the drmmode_set_mode_major is
 going to set our old mode back.  Won't the modeset then fail to link
 train again, and bring us back into this loop?  The only escape
 that I
 see would be some other userspace responding to the advertised
 mode list
 changing, and then asking X to modeset to something new.

 To avoid that failure busy loop, should we re-fetching modes at this
 point, and only re-setting if our mode still exists?
>>> Disclaimer: I don't know anything about the internals of the
>>> modesetting
>>> driver.
>>>
>>> Perhaps we can identify the two cases now, but I'd put this more
>>> generally: if the link status has gone bad, it's an indicator to
>>> userspace that the circumstances may have changed, and userspace
>>> should
>>> query the kernel for the list of available modes again. It should no
>>> longer trust information obtained prior to getting the bad link
>>> status,
>>> including the current mode.
>>>
>>> But specifically, I think you're right, and AFAICT asking for the
>>> list
>>> of modes again is the only way for the userspace to distinguish
>>> between
>>> the two cases. I don't think there's a shortcut for deciding the
>>> current
>>> mode is still valid.
>> To avoid the busy-loop problem, I think I'd like this patch to
>> re-query
>> the kernel to ask about the current mode list, and only try to re-set
>> the mode if our mode is still there.
>>
>> If the mode isn't there, then it's up to the DE to take action in
>> response to the notification of new modes.  If you don't have a DE to
>> take appropriate action, you're kind of out of luck.
>>
>> As far as the ABI goes, this seems fine to me.  The only concern I had
>> about ABI was having to walk all the connectors on every uevent to see
>> if any had gone bad -- couldn't we have a flag of some sort about what
>> the uevent indicates?  But uevents should be super rare, so I'd say
>> the
>> kernel could go ahead with the current plan.
> Yes I agree. The kernel sets the link status BAD as soona s link
> training fails
> but does not prune the modes until a new modelist is requested by
> the userspace.
> So this patch should re query the mode list as soon as it sees the
> link status
> BAD in order for the kernel to validate the modes again based on new
> link
> paarmeters and send a new mode list back.
 Seems like a bad behaviour from the kernel, isn't it? It should return
 immediatly
 if the mode is gonna be pruned :s
>>> The mode list pruning isn't relevant for modeesets, the kernel doesn't
>>> validate requested modes against that. The mode list is purely for
>>> userspace's information. Which means updating it only when userspace asks
>>> for it is fine.
>>
>> Hmm, ok. Fair enough!
>>
>>> I also thought some more about the loop when we're stuck on BAD, and I
>>> think it shouldn't happen: When the link goes BAD we update the link
>>> parameter values to the new limits, and the kernel will reject any mode
>>> that won't fit anymore. Of course you might be unlucky, and the new link
>>> limits are also not working, but eventually you're stuck at the "you're
>>> link is broken, sry" stage,

Re: [PATCH xserver] glamor: Paint first and last pixel of lines

2017-02-13 Thread Adam Jackson 
On Mon, 2017-02-13 at 09:42 -0800, Keith Packard wrote:
> Max Staudt  writes:
> 
> > Okay, so do you think we can take the patch for the GXcopy case,
> > and fall back to mi otherwise?
> 
> We shouldn't mask driver bugs like this; is there some reason you
> believe we can't actually go get the GL drivers to work right?

Is there some reason you believe GL's rasterisation rules for lines
match fb's zero-width lines? Section 14.5.1 of the 4.5 spec looks quite
a bit looser than fb to me.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] glamor: Paint first and last pixel of lines

2017-02-13 Thread Keith Packard 
Max Staudt  writes:

> Okay, so do you think we can take the patch for the GXcopy case, and fall
> back to mi otherwise?

We shouldn't mask driver bugs like this; is there some reason you
believe we can't actually go get the GL drivers to work right?

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] glamor: Paint first and last pixel of lines

2017-02-13 Thread Max Staudt 
On 02/08/2017 06:30 PM, Adam Jackson wrote:
> I think, practically speaking, that glamor needs to match fb even along
> the corner cases where the X spec allows driver-dependent behavior. The
> simplest way to do this for this case would be to fall down to the mi
> line code for the case of non-trivial cap style and rop that reads the
> destination; if done correctly this will still be "accelerated" in that
> we'll still hit glamor's SetSpans path.

Okay, so do you think we can take the patch for the GXcopy case, and fall
back to mi otherwise?


And how about https://bugs.freedesktop.org/show_bug.cgi?id=99708 - should
we fall back to mi until we have a better approximation in GLAMOR?

It's sad to see acceleration go, but currently it seems to create a lot of
confusion. And raw X11 ops are barely used (if at all) in average modern
desktop environments.



Max

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel