Why is XSetStandardProperties freezing?
Hi, I have a program using an X graphics library that works on FC 13 and ScientificLinux 6, but freezes on OpenSuse 12.1. I need to get it running, and I am trying to determine the cause of failure. I'm not an X developer, and because the library is complex, I am struggling to come up with a minimal example. The specific cause of the problem is the call in the code: XSetStandardProperties(win-theDisp, win-theWindow, wname, hgraf, None, NULL, 0, (win-hints)); I verified by putting print statements around it that it never returns, the program freezes there. The initialization code is complex, but the best I can tell it boils down to char *hgraf = HGraf; win-theDisp = XOpenDisplay(0) win-theScreen=DefaultScreen(win-theDisp); win-rootW=RootWindow(win-theDisp, win-theScreen); win-theWindow = XCreateSimpleWindow(win-theDisp, win-rootW, x, y, w, h, bw, black, white ); I am at a loss as to what I should be checking here, and what could cause the program to hang at that XSetStandardProperties call, with no error messages or exceptions. How can I debug this? Thanks, Myrosia ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xorg-server 1.12.2.901
== Description == This is the first release candidate for 1.12.3. The primary changes from the first release candidate pertain to documentation, input and XQuartz. == Known Issues == Currently open bugs the 1.12 Tracker: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.12 23938: keys occasionally get stuck with xorg-server 1.6.99.901 http://bugs.freedesktop.org/23938 31501: crash accessing font info with xfs in fontpath http://bugs.freedesktop.org/31501 39094: WaitFor does not handle EIO (causes 100% cpu load) http://bugs.freedesktop.org/39094 39383: X server crashes when restarting KDE from Alt+F2 http://bugs.freedesktop.org/39383 39949: RandR panning scaling don't work http://bugs.freedesktop.org/39949 41124: Xorg crashes while resizing OpenGL windows http://bugs.freedesktop.org/41124 43988: crtc-desiredMode.name can point to freed memory. http://bugs.freedesktop.org/43988 44038: some 3D wine apps no longer work (bisected) http://bugs.freedesktop.org/44038 45445: Key press crashes the xserver when kdm is running http://bugs.freedesktop.org/45445 49170: crash when starting or after some time of using psi http://bugs.freedesktop.org/49170 50641: xorg-server-1.12.0 - When SELinux is enabled the xserver fails http://bugs.freedesktop.org/50641 50683: Black screen with AutoAddDevices Off http://bugs.freedesktop.org/50683 == New Issues == If you encounter an issue that you think should block a future 1.11 release, please follow the instructions listed in the wiki to raise this to our attention. http://www.x.org/wiki/Server112Branch == Changes since 1.12.1.901 == Alan Coopersmith (4): Undocument mandatory loadable modules Undocument Font Module loading cvt man page should use Hz, not kHz, for vertical refresh rate Convert sbusPaletteKey to latest DevPrivate API Jeremy Huddleston (4): XQuartz: Workaround an SDK bug on Leopard/x86_64 XQuartz: Tiger build fix XQuartz: Provide fls implementation for Tiger XQuartz: Avoid a race in initialization of darwinPointer Julien Cristau (1): Xi: make stub DeleteInputDeviceRequest call RemoveDevice Marcin Slusarz (1): xfree86: fix mouse wheel support for DGA clients Michal Suchanek (1): Fix crash for motion events from devices without valuators Peter Hutterer (2): dix: undo transformation for missing valuators (#49347) configure.ac: Version bump to 1.12.2.901 (1.12.3 RC1) Siddhesh Poyarekar (1): xkb: Allocate size_syms correctly when width of a type increases git tag: xorg-server-1.12.2.901 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.2.901.tar.bz2 MD5: 07e592e690c75e9ae4d5e79d5d3e34ad xorg-server-1.12.2.901.tar.bz2 SHA1: 9431b3a577a133f5b38be3abfe4356191fd7e746 xorg-server-1.12.2.901.tar.bz2 SHA256: 6a5ff9e2fbff26a445d623c42fae5bfa39a8cb3d1ee540446fc24d27aeda5b78 xorg-server-1.12.2.901.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.2.901.tar.gz MD5: e02512d2fc3af13f4006bbd72841394e xorg-server-1.12.2.901.tar.gz SHA1: 986c624a53572306e0ff6d296724c132ad8729ff xorg-server-1.12.2.901.tar.gz SHA256: 2a0461a61cdd949135ad26b6a84ed73956a7b8b0e4b35e87060c8d171ff4f7c5 xorg-server-1.12.2.901.tar.gz pgpNOP74b0ZQE.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: gpu screen infrastructure patches
On Wed, Jun 13, 2012 at 2:53 PM, Dave Airlie airl...@gmail.com wrote: Hi, This set of patches introduces infrastructure to support GPU screens, hotplugging of platform devices and provision of the randr provider objects. This code is mostly scaffolding, and by itself doesn't provider any new feature, except exposing providers to the clients. The providers so far won't support any abilities or roles yet, just protocol to show the exist. So you can hotplug and watch them appear/disappear in the randr protocol. This set requires the randrproto changes sent to the list along with the platform bus patches sent to the list. This stuff is also available in my randr-provider branch http://cgit.freedesktop.org/~airlied/xserver/log/?h=randr-provider Thanks to Aaron for reminding me. Dave. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Very strange problem with input events
On Thu, Jun 14, 2012 at 01:52:28PM +1000, Peter Hutterer wrote: On Wed, Jun 13, 2012 at 09:02:52PM +0200, Cedric Sodhi wrote: Two examples: Tint2 (the panel) had me drag window-icons (tasks) on the taskbar, when I clicked them, as if I had held the mouse button down. I was able to fix that by a minor change in the code of tint2, but as no one else is getting any such behaviour I assume I did not really fix the bug but only found some solution to somewhich, which fails elsewhere. I was not able to track the logic which is supposed to run, though. Second example, Midori (the browser). When I right click a hyperlink and subsequently left click an entry in the context menu, the context menu disappears (as it should) and I'm suddenly dragging the link upon which I clicked. Similar things happen everywhere else, too. I'm not even sure where to start looking. I wish I could get a suggestion from you, what to do. For the link issue, I'd check the evtest output of the touchscreen to see if the actual device data makes sense. Just to make this clear, this has nothing to do with the touchscreen. I'm using a normal USB mouse. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Very strange problem with input events
On Thu, Jun 14, 2012 at 01:52:28PM +1000, Peter Hutterer wrote: On Wed, Jun 13, 2012 at 09:02:52PM +0200, Cedric Sodhi wrote: Unfortunally, I lack a better or just more precise description of my problem. I get strange behaviour all throughout X, everywhere clicks are involved. One thing I think I had already mentioned is that my touchscreen, which runs evdev does work properly everywhere, but there are no regular events generated - only XI events. this can only be a client issue. I can't tell you which client from here though. The drivers and the server don't deal with core vs XI events until very late. There' internal events and then based on the client selection that internal event structure is converted to the wire event and sent. So if you don't see core events, the clients haven't registered for it, or clients have otherwise registered for XI events and take precedence over core.. Also, many applications strangely misbehave in a way that other people cannot possibly reproduce. Unrelated to the touchscreen, that is. Using an ordinary mouse with evdev. Two examples: Tint2 (the panel) had me drag window-icons (tasks) on the taskbar, when I clicked them, as if I had held the mouse button down. I was able to fix that by a minor change in the code of tint2, but as no one else is getting any such behaviour I assume I did not really fix the bug but only found some solution to somewhich, which fails elsewhere. I was not able to track the logic which is supposed to run, though. Second example, Midori (the browser). When I right click a hyperlink and subsequently left click an entry in the context menu, the context menu disappears (as it should) and I'm suddenly dragging the link upon which I clicked. Similar things happen everywhere else, too. I'm not even sure where to start looking. I wish I could get a suggestion from you, what to do. options are trying an older X servers and bisecting from a good one if you can find one. or look at the protocol with xscope to see the actual events sent on the wire (you can also use systemtap/dtrace for that but it's less pretty). For the link issue, I'd check the evtest output of the touchscreen to see if the actual device data makes sense. I take back what I said previously, that it was unrelated to the touchscreen. In fact, I narrowed down the source of the problem exactly to the touchscreen. It appears that if I do not touch the touchscreen at all, after the server has started, everything works. But as soon as I touched it at least once - thought there appears to be no sign of problems at first - these strange things (see the two examples above - I've got more examples, if you like) start happening, even if I just use the normal mouse. I had attached an evtest log of the device, do you see any indication of problems in that? regards, Cedric Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0xeef product 0xa001 version 0x210 Input device name: eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 330 (BTN_TOUCH) Event type 3 (EV_ABS) Event code 0 (ABS_X) Value 22528 Min0 Max32767 Fuzz 7 Event code 1 (ABS_Y) Value 21168 Min0 Max32767 Fuzz 7 Event code 47 (ABS_MT_SLOT) Value 0 Min0 Max9 Event code 53 (ABS_MT_POSITION_X) Value 0 Min0 Max32767 Fuzz 7 Event code 54 (ABS_MT_POSITION_Y) Value 0 Min0 Max32767 Fuzz 7 Event code 57 (ABS_MT_TRACKING_ID) Value 0 Min0 Max65535 Properties: Property type 1 (INPUT_PROP_DIRECT) Testing ... (interrupt to exit) Event: time 1338794791.107562, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 16 Event: time 1338794791.107563, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 22496 Event: time 1338794791.107564, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 18016 Event: time 1338794791.107573, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1 Event: time 1338794791.107574, type 3 (EV_ABS), code 0 (ABS_X), value 22496 Event: time 1338794791.107575, type 3 (EV_ABS), code 1 (ABS_Y), value 18016 Event: time 1338794791.107576, -- SYN_REPORT Event: time 1338794791.197575, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 18032 Event: time 1338794791.197585, type 3 (EV_ABS), code 1 (ABS_Y), value 18032 Event: time 1338794791.197586, -- SYN_REPORT Event: time 1338794791.198566, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1 Event: time 1338794791.198575, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0 Event: time 1338794791.198576, -- SYN_REPORT ___
Re: XInput transform matrix
On Thu, Jun 14, 2012 at 02:43:30PM +1000, Peter Hutterer wrote: On Wed, Jun 13, 2012 at 05:46:19PM +0200, Cedric Sodhi wrote: Can anyone tell me which transform matrix (prop 133 in XI) I have to fwiw, the numerical value may be different on each machine (even on each startup), it purely depends on how many other properties were created before this one. only a handful of atoms have real fixed values, they're named XA_... (XA_ATOM, XA_CARDINAL, etc.) choose so that my touchscreen lines up with my 90 ccw rotated display? I've tried practically everything I found sensible but I got absolutly no useful results. In fact I get a jumping and flickering cursor, which also maps differently based upon which direction I move in. the rotation matrix is defined as [ cos -sin 0 ] [ sin cos 0 ] [ 00 1 ] so for a 90 degree rotation you'd use 0 -1 0 1 0 0 0 0 1. However, it's important to remember you're rotating around the origin, so if you do rotate you need to offset too, so the above example actually becomes. [ 0 -1 1 ] [ 1 0 0 ] [ 0 0 1 ] The offset is the important bit, forget about it and you get the cursor stuck in corners or edges. I had the same thoughts and came to the same conclusion, the same matrix. But I get a randomly jumping cursor then. I thought that maybe, the device (that touchscreen, again) happend to export two event devices of which I had then only rotated one, but that isn't the case. Floating the one device I tried to rotate disables it, completey. Even if the matrix were wrong, which I tink it isn't, after you just confimed it, why would the cursor jump arround like crazy? regards, Cedric ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH:xf86-video-ati 9/15] Link with modules needed to build with no-undefined linking
On Mit, 2012-06-13 at 15:31 -0700, Alan Coopersmith wrote: On 06/12/12 12:06 AM, Michel Dänzer wrote: On Mon, 2012-06-11 at 18:36 -0700, Alan Coopersmith wrote: On 06/ 1/12 02:56 AM, Michel Dänzer wrote: On Fre, 2012-05-25 at 08:02 -0700, Alan Coopersmith wrote: Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com --- src/Makefile.am | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index dc77c02..4357135 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -26,11 +26,12 @@ # _ladir passes a dummy rpath to libtool so the thing will actually link # TODO: -nostdlib/-Bstatic/-lgcc platform magic, not installing the .a, etc. -radeon_drv_la_LIBADD = $(LIBDRM_RADEON_LIBS) +radeon_drv_la_LIBADD = $(LIBDRM_RADEON_LIBS) $(XORG_LIBS) -lpixman-1 -lm The driver doesn't depend on pixman directly, does it? I'd prefer that to be inherited from xserver somehow. If it isn't covered by -lfb anyway, that is. It does, thanks to the fb macros that now implement region operations using pixman functions - nm on radeon_drv.so here shows it calling: pixman_region_copy pixman_region_equal pixman_region_subtract pixman_region_union Ugh. I stand by my point though: This is an xserver implementation detail, so ideally the -lpixman-1 should be inherited from xserver. Maybe that's beyond the scope of this patch, but at the least the pixman link stanza needs to be determined via pkg-config. Unfortunately, the X server pkg-config file doesn't know which modules are going to call the region functions or not - I suppose we could add it to the .pc file and have libpixman linked into every module, whether it uses it or not. That's not ideal either, e.g. Debian package builds warn about linking to libraries without referencing any of their symbols. OTOH that's probably the case even with this patch with xserver 1.8 or older. So maybe that would still be a better solution than forcing drivers to deal with this... -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Very strange problem with input events
On 14/06/12 17:35 , Cedric Sodhi wrote: On Thu, Jun 14, 2012 at 01:52:28PM +1000, Peter Hutterer wrote: On Wed, Jun 13, 2012 at 09:02:52PM +0200, Cedric Sodhi wrote: Unfortunally, I lack a better or just more precise description of my problem. I get strange behaviour all throughout X, everywhere clicks are involved. One thing I think I had already mentioned is that my touchscreen, which runs evdev does work properly everywhere, but there are no regular events generated - only XI events. this can only be a client issue. I can't tell you which client from here though. The drivers and the server don't deal with core vs XI events until very late. There' internal events and then based on the client selection that internal event structure is converted to the wire event and sent. So if you don't see core events, the clients haven't registered for it, or clients have otherwise registered for XI events and take precedence over core.. Also, many applications strangely misbehave in a way that other people cannot possibly reproduce. Unrelated to the touchscreen, that is. Using an ordinary mouse with evdev. Two examples: Tint2 (the panel) had me drag window-icons (tasks) on the taskbar, when I clicked them, as if I had held the mouse button down. I was able to fix that by a minor change in the code of tint2, but as no one else is getting any such behaviour I assume I did not really fix the bug but only found some solution to somewhich, which fails elsewhere. I was not able to track the logic which is supposed to run, though. Second example, Midori (the browser). When I right click a hyperlink and subsequently left click an entry in the context menu, the context menu disappears (as it should) and I'm suddenly dragging the link upon which I clicked. Similar things happen everywhere else, too. I'm not even sure where to start looking. I wish I could get a suggestion from you, what to do. options are trying an older X servers and bisecting from a good one if you can find one. or look at the protocol with xscope to see the actual events sent on the wire (you can also use systemtap/dtrace for that but it's less pretty). For the link issue, I'd check the evtest output of the touchscreen to see if the actual device data makes sense. I take back what I said previously, that it was unrelated to the touchscreen. In fact, I narrowed down the source of the problem exactly to the touchscreen. It appears that if I do not touch the touchscreen at all, after the server has started, everything works. But as soon as I touched it at least once - thought there appears to be no sign of problems at first - these strange things (see the two examples above - I've got more examples, if you like) start happening, even if I just use the normal mouse. I had attached an evtest log of the device, do you see any indication of problems in that? disable the device in X with xinput and run mtview against it, that should tell you if the device misbehaves. the log looks ok on a glance. https://github.com/whot/mtview/ Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Very strange problem with input events
On Thu, Jun 14, 2012 at 07:19:22PM +1000, Peter Hutterer wrote: On 14/06/12 17:35 , Cedric Sodhi wrote: On Thu, Jun 14, 2012 at 01:52:28PM +1000, Peter Hutterer wrote: On Wed, Jun 13, 2012 at 09:02:52PM +0200, Cedric Sodhi wrote: Unfortunally, I lack a better or just more precise description of my problem. I get strange behaviour all throughout X, everywhere clicks are involved. One thing I think I had already mentioned is that my touchscreen, which runs evdev does work properly everywhere, but there are no regular events generated - only XI events. this can only be a client issue. I can't tell you which client from here though. The drivers and the server don't deal with core vs XI events until very late. There' internal events and then based on the client selection that internal event structure is converted to the wire event and sent. So if you don't see core events, the clients haven't registered for it, or clients have otherwise registered for XI events and take precedence over core.. Also, many applications strangely misbehave in a way that other people cannot possibly reproduce. Unrelated to the touchscreen, that is. Using an ordinary mouse with evdev. Two examples: Tint2 (the panel) had me drag window-icons (tasks) on the taskbar, when I clicked them, as if I had held the mouse button down. I was able to fix that by a minor change in the code of tint2, but as no one else is getting any such behaviour I assume I did not really fix the bug but only found some solution to somewhich, which fails elsewhere. I was not able to track the logic which is supposed to run, though. Second example, Midori (the browser). When I right click a hyperlink and subsequently left click an entry in the context menu, the context menu disappears (as it should) and I'm suddenly dragging the link upon which I clicked. Similar things happen everywhere else, too. I'm not even sure where to start looking. I wish I could get a suggestion from you, what to do. options are trying an older X servers and bisecting from a good one if you can find one. or look at the protocol with xscope to see the actual events sent on the wire (you can also use systemtap/dtrace for that but it's less pretty). For the link issue, I'd check the evtest output of the touchscreen to see if the actual device data makes sense. I take back what I said previously, that it was unrelated to the touchscreen. In fact, I narrowed down the source of the problem exactly to the touchscreen. It appears that if I do not touch the touchscreen at all, after the server has started, everything works. But as soon as I touched it at least once - thought there appears to be no sign of problems at first - these strange things (see the two examples above - I've got more examples, if you like) start happening, even if I just use the normal mouse. I had attached an evtest log of the device, do you see any indication of problems in that? disable the device in X with xinput and run mtview against it, that should tell you if the device misbehaves. the log looks ok on a glance. https://github.com/whot/mtview/ Ok, I think I noticed a few irregularities. Here is what I did: From the outer left and right towards the middle, I repeatedly: Put down the first finger at the righter top, dragged it down a bit. Then put down the second finger on the lefter top, and dragged both fingers down a way. Then I first took the right finger off, kept dragging a bit more downwards with the left, and then also took that one off. And did so repeatedly towards the middle of the screen. If you look carefully, you can see not onle that a single line consist of two, but really three colors! The third colored blob at the very bottom appears the moment I start over with new lines towards the middle (as consistently represented by the color). Also, on the first iteration the left finger does not appear until I raised the right finger. Can I do anything else? regards, Cedric ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xorg-docs] add maintainers entry for xf86-video-omap
From: Rob Clark r...@ti.com Signed-off-by: Rob Clark r...@ti.com --- MAINTAINERS |7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ee24014..b982409 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -902,6 +902,13 @@ L: xorg-devel@lists.x.org W: http://wiki.x.org S: Maintained +xf86-video-omap +P: Rob Clark +M: robcl...@freedesktop.org +L: xorg-devel@lists.x.org +W: http://wiki.x.org +S: Maintained + xf86-video-qxl P: ? M: ? -- 1.7.9.5 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH:xf86-video-ati 9/15] Link with modules needed to build with no-undefined linking
On 12-06-13 06:31 PM, Alan Coopersmith wrote: On 06/12/12 12:06 AM, Michel Dänzer wrote: On Mon, 2012-06-11 at 18:36 -0700, Alan Coopersmith wrote: On 06/ 1/12 02:56 AM, Michel Dänzer wrote: On Fre, 2012-05-25 at 08:02 -0700, Alan Coopersmith wrote: Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com --- src/Makefile.am | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index dc77c02..4357135 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -26,11 +26,12 @@ # _ladir passes a dummy rpath to libtool so the thing will actually link # TODO: -nostdlib/-Bstatic/-lgcc platform magic, not installing the .a, etc. -radeon_drv_la_LIBADD = $(LIBDRM_RADEON_LIBS) +radeon_drv_la_LIBADD = $(LIBDRM_RADEON_LIBS) $(XORG_LIBS) -lpixman-1 -lm The driver doesn't depend on pixman directly, does it? I'd prefer that to be inherited from xserver somehow. If it isn't covered by -lfb anyway, that is. It does, thanks to the fb macros that now implement region operations using pixman functions - nm on radeon_drv.so here shows it calling: pixman_region_copy pixman_region_equal pixman_region_subtract pixman_region_union Ugh. I stand by my point though: This is an xserver implementation detail, so ideally the -lpixman-1 should be inherited from xserver. Maybe that's beyond the scope of this patch, but at the least the pixman link stanza needs to be determined via pkg-config. Unfortunately, the X server pkg-config file doesn't know which modules are going to call the region functions or not - I suppose we could add it to the .pc file and have libpixman linked into every module, whether it uses it or not. But certainly I can replace -lpixman-1 in Makefile.am with a PKG_CHECK_MODULES(..., pixman-1) in configure.ac. I don't remember why I didn't do that in the first place. I am out of context here, didn't read the whole thread. Isn't there a -lpixman-1 already provided by the server? PKG_CHECK_MODULES(XORG, [xorg-server = 1.3 xproto fontsproto $REQUIRED_MODULES]) Which leads to: XORG_LIBS = -L/home/nadon/xorg/src/inst/lib -lpixman-1 -lpciaccess ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
platform probing and gpu screens (round 2)
In testing found a few bugs with this set of patches, so there are a few version bumps in here to address the issues, along with two extra patches at the end to fix up some other issues I found in testing. Dave. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 03/14] dix: introduce gpu screens.
From: Dave Airlie airl...@redhat.com
This patch introduces gpu screens into screenInfo. It adds interfaces
for adding and removing gpu screens, along with adding private fixup,
block handler support, and scratch pixmap init.
GPU screens have a myNum that is offset by GPU_SCREEN_OFFSET (256),
this is used for logging etc.
Signed-off-by: Dave Airlie airl...@redhat.com
---
dix/dispatch.c | 75 --
dix/dixutils.c |6
dix/main.c | 15 ++
dix/privates.c |5
include/misc.h |1 +
include/screenint.h |9 ++
include/scrnintstr.h |4 +++
7 files changed, 113 insertions(+), 2 deletions(-)
diff --git a/dix/dispatch.c b/dix/dispatch.c
index 5448298..58d594a 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3724,7 +3724,7 @@ with its screen number, a pointer to its ScreenRec, argc,
and argv.
*/
-static int init_screen(ScreenPtr pScreen, int i)
+static int init_screen(ScreenPtr pScreen, int i, Bool gpu)
{
int scanlinepad, format, depth, bitsPerPixel, j, k;
@@ -3732,6 +3732,10 @@ static int init_screen(ScreenPtr pScreen, int i)
return -1;
}
pScreen-myNum = i;
+if (gpu) {
+pScreen-myNum += GPU_SCREEN_OFFSET;
+pScreen-isGPU = TRUE;
+}
pScreen-totalPixmapSize = 0; /* computed in
CreateScratchPixmapForScreen */
pScreen-ClipNotify = 0;/* for R4 ddx compatibility */
pScreen-CreateScreenResources = 0;
@@ -3788,7 +3792,7 @@ AddScreen(Bool (*pfnInit) (ScreenPtr /*pScreen */ ,
if (!pScreen)
return -1;
-ret = init_screen(pScreen, i);
+ret = init_screen(pScreen, i, FALSE);
if (ret) {
free(pScreen);
return ret;
@@ -3817,3 +3821,70 @@ AddScreen(Bool (*pfnInit) (ScreenPtr /*pScreen */ ,
return i;
}
+
+int
+AddGPUScreen(Bool (*pfnInit) (ScreenPtr /*pScreen */ ,
+ int /*argc */ ,
+ char ** /*argv */
+ ),
+ int argc, char **argv)
+{
+int i;
+ScreenPtr pScreen;
+Bool ret;
+
+i = screenInfo.numGPUScreens;
+if (i == MAXSCREENS)
+return -1;
+
+pScreen = (ScreenPtr) calloc(1, sizeof(ScreenRec));
+if (!pScreen)
+return -1;
+
+ret = init_screen(pScreen, i, TRUE);
+if (ret) {
+free(pScreen);
+return ret;
+}
+
+/* This is where screen specific stuff gets initialized. Load the
+ screen structure, call the hardware, whatever.
+ This is also where the default colormap should be allocated and
+ also pixel values for blackPixel, whitePixel, and the cursor
+ Note that InitScreen is NOT allowed to modify argc, argv, or
+ any of the strings pointed to by argv. They may be passed to
+ multiple screens.
+ */
+screenInfo.gpuscreens[i] = pScreen;
+screenInfo.numGPUScreens++;
+if (!(*pfnInit) (pScreen, argc, argv)) {
+dixFreePrivates(pScreen-devPrivates, PRIVATE_SCREEN);
+free(pScreen);
+screenInfo.numGPUScreens--;
+return -1;
+}
+
+update_desktop_dimensions();
+
+dixRegisterScreenPrivateKey(cursorScreenDevPriv, pScreen, PRIVATE_CURSOR,
+0);
+
+return i;
+}
+
+void
+RemoveGPUScreen(ScreenPtr pScreen)
+{
+int idx, j;
+if (!pScreen-isGPU)
+return;
+
+idx = pScreen-myNum - GPU_SCREEN_OFFSET;
+for (j = idx; j screenInfo.numGPUScreens - 1; j++) {
+screenInfo.gpuscreens[j] = screenInfo.gpuscreens[j + 1];
+}
+screenInfo.numGPUScreens--;
+
+free(pScreen);
+
+}
diff --git a/dix/dixutils.c b/dix/dixutils.c
index b249a81..c06315e 100644
--- a/dix/dixutils.c
+++ b/dix/dixutils.c
@@ -386,6 +386,9 @@ BlockHandler(pointer pTimeout, pointer pReadmask)
for (i = 0; i screenInfo.numScreens; i++)
(*screenInfo.screens[i]-BlockHandler) (screenInfo.screens[i],
pTimeout, pReadmask);
+for (i = 0; i screenInfo.numGPUScreens; i++)
+(*screenInfo.gpuscreens[i]-BlockHandler) (screenInfo.gpuscreens[i],
+ pTimeout, pReadmask);
for (i = 0; i numHandlers; i++)
if (!handlers[i].deleted)
(*handlers[i].BlockHandler) (handlers[i].blockData,
@@ -422,6 +425,9 @@ WakeupHandler(int result, pointer pReadmask)
for (i = 0; i screenInfo.numScreens; i++)
(*screenInfo.screens[i]-WakeupHandler) (screenInfo.screens[i],
result, pReadmask);
+for (i = 0; i screenInfo.numGPUScreens; i++)
+(*screenInfo.gpuscreens[i]-WakeupHandler) (screenInfo.gpuscreens[i],
+result, pReadmask);
if (handlerDeleted) {
for (i = 0; i numHandlers;)
if (handlers[i].deleted) {
diff --git a/dix/main.c
[PATCH 04/14] xfree86: add DDX gpu screen support. (v2)
From: Dave Airlie airl...@redhat.com
This just adds the structures and interfaces required for adding/deleteing
gpu screens at the DDX level. The platform probe can pass a new flag
to the driver, so they can call xf86AllocateScreen and pass back the new
gpu screen flag.
It also calls the gpu screens preinit and screeninit routines at
startup.
v2: fix delete screen use after free.
Signed-off-by: Dave Airlie airl...@redhat.com
---
hw/xfree86/common/xf86.h|3 ++
hw/xfree86/common/xf86Bus.c |4 ++
hw/xfree86/common/xf86Globals.c |2 +
hw/xfree86/common/xf86Helper.c | 108 +--
hw/xfree86/common/xf86Init.c| 42 +++
hw/xfree86/common/xf86Priv.h|2 +
hw/xfree86/common/xf86str.h |5 +-
7 files changed, 138 insertions(+), 28 deletions(-)
diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
index 88a219c..6116985 100644
--- a/hw/xfree86/common/xf86.h
+++ b/hw/xfree86/common/xf86.h
@@ -465,4 +465,7 @@ extern _X_EXPORT ScreenPtr xf86ScrnToScreen(ScrnInfoPtr
pScrn);
#define XF86_SCRN_INTERFACE 1 /* define for drivers to use in api compat */
+/* flags passed to xf86 allocate screen */
+#define XF86_ALLOCATE_GPU_SCREEN 1
+
#endif /* _XF86_H */
diff --git a/hw/xfree86/common/xf86Bus.c b/hw/xfree86/common/xf86Bus.c
index d0cfb2b..6de8409 100644
--- a/hw/xfree86/common/xf86Bus.c
+++ b/hw/xfree86/common/xf86Bus.c
@@ -189,6 +189,10 @@ xf86BusConfig(void)
}
}
+/* bind GPU conf screen to protocol screen 0 */
+for (i = 0; i xf86NumGPUScreens; i++)
+xf86GPUScreens[i]-confScreen = xf86Screens[0]-confScreen;
+
/* If no screens left, return now. */
if (xf86NumScreens == 0) {
xf86Msg(X_ERROR,
diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index 0071004..bb08917 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -51,6 +51,7 @@ DevPrivateKeyRec xf86CreateRootWindowKeyRec;
DevPrivateKeyRec xf86ScreenKeyRec;
ScrnInfoPtr *xf86Screens = NULL;/* List of ScrnInfos */
+ScrnInfoPtr *xf86GPUScreens = NULL;/* List of ScrnInfos */
const unsigned char byte_reversed[256] = {
0x00, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
@@ -153,6 +154,7 @@ int xf86NumDrivers = 0;
InputDriverPtr *xf86InputDriverList = NULL;
int xf86NumInputDrivers = 0;
int xf86NumScreens = 0;
+int xf86NumGPUScreens = 0;
const char *xf86VisualNames[] = {
StaticGray,
diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
index 5ef1dab..c20ddc6 100644
--- a/hw/xfree86/common/xf86Helper.c
+++ b/hw/xfree86/common/xf86Helper.c
@@ -167,29 +167,45 @@ ScrnInfoPtr
xf86AllocateScreen(DriverPtr drv, int flags)
{
int i;
+ScrnInfoPtr pScrn;
+
+if (flags XF86_ALLOCATE_GPU_SCREEN) {
+if (xf86GPUScreens == NULL)
+xf86NumGPUScreens = 0;
+i = xf86NumGPUScreens++;
+xf86GPUScreens = xnfrealloc(xf86GPUScreens, xf86NumGPUScreens *
sizeof(ScrnInfoPtr));
+xf86GPUScreens[i] = xnfcalloc(sizeof(ScrnInfoRec), 1);
+pScrn = xf86GPUScreens[i];
+pScrn-scrnIndex = i + GPU_SCREEN_OFFSET; /* Changes when a
screen is removed */
+pScrn-is_gpu = TRUE;
+} else {
+if (xf86Screens == NULL)
+xf86NumScreens = 0;
+
+i = xf86NumScreens++;
+xf86Screens = xnfrealloc(xf86Screens, xf86NumScreens *
sizeof(ScrnInfoPtr));
+xf86Screens[i] = xnfcalloc(sizeof(ScrnInfoRec), 1);
+pScrn = xf86Screens[i];
+
+pScrn-scrnIndex = i; /* Changes when a screen is removed */
+}
-if (xf86Screens == NULL)
-xf86NumScreens = 0;
-i = xf86NumScreens++;
-xf86Screens = xnfrealloc(xf86Screens, xf86NumScreens *
sizeof(ScrnInfoPtr));
-xf86Screens[i] = xnfcalloc(sizeof(ScrnInfoRec), 1);
-xf86Screens[i]-scrnIndex = i; /* Changes when a screen is removed */
-xf86Screens[i]-origIndex = i; /* This never changes */
-xf86Screens[i]-privates = xnfcalloc(sizeof(DevUnion),
+pScrn-origIndex = pScrn-scrnIndex; /* This never changes */
+pScrn-privates = xnfcalloc(sizeof(DevUnion),
xf86ScrnInfoPrivateCount);
/*
* EnableDisableFBAccess now gets initialized in InitOutput()
- * xf86Screens[i]-EnableDisableFBAccess = xf86EnableDisableFBAccess;
+ * pScrn-EnableDisableFBAccess = xf86EnableDisableFBAccess;
*/
-xf86Screens[i]-drv = drv;
+pScrn-drv = drv;
drv-refCount++;
-xf86Screens[i]-module = DuplicateModule(drv-module, NULL);
+pScrn-module = DuplicateModule(drv-module, NULL);
-xf86Screens[i]-DriverFunc = drv-driverFunc;
+pScrn-DriverFunc = drv-driverFunc;
-return xf86Screens[i];
+return pScrn;
}
/*
@@ -202,10 +218,17 @@ xf86DeleteScreen(ScrnInfoPtr pScrn)
{
int i;
int scrnIndex;
-
-/* First check if the
[PATCH 05/14] xserver/config: add udev/drm hotplug callbacks.
From: Dave Airlie airl...@redhat.com
This adds callbacks into the ddx for udev gpu hotplug.
Signed-off-by: Dave Airlie airl...@redhat.com
---
config/udev.c | 42 ++
include/hotplug.h |4
2 files changed, 46 insertions(+)
diff --git a/config/udev.c b/config/udev.c
index 4657a47..a8e2931 100644
--- a/config/udev.c
+++ b/config/udev.c
@@ -52,6 +52,12 @@
static struct udev_monitor *udev_monitor;
+#ifdef CONFIG_UDEV_KMS
+static Bool
+config_udev_odev_setup_attribs(const char *path, const char *syspath,
+ config_odev_probe_proc_ptr probe_callback);
+#endif
+
static void
device_added(struct udev_device *udev_device)
{
@@ -85,6 +91,20 @@ device_added(struct udev_device *udev_device)
if (!SeatId strcmp(dev_seat, seat0))
return;
+#ifdef CONFIG_UDEV_KMS
+if (!strcmp(udev_device_get_subsystem(udev_device), drm)) {
+const char *sysname = udev_device_get_sysname(udev_device);
+
+if (strncmp(sysname, card, 4))
+return;
+
+LogMessage(X_INFO, config/udev: Adding drm device (%s)\n, path);
+
+config_udev_odev_setup_attribs(path, syspath, NewGPUDeviceRequest);
+return;
+}
+#endif
+
if (!udev_device_get_property_value(udev_device, ID_INPUT)) {
LogMessageVerb(X_INFO, 10,
config/udev: ignoring device %s without
@@ -240,6 +260,22 @@ device_removed(struct udev_device *device)
char *value;
const char *syspath = udev_device_get_syspath(device);
+#ifdef CONFIG_UDEV_KMS
+if (!strcmp(udev_device_get_subsystem(device), drm)) {
+const char *sysname = udev_device_get_sysname(device);
+const char *path = udev_device_get_devnode(device);
+
+if (strncmp(sysname,card, 4))
+return;
+ErrorF(removing GPU device %s %d\n, syspath, path);
+if (!path)
+return;
+
+config_udev_odev_setup_attribs(path, syspath, DeleteGPUDeviceRequest);
+return;
+}
+#endif
+
if (asprintf(value, udev:%s, syspath) == -1)
return;
@@ -296,6 +332,9 @@ config_udev_pre_init(void)
udev_monitor_filter_add_match_subsystem_devtype(udev_monitor, input,
NULL);
udev_monitor_filter_add_match_subsystem_devtype(udev_monitor, tty,
NULL); /* For Wacom serial devices */
+#ifdef CONFIG_UDEV_KMS
+udev_monitor_filter_add_match_subsystem_devtype(udev_monitor, drm,
NULL); /* For output GPU devices */
+#endif
#ifdef HAVE_UDEV_MONITOR_FILTER_ADD_MATCH_TAG
if (SeatId strcmp(SeatId, seat0))
@@ -322,6 +361,9 @@ config_udev_init(void)
udev_enumerate_add_match_subsystem(enumerate, input);
udev_enumerate_add_match_subsystem(enumerate, tty);
+#ifdef CONFIG_UDEV_KMS
+udev_enumerate_add_match_subsystem(enumerate, drm);
+#endif
#ifdef HAVE_UDEV_ENUMERATE_ADD_MATCH_TAG
if (SeatId strcmp(SeatId, seat0))
diff --git a/include/hotplug.h b/include/hotplug.h
index 5000762..96b078d 100644
--- a/include/hotplug.h
+++ b/include/hotplug.h
@@ -65,4 +65,8 @@ config_odev_free_attributes(struct OdevAttributes *attribs);
typedef void (*config_odev_probe_proc_ptr)(struct OdevAttributes *attribs);
void config_odev_probe(config_odev_probe_proc_ptr probe_callback);
+#ifdef CONFIG_UDEV_KMS
+void NewGPUDeviceRequest(struct OdevAttributes *attribs);
+void DeleteGPUDeviceRequest(struct OdevAttributes *attribs);
+#endif
#endif /* HOTPLUG_H */
--
1.7.10.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 02/14] screen: split out screen init code.
From: Dave Airlie airl...@redhat.com
This is a precursor for reusing this code to init gpu screens.
Signed-off-by: Dave Airlie airl...@redhat.com
---
dix/dispatch.c | 44 +++-
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/dix/dispatch.c b/dix/dispatch.c
index b88f974..5448298 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3724,27 +3724,11 @@ with its screen number, a pointer to its ScreenRec,
argc, and argv.
*/
-int
-AddScreen(Bool (*pfnInit) (ScreenPtr /*pScreen */ ,
- int /*argc */ ,
- char ** /*argv */
- ), int argc, char **argv)
+static int init_screen(ScreenPtr pScreen, int i)
{
-
-int i;
int scanlinepad, format, depth, bitsPerPixel, j, k;
-ScreenPtr pScreen;
-
-i = screenInfo.numScreens;
-if (i == MAXSCREENS)
-return -1;
-
-pScreen = (ScreenPtr) calloc(1, sizeof(ScreenRec));
-if (!pScreen)
-return -1;
if (!dixAllocatePrivates(pScreen-devPrivates, PRIVATE_SCREEN)) {
-free(pScreen);
return -1;
}
pScreen-myNum = i;
@@ -3782,7 +3766,33 @@ AddScreen(Bool (*pfnInit) (ScreenPtr /*pScreen */ ,
PixmapWidthPaddingInfo[depth].notPower2 = 0;
}
}
+return 0;
+}
+
+int
+AddScreen(Bool (*pfnInit) (ScreenPtr /*pScreen */ ,
+ int /*argc */ ,
+ char ** /*argv */
+ ), int argc, char **argv)
+{
+int i;
+ScreenPtr pScreen;
+Bool ret;
+
+i = screenInfo.numScreens;
+if (i == MAXSCREENS)
+return -1;
+
+pScreen = (ScreenPtr) calloc(1, sizeof(ScreenRec));
+if (!pScreen)
+return -1;
+
+ret = init_screen(pScreen, i);
+if (ret) {
+free(pScreen);
+return ret;
+}
/* This is where screen specific stuff gets initialized. Load the
screen structure, call the hardware, whatever.
This is also where the default colormap should be allocated and
--
1.7.10.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 06/14] xfree86: add platform bus hotplug support (v2)
From: Dave Airlie airl...@redhat.com
This provides add/remove support for platform devices at xfree86 ddx level.
v2: cleanup properly if no driver found.
Signed-off-by: Dave Airlie airl...@redhat.com
---
hw/xfree86/common/xf86platformBus.c| 99
hw/xfree86/common/xf86platformBus.h|5 ++
hw/xfree86/os-support/linux/lnx_platform.c | 49 ++
3 files changed, 153 insertions(+)
diff --git a/hw/xfree86/common/xf86platformBus.c
b/hw/xfree86/common/xf86platformBus.c
index c13978e..3018017 100644
--- a/hw/xfree86/common/xf86platformBus.c
+++ b/hw/xfree86/common/xf86platformBus.c
@@ -376,4 +376,103 @@ xf86platformProbeDev(DriverPtr drvp)
return foundScreen;
}
+int
+xf86platformAddDevice(int index)
+{
+int i, old_screens, scr_index;
+DriverPtr drvp = NULL;
+int entity;
+screenLayoutPtr layout;
+
+for (i = 0; i xf86NumDrivers; i++) {
+if (!xf86DriverList[i])
+continue;
+
+if (!strcmp(xf86DriverList[i]-driverName, modesetting)) {
+drvp = xf86DriverList[i];
+break;
+}
+}
+if (i == xf86NumDrivers)
+return -1;
+
+old_screens = xf86NumGPUScreens;
+entity = xf86ClaimPlatformSlot(xf86_platform_devices[index],
+ drvp, 0, 0, 0);
+if (!drvp-platformProbe(drvp, entity, PLATFORM_PROBE_GPU_SCREEN,
xf86_platform_devices[index], 0)) {
+xf86UnclaimPlatformSlot(xf86_platform_devices[index], NULL);
+}
+if (old_screens == xf86NumGPUScreens)
+return -1;
+i = old_screens;
+
+for (layout = xf86ConfigLayout.screens; layout-screen != NULL;
+ layout++) {
+xf86GPUScreens[i]-confScreen = layout-screen;
+break;
+}
+
+if (xf86GPUScreens[i]-PreInit
+xf86GPUScreens[i]-PreInit(xf86GPUScreens[i], 0))
+xf86GPUScreens[i]-configured = TRUE;
+
+if (!xf86GPUScreens[i]-configured) {
+ErrorF(hotplugged device %d didn't configure\n, i);
+xf86DeleteScreen(xf86GPUScreens[i]);
+return -1;
+}
+
+ scr_index = AddGPUScreen(xf86GPUScreens[i]-ScreenInit, 0, NULL);
+
+ dixSetPrivate(xf86GPUScreens[i]-pScreen-devPrivates,
+ xf86ScreenKey, xf86GPUScreens[i]);
+
+ CreateScratchPixmapsForScreen(xf86GPUScreens[i]-pScreen);
+
+ return 0;
+}
+
+void
+xf86platformRemoveDevice(int index)
+{
+EntityPtr entity;
+int ent_num, i, j;
+Bool found;
+
+for (ent_num = 0; ent_num xf86NumEntities; ent_num++) {
+ entity = xf86Entities[ent_num];
+ if (entity-bus.type == BUS_PLATFORM
+ entity-bus.id.plat == xf86_platform_devices[index])
+ break;
+}
+if (ent_num == xf86NumEntities)
+goto out;
+
+found = FALSE;
+for (i = 0; i xf86NumGPUScreens; i++) {
+ for (j = 0; j xf86GPUScreens[i]-numEntities; j++)
+ if (xf86GPUScreens[i]-entityList[j] == ent_num) {
+ found = TRUE;
+ break;
+ }
+ if (found)
+ break;
+}
+if (!found) {
+ErrorF(failed to find screen to remove\n);
+goto out;
+}
+
+xf86GPUScreens[i]-pScreen-CloseScreen(xf86GPUScreens[i]-pScreen);
+
+RemoveGPUScreen(xf86GPUScreens[i]-pScreen);
+xf86DeleteScreen(xf86GPUScreens[i]);
+
+xf86UnclaimPlatformSlot(xf86_platform_devices[index], NULL);
+
+xf86_remove_platform_device(index);
+
+ out:
+return;
+}
#endif
diff --git a/hw/xfree86/common/xf86platformBus.h
b/hw/xfree86/common/xf86platformBus.h
index 15a3022..49afc24 100644
--- a/hw/xfree86/common/xf86platformBus.h
+++ b/hw/xfree86/common/xf86platformBus.h
@@ -47,6 +47,11 @@ xf86_remove_platform_device(int dev_index);
extern Bool
xf86_add_platform_device_attrib(int index, int attrib_id, char *attrib_str);
+extern int
+xf86platformAddDevice(int index);
+extern void
+xf86platformRemoveDevice(int index);
+
extern _X_EXPORT char *
xf86_get_platform_device_attrib(struct xf86_platform_device *device, int
attrib_id);
extern _X_EXPORT Bool
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c
b/hw/xfree86/os-support/linux/lnx_platform.c
index 9c63ee5..76f5583 100644
--- a/hw/xfree86/os-support/linux/lnx_platform.c
+++ b/hw/xfree86/os-support/linux/lnx_platform.c
@@ -15,6 +15,8 @@
#include xf86platformBus.h
#include xf86Bus.h
+#include hotplug.h
+
static Bool
get_drm_info(struct OdevAttributes *attribs, char *path)
{
@@ -127,4 +129,51 @@ out_free:
config_odev_free_attribute_list(attribs);
}
+void NewGPUDeviceRequest(struct OdevAttributes *attribs)
+{
+int old_num = xf86_num_platform_devices;
+int ret;
+xf86PlatformDeviceProbe(attribs);
+
+if (old_num == xf86_num_platform_devices)
+return;
+
+ret = xf86platformAddDevice(xf86_num_platform_devices-1);
+if (ret == -1)
+xf86_remove_platform_device(xf86_num_platform_devices-1);
+
+ErrorF(xf86: found device %d\n,
[PATCH 07/14] xfree86: add autoAddGPU option
From: Dave Airlie airl...@redhat.com
This option is to stop the X server adding non-primary devices as
gpu screens.
Signed-off-by: Dave Airlie airl...@redhat.com
---
hw/xfree86/common/xf86Config.c | 15 ++-
hw/xfree86/common/xf86Globals.c |9 +++--
hw/xfree86/common/xf86Privstr.h |2 ++
hw/xfree86/common/xf86platformBus.c | 11 +++
4 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index b22b617..edc0d3d 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -712,7 +712,8 @@ typedef enum {
FLAG_AUTO_ENABLE_DEVICES,
FLAG_GLX_VISUALS,
FLAG_DRI2,
-FLAG_USE_SIGIO
+FLAG_USE_SIGIO,
+FLAG_AUTO_ADD_GPU,
} FlagValues;
/**
@@ -770,6 +771,8 @@ static OptionInfoRec FlagOptions[] = {
{0}, FALSE},
{FLAG_USE_SIGIO, UseSIGIO, OPTV_BOOLEAN,
{0}, FALSE},
+{FLAG_AUTO_ADD_GPU, AutoAddGPU, OPTV_BOOLEAN,
+ {0}, FALSE},
{-1, NULL, OPTV_NONE,
{0}, FALSE},
};
@@ -862,6 +865,16 @@ configServerFlags(XF86ConfFlagsPtr flagsconf,
XF86OptionPtr layoutopts)
xf86Msg(from, %sutomatically enabling devices\n,
xf86Info.autoEnableDevices ? A : Not a);
+if (xf86IsOptionSet(FlagOptions, FLAG_AUTO_ADD_GPU)) {
+xf86GetOptValBool(FlagOptions, FLAG_AUTO_ADD_GPU,
+ xf86Info.autoAddGPU);
+from = X_CONFIG;
+}
+else {
+from = X_DEFAULT;
+}
+xf86Msg(from, %sutomatically adding GPU devices\n,
+xf86Info.autoAddGPU ? A : Not a);
/*
* Set things up based on the config file information. Some of these
* settings may be overridden later when the command line options are
diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index bb08917..7df7a80 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -126,11 +126,16 @@ xf86InfoRec xf86Info = {
#if defined(CONFIG_HAL) || defined(CONFIG_UDEV) || defined(CONFIG_WSCONS)
.forceInputDevices = FALSE,
.autoAddDevices = TRUE,
-.autoEnableDevices = TRUE
+.autoEnableDevices = TRUE,
#else
.forceInputDevices = TRUE,
.autoAddDevices = FALSE,
-.autoEnableDevices = FALSE
+.autoEnableDevices = FALSE,
+#endif
+#if defined(CONFIG_UDEV_KMS)
+.autoAddGPU = TRUE,
+#else
+.autoAddGPU = FALSE,
#endif
};
diff --git a/hw/xfree86/common/xf86Privstr.h b/hw/xfree86/common/xf86Privstr.h
index e78cd40..e20be03 100644
--- a/hw/xfree86/common/xf86Privstr.h
+++ b/hw/xfree86/common/xf86Privstr.h
@@ -110,6 +110,8 @@ typedef struct {
Bool dri2;
MessageType dri2From;
+
+Bool autoAddGPU;
} xf86InfoRec, *xf86InfoPtr;
#ifdef DPMSExtension
diff --git a/hw/xfree86/common/xf86platformBus.c
b/hw/xfree86/common/xf86platformBus.c
index 3018017..cd402b8 100644
--- a/hw/xfree86/common/xf86platformBus.c
+++ b/hw/xfree86/common/xf86platformBus.c
@@ -373,6 +373,17 @@ xf86platformProbeDev(DriverPtr drvp)
continue;
}
+/* if autoaddgpu devices is enabled then go find a few more and add them
as GPU screens */
+if (xf86Info.autoAddGPU == FALSE)
+return foundScreen;
+
+if (numDevs) {
+ for (j = 0; j xf86_num_platform_devices; j++) {
+ probeSingleDevice(xf86_platform_devices[j], drvp, devList[0],
PLATFORM_PROBE_GPU_SCREEN);
+
+ }
+}
+
return foundScreen;
}
--
1.7.10.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 11/14] dix: attach unbound screens to protocol screen 0
From: Dave Airlie airl...@redhat.com This is the default attachment, unbound gpu screens get attached to the 0 protocol screen. detach on hotunplug. Signed-off-by: Dave Airlie airl...@redhat.com --- hw/xfree86/common/xf86Init.c|3 +++ hw/xfree86/common/xf86platformBus.c |5 + 2 files changed, 8 insertions(+) diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c index 6dbb10a..745532b 100644 --- a/hw/xfree86/common/xf86Init.c +++ b/hw/xfree86/common/xf86Init.c @@ -920,6 +920,9 @@ InitOutput(ScreenInfo * pScreenInfo, int argc, char **argv) #endif } +for (i = 0; i xf86NumGPUScreens; i++) +AttachUnboundGPU(xf86Screens[0]-pScreen, xf86GPUScreens[i]-pScreen); + xf86VGAarbiterWrapFunctions(); xf86UnblockSIGIO(was_blocked); diff --git a/hw/xfree86/common/xf86platformBus.c b/hw/xfree86/common/xf86platformBus.c index cd402b8..23aec1f 100644 --- a/hw/xfree86/common/xf86platformBus.c +++ b/hw/xfree86/common/xf86platformBus.c @@ -439,6 +439,9 @@ xf86platformAddDevice(int index) xf86ScreenKey, xf86GPUScreens[i]); CreateScratchPixmapsForScreen(xf86GPUScreens[i]-pScreen); + + /* attach unbound to 0 protocol screen */ + AttachUnboundGPU(xf86Screens[0]-pScreen, xf86GPUScreens[i]-pScreen); return 0; } @@ -474,6 +477,8 @@ xf86platformRemoveDevice(int index) goto out; } +DetachUnboundGPU(xf86GPUScreens[i]-pScreen); + xf86GPUScreens[i]-pScreen-CloseScreen(xf86GPUScreens[i]-pScreen); RemoveGPUScreen(xf86GPUScreens[i]-pScreen); -- 1.7.10.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 09/14] xfree86: add framework for provider support in ddx.
From: Dave Airlie airl...@redhat.com
This adds the framework for DDX provider support.
Signed-off-by: Dave Airlie airl...@redhat.com
---
hw/xfree86/common/xf86str.h|4 +++
hw/xfree86/modes/xf86Crtc.c| 46 ++
hw/xfree86/modes/xf86Crtc.h| 58 ++
hw/xfree86/modes/xf86RandR12.c | 60
4 files changed, 168 insertions(+)
diff --git a/hw/xfree86/common/xf86str.h b/hw/xfree86/common/xf86str.h
index 6bd6a62..56397f1 100644
--- a/hw/xfree86/common/xf86str.h
+++ b/hw/xfree86/common/xf86str.h
@@ -814,6 +814,10 @@ typedef struct _ScrnInfoRec {
funcPointer reservedFuncs[NUM_RESERVED_FUNCS];
Bool is_gpu;
+uint32_t roles;
+uint32_t abilities;
+uint32_t current_role;
+
} ScrnInfoRec;
typedef struct {
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 2c8878f..238fb91 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -3202,3 +3202,49 @@ xf86_crtc_supports_gamma(ScrnInfoPtr pScrn)
return FALSE;
}
+
+xf86ProviderPtr
+xf86ProviderCreate(ScrnInfoPtr scrn,
+ const xf86ProviderFuncsRec *funcs, const char *name)
+{
+xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
+xf86ProviderPtr provider;
+int len;
+
+if (xf86_config-provider)
+return xf86_config-provider;
+
+if (name)
+len = strlen(name) + 1;
+else
+len = 0;
+
+provider = calloc(sizeof(xf86ProviderRec) + len, 1);
+if (!provider)
+return NULL;
+
+provider-scrn = scrn;
+provider-funcs = funcs;
+if (name) {
+provider-name = (char *) (provider + 1);
+strcpy(provider-name, name);
+}
+#ifdef RANDR_12_INTERFACE
+provider-randr_provider = NULL;
+#endif
+
+xf86_config-provider = provider;
+return provider;
+}
+
+void
+xf86SetCurrentRole(ScrnInfoPtr scrn, uint32_t role)
+{
+xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(scrn);
+scrn-current_role = role;
+
+if (config-provider)
+if (config-provider-randr_provider)
+RRProviderSetCurrentRole(config-provider-randr_provider,
scrn-current_role);
+}
+
diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h
index a6a3c2e..55466b6 100644
--- a/hw/xfree86/modes/xf86Crtc.h
+++ b/hw/xfree86/modes/xf86Crtc.h
@@ -50,6 +50,7 @@
typedef struct _xf86Crtc xf86CrtcRec, *xf86CrtcPtr;
typedef struct _xf86Output xf86OutputRec, *xf86OutputPtr;
+typedef struct _xf86Provider xf86ProviderRec, *xf86ProviderPtr;
/* define a standard for connector types */
typedef enum _xf86ConnectorType {
@@ -607,6 +608,55 @@ struct _xf86Output {
INT16 initialBorder[4];
};
+typedef struct _xf86ProviderFuncs {
+/**
+ * Called to allow the output a chance to create properties after the
+ * RandR objects have been created.
+ */
+void
+ (*create_resources) (xf86ProviderPtr provider);
+
+/**
+ * Callback when an provider's property has changed.
+ */
+Bool
+(*set_property) (xf86ProviderPtr provider,
+ Atom property, RRPropertyValuePtr value);
+
+/**
+ * Callback to get an updated property value
+ */
+Bool
+(*get_property) (xf86ProviderPtr provider, Atom property);
+
+/**
+ * Clean up driver-specific bits of the provider
+ */
+void
+ (*destroy) (xf86ProviderPtr provider);
+
+} xf86ProviderFuncsRec, *xf86ProviderFuncsPtr;
+
+struct _xf86Provider {
+/**
+ * ABI versioning
+ */
+int version;
+
+ScrnInfoPtr scrn;
+
+/** Provider name */
+char *name;
+
+/** provider-specific functions */
+const xf86ProviderFuncsRec *funcs;
+#ifdef RANDR_12_INTERFACE
+RRProviderPtr randr_provider;
+#else
+void *randr_provider;
+#endif
+};
+
typedef struct _xf86CrtcConfigFuncs {
/**
* Requests that the driver resize the screen.
@@ -681,6 +731,7 @@ typedef struct _xf86CrtcConfig {
/* callback when crtc configuration changes */
xf86_crtc_notify_proc_ptr xf86_crtc_notify;
+xf86ProviderPtr provider;
} xf86CrtcConfigRec, *xf86CrtcConfigPtr;
extern _X_EXPORT int xf86CrtcConfigPrivateIndex;
@@ -975,4 +1026,11 @@ extern _X_EXPORT void
extern _X_EXPORT Bool
xf86_crtc_supports_gamma(ScrnInfoPtr pScrn);
+extern _X_EXPORT xf86ProviderPtr
+xf86ProviderCreate(ScrnInfoPtr scrn,
+ const xf86ProviderFuncsRec * funcs, const char *name);
+
+extern _X_EXPORT void
+xf86SetCurrentRole(ScrnInfoPtr scrn, uint32_t role);
+
#endif /* _XF86CRTC_H_ */
diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index 59b6f82..78cad63 100644
--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes/xf86RandR12.c
@@ -1552,6 +1552,19 @@ xf86RandR12CreateObjects12(ScreenPtr pScreen)
output-funcs-create_resources(output);
[PATCH 08/14] randr: add provider object and provider property support
From: Dave Airlie airl...@redhat.com
This adds the initial provider object and provider property
support to the randr dix code.
Signed-off-by: Dave Airlie airl...@redhat.com
---
randr/Makefile.am |2 +
randr/randr.c | 23 ++
randr/randrstr.h | 108 ++-
randr/rrdispatch.c | 17 +-
randr/rrprovider.c | 321
randr/rrproviderproperty.c | 716
6 files changed, 1185 insertions(+), 2 deletions(-)
create mode 100644 randr/rrprovider.c
create mode 100644 randr/rrproviderproperty.c
diff --git a/randr/Makefile.am b/randr/Makefile.am
index de338b9..ccaff3f 100644
--- a/randr/Makefile.am
+++ b/randr/Makefile.am
@@ -18,6 +18,8 @@ librandr_la_SOURCES = \
rroutput.c \
rrpointer.c \
rrproperty.c\
+ rrprovider.c\
+ rrproviderproperty.c\
rrscreen.c \
rrsdispatch.c \
rrtransform.h \
diff --git a/randr/randr.c b/randr/randr.c
index a64aae3..d2574ae 100644
--- a/randr/randr.c
+++ b/randr/randr.c
@@ -175,6 +175,25 @@ SRROutputPropertyNotifyEvent(xRROutputPropertyNotifyEvent
* from,
/* pad4 */
}
+
+static void
+SRRProviderPropertyNotifyEvent(xRRProviderPropertyNotifyEvent * from,
+ xRRProviderPropertyNotifyEvent * to)
+{
+to-type = from-type;
+to-subCode = from-subCode;
+cpswaps(from-sequenceNumber, to-sequenceNumber);
+cpswapl(from-window, to-window);
+cpswapl(from-provider, to-provider);
+cpswapl(from-atom, to-atom);
+cpswapl(from-timestamp, to-timestamp);
+to-state = from-state;
+/* pad1 */
+/* pad2 */
+/* pad3 */
+/* pad4 */
+}
+
static void
SRRNotifyEvent(xEvent *from, xEvent *to)
{
@@ -191,6 +210,10 @@ SRRNotifyEvent(xEvent *from, xEvent *to)
SRROutputPropertyNotifyEvent((xRROutputPropertyNotifyEvent *) from,
(xRROutputPropertyNotifyEvent *) to);
break;
+case RRNotify_ProviderProperty:
+SRRProviderPropertyNotifyEvent((xRRProviderPropertyNotifyEvent *) from,
+ (xRRProviderPropertyNotifyEvent *) to);
+break;
default:
break;
}
diff --git a/randr/randrstr.h b/randr/randrstr.h
index 38fb107..bf1d1f7 100644
--- a/randr/randrstr.h
+++ b/randr/randrstr.h
@@ -62,6 +62,7 @@
typedef XID RRMode;
typedef XID RROutput;
typedef XID RRCrtc;
+typedef XID RRProvider;
extern _X_EXPORT int RREventBase, RRErrorBase;
@@ -78,6 +79,7 @@ typedef struct _rrPropertyValue RRPropertyValueRec,
*RRPropertyValuePtr;
typedef struct _rrProperty RRPropertyRec, *RRPropertyPtr;
typedef struct _rrCrtc RRCrtcRec, *RRCrtcPtr;
typedef struct _rrOutput RROutputRec, *RROutputPtr;
+typedef struct _rrProvider RRProviderRec, *RRProviderPtr;
struct _rrMode {
int refcnt;
@@ -152,6 +154,19 @@ struct _rrOutput {
void *devPrivate;
};
+struct _rrProvider {
+RRProvider id;
+ScreenPtr pScreen; /* gpu screen more than likely */
+int current_role;
+uint32_t roles;
+uint32_t abilities;
+void *devPrivate;
+char *name;
+int nameLength;
+RRPropertyPtr properties;
+Bool pendingProperties;
+};
+
#if RANDR_12_INTERFACE
typedef Bool (*RRScreenSetSizeProcPtr) (ScreenPtr pScreen,
CARD16 width,
@@ -197,6 +212,17 @@ typedef Bool (*RRSetPanningProcPtr) (ScreenPtr pScrn,
#endif /* RANDR_13_INTERFACE */
+typedef Bool (*RRProviderSetRoleProcPtr)(ScreenPtr pScreen,
+RRProviderPtr provider,
+uint32_t new_role);
+
+typedef Bool (*RRProviderGetPropertyProcPtr) (ScreenPtr pScreen,
+RRProviderPtr provider, Atom
property);
+typedef Bool (*RRProviderSetPropertyProcPtr) (ScreenPtr pScreen,
+ RRProviderPtr provider,
+ Atom property,
+ RRPropertyValuePtr value);
+
typedef Bool (*RRGetInfoProcPtr) (ScreenPtr pScreen, Rotation * rotations);
typedef Bool (*RRCloseScreenProcPtr) (ScreenPtr pscreen);
@@ -247,6 +273,9 @@ typedef struct _rrScrPriv {
RRSetPanningProcPtr rrSetPanning;
#endif
+RRProviderSetRoleProcPtr rrProviderSetRole;
+RRProviderGetPropertyProcPtr rrProviderGetProperty;
+RRProviderSetPropertyProcPtr rrProviderSetProperty;
/*
* Private part of the structure; not considered part of the ABI
*/
@@ -288,6 +317,8 @@ typedef struct _rrScrPriv {
int size;
#endif
Bool discontiguous;
+
+RRProviderPtr provider;
} rrScrPrivRec, *rrScrPrivPtr;
extern _X_EXPORT DevPrivateKeyRec rrPrivKeyRec;
@@ -331,7 +362,7 @@ extern _X_EXPORT RESTYPE RRClientType, RREventType; /*
resource types for ev
extern _X_EXPORT
[PATCH 13/14] xf86dga: handle DGAAvailable for gpu screens.
From: Dave Airlie airl...@redhat.com
Just check for GPU screens, in DGAAvailable,
should probably overhaul DGA interface at some point,
or remove it.
Signed-off-by: Dave Airlie airl...@redhat.com
---
hw/xfree86/common/xf86DGA.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/hw/xfree86/common/xf86DGA.c b/hw/xfree86/common/xf86DGA.c
index 6416372..4fe12f2 100644
--- a/hw/xfree86/common/xf86DGA.c
+++ b/hw/xfree86/common/xf86DGA.c
@@ -523,10 +523,15 @@ DGAChangePixmapMode(int index, int *x, int *y, int mode)
Bool
DGAAvailable(int index)
{
+ScreenPtr pScreen;
if (!DGAScreenKeyRegistered)
return FALSE;
-if (DGA_GET_SCREEN_PRIV(screenInfo.screens[index]))
+if (index = GPU_SCREEN_OFFSET)
+pScreen = screenInfo.gpuscreens[index - GPU_SCREEN_OFFSET];
+else
+pScreen = screenInfo.screens[index];
+if (DGA_GET_SCREEN_PRIV(pScreen))
return TRUE;
return FALSE;
--
1.7.10.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 12/14] randr: expose unattached providers to the clients.
From: Dave Airlie airl...@redhat.com
This provides the unattached provider list to the clients.
Signed-off-by: Dave Airlie airl...@redhat.com
---
randr/rrprovider.c |8
1 file changed, 8 insertions(+)
diff --git a/randr/rrprovider.c b/randr/rrprovider.c
index 4f754fd..acdb3c3 100644
--- a/randr/rrprovider.c
+++ b/randr/rrprovider.c
@@ -50,6 +50,7 @@ ProcRRGetProviders (ClientPtr client)
RRProvider *providers;
int flags = 0;
int total_providers = 0, count_providers = 0;
+ScreenPtr iter;
REQUEST_SIZE_MATCH(xRRGetProvidersReq);
rc = dixLookupWindow(pWin, stuff-window, client, DixGetAttrAccess);
@@ -62,6 +63,10 @@ ProcRRGetProviders (ClientPtr client)
if (pScrPriv-provider)
total_providers++;
+xorg_list_for_each_entry(iter, pScreen-unattached_list, unattached_head)
{
+pScrPriv = rrGetScrPriv(iter);
+total_providers += pScrPriv-provider ? 1 : 0;
+}
pScrPriv = rrGetScrPriv(pScreen);
rep.pad = 0;
@@ -94,6 +99,9 @@ ProcRRGetProviders (ClientPtr client)
providers = (RRProvider *)extra;
ADD_PROVIDER(pScreen);
+xorg_list_for_each_entry(iter, pScreen-unattached_list,
unattached_head) {
+ADD_PROVIDER(iter);
+}
}
if (client-swapped) {
--
1.7.10.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 14/14] xf86: load modesetting driver on Linux hotplug
From: Dave Airlie airl...@redhat.com This driver is currently really the only choice for a hotplug at the moment, we can refine this in the future to try and pick the driver names. We have to reload this as it can get unloaded it not used in the original probe. Signed-off-by: Dave Airlie airl...@redhat.com --- hw/xfree86/os-support/linux/lnx_platform.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/xfree86/os-support/linux/lnx_platform.c b/hw/xfree86/os-support/linux/lnx_platform.c index 76f5583..56887a1 100644 --- a/hw/xfree86/os-support/linux/lnx_platform.c +++ b/hw/xfree86/os-support/linux/lnx_platform.c @@ -138,6 +138,9 @@ void NewGPUDeviceRequest(struct OdevAttributes *attribs) if (old_num == xf86_num_platform_devices) return; +/* force load the modesetting driver for now */ +xf86LoadOneModule(modesetting, NULL); + ret = xf86platformAddDevice(xf86_num_platform_devices-1); if (ret == -1) xf86_remove_platform_device(xf86_num_platform_devices-1); -- 1.7.10.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 10/14] dix: add unattached list for attaching screens to initially.
From: Dave Airlie airl...@redhat.com
This list is meant for attaching unbound gpu screens to initially,
before the client side rebinds them.
Signed-off-by: Dave Airlie airl...@redhat.com
---
dix/dispatch.c | 19 +++
include/screenint.h |5 +
include/scrnintstr.h |6 ++
3 files changed, 30 insertions(+)
diff --git a/dix/dispatch.c b/dix/dispatch.c
index 58d594a..67c1d49 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3740,6 +3740,8 @@ static int init_screen(ScreenPtr pScreen, int i, Bool gpu)
pScreen-ClipNotify = 0;/* for R4 ddx compatibility */
pScreen-CreateScreenResources = 0;
+xorg_list_init(pScreen-unattached_list);
+
/*
* This loop gets run once for every Screen that gets added,
* but thats ok. If the ddx layer initializes the formats
@@ -3888,3 +3890,20 @@ RemoveGPUScreen(ScreenPtr pScreen)
free(pScreen);
}
+
+void
+AttachUnboundGPU(ScreenPtr pScreen, ScreenPtr new)
+{
+assert(new-isGPU);
+xorg_list_add(new-unattached_head, pScreen-unattached_list);
+new-current_master = pScreen;
+}
+
+void
+DetachUnboundGPU(ScreenPtr slave)
+{
+assert(slave-isGPU);
+xorg_list_del(slave-unattached_head);
+slave-current_master = NULL;
+}
+
diff --git a/include/screenint.h b/include/screenint.h
index 8205f63..c0c60ef 100644
--- a/include/screenint.h
+++ b/include/screenint.h
@@ -71,6 +71,11 @@ extern _X_EXPORT int AddGPUScreen(Bool (*pfnInit) (ScreenPtr
/*pScreen */ ,
extern _X_EXPORT void RemoveGPUScreen(ScreenPtr pScreen);
+extern _X_EXPORT void
+AttachUnboundGPU(ScreenPtr pScreen, ScreenPtr new);
+extern _X_EXPORT void
+DetachUnboundGPU(ScreenPtr unbound);
+
typedef struct _ColormapRec *ColormapPtr;
#endif /* SCREENINT_H */
diff --git a/include/scrnintstr.h b/include/scrnintstr.h
index 4d633fe..3d4ce2f 100644
--- a/include/scrnintstr.h
+++ b/include/scrnintstr.h
@@ -477,6 +477,12 @@ typedef struct _Screen {
Bool canDoBGNoneRoot;
Bool isGPU;
+
+struct xorg_list unattached_list;
+struct xorg_list unattached_head;
+
+ScreenPtr current_master;
+
} ScreenRec;
static inline RegionPtr
--
1.7.10.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 02/14] screen: split out screen init code.
Am 14.06.2012 16:43, schrieb Dave Airlie:
From: Dave Airlie airl...@redhat.com
This is a precursor for reusing this code to init gpu screens.
Signed-off-by: Dave Airlie airl...@redhat.com
---
dix/dispatch.c | 44 +++-
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/dix/dispatch.c b/dix/dispatch.c
index b88f974..5448298 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3724,27 +3724,11 @@ with its screen number, a pointer to its ScreenRec,
argc, and argv.
*/
-int
-AddScreen(Bool (*pfnInit) (ScreenPtr /*pScreen */ ,
- int /*argc */ ,
- char ** /*argv */
- ), int argc, char **argv)
+static int init_screen(ScreenPtr pScreen, int i)
{
-
-int i;
int scanlinepad, format, depth, bitsPerPixel, j, k;
-ScreenPtr pScreen;
-
-i = screenInfo.numScreens;
-if (i == MAXSCREENS)
-return -1;
-
-pScreen = (ScreenPtr) calloc(1, sizeof(ScreenRec));
-if (!pScreen)
-return -1;
if (!dixAllocatePrivates(pScreen-devPrivates, PRIVATE_SCREEN)) {
-free(pScreen);
return -1;
}
pScreen-myNum = i;
@@ -3782,7 +3766,33 @@ AddScreen(Bool (*pfnInit) (ScreenPtr /*pScreen */ ,
PixmapWidthPaddingInfo[depth].notPower2 = 0;
}
}
+return 0;
+}
+
+int
+AddScreen(Bool (*pfnInit) (ScreenPtr /*pScreen */ ,
+ int /*argc */ ,
+ char ** /*argv */
+ ), int argc, char **argv)
+{
+int i;
+ScreenPtr pScreen;
+Bool ret;
+
+i = screenInfo.numScreens;
+if (i == MAXSCREENS)
+return -1;
+
is it better to return -2 here ?
you can still check via if (AddScreen 0) but you can
see the difference between running out-of-screens (bad)
and out-of-memory (panic).
just my to 2 cents,
re,
wh
+pScreen = (ScreenPtr) calloc(1, sizeof(ScreenRec));
+if (!pScreen)
+return -1;
+
+ret = init_screen(pScreen, i);
+if (ret) {
+free(pScreen);
+return ret;
+}
/* This is where screen specific stuff gets initialized. Load the
screen structure, call the hardware, whatever.
This is also where the default colormap should be allocated and
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Change autogen.sh scripts to respect NOCONFIGURE
On Sat, 2012-06-09 at 17:26 -0400, Gaetan Nadon wrote: I'd rather have a script change only and drop the install through util-macros part. This will reduce the overall complexity and reduce the number of places to investigate when things go wrong. Changes to the script are likely to be several years apart. Makes sense. A note about http://cgit.freedesktop.org/xorg/test/xorg-gtest/. This module has a different script (the only one so far) which never runs ./configure. Chase Douglas is actively maintaining this module. The new script you are proposing might just well be what he was waiting for. Yes, that autogen.sh is fine. The build API doesn't care whether or not autogen.sh runs configure by default or not, merely that there is a standard way to ensure it doesn't. Overall there are about 240 modules that are being published at different intervals. The list can be obtained by running modular/build.sh -L. If you post the revised patch, I'll be happy to review it. Looks like this is the diff of the autogen.sh from xorg-test as applied to xorg-xserver: diff --git a/autogen.sh b/autogen.sh index 4e8b11b..a08311b 100755 --- a/autogen.sh +++ b/autogen.sh @@ -6,7 +6,6 @@ test -z $srcdir srcdir=. ORIGDIR=`pwd` cd $srcdir -autoreconf --force -v --install || exit 1 +autoreconf -v --install || exit 1 cd $ORIGDIR || exit $? -$srcdir/configure --enable-maintainer-mode $@ So if we're going with the use xorg-gtest autogen.sh approach, the main question is: Use --force or not? It doesn't matter to me because my build system builds ONLY from git, and X.org modules don't include pregenerated configure scripts in git (because you're sane). However, someone may want to rerun auto* from a Linux distribution package where they build from tarballs (because they're stuck in the 1990s), and it would help them if --force was used. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Add a write BlockHandler?
I'm trying to solve an issue with the Spice xf86_video_qxl driver.[1] It relies on X for it's mainline, and uses the block handler to detect input from it's own clients, in addition to finding input from regular X clients. However, in certain circumstances, a write() call to it's (non X) client will return EAGAIN. In an ideal case, we would add that socket to the writefds of the select() call and go back to waiting. But the X server has no facility to allow us to do that, so in theory we fallback on a spinloop poll.[2] The Spice maintainers feel the best solution is to modify X to allow us to add watches to the writefds, so I am here to explore that option. Note that I'm about as much of a babe in the woods as you can get, so clue bats are quite welcome. Just please be gentle. The relevant xorg code appears nice and simple; a little tweak to os/WaitFor.c and dix/dixutils.c, and we're all done! Easy as that, I'm sure grin. Seriously, if any such change would be accepted, there would seem to be two approaches, as pointed out by Alon: 1. Add an additional parameter (pWritemask) to the callbacks. While this technically breaks the ABI, is it in practice sufficiently compatible to pass muster? This would imply modifying WaitFor to always send a writemask to select(), which is probably not a change we want. Thus, we would likely have to also have some new way to indicate that the writemask is desired. 2. Add a new set of callbacks Borrowing from my Wine heritage, we could have RegisterBlockHandlerEx() and RegisterWakeupHandlerEx() evil grin. Thoughts? If given a bit of guidance, I'd be willing to write a naive but earnest patch. That would hopefully fill a good developer with enough pity to write it properly :-/. Cheers, Jeremy [1] http://lists.freedesktop.org/archives/spice-devel/2012-June/009414.html [2] In practice, the code is buggy, and we never check the socket again and the client is lost to us forever. I have a patch to make the polling work, but the Spice maintainers feel that the best solution would be to add a facility to X to allow WaitFor to monitor writefds as well. So I'm being sent forth like a sacrificial lamb to plead our case. @#$@#$ open source development process :-/. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Change autogen.sh scripts to respect NOCONFIGURE
On 12-06-14 11:17 AM, Colin Walters wrote: On Sat, 2012-06-09 at 17:26 -0400, Gaetan Nadon wrote: I'd rather have a script change only and drop the install through util-macros part. This will reduce the overall complexity and reduce the number of places to investigate when things go wrong. Changes to the script are likely to be several years apart. Makes sense. A note about http://cgit.freedesktop.org/xorg/test/xorg-gtest/. This module has a different script (the only one so far) which never runs ./configure. Chase Douglas is actively maintaining this module. The new script you are proposing might just well be what he was waiting for. Yes, that autogen.sh is fine. The build API doesn't care whether or not autogen.sh runs configure by default or not, merely that there is a standard way to ensure it doesn't. Ok Overall there are about 240 modules that are being published at different intervals. The list can be obtained by running modular/build.sh -L. If you post the revised patch, I'll be happy to review it. Looks like this is the diff of the autogen.sh from xorg-test as applied to xorg-xserver: diff --git a/autogen.sh b/autogen.sh index 4e8b11b..a08311b 100755 --- a/autogen.sh +++ b/autogen.sh @@ -6,7 +6,6 @@ test -z $srcdir srcdir=. ORIGDIR=`pwd` cd $srcdir -autoreconf --force -v --install || exit 1 +autoreconf -v --install || exit 1 cd $ORIGDIR || exit $? -$srcdir/configure --enable-maintainer-mode $@ So if we're going with the use xorg-gtest autogen.sh approach, the main question is: Use --force or not? It doesn't matter to me because my build system builds ONLY from git, and X.org modules don't include pregenerated configure scripts in git (because you're sane). That was one additional change I intended to make in the xorg modules, that is, using --force. Currently only the xserver and gtest uses it. The reason I wanted to switch all modules to use --force is in the case where the source is built with different versions of autotools. Of course it does not happen often, but it's quite a pain to investigate. However, someone may want to rerun auto* from a Linux distribution package where they build from tarballs (because they're stuck in the 1990s), and it would help them if --force was used. Note that autogen.sh is not shipped in tarballs except in some modules where a controversy exists. I noticed the jhbuild system and the modular/build.sh looks at the presence of this file to make some decisions. I did as much reading as I could on the topic, I found that autogen.sh is a legacy script prior to the introduction of autoreconf as there were too many commands to type. It's not part of the GNU build system and isn't included in any GNU tarballs. There are two main reasons why we have identical scripts in all (but a couple) modules. It would be very disruptive to the developers if there were several behaviours to cope with. One would have to make a mental note which modules behave differently. Writing and applying patches is a lot easier. It looks like the original patch at the top of the thread is still valid. It allows you to avoid any xorg internal issues as it only adds a test around the configure call. I could not get it to apply, however. Perhaps it is the attachment or something. Maybe using git send-email will help. Because of the --force difference, you'll need of path for the xserver (which can only be applied by Keith) and one for the rest of the modules. FYI I'll be away for a week tomorrow. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: reentrancy of mieqProcessInputEvents()?
Thanks, Peter and Keith. I'll send out a patch to fix this up.
Thanks,
- Andy
On Tue, Jun 12, 2012 at 05:48:30PM -0700, Peter Hutterer wrote:
On Tue, Jun 12, 2012 at 05:11:49PM -0700, Andy Ritger wrote:
Is mi/mieq.c:mieqProcessInputEvents() expected to be reentrant? Or should
mieqProcessInputEvents() never be called in that situation?
More specifically, is there a reason that the 'event' local variable in
mieqProcessInputEvents() is declared static?
static InternalEvent event;
I don't think so, this doesn't look right. looking at the log this was added
in xorg-server-1.5.99.1-136-ga939368 to avoid calloc but you're certainly
right, it breaks reentrancy. Following the history of that, it's not even
needed anymore, this came from a time when we had to callloc a list of
devices - now we can have just have one InternalEvent on the stack.
see more below though.
Consider the following sequence:
(a) User hits ctrl-alt-+ to do an old-school mode switch, and the keyboard
event is put on the event queue.
(b) mieqProcessInputEvents() pops the keyboard event from the event queue,
storing the event data in a static local variable, and then passing a
pointer to that variable into mieqProcessDeviceEvent():
mieqProcessInputEvents(void)
{
[...]
static InternalEvent event;
[...]
while (miEventQueue.head != miEventQueue.tail) {
e = miEventQueue.events[miEventQueue.head];
event = *e-events;
[...]
mieqProcessDeviceEvent(dev, event, screen);
[...]
}
(c) The event pointer gets passed through several functions until we
hit XkbHandleActions():
#34 0x00585596 in XkbHandleActions (dev=0x1176370, kbd=0x1176370,
event=0x85cf00) at xkbActions.c:1234
#35 0x005865d8 in XkbProcessKeyboardEvent (event=0x85cf00,
keybd=0x1176370) at xkbPrKeyEv.c:146
#36 0x0057ad28 in AccessXFilterPressEvent (event=0x85cf00,
keybd=0x1176370) at xkbAccessX.c:569
#37 0x0058678e in ProcessKeyboardEvent (ev=0x85cf00,
keybd=0x1176370) at xkbPrKeyEv.c:181
#38 0x005aec39 in mieqProcessDeviceEvent (dev=0x1176370,
event=0x85cf00, screen=0xaa49e0) at mieq.c:557
#39 0x005aee75 in mieqProcessInputEvents () at mieq.c:624
#40 0x0048adb9 in ProcessInputEvents () at xf86Events.c:164
#41 0x00430835 in Dispatch () at dispatch.c:353
#42 0x00421a45 in main (argc=1, argv=0x7fff049880d8,
envp=0x7fff049880e8) at main.c:288
(d) XkbHandleActions() will look at the event type to decide it is a
keyEvent type, query the key action type, perform some operation based
on the key action type, then pass the event into FixKeyState():
void
XkbHandleActions(DeviceIntPtr dev, DeviceIntPtr kbd, DeviceEvent *event)
{
[...]
keyEvent = ((event-type == ET_KeyPress) || (event-type ==
ET_KeyRelease));
[...]
act = XkbGetKeyAction(xkbi, xkbi-state, key);
[...]
switch (act.type) {
[...]
case XkbSA_XFree86Private:
filter = _XkbNextFreeFilter(xkbi);
sendEvent = _XkbFilterXF86Private(xkbi, filter, key, act);
break;
}
}
[...]
if (keyEvent) {
FixKeyState(event, dev);
}
[...]
}
(e) FixKeyState() does this:
if (event-type == ET_KeyPress)
set_key_down(keybd, key, KEY_PROCESSED);
else if (event-type == ET_KeyRelease)
set_key_up(keybd, key, KEY_PROCESSED);
else
FatalError(Impossible keyboard event);
(that will be important later...)
(f) Back in XkbHandleActions(), we called _XkbFilterXF86Private which
passes the key event to the XFree86 layer, which decodes the key event
as
+vmode, and we call through the pScrnInfo-SwitchMode wrap chain:
#6 0x004df525 in xf86CursorSwitchMode (index=0, mode=0x1c54eb0,
flags=0) at xf86Cursor.c:253
#7 0x00496ef1 in CMapSwitchMode (index=0, mode=0x1c54eb0, flags=0)
at xf86cmap.c:492
#8 0x00485fb1 in xf86SwitchMode (pScreen=0x1c40c00,
mode=0x1c54eb0) at xf86Cursor.c:232
#9 0x004863f8 in xf86ZoomViewport (pScreen=0x1c40c00, zoom=1) at
xf86Cursor.c:332
#10 0x0048ae8e in xf86ProcessActionEvent (action=ACTION_NEXT_MODE,
arg=0x0) at xf86Events.c:191
#11 0x004eb36c in XkbDDXPrivate (dev=0x22ac580, key=86 'V',
act=0x78e60770) at xkbPrivate.c:32
#12 0x00584746 in _XkbFilterXF86Private (xkbi=0x22ad470,
filter=0x2265400, keycode=86,
pAction=0x78e60770) at xkbActions.c:959
#13 0x00585596 in XkbHandleActions (dev=0x22ac580, kbd=0x22ac580,
event=0x85cf00)
at xkbActions.c:1234
(g) Someone in the
[PATCH 0/2] Avoid mieqProcessInputEvents() recursion
The following two patches fix RRTellChanged() to not trigger a call into mieqProcessInputEvents(), and generate log messages if mieqProcessInputEvents() recurses in the future. Thanks to Keith and Peter for recommending this. - Andy Andy Ritger (2): randr: Don't recurse into mieqProcessInputEvents() from RRTellChanged(). mi: Log an error if mieqProcessInputEvents() recurses. mi/mieq.c | 16 +++- randr/randr.c |2 +- 2 files changed, 16 insertions(+), 2 deletions(-) -- 1.7.7 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/2] mi: Log an error if mieqProcessInputEvents() recurses.
Also, remove the unnecessary static qualifier on mieqProcessInputEvents()'s
'event' local variable.
Signed-off-by: Andy Ritger arit...@nvidia.com
---
mi/mieq.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/mi/mieq.c b/mi/mieq.c
index e117a8d..8339afb 100644
--- a/mi/mieq.c
+++ b/mi/mieq.c
@@ -569,14 +569,25 @@ mieqProcessInputEvents(void)
{
EventRec *e = NULL;
ScreenPtr screen;
-static InternalEvent event;
+InternalEvent event;
DeviceIntPtr dev = NULL, master = NULL;
size_t n_enqueued;
+static Bool inProcessInputEvents = FALSE;
#ifdef XQUARTZ
pthread_mutex_lock(miEventQueueMutex);
#endif
+/*
+ * report an error if mieqProcessInputEvents() is called recursively;
+ * this can happen, e.g., if something in the mieqProcessDeviceEvent()
+ * call chain calls UpdateCurrentTime() instead of UpdateCurrentTimeIf()
+ */
+if (inProcessInputEvents) {
+ErrorF([mi] mieqProcessInputEvents() called recursively.\n);
+}
+inProcessInputEvents = TRUE;
+
/* Grow our queue if we are reaching capacity: 2 * QUEUE_RESERVED_SIZE
remaining */
n_enqueued = mieqNumEnqueued(miEventQueue);
if (n_enqueued = (miEventQueue.nevents - (2 * QUEUE_RESERVED_SIZE))
@@ -631,6 +642,9 @@ mieqProcessInputEvents(void)
pthread_mutex_lock(miEventQueueMutex);
#endif
}
+
+inProcessInputEvents = FALSE;
+
#ifdef XQUARTZ
pthread_mutex_unlock(miEventQueueMutex);
#endif
--
1.7.7
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/2] randr: Don't recurse into mieqProcessInputEvents() from RRTellChanged().
Call UpdateCurrentTimeIf(), not UpdateCurrentTime(), from RRTellChanged().
The latter calls ProcessInputEvents(), which can trigger a recursion
into mieqProcessInputEvents(). The former omits the call to
ProcessInputEvents().
Signed-off-by: Andy Ritger arit...@nvidia.com
---
randr/randr.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/randr/randr.c b/randr/randr.c
index a64aae3..4d4298a 100644
--- a/randr/randr.c
+++ b/randr/randr.c
@@ -416,7 +416,7 @@ RRTellChanged(ScreenPtr pScreen)
int i;
if (pScrPriv-changed) {
-UpdateCurrentTime();
+UpdateCurrentTimeIf();
if (pScrPriv-configChanged) {
pScrPriv-lastConfigTime = currentTime;
pScrPriv-configChanged = FALSE;
--
1.7.7
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] mi: Log an error if mieqProcessInputEvents() recurses.
On 06/14/12 09:15 AM, Andy Ritger wrote:
+if (inProcessInputEvents) {
+ErrorF([mi] mieqProcessInputEvents() called recursively.\n);
Would it be useful to throw a backtrace in the log as well, to help us figure
out how we looped back around to that point?
--
-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: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xfree86: always enable SIGIO on OsVendorInit (#50957)
Drivers call xf86InstallSIGIOHandler() for their fd on DEVICE_ON. That function does not actually enable the signal if it was blocked to begin with. As a result, if one vt-switches away from the server (SIGIO is blocked) and then triggers a server regeneration, the signal remains blocked and input devices are dead. Avoid this by always unblocking SIGIO when we start the server. X.Org Bug 50957 http://bugs.freedesktop.org/show_bug.cgi?id=50957 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- An alternative change would be to add this to os/osinit.c but iirc the xfree86 ddx is the only one that actually needs SIGIO, right? hw/xfree86/common/xf86Init.c |1 + 1 file changed, 1 insertion(+) diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c index ead47cc..dba9eef 100644 --- a/hw/xfree86/common/xf86Init.c +++ b/hw/xfree86/common/xf86Init.c @@ -964,6 +964,7 @@ OsVendorInit(void) } #endif #endif +xf86UnblockSIGIO(0); beenHere = TRUE; } -- 1.7.10.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] mi: Log an error if mieqProcessInputEvents() recurses.
On Thu, Jun 14, 2012 at 04:47:30PM -0700, Alan Coopersmith wrote:
On 06/14/12 09:15 AM, Andy Ritger wrote:
+if (inProcessInputEvents) {
+ErrorF([mi] mieqProcessInputEvents() called recursively.\n);
Would it be useful to throw a backtrace in the log as well, to help us figure
out how we looped back around to that point?
just use BUG_WARN_MSG(inProcessInputEvents, blah blah); and that'll print
a backtrace.
Cheers,
Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Very strange problem with input events
On Thu, Jun 14, 2012 at 11:52:50AM +0200, Cedric Sodhi wrote: On Thu, Jun 14, 2012 at 07:19:22PM +1000, Peter Hutterer wrote: On 14/06/12 17:35 , Cedric Sodhi wrote: On Thu, Jun 14, 2012 at 01:52:28PM +1000, Peter Hutterer wrote: On Wed, Jun 13, 2012 at 09:02:52PM +0200, Cedric Sodhi wrote: Unfortunally, I lack a better or just more precise description of my problem. I get strange behaviour all throughout X, everywhere clicks are involved. One thing I think I had already mentioned is that my touchscreen, which runs evdev does work properly everywhere, but there are no regular events generated - only XI events. this can only be a client issue. I can't tell you which client from here though. The drivers and the server don't deal with core vs XI events until very late. There' internal events and then based on the client selection that internal event structure is converted to the wire event and sent. So if you don't see core events, the clients haven't registered for it, or clients have otherwise registered for XI events and take precedence over core.. Also, many applications strangely misbehave in a way that other people cannot possibly reproduce. Unrelated to the touchscreen, that is. Using an ordinary mouse with evdev. Two examples: Tint2 (the panel) had me drag window-icons (tasks) on the taskbar, when I clicked them, as if I had held the mouse button down. I was able to fix that by a minor change in the code of tint2, but as no one else is getting any such behaviour I assume I did not really fix the bug but only found some solution to somewhich, which fails elsewhere. I was not able to track the logic which is supposed to run, though. Second example, Midori (the browser). When I right click a hyperlink and subsequently left click an entry in the context menu, the context menu disappears (as it should) and I'm suddenly dragging the link upon which I clicked. Similar things happen everywhere else, too. I'm not even sure where to start looking. I wish I could get a suggestion from you, what to do. options are trying an older X servers and bisecting from a good one if you can find one. or look at the protocol with xscope to see the actual events sent on the wire (you can also use systemtap/dtrace for that but it's less pretty). For the link issue, I'd check the evtest output of the touchscreen to see if the actual device data makes sense. I take back what I said previously, that it was unrelated to the touchscreen. In fact, I narrowed down the source of the problem exactly to the touchscreen. It appears that if I do not touch the touchscreen at all, after the server has started, everything works. But as soon as I touched it at least once - thought there appears to be no sign of problems at first - these strange things (see the two examples above - I've got more examples, if you like) start happening, even if I just use the normal mouse. I had attached an evtest log of the device, do you see any indication of problems in that? disable the device in X with xinput and run mtview against it, that should tell you if the device misbehaves. the log looks ok on a glance. https://github.com/whot/mtview/ Ok, I think I noticed a few irregularities. Here is what I did: From the outer left and right towards the middle, I repeatedly: Put down the first finger at the righter top, dragged it down a bit. Then put down the second finger on the lefter top, and dragged both fingers down a way. Then I first took the right finger off, kept dragging a bit more downwards with the left, and then also took that one off. And did so repeatedly towards the middle of the screen. If you look carefully, you can see not onle that a single line consist of two, but really three colors! The third colored blob at the very bottom appears the moment I start over with new lines towards the middle (as consistently represented by the color). Also, on the first iteration the left finger does not appear until I raised the right finger. that's a missing feature in evemu that'll be fixed with the new version. if you're running against the current evemu release, you won't see touchpoints until the MT_SLOT value changes. Can I do anything else? fix your kernel driver :) if mtview shows the events this way it means that the touch points aren't tracked properly in the kernel - could be a device issue, could be the kernel driver. but until mtview shows the touchpoints as they should be, the issue isn't in X. judging from the picture what happens is that when you start with a new touchpoint, the device gets confused about which touch is which. look at the yellow-green line. apparently when you put the right finger down, it assumed that this was a continuation of the previous touch, while at the same time it started
Re: [PULL] Implement GLX_ARB_create_context
Ian Romanick i...@freedesktop.org writes: Ian Romanick (11): glx: Fix mishandling of shared contexts glx: Don't track GLClientmajorVersion or GLClientminorVersion glx: Extend __GLXscreen::createContext to take attributes glx: Add tracking for GLX_ARB_create_context and GLX_ARB_create_context_profile glx: Optionally call DRI2 createContextAttribs from __glXDRIscreenCreateContext glx: Implement GLX SetClientInfoARB protocol glx: Initialize all context fields together glx: Initialize remaining context fields glx: Use one function to add a context to all global tables glx: Make several functions available outside the glxcmds.c compilation unit glx: Implement protocol for glXCreateContextAttribsARB Merged. db9d2b8..ffb47a1 master - master -- keith.pack...@intel.com pgpH6jc97SYC9.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL: xserver master] build warning fixes
Alan Coopersmith alan.coopersm...@oracle.com writes: Alan Coopersmith (3): Provide prototypes for Mmio functions for Solaris Studio on SPARC Fix statement not reached warning in _DMXXineramaActive Make stub version of fbdevHWAdjustFrame match new prototype in fbdevhw.h hw/dmx/dmx.c |3 ++- hw/xfree86/common/compiler.h | 17 + hw/xfree86/fbdevhw/fbdevhwstub.c |2 +- 3 files changed, 20 insertions(+), 2 deletions(-) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc Merged. ffb47a1..8dc70ac master - master -- keith.pack...@intel.com pgp0qTEFNm3Hc.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Bug#677412: xserver-xorg-video-radeon: Package description shouldn't praise fglrx too much
Hello, Christian Meyer c2h...@web.de (13/06/2012): So: Please add a list of 3D supported video-cards[1] in the package description or, at least change the description to something like: xserver-xorg-video- radeon is the recommended driver, which works for most cards. Please try the proprietary and unsupported ATI 'fglrx-driver' if xserver-xorg-video-radeon does not work. here's the new description: Description: X.Org X server -- AMD/ATI Radeon display driver This package provides the 'radeon' driver for the AMD/ATI cards. The following chips should be supported: R100, RV100, RS100, RV200, RS200, RS250, R200, RV250, RV280, RS300, RS350, RS400/RS480, R300, R350, R360, RV350, RV360, RV370, RV380, RV410, R420, R423/R430, R480/R481, RV505/RV515/RV516/RV550, R520, RV530/RV560, RV570/R580, RS600/RS690/RS740, R600, RV610/RV630, RV620/RV635, RV670, RS780/RS880, RV710/RV730, RV740/RV770/RV790, CEDAR, REDWOOD, JUNIPER, CYPRESS, HEMLOCK, PALM, SUMO/SUMO2, BARTS, TURKS, CAICOS, CAYMAN, ARUBA. . More information about X.Org can be found at: URL:http://www.X.org . This package is built from the X.org xf86-video-ati driver module. I'm pretty sure the previous one wasn't praising fglrx, but I hear your point and your joyless experience. Mraw, KiBi. signature.asc Description: Digital signature ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Hot temperature
On Mit, 2012-06-13 at 22:26 +0200, Stefano Negro wrote: Dear all, first of all I'd like to thank you all people in this list that help developing the driver free for ati cards. I am using an HP notebook with a radeonhd 4650. I have big problems using the driver X11-driver-video-ati because it cause a very high temperature increasing. The fglrx is not causing this problem, and I'd like to use the free driver. Could someone be so kind to help me to configure the driver? This wiki section describes the options available currently: http://www.x.org/wiki/RadeonFeature#KMS_Power_Management_Options -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
dropping UMS - xf86-video-ati-7.0.0
I'm seriously thinking of resurrecting the kms killing branch, can anyone give me a reason not too, we'd fork the current master into a UMS branch and move on. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: dropping UMS - xf86-video-ati-7.0.0
On Thu, Jun 14, 2012 at 3:19 PM, Dave Airlie airl...@gmail.com wrote: I'm seriously thinking of resurrecting the kms killing branch, can anyone give me a reason not too, we'd fork the current master into a UMS branch and move on. +1 Alex Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
