Re: [PATCH v4 xserver] xkb: fix releasing overlay while keydown

[Peter Hutterer]

On Sun, Nov 27, 2016 at 01:14:35AM +0500, Mihail Konev wrote:
> On Sun, Nov 27, 2016 at 12:55:40AM +0500, Mihail Konev wrote:
> > Is adding an Xinput property the only way?
> 
> Rather,  should  it be an Xi property, or static arrays in xkb are enough?

sorry, I meant a per-device field, not a full XI property.

side-note: if you reply to list only, I may not see your email for days :)

Cheers,
   Peter
___
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 xserver 0/3] Allow XWM to control Xwayland commits

[Owen Taylor]

Probably a combination of factors:
 * It never got into the official spec (I didn't want to push it in without
some review and hopefully a second implementation)
 * It requires coordinated window manager and toolkit changes to get any
benefit
 * The original spec fixed a huge problem with opaque resizing where the
application could lag arbitrarily behind the window manager - the extended
spec just makes things look better when you look close.
 * People who really care about these things were already beginning to put
their efforts into Wayland

- Owen

On Thu, Dec 1, 2016 at 4:53 AM, Pekka Paalanen  wrote:

> On Wed, 30 Nov 2016 15:12:54 -0500
> Owen Taylor  wrote:
>
> > Hi Pekka,
> >
> > I don't have a lot of of commentary to add here. Certainly getting the
> > frame-sync protocols right does require integration between Xwayland and
> > the compositing manager. I don't think there's that much virtue in
> spending
> > time on the extended version of the sync protocol and
> > _NET_WM_FRAME_TIMINGS, because, to my knowledge, those are implemented
> only
> > by GTK+ 3, and most GTK+ 3 apps will be running as native Wayland apps.
> On
> > the other hand, gtk2 and qt4 X clients will be around to exercise the
> basic
> > version of the protocol for the forseeable future.
>
> Hi Owen,
>
> that's valuable, saves me the effort of designing for and maybe
> implementing the extended version. :-)
>
> I'm kind of curious though why no other toolkit saw the benefit of the
> extended sync protocol.
>
>
> Thanks,
> pq
>
___
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: AMD SUMO vs Xorg 7.7

[Michel Dänzer]

On 02/12/16 05:18 AM, Alexander Konotop wrote:
> Hello! It looks like I've found a radeon driver bug.
> 
> Distro:
> Debian Sid(Unstable).
> 
> Hardware:
> * SUMO (integrated in AMD A4 APU)
> * CAICOS (external)
> 
> Problem:
> All webkit browsers freeze in few moments after startup while loading/opening 
> or closing tabs.
> It happens only whith an integrated card (SUMO).
> Either propagating --disable-gpu to a browser or running on CAICOS using 
> DRI_PRIME=1 eliminates
> freezing.
> Also running sauerbraten on SUMO causes freezing in few seconds after game 
> starts, in menu.
> Switching to a terminal and back (ctrl+alt+f1 and then ctrl+alt+f7) unfreezes 
> the game for few
> seconds and then it freezes again.

Please provide the corresponding Xorg log file.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

AMD SUMO vs Xorg 7.7

[Alexander Konotop]

Hello! It looks like I've found a radeon driver bug.

Distro:
Debian Sid(Unstable).

Hardware:
* SUMO (integrated in AMD A4 APU)
* CAICOS (external)

Problem:
All webkit browsers freeze in few moments after startup while loading/opening 
or closing tabs.
It happens only whith an integrated card (SUMO).
Either propagating --disable-gpu to a browser or running on CAICOS using 
DRI_PRIME=1 eliminates
freezing.
Also running sauerbraten on SUMO causes freezing in few seconds after game 
starts, in menu.
Switching to a terminal and back (ctrl+alt+f1 and then ctrl+alt+f7) unfreezes 
the game for few
seconds and then it freezes again.
No problems for sauerbraten with DRI_PRIME=1 on CAICOS.

Here's a forum topic which I started before I determined that the browsers 
problem is caused by
videocard:
https://forum.siduction.org/index.php?topic=6469
But there's not much useful debug info actually.
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: What does this backtrace mean?

[Alex Villací­s Lasso]

El 01/12/16 a las 13:42, Adam Jackson escribió:

On Wed, 2016-11-30 at 13:01 -0500, Alex Villací­s Lasso wrote:

El 28/11/16 a las 19:59, Alex Villacís Lasso escribió:

I have this computer (Acer Aspire One ZG5 using Fedora 25 32-bits)
where the backtrace shown below appears every single time the
machine boots. What does it mean? Should I be worried about it?
Last seen on kernel version 4.8.8.


Is this the right list to ask this question?

Maybe.  intel-...@lists.freedesktop.org might be more appropriate since
this is a kernel driver bug.


[4.884815] WARN_ON(!connector->state->crtc)

What this is saying is the driver had some expectations about the state
the hardware would be in when efifb handed the device off, and those
expectations were violated. If there's no functional problem you can
safely ignore it, but it's a kernel driver bug either way.

- ajax


Thanks for your answer. I will collect more information and create a proper bug 
report. BTW, the laptop is legacy BIOS only - no EFI support present.

