Re: [JANITOR] Request for review

[Keith Packard]

Kayo Hamid  writes:

> I'm trying to do one janitor task looking for bad allocations. Someone
> could review my diff and see if is okay?
>
> Thanks.
>
> -- 
> Kayo Hamid
> diff --git a/dix/enterleave.c b/dix/enterleave.c
> index 1b341f2..8cec9a2 100644
> --- a/dix/enterleave.c
> +++ b/dix/enterleave.c
> @@ -715,6 +715,13 @@ DeliverStateNotifyEvent(DeviceIntPtr dev, WindowPtr win)
>  }
>  
>  sev = ev = xallocarray(evcount, sizeof(xEvent));
> +
> +if(!ev) {
> +free(ev);
> +free(sev);
> +return BadAlloc;
> +}
> +

Good catch on the allocation failure, but in this case you don't need to
free anything, and you should make sure your code compiles without
warnings as this function is void, and so wouldn't need a return value.

-- 
-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

[JANITOR] Request for review

[Kayo Hamid]

I'm trying to do one janitor task looking for bad allocations. Someone
could review my diff and see if is okay?

Thanks.

-- 
Kayo Hamid
diff --git a/dix/enterleave.c b/dix/enterleave.c
index 1b341f2..8cec9a2 100644
--- a/dix/enterleave.c
+++ b/dix/enterleave.c
@@ -715,6 +715,13 @@ DeliverStateNotifyEvent(DeviceIntPtr dev, WindowPtr win)
 }
 
 sev = ev = xallocarray(evcount, sizeof(xEvent));
+
+if(!ev) {
+free(ev);
+free(sev);
+return BadAlloc;
+}
+
 FixDeviceStateNotify(dev, ev, NULL, NULL, NULL, first);
 
 if (b != NULL) {
___
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

[PATCH 7/7] drm/dp_helper: Rate limit timeout errors from drm_dp_i2c_do_msg()

[Lyude]

Timeouts can be errors, but timeouts are also usually normal behavior
and happen a lot. Since the kernel already lets us know when we're
suppressing messages due to rate limiting, rate limit timeout errors so
we don't make too much noise in the kernel log.

Signed-off-by: Lyude 
---
 drivers/gpu/drm/drm_dp_helper.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 43be189..5ca72d25 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -574,7 +574,17 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg)
if (ret == -EBUSY)
continue;
 
-   DRM_DEBUG_KMS("transaction failed: %d\n", ret);
+   /*
+* While timeouts can be errors, they're usually normal
+* behavior (for instance, when a driver tries to
+* communicate with a non-existant DisplayPort device).
+* Avoid spamming the kernel log with timeout errors.
+*/
+   if (ret == -ETIMEDOUT)
+   DRM_DEBUG_KMS_RATELIMITED("transaction timed 
out\n");
+   else
+   DRM_DEBUG_KMS("transaction failed: %d\n", ret);
+
return ret;
}
 
-- 
2.7.4

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[PATCH 6/7] drm: Add ratelimited versions of the DRM_DEBUG* macros

[Lyude]

There's a couple of places where this would be useful for drivers (such
as reporting DP aux transaction timeouts).

Signed-off-by: Lyude 
---
 include/drm/drmP.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d377865..1c4d91b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -231,6 +231,36 @@ void drm_err(const char *format, ...);
drm_ut_debug_printk(__func__, fmt, ##args); \
} while (0)
 
