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

[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

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

Michel Dänzer  changed:

   What|Removed |Added

  Component|Driver/AMDgpu   |DRM/AMDgpu
Product|xorg|DRI
 CC||harry.wentl...@amd.com
 QA Contact|xorg-t...@lists.x.org   |
   Assignee|xorg-driver-ati@lists.x.org |dri-devel@lists.freedesktop
   ||.org

--- Comment #11 from Michel Dänzer  ---
Anyway, this is likely a kernel driver issue.

Harry / DC folks, can you take a look?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

--- Comment #10 from Matthew Treinish  ---
Created attachment 129577
  --> https://bugs.freedesktop.org/attachment.cgi?id=129577=edit
xorg log when running with amd-staging-4.9 kernel

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

--- Comment #9 from Matthew Treinish  ---
Created attachment 129576
  --> https://bugs.freedesktop.org/attachment.cgi?id=129576=edit
xrandr output when running with amd-staging-4.9 branch kernel

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

--- Comment #8 from Matthew Treinish  ---
Created attachment 129575
  --> https://bugs.freedesktop.org/attachment.cgi?id=129575=edit
dmesg output grepped for drm or amdgpu with kernel built from amd-staging-4.9

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

--- Comment #7 from Matthew Treinish  ---
Created attachment 129574
  --> https://bugs.freedesktop.org/attachment.cgi?id=129574=edit
Picture of broken output with amd-staging-4.9 kernel

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

--- Comment #6 from Matthew Treinish  ---
I just ran with the kernel built from the current head of the amd-staging-4.9
branch and still had the same problem. I'll upload the logs from this too. The
weird tiling got a bit stranger this time with things being the corners and
more things scrolling

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #129570|text/x-log  |text/plain
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

--- Comment #5 from Matthew Treinish  ---
Thanks, I wasn't aware of that. I have not tried running from that branch, I'm
just using what comes in the archlinux packages. I'll build that and give it a
try.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

--- Comment #4 from Matthew Treinish  ---
Created attachment 129572
  --> https://bugs.freedesktop.org/attachment.cgi?id=129572=edit
xrandr output when display output is like in picture

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

--- Comment #3 from Matthew Treinish  ---
Created attachment 129571
  --> https://bugs.freedesktop.org/attachment.cgi?id=129571=edit
The dmesg output related to drm and amdgpu

I'm not sure what else you need from the dmesg output, this was all I found
related to graphics card

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

--- Comment #2 from Matthew Treinish  ---
Created attachment 129570
  --> https://bugs.freedesktop.org/attachment.cgi?id=129570=edit
xorg log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

--- Comment #1 from Michel Dänzer  ---
Please attach the Xorg log and the output of dmesg and xrandr corresponding to
the problem.

Assuming you aren't already, using the amdgpu driver from the amd-staging-4.9
branch of https://cgit.freedesktop.org/~agd5f/linux/ with CONFIG_DRM_AMD_DC
enabled might help.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99801] New: Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99801

Bug ID: 99801
   Summary: Rx480 doesn't output properly onto z27q at 5120x2880
   Product: xorg
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: major
  Priority: medium
 Component: Driver/AMDgpu
  Assignee: xorg-driver-ati@lists.x.org
  Reporter: mtrein...@kortar.org
QA Contact: xorg-t...@lists.x.org

Created attachment 129569
  --> https://bugs.freedesktop.org/attachment.cgi?id=129569=edit
Example output when X first starts

I have a a z27q monitor and an rx480 gpu I've just purchased. When I startx on
the machine trying to run the monitor at it's native 5120x2880 across the 2
display ports doesn't work. The output is divided with the image mirrored
across both halves of the screen. Then one half is itself split in 2 with a
negative image that is scrolling horizontally. I took a picture with my
cellphone, since a screenshot showed the proper image.

I'm currently running the monitor over the single display port at a lower
resolution of 3840x2160 (albeit with heavy flickering, which I think is a
separate if not related issue)

The current output of xrandr is:

Screen 0: minimum 320 x 200, current 5040 x 2160, maximum 16384 x 16384
DisplayPort-0 connected primary 3840x2160+1200+0 (normal left inverted right x
axis y axis) 597mm x 336mm
   2560x2880 59.98 +
   2560x1440 59.95 +
   3840x2160 60.00* 
   1920x1080 60.00  
   1600x900  60.00  
   1366x768  59.99  
   1280x720  60.0059.94  
   1024x768  60.00  
   800x600   60.32  
   640x480   60.0059.94  
DisplayPort-1 connected (normal left inverted right x axis y axis)
   2560x2880 59.98 +
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
HDMI-A-0 connected 1200x1920+0+0 left (normal left inverted right x axis y
axis) 474mm x 296mm
   1920x1200 59.95*+
   1920x1080 60.00  
   1600x1200 60.00  
   1680x1050 59.88  
   1400x1050 59.95  
   1280x1024 75.0260.02  
   1440x900  74.9859.90  
   1024x768  75.0370.0760.00  
   800x600   72.1975.0060.32