___
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: What does this backtrace mean?

[Adam Jackson]

On Wed, 2016-11-30 at 13:01 -0500, Alex Villací­s Lasso wrote:
> El 28/11/16 a las 19:59, Alex Villacís Lasso escribió:
> > I have this computer (Acer Aspire One ZG5 using Fedora 25 32-bits)
> > where the backtrace shown below appears every single time the
> > machine boots. What does it mean? Should I be worried about it?
> > Last seen on kernel version 4.8.8.
> > 
> 
> Is this the right list to ask this question?

Maybe.  intel-...@lists.freedesktop.org might be more appropriate since
this is a kernel driver bug.

> > [4.884815] WARN_ON(!connector->state->crtc)

What this is saying is the driver had some expectations about the state
the hardware would be in when efifb handed the device off, and those
expectations were violated. If there's no functional problem you can
safely ignore it, but it's a kernel driver bug either way.

- 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

[PATCH libpciaccess 1/2] linux sysfs: retrieve vendor, device... info via separate sysfs files

[Emil Velikov]

From: Emil Velikov 

Currently the kernel does not expose the revision file. With that about
to change (due in 4.10) we can read all the information required from
separate files and avoid opening the config one.

The latter has the [negative] side effect of waking up the device, which
in some cases can be quite costly.

Cc: Adam Jackson 
Signed-off-by: Emil Velikov 
---
Adam, as suggested - here we fallback to config, if one is using an old
kernel.
---
 src/linux_sysfs.c | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/src/linux_sysfs.c b/src/linux_sysfs.c
index cd2713d..8055e8d 100644
--- a/src/linux_sysfs.c
+++ b/src/linux_sysfs.c
@@ -146,6 +146,56 @@ scan_sys_pci_filter( const struct dirent * d )
 }
 
 
+static int
+parse_separate_sysfs_files(struct pci_device * dev)
+{
+static const char *attrs[] = {
+  "vendor",
+  "device",
+  "class",
+  "revision",
+  "subsystem_vendor",
+  "subsystem_device",
+};
+char name[256];
+char resource[512];
+uint64_t data[6];
+int fd;
+int i;
+
+for (i = 0; i < 6; i++) {
+   snprintf(name, 255, "%s/%04x:%02x:%02x.%1u/%s",
+SYS_BUS_PCI,
+dev->domain,
+dev->bus,
+dev->dev,
+dev->func,
+attrs[i]);
+
+   fd = open(name, O_RDONLY | O_CLOEXEC);
+   if (fd == -1) {
+   return errno;
+   }
+
+   read(fd, resource, 512);
+   resource[511] = '\0';
+
+   close(fd);
+
+   data[i] = strtoull(resource, NULL, 16);
+}
+
+dev->vendor_id = data[0] & 0x;
+dev->device_id = data[1] & 0x;
+dev->device_class = data[2] & 0xff;
+dev->revision = data[3] & 0xff;
+dev->subvendor_id = data[4] & 0x;
+dev->subdevice_id = data[5] & 0x;
+
+return 0;
+}
+
+
 int
 populate_entries( struct pci_system * p )
 {
@@ -178,6 +228,10 @@ populate_entries( struct pci_system * p )
device->base.func = func;
 
 
+   err = parse_separate_sysfs_files(& device->base);
+   if (!err)
+   continue;
+
err = pci_device_linux_sysfs_read(& device->base, config, 0,
  48, & bytes);
if ((bytes == 48) && !err) {
-- 
2.10.2

___
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 libpciaccess 2/2] Revert "linux_sysfs: include for PATH_MAX"

[Emil Velikov]

This reverts commit 8ea3af620a2d4ad5648917b4a0ef2b23ff566774.

The include was added with 6bd2f7f92eae713663f4e13f6e2cb23526607b8c

Cc: Adam Jackson 
---
 src/linux_sysfs.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/linux_sysfs.c b/src/linux_sysfs.c
index 8055e8d..dd8ef3e 100644
--- a/src/linux_sysfs.c
+++ b/src/linux_sysfs.c
@@ -49,7 +49,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #if defined(__i386__) || defined(__x86_64__) || defined(__arm__)
 #include 
-- 
2.10.2

___
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 xserver 0/3] Allow XWM to control Xwayland commits

[Pekka Paalanen]

On Wed, 30 Nov 2016 15:12:54 -0500
Owen Taylor  wrote:

> Hi Pekka,
> 
> I don't have a lot of of commentary to add here. Certainly getting the
> frame-sync protocols right does require integration between Xwayland and
> the compositing manager. I don't think there's that much virtue in spending
> time on the extended version of the sync protocol and
> _NET_WM_FRAME_TIMINGS, because, to my knowledge, those are implemented only
> by GTK+ 3, and most GTK+ 3 apps will be running as native Wayland apps. On
> the other hand, gtk2 and qt4 X clients will be around to exercise the basic
> version of the protocol for the forseeable future.

Hi Owen,

that's valuable, saves me the effort of designing for and maybe
implementing the extended version. :-)

I'm kind of curious though why no other toolkit saw the benefit of the
extended sync protocol.


Thanks,
pq


pgpCSDHm8qtjg.pgp
Description: OpenPGP digital 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