+#define _DRM_DEFINE_DEBUG_RATELIMITED(level, fmt, args...) \
+   do {\
+   if (unlikely(drm_debug & DRM_UT_ ## level)) {   \
+   static DEFINE_RATELIMIT_STATE(  \
+   _rs,\
+   DEFAULT_RATELIMIT_INTERVAL, \
+   DEFAULT_RATELIMIT_BURST);   \
+   \
+   if (__ratelimit(&_rs)) {\
+   drm_ut_debug_printk(__func__, fmt,  \
+   ##args);\
+   }   \
+   }   \
+   } while (0)
+
+/**
+ * Rate limited debug output. Like DRM_DEBUG() but won't flood the log.
+ *
+ * \param fmt printf() like format string.
+ * \param arg arguments
+ */
+#define DRM_DEBUG_RATELIMITED(fmt, args...)\
+   _DRM_DEFINE_DEBUG_RATELIMITED(CORE, fmt, ##args)
+#define DRM_DEBUG_DRIVER_RATELIMITED(fmt, args...) \
+   _DRM_DEFINE_DEBUG_RATELIMITED(DRIVER, fmt, ##args)
+#define DRM_DEBUG_KMS_RATELIMITED(fmt, args...)
\
+   _DRM_DEFINE_DEBUG_RATELIMITED(KMS, fmt, ##args)
+#define DRM_DEBUG_PRIME_RATELIMITED(fmt, args...)  \
+   _DRM_DEFINE_DEBUG_RATELIMITED(PRIME, fmt, ##args)
+
 /*@}*/
 
 /***/
-- 
2.7.4

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[PATCH 1/7] drm/dp_helper: Print first error received on failure in drm_dp_dpcd_access()

[Lyude]

Since we always retry in drm_dp_dpcd_access() regardless of the error,
we're going to make a lot of noise if the aux->transfer function prints
it's own errors (as is the case with radeon). If we can print the error
code here, this reduces the need for drivers to do this. So instead of
having to print "dp_aux_ch timed out" over 32 times we can just print
once.

Signed-off-by: Lyude 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 8f11b87..43be189 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -223,7 +223,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
err = ret;
}
 
-   DRM_DEBUG_KMS("too many retries, giving up\n");
+   DRM_DEBUG_KMS("Too many retries, giving up. First error: %d\n", err);
ret = err;
 
 unlock:
-- 
2.7.4

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[PATCH 3/7] drm/radeon: Don't retry 7 times in radeon_dp_dpcd()

[Lyude]

When this code was written, we didn't retry DP aux transactions on any
error, which required retrying important transactions like this in
individual drivers. Since that's no longer the case, retrying here is
not necessary. As well, we retry any aux transaction on any error 32
times. 7 * 32 = 224, which means this loop causes us to retry grabbing
the dpcd 224 times. This is definitely far more then we actually need to
do.

Signed-off-by: Lyude 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index cead089a..432cb46 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -389,22 +389,21 @@ bool radeon_dp_getdpcd(struct radeon_connector 
*radeon_connector)
 {
struct radeon_connector_atom_dig *dig_connector = 
radeon_connector->con_priv;
u8 msg[DP_DPCD_SIZE];
-   int ret, i;
+   int ret;
 
-   for (i = 0; i < 7; i++) {
-   ret = drm_dp_dpcd_read(_connector->ddc_bus->aux, 
DP_DPCD_REV, msg,
-  DP_DPCD_SIZE);
-   if (ret == DP_DPCD_SIZE) {
-   memcpy(dig_connector->dpcd, msg, DP_DPCD_SIZE);
+   ret = drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_DPCD_REV, 
msg,
+  DP_DPCD_SIZE);
+   if (ret == DP_DPCD_SIZE) {
+   memcpy(dig_connector->dpcd, msg, DP_DPCD_SIZE);
 
-   DRM_DEBUG_KMS("DPCD: %*ph\n", 
(int)sizeof(dig_connector->dpcd),
- dig_connector->dpcd);
+   DRM_DEBUG_KMS("DPCD: %*ph\n", (int)sizeof(dig_connector->dpcd),
+ dig_connector->dpcd);
 
-   radeon_dp_probe_oui(radeon_connector);
+   radeon_dp_probe_oui(radeon_connector);
 
-   return true;
-   }
+   return true;
}
+
dig_connector->dpcd[0] = 0;
return false;
 }
-- 
2.7.4

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[PATCH 2/7] drm/radeon: Don't print error on aux transaction timeouts

[Lyude]

Since it's normal for DRM to retry our aux transaction helpers multiple
times in a row, up to 32 times for each attempted transaction, we're
making a lot of noise that is no longer necessary now that DRM will just
print the return code we give it.

Signed-off-by: Lyude 
---
 drivers/gpu/drm/radeon/radeon_dp_auxch.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c 
b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
index db64e00..2d46564 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
@@ -164,7 +164,6 @@ radeon_dp_aux_transfer_native(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg
}
 
if (tmp & AUX_SW_RX_TIMEOUT) {
-   DRM_DEBUG_KMS("dp_aux_ch timed out\n");
ret = -ETIMEDOUT;
goto done;
}
-- 
2.7.4

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

RE: compositing enabled with Radeon mobility X300

[Jethro Tull]

From: Thomas Lübking [thomas.luebk...@gmx.de]
Sent: Friday, August 5, 2016 9:23 PM
To: Jethro Tull
Cc: x...@freedesktop.org
Subject: Re: compositing enabled with Radeon mobility X300

On Fri, Aug 05, 2016 at 09:24:01AM -0400, Alex Deucher wrote:
> How many displays are you using?  What resolution(s)?

Where did go the original email of Alex Deucher?
I mostly use only one monitor which is the LCD screen of the laptop I'm using
which is has a resolution of 1280 x 800. Sometimes I connect an external LCD
monitor set as extended desktop which resolution is 1440x900. But the problem
with slow acceleration when compositing is enabled is on, either with or without
the external monitor. On the other side, the refreshing of some windows I
described were making the screens more or less scrambled after some time of
work happens ONLY when the second monitor is on. I forgot to mention this last
point in my original email.


This translates to "the output of 'xrandr -q'" ;-)
You might also try other compositors like xcompmgr or compton to rule
out a bug in the one used (xfwm?)

yes I'm using xfwm. But I think this is the thing that is used by XFCE, which
is my desktop environment.


Finally, check the performance on low-resolution (XGA). The device is
short on RAM and compositing quite memory intense (notably in case of GL
compositing)

Other resolutions than native give an ugly thing on LCD screens. My computer
has 2 GB RAM, the video card is either 64 or 128 MB, and from what I can see in
htop there is always plenty of free RAM available most of the time. I could
nevertheless try low resolution just to see if compositing works better but I'm
not sure that would mean I was short of RAM if the acceleration problem is
partly or totally solved.


Cheers,
Thomas
___
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

When using PBOs to upload texture data, which call triggers the actual DMA operation?

[Clemens Eisserer]

Hi,

I am trying to better understand /optimize texture upload on r600 and
GCN based GPUs.

Currently I use PBOs to upload data generated by a worker thread to
textures, using the following steps:

1. Unmap buffer n (from worker)
2. glTexSubImage2D n-1 to texture n-1
3. bin texture n-2 & draw & glutSwapBuffers
4. map buffer n-3 again and pass it to worker thread

For each buffer only one step is executed per frame to avoid GPU stalls.

However, after I had a look at radeon_gem_objects I am not sure this
approach makes a lot of sence.
All PBOs are located in system memory (GTT), so as far as I understand
it, unmapping a PBO is actually a no-on and doesn't trigger any
transfer?
However, where is the actual DMA transfer triggerd - by
glTexSubImage2D? And at which point the driver checks for DMA
completion - at glutSwapBuffers?

Furthermore, is it possible to perform async upload and rendering in
parallel in case there are no data-dependencies?

Some insights would be really great to better optimize the code.

Thank you in advance & best regards, Clemens
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: Open Shared Memory and Render Pictures

[Dennis Clarke]

On 08/05/2016 12:38 PM, Ilya Anfimov wrote:

X Window Sys-
tem Protocol X Consortium Standard.


For those that want to know :

X Window System Protocol X Consortium Standard.
https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.pdf

___
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: Open Shared Memory and Render Pictures

[Ilya Anfimov]

On Fri, Aug 05, 2016 at 02:53:06PM +0200, Michael Titke wrote:

[skipped]

> 
> I'm just asking because solving a puzzle is funny but maybe someone still
> knows about those "private" protocol "mechanics".

 All of that protocol mechanics is described in the X Window Sys-
tem Protocol X Consortium Standard.
 Any your misunderstanding means that you misread  some  part  of
that book.
 There  is  no other possibilities with the CORE at your level of
confidence with the protocol.

___
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: modesetting and DRI2/3

[zahlenmeer]

This raises more questions than it answers.
The modesetting driver uses DRI3 by default, and I haven't touched the
defaults. Compiling with the --disable-dri2 flag should work, but then I
get "failed to initalize the DRI2 extension" errors in my log file.
If you say that VDPAU still relies on DRI2 I totally understand the
errors, but I don't need VDPAU (only Intel graphics, so VAAPI) and I
also don't have it installed and mesa is compiled without VDPAU support.
So why does xorg load it? (I am not sure what exactly is responsible for
the VDPAU line in my logs, but I interpret is as Xorg loading this driver)

On 08/05/16 13:09, Steven Newbury wrote:
> On Wed, 2016-07-27 at 18:24 +0200, zahlenm...@gmx.de wrote:
>> Hey everyone,
>> I am struggling to understand how the modesetting driver and DRI play
>> together.
>> This is from Xorg.0.log:
>>
>> [  2350.977] (II) Loading
>> /usr/lib/xorg/modules/drivers/modesetting_drv.so
>> [  2350.977] (II) modeset(0): using drv /dev/dri/card0
>> [  2350.984] (II) glamor: OpenGL accelerated X.org driver based.
>> [  2351.387] (II) modeset(0): [DRI2]   DRI driver: i965
>> [  2351.387] (II) modeset(0): [DRI2]   VDPAU driver: i965
>>
>> And this is from glxinfo:
>>
>> libGL: Using DRI3 for screen 0
>>
>> I read that modesetting uses DRI3 by default so I am a bit surprised
>> to
>> read something like "modeset(0): [DRI2]" in my logs. I also tried and
>> compiled xorg with the --disable-dri2 flag. In this case I get aiglx
>> errors that modesetting failed to initalize the DRI2 extension.
>> Could anyone explain this behaviour to me?
>>
>> Kind regards
>> ___
>> 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
> 
> VDPAU doesn't use DRI3 as yet, AFAIK.
> 
> DRI2 is still available unless it's build time disabled, even if DRI3
> is default.
> 
___
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: compositing enabled with Radeon mobility X300

[Alex Deucher]

On Fri, Aug 5, 2016 at 5:11 AM, Jethro Tull  wrote:
> From: Michel Dänzer [mic...@daenzer.net]
> Sent: Friday, August 5, 2016 1:41 AM
> To: Jethro Tull
> Cc: x...@freedesktop.org
> Subject: Re: compositing enabled with Radeon mobility X300
>
> On 05.08.2016 06:23, Jethro Tull wrote:
>> I'm using the kernel 4.4.14 with XFCE 4.12, as written in the subject
>> my GPU is a Radeon mobility X300 and the driver used is the open
>> source "radeon".
>>
>> I noticed that enabling compositing was resulting in very slow
>> windows manipulations like dragging, resizing, browsing them with Alt
>> + tab. It takes nearly 2 seconds to display the big contextual menu
>> when starting to browse through the windows. And I also noticed that
>> using an extended desktop on a second monitor was leading to some
>> windows not being refreshed resulting in a nearly scrambled desktop
>> after some time of use with several graphical programs. I also
>> noticed some similar problems with the terminal.
>
> Please provide the corresponding Xorg log file.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
> here it is:

Please include the full log and your dmesg output.  How many displays
are you using?  What resolution(s)?

Alex
___
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

Open Shared Memory and Render Pictures

[Michael Titke]

After some effort to modernize the IO path with shared memory segments 
XShmCreatePixmap fails with a Bad Access error. Maybe someone can 
confirm this is due to the security extension? (The actual system calls 
used and their flags correspond to the examples in the documentation of 
the X shared memory extension but then there's also version 1.2 ...)


The example setup contains a mismatch where the visual of the drawable 
should have a depth of 24 while MIT-SHM seems to ask for a format with a 
depth of 32 (if that undocumented field is interpreted correctly) but 
that should result in a Bad Match error and not in a Bad Access error.


Is it possible to use X render extension Pictures where a pixmap is 
requested in the core protocol?


I'm just asking because solving a puzzle is funny but maybe someone 
still knows about those "private" protocol "mechanics".

___
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: modesetting and DRI2/3

[Steven Newbury]

On Wed, 2016-07-27 at 18:24 +0200, zahlenm...@gmx.de wrote:
> Hey everyone,
> I am struggling to understand how the modesetting driver and DRI play
> together.
> This is from Xorg.0.log:
> 
> [  2350.977] (II) Loading
> /usr/lib/xorg/modules/drivers/modesetting_drv.so
> [  2350.977] (II) modeset(0): using drv /dev/dri/card0
> [  2350.984] (II) glamor: OpenGL accelerated X.org driver based.
> [  2351.387] (II) modeset(0): [DRI2]   DRI driver: i965
> [  2351.387] (II) modeset(0): [DRI2]   VDPAU driver: i965
> 
> And this is from glxinfo:
> 
> libGL: Using DRI3 for screen 0
> 
> I read that modesetting uses DRI3 by default so I am a bit surprised
> to
> read something like "modeset(0): [DRI2]" in my logs. I also tried and
> compiled xorg with the --disable-dri2 flag. In this case I get aiglx
> errors that modesetting failed to initalize the DRI2 extension.
> Could anyone explain this behaviour to me?
> 
> Kind regards
> ___
> 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

VDPAU doesn't use DRI3 as yet, AFAIK.

DRI2 is still available unless it's build time disabled, even if DRI3
is default.


signature.asc
Description: This is a digitally signed message part
___
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

[PATCH] Re: wrong display size

[Steven Newbury]

On Tue, 2016-06-14 at 23:46 -0400, Felix Miata wrote:
> Sebastian Gutzwiller composed on 2016-06-14 11:10 (UTC+0200):
> 
> > I have a LCD display (115 mm x 86 mm) with VGA resolution (640 x
> > 480)
> > connected over LVDS with an Intel Atom N450.
> 
> > After upgrading from Ubuntu 10.04 to 14.04  I only see the upper
> > left
> > detail of the whole screen (see attachment 'display_picture.jpg').
> 
> > The Xorg log (see attachment 'Xubuntu.14.04.4.LTS.Xorg.0.log')
> > reported
> > a physical screen size of 270 mm x 203 mm which is pretty much the
> > size
> > of the whole screen.
> 
> > Any suggestions?
> 
> Something to try (I don't have any Intel Atoms to test on):
> 
> 1.login on a vtty
> 2.sudo apt-get purge xserver-xorg-video-intel
> 3.reboot (or restart X xserver)
> 
> Reason: sometime post-server 1.16.x. the generic modesetting driver
> was moved 
> directly into the server itself. It's supposed to be competent for
> all 
> non-ancient mainstream gfxchips, a substitute for chip-specific
> drivers. If 
> it doesn't help, it's up to you whether to bother reinstalling the
> intel driver.
I made this patch a few years ago, still applies:

--- hw/xfree86/ddc/interpret_edid.c~2013-10-03 07:25:56.0 +0100
+++ hw/xfree86/ddc/interpret_edid.c 2013-10-03 07:48:55.168972224 +0100
@@ -144,6 +144,15 @@
 
 xf86ForEachDetailedBlock(m, handle_detailed_hvsize, );
 
+if ((p.real_hsize != m->features.hsize ) ||
+(p.real_vsize != m->features.vsize)) {
+xf86Msg(X_INFO, "Inconsistency in detected Display Size:\n");
+xf86Msg(X_INFO, "Monitor features physical dimensions %dx%d mm\n",
+m->features.hsize, m->features.vsize);
+xf86Msg(X_INFO, "Detailed timings physical dimensions %dx%d mm\n",
+p.real_hsize, p.real_vsize);
+}
+
 if (!p.real_hsize || !p.real_vsize) {
 m->features.hsize = m->features.vsize = 0;
 }
--- hw/xfree86/modes/xf86Crtc.c.orig2013-11-01 16:59:03.904169898 +
+++ hw/xfree86/modes/xf86Crtc.c 2013-11-01 17:06:28.387359579 +
@@ -3052,8 +3052,15 @@
  (det_mon->section.d_timings.v_size * 12)) &&
 ((det_mon->section.d_timings.v_size * 5) <
  (det_mon->section.d_timings.h_size * 12))) {
-p->output->mm_width = det_mon->section.d_timings.h_size;
-p->output->mm_height = det_mon->section.d_timings.v_size;
+if (!(p->output->conf_monitor &&
+(p->output->conf_monitor->mon_width > 0 &&
+p->output->conf_monitor->mon_height > 0))) {
+/*
+ * Do not update size if user configured DisplaySize
+ */
+p->output->mm_width = det_mon->section.d_timings.h_size;
+p->output->mm_height = det_mon->section.d_timings.v_size;
+}
 p->ret = TRUE;
 } else
 xf86DrvMsg(p->output->scrn->scrnIndex, X_WARNING,
@@ -3109,6 +3116,15 @@
 xf86OutputSetEDIDProperty(output, edid_mon ? edid_mon->rawData : NULL,
   size);
 #endif
+if (output->conf_monitor &&
+(output->conf_monitor->mon_width > 0 &&
+output->conf_monitor->mon_height > 0)) {
+/*
+ * Prefer user configured DisplaySize
+ */
+output->mm_width = output->conf_monitor->mon_width;
+output->mm_height = output->conf_monitor->mon_height;
+}
 
 if (edid_mon) {
 


signature.asc
Description: This is a digitally signed message part
___
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 v3 xf86-input-synaptics] syndaemon: enable touchpad when pressing a modifier combo

[Anton Lindqvist]

When ignoring modifiers, ensure the touchpad is enabled once a modifier
key is pressed disregarding any previous key press that caused the
touchpad to be disabled.

Signed-off-by: Anton Lindqvist 
---
On Fri, Aug 05, 2016 at 08:17:17AM +1000, Peter Hutterer wrote:
> On Thu, Aug 04, 2016 at 01:06:37PM +0200, Anton Lindqvist wrote:
> > Thanks for the feedback. Here's a revised patch trying to resolve the
> > issues. Should the new patch be re-submitted in a separate thread?
> 
> sticking it in the same thread makes them easier to associate, but for next
> time please add a v2, v3, etc. right after PATCH
> 
> > 
> >  >8 
> > 
> > When ignoring modifiers, ensure the touchpad is enabled once a modifier
> > key is pressed disregarding any previous key press that caused the
> > touchpad to be disabled.
> > 
> > Signed-off-by: Anton Lindqvist 
> > ---
> 
> fwiw, if you write the general comments here, after the --- then git am will
> automatically remove it and there's no need to get the scissors out.

Thanks, didn't know. I am able to apply this message as a patch using
git-am(1).

> 
> >  tools/syndaemon.c | 48 +++-
> >  1 file changed, 35 insertions(+), 13 deletions(-)
> > 
> > diff --git a/tools/syndaemon.c b/tools/syndaemon.c
> > index 29e75f5..1d5ce1d 100644
> > --- a/tools/syndaemon.c
> > +++ b/tools/syndaemon.c
> > @@ -47,6 +47,12 @@
> >  
> >  #include "synaptics-properties.h"
> >  
> > +enum KeyboardActivity {
> > +ActivityNew,
> > +ActivityNone,
> > +ActivityReset
> > +};
> > +
> >  enum TouchpadState {
> >  TouchpadOn = 0,
> >  TouchpadOff = 1,
> > @@ -181,29 +187,29 @@ install_signal_handler(void)
> >  }
> >  }
> >  
> > -/**
> > - * Return non-zero if the keyboard state has changed since the last call.
> > - */
> > -static int
> > +static enum KeyboardActivity
> >  keyboard_activity(Display * display)
> >  {
> >  static unsigned char old_key_state[KEYMAP_SIZE];
> >  unsigned char key_state[KEYMAP_SIZE];
> >  int i;
> > -int ret = 0;
> > +int ret = ActivityNone;
> >  
> >  XQueryKeymap(display, (char *) key_state);
> >  
> >  for (i = 0; i < KEYMAP_SIZE; i++) {
> >  if ((key_state[i] & ~old_key_state[i]) & keyboard_mask[i]) {
> > -ret = 1;
> > +ret = ActivityNew;
> >  break;
> >  }
> >  }
> >  if (ignore_modifier_combos) {
> >  for (i = 0; i < KEYMAP_SIZE; i++) {
> >  if (key_state[i] & ~keyboard_mask[i]) {
> > -ret = 0;
> > +if (old_key_state[i] & ~keyboard_mask[i])
> > +ret = ActivityNone;
> > +else
> > +ret = ActivityReset;
> >  break;
> >  }
> >  }
> > @@ -232,8 +238,17 @@ main_loop(Display * display, double idle_time, int 
> > poll_delay)
> >  
> >  for (;;) {
> >  current_time = get_time();
> > -if (keyboard_activity(display))
> > -last_activity = current_time;
> > +switch (keyboard_activity(display)) {
> > +case ActivityNew:
> > +last_activity = current_time;
> > +break;
> > +case ActivityNone:
> > +/* NOP */;
> > +break;
> > +case ActivityReset:
> > +last_activity = 0.0;
> > +break;
> > +}
> >  
> >  /* If system times goes backwards, touchpad can get locked. Make
> >   * sure our last activity wasn't in the future and reset if it 
> > was. */
> > @@ -423,6 +438,7 @@ record_main_loop(Display * display, double idle_time)
> >  fd_set read_fds;
> >  int ret;
> >  int disable_event = 0;
> > +   int modifier_event = 0;
> 
> all the record bits have tabs instead of spaces. I fixed that up locally,
> but...

Sorry, my bad. The expandtab option is disabled in Vim from the modeline
present in the file. This seems to be the only file with a modeline in
this repository, maybe it should be removed? Anyway, I fixed the
whitespace in the attached patch.

> 
> >  struct timeval timeout;
> >  
> >  FD_ZERO(_fds);
> > @@ -454,9 +470,12 @@ record_main_loop(Display * display, double idle_time)
> >  disable_event = 1;
> >  }
> >  
> > -if (cbres.non_modifier_event &&
> > -!(ignore_modifier_combos && is_modifier_pressed())) {
> > -disable_event = 1;
> > +if (cbres.non_modifier_event) {
> > +   if (ignore_modifier_combos && is_modifier_pressed()) {
> > +   modifier_event = 1;
> 
> this doesn't work the same way. in poll mode, any modifier will re-enable
> the touchpad immediately. but this path is only hit for the non-modifier
> keys while a modifer is down. 
> 
> - press a
> - touchpad 

RE: compositing enabled with Radeon mobility X300

[Jethro Tull]

From: Michel Dänzer [mic...@daenzer.net]
Sent: Friday, August 5, 2016 1:41 AM
To: Jethro Tull
Cc: x...@freedesktop.org
Subject: Re: compositing enabled with Radeon mobility X300

On 05.08.2016 06:23, Jethro Tull wrote:
> I'm using the kernel 4.4.14 with XFCE 4.12, as written in the subject
> my GPU is a Radeon mobility X300 and the driver used is the open
> source "radeon".
>
> I noticed that enabling compositing was resulting in very slow
> windows manipulations like dragging, resizing, browsing them with Alt
> + tab. It takes nearly 2 seconds to display the big contextual menu
> when starting to browse through the windows. And I also noticed that
> using an extended desktop on a second monitor was leading to some
> windows not being refreshed resulting in a nearly scrambled desktop
> after some time of use with several graphical programs. I also
> noticed some similar problems with the terminal.

Please provide the corresponding Xorg log file.


--
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

here it is: 

[67.164] 
X.Org X Server 1.18.3
Release Date: 2016-04-04
[67.164] X Protocol Version 11, Revision 0
[67.164] Build Operating System: Slackware 14.2 Slackware Linux Project
[67.164] Current Operating System: Linux darkstar 4.4.14-smp #1 SMP Fri Jun 
24 14:35:42 CDT 2016 i686
[67.164] Kernel command line: auto BOOT_IMAGE=linux_4.4.14 ro root=fd00 
vt.default_utf8=0
[67.164] Build Date: 15 April 2016  11:51:37AM
[67.164]  
[67.164] Current version of pixman: 0.34.0
[67.164]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[67.164] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[67.164] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Aug  5 07:24:01 
2016
[67.171] (==) Using config directory: "/etc/X11/xorg.conf.d"
[67.171] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[67.172] (==) No Layout section.  Using the first Screen section.
[67.172] (==) No screen section available. Using defaults.
[67.172] (**) |-->Screen "Default Screen Section" (0)
[67.172] (**) |   |-->Monitor ""
[67.173] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[67.173] (==) Automatically adding devices
[67.173] (==) Automatically enabling devices
[67.173] (==) Automatically adding GPU devices
[67.173] (==) Max clients allowed: 256, resource mask: 0x1f
[67.173] (WW) The directory "/usr/share/fonts/local" does not exist.
[67.173]Entry deleted from font path.
[67.173] (WW) The directory "/usr/share/fonts/CID" does not exist.
[67.173]Entry deleted from font path.
[67.249] (==) FontPath set to:
/usr/share/fonts/TTF,
/usr/share/fonts/OTF,
/usr/share/fonts/Type1,
/usr/share/fonts/misc,
/usr/share/fonts/75dpi/:unscaled,
/usr/share/fonts/100dpi/:unscaled,
/usr/share/fonts/75dpi,
/usr/share/fonts/100dpi,
/usr/share/fonts/cyrillic
[67.249] (==) ModulePath set to "/usr/lib/xorg/modules"
[67.249] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[67.249] (II) Loader magic: 0x827b600
[67.250] (II) Module ABI versions:
[67.250]X.Org ANSI C Emulation: 0.4
[67.250]X.Org Video Driver: 20.0
[67.250]X.Org XInput driver : 22.1
[67.250]X.Org Server Extension : 9.0
[67.250] (II) xfree86: Adding drm device (/dev/dri/card0)
[67.252] (--) PCI:*(0:1:0:0) 1002:5460:17c0:2079 rev 0, Mem @ 
0xc000/268435456, 0xb010/65536, I/O @ 0x2000/256, BIOS @ 
0x/131072
[67.252] (II) Open ACPI successful (/var/run/acpid.socket)
[67.252] (II) LoadModule: "glx"
[67.360] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[67.381] (II) Module glx: vendor="X.Org Foundation"
[67.381]compiled for 1.18.3, module version = 1.0.0
[67.381]ABI class: X.Org Server Extension, version 9.0
[67.381] (==) AIGLX enabled
[67.381] (==) Matched ati as autoconfigured driver 0
[67.381] (==) Matched ati as autoconfigured driver 1
[67.381] (==) Matched modesetting as autoconfigured driver 2
[67.381] (==) Matched fbdev as autoconfigured driver 3
[67.381] (==) Matched vesa as autoconfigured driver 4
[67.381] (==) Assigned the driver to the xf86ConfigLayout
[67.381] (II) LoadModule: "ati"
[67.383] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[67.423] (II) Module ati: vendor="X.Org Foundation"
[67.423]compiled for 1.18.3, module version = 7.7.0
[67.423]