This might just be a configuration issue as I'm not used to the KMS way of
doing things. (I previously had an nvidia gpu using their binary blob on this
display without issue) But, from what I can tell things are being configured to
do the right thing automatically and it is not rendered properly over the wire.
(especially because when I tried to take a screenshot of the issue it looked
like it was supposed to)

I apologize that bug report lacks concrete details I'm willing to provide
whatever information is necessary to debug this. I'm just not sure where to
begin.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99769] RADEON(0): flip queue failed in radeon_scanout_flip: Cannot allocate memory

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99769

--- Comment #4 from Michel Dänzer  ---
There's no direct interaction between application OpenGL stuff and the failing
code in the Xorg driver. The only thing I can imagine is that QGLPixelBuffer
might leak OpenGL resources, which might ultimately prevent the dedicated
scanout buffers used for TearFree from fitting into VRAM. It seems rather
unlikely that this could happen with current xf86-video-ati though.

BTW, the original bug description mentions xserver-xorg-video-ati
7.8.99+git1702081933.1351e4~gd~x, but the attached Xorg log file shows version
7.7.0 being used. Did you actually test xf86-video-ati newer than 7.7.0?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

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

[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

[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

[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

[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

[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

[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: inexplicable fallback mode used when preferred mode 2560x1080 not supported by connection

[Felix Miata]

Adam Jackson composed on 2017-02-13 11:27 (UTC-0500):


On Sun, 2017-02-12 at 05:10 -0500, Felix Miata wrote:



http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log-big31-ostw-d2913wm.txt is
Xorg.0.log plus output from inxi -c0 -G, hwinfo --gfxcard and xrandr from a
GT210[1] on host big31 booted to openSUSE Tumbleweed and modesetting driver,
which falls to 1400x1050 using an HDMI cable. Using instead nouveau, fall is to
1152x864, same as same PC booted to openSUSE 42.1 using HDMI and modesetting
driver, and same PC booted to Fedora 25 using HDMI and nouveau driver.



Can you add Option "ModeDebug" "true" to your Device section in
xorg.conf and give the log from that?




http://fm.no-ip.com/Tmp/Linux/Xorg/get-edid-big41-d2913wm-hdmi-deb9.txt is the 
output from 'get-edid | parse-edid' running TDE on Sid fallen back to 1152x864 
mode using modesetting driver and HDMI on Intel gfx host big41, where mode 
details for 0 and 17 are conspicuously absent.


http://fm.no-ip.com/Tmp/Linux/Xorg/get-edid-big41-d2913wm-vga-deb9.txt is the 
output from 'get-edid | parse-edid' running TDE on Sid running native mode 
2560x1080 using modesetting driver and VGA on Intel gfx host big41, where 
extension block is conspicuously absent, and output sharpness is very poor 
compared to same display running 2560x1080 via either DVI or DisplayPort inputs.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

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

[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

[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: inexplicable fallback mode used when preferred mode 2560x1080 not supported by connection

[Adam Jackson]

On Sun, 2017-02-12 at 05:10 -0500, Felix Miata wrote:

> http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log-big31-ostw-d2913wm.txt is 
> Xorg.0.log plus output from inxi -c0 -G, hwinfo --gfxcard and xrandr from a 
> GT210[1] on host big31 booted to openSUSE Tumbleweed and modesetting driver, 
> which falls to 1400x1050 using an HDMI cable. Using instead nouveau, fall is 
> to 
> 1152x864, same as same PC booted to openSUSE 42.1 using HDMI and modesetting 
> driver, and same PC booted to Fedora 25 using HDMI and nouveau driver.

Can you add Option "ModeDebug" "true" to your Device section in
xorg.conf and give the log from that?

- ajax
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[Bug 99769] RADEON(0): flip queue failed in radeon_scanout_flip: Cannot allocate memory

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99769

--- Comment #3 from jorge_monteag...@hotmail.com ---
I've track down the problem to some code handling OpenGL contexts in my
application.

In catalyst and nvidia the code works OK but with the radeon/amdgpu driver
makes the screen paint with artifacts and the 'Cannot allocate memory' trace in
Xorg log.

I'm using Qt5 and SDL libraries. The problematic code is:

static GLXContext defaultContext = NULL;
static GLXContext qtContext  = NULL;
static QGLPixelBuffer* pixelBuffer = NULL;
...
pixelBuffer = new QGLPixelBuffer (QSize (1,1), QGLFormat::defaultFormat ());
pixelBuffer->makeCurrent();

qtContext = glXGetCurrentContext();

// create default context
defaultContext = CreateOGLContext (qtContext);

// activate it, hiding context created by SDL
ActivateOGLContext (defaultContext);


Then all the OpenGL objects are created in this 'defaultContext' and something
makes not happy the OpenGL stack. Removing the QGLPixelBuffer and using the
default OpenGL context created by SDL makes the trick but I can't use the Qt5
with his own context.

Well, I'll try to isolate a minimum example to replicate this problem, but for
now I can run my app.

Thanks!




The rest of code:

GLXContext CreateOGLContext(GLXContext share)
{
GLXContext ctx = NULL;

// Set error handler
int32_t (*oldHandler)(Display*, XErrorEvent*) = XSetErrorHandler(
 );

// Flush errors
XSync( m_sdl_info.info.x11.display, False );

// Get window attributes
XWindowAttributes xWindowAttribs;
XGetWindowAttributes( m_sdl_info.info.x11.display,
m_sdl_info.info.x11.window,  );

// Get visual id from current display
XVisualInfo visualInfo;
int32_t numItems;

visualInfo.visualid = XVisualIDFromVisual( xWindowAttribs.visual );

// Get visual info matching the desired visual id
XVisualInfo* pVisualInfo = XGetVisualInfo( m_sdl_info.info.x11.display,
   
   VisualIDMask,
   
   ,
   
);
if (!pVisualInfo)
{
fprintf( stderr, "[CreateOGLContext] Error obtaining visual
info\n" );
}
else
{
// Print selected visual
// fprintf( stderr, "[CreateOGLContext] Visual 0x%x has been
selected\n", (uint32_t)pVisualInfo->visualid );

// Create new context sharing display lists with current one
Bool bDirect = share? glXIsDirect( m_sdl_info.info.x11.display,
share ) : True;

ctx = glXCreateContext( m_sdl_info.info.x11.display,
pVisualInfo, share, bDirect );

// Flush errors
XSync( m_sdl_info.info.x11.display, False );

// Free visual info
XFree( pVisualInfo );
}

XSetErrorHandler( oldHandler );

return ctx;
}


int ActivateOGLContext( GLXContext ctx )
{
// Default returns TRUE! This avoid to do checks when no contexts are
enabled.
int ret = 1;

// Check OpenGL contexts allowed or if we're activating current context
if( ctx == glXGetCurrentContext () )
return ret;

XLockDisplay( m_sdl_info.info.x11.display );

ret = glXMakeCurrent( m_sdl_info.info.x11.display, (ctx == NULL)? None
: m_sdl_info.info.x11.window, ctx );

XSync( m_sdl_info.info.x11.display, False );

XUnlockDisplay( m_sdl_info.info.x11.display );
return ret;
}

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

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

[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

[Bug 99457] Excessive CPU load by the xorg-server and GUI's hard lags

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99457

--- Comment #31 from Eugenij Shkrigunov  ---
Thank you. I wrote to bug report for tigervnc:
https://github.com/TigerVNC/tigervnc/issues/401 about comment #30

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99457] Excessive CPU load by the xorg-server and GUI's hard lags

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99457

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #30 from Michel Dänzer  ---
Thanks, now I understand what's happening:

It's a bug in the tigervnc vncHooksBlockHandler function, it doesn't handle the
function wrapping correctly: It keeps calling RADEONBlockHandler_oneshot,
although that function sets pScreen->BlockHandler = RADEONBlockHandler_KMS.
vncHooksBlockHandler needs to re-retrieve the current pScreen->BlockHandler
pointer after calling it.

Though if it turns out difficult to get this fixed in tigervnc, we can consider
a workaround.

P.S. This would also happen with the modesetting driver as of xserver 1.19.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99457] Excessive CPU load by the xorg-server and GUI's hard lags

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99457

--- Comment #28 from Eugenij Shkrigunov  ---
Created attachment 129550
  --> https://bugs.freedesktop.org/attachment.cgi?id=129550=edit
Data for sysprof

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99457] Excessive CPU load by the xorg-server and GUI's hard lags

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99457

--- Comment #29 from Eugenij Shkrigunov  ---
Created attachment 129551
  --> https://bugs.freedesktop.org/attachment.cgi?id=129551=edit
gdb output

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99457] Excessive CPU load by the xorg-server and GUI's hard lags

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99457

--- Comment #27 from Eugenij Shkrigunov  ---
(In reply to Michel Dänzer from comment #26)
> 1. Make sure /usr/bin/Xorg and /usr/lib64/xorg/modules/drivers/radeon_drv.so
> are compiled with -fno-omit-frame-pointer (after any -O2/-O3 etc. flags),
> and get another profile with sysprof.

I compiled xorg-server, xf86-video-ati with CFLAGS="-ggdb2 -O1
-fno-omit-frame-pointer -pipe"

Data for sysprof and gdb output in the next attachments.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 99457] Excessive CPU load by the xorg-server and GUI's hard lags

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99457

--- Comment #26 from Michel Dänzer  ---
Thanks, this helps a little. Unfortunately though, it's still not clear where
drmmode_set_mode_major is getting called from. There are two possibilities for
getting better information about that:

1. Make sure /usr/bin/Xorg and /usr/lib64/xorg/modules/drivers/radeon_drv.so
are compiled with -fno-omit-frame-pointer (after any -O2/-O3 etc. flags), and
get another profile with sysprof.

2. Attach gdb to the Xorg process, and enter the following at the gdb prompt:

b drmmode_set_mode_major
commands 1
bt full
c
end
continue

After that, gdb should start spewing backtraces of where drmmode_set_mode_major
gets called from. You can interrupt it with Ctrl-C after a few seconds, then
attach the backtraces here.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati