Re: [PATCH xi2.1 inputproto] Many more updates to the XI 2.1 protocol
On Thu, Mar 10, 2011 at 03:47:41PM -0500, Chase Douglas wrote: Signed-off-by: Chase Douglas chase.doug...@canonical.com --- To see the full protocol spec as I make changes, go to: http://cgit.freedesktop.org/~cndougla/inputproto [...] Areas known to be lacking consensus agreement: * How to handle touch begin for clients who don't want unowned events. I think defining touch begin as a representation of the begining of a touch, as opposed to an event sent immediately after a touch begins, clarifies things. * Dropping of TouchUpdateUnowned hasn't been discussed before. * Should IndependentPointer devices be a separate touch device mode? Peter suggested using labels somehow, but I'm not sure what that means. I've left things as they were for now. * Addition of active_touches to DeviceEvent has not been formally reviewed * Should clients be able to make multiple grabs/selections per physical device per window? This also affects whether slave touch selections are canceled on device attachment. * Should direct touch emulated pointer events send motion then button press events, or just button press events? I worry about XI 1.x, which turns a button press into two or more events (button press + 1 or more valuator events) and how that could affect things. I think it's easier to leave it as it is. Slugging my way through it. fwiw, I didn't look at the patch but rather at the protocol spec as a whole to check if it makes sense when you _dont_ see what's been there before. I've read through the whole protocol, but these comments here affect mainly the top section before the actual protocol descriptions start. Comments: * the different TouchBegin semantics (owner/non-owner) IMO make sense because they simply reduce the semantics to Begin is the first event you'll get. this made less sense in the patch but reading the spec in one go it seems to fit nicely * there were several sections where I got badly confused. I've tried to improve them, feel free to point out where things aren't clear. * it is not clear whether a passive grab can be established for owner-only. does a grab always require the ownership semantics or can there be the default TouchBegin semantics too? If so, how is this decided? * can we allow more than one TouchObserve grab on the root window? after all, they won't be doing anything with it anyway * it seems impossible to be an observer that gets ownership. for a situation where you are below the accepting client, this means you're stuck. you can either observe (and never get ownership) or not observe (and lose those touch sequence the parent accepts) * the TouchObserve grab concept as-is doesn't quite fit. the idea originally came up to solve the problem of a grabber that wants to keep getting events after rejecting. That is what TouchRejectObserve does. The grab mode TouchObserve doesn't fit. if you can't become owner anyway, this is hardly different to RawEvents so we could use those. which brings me to * no RawEvents for touches? would be a good time to fix the broken grab semantics for raw events too (deliver them even if a grab is present) * SemiMultitouch simply needs a better name. Why not use BoundingBox or something more descriptive? * If SemiMultitouch isn't good enough to give you touch points, how is the pointer emulation decided? * as pointed out in the other email, I'm still confused on whether the master device delivers touch events. this isn't mentioned in the spec but the last patchset I reviewed skipped touch events from the master device * in the touch event delivery section, the sentence No touches from an * indirect device may begin while the device is floating, as it does not have an associated pointer position to focus events. This is incorrect. Run XIQueryPointer on the floating slave, you'll see it does have a pointer position. In fact, it even has a sprite, it's just not rendered. this is in-line with XI1 where clients are expected to manually render the cursor. * pointer event handling for indirect devices: what was the motivation for withholding touch events when the pointer leaves the window again? It isn't clear what withheld means, even if you have the ownership selection, you still don't get it? this whole concept feels a bit tacked on the side and breaks ownership assumptions (that touch events are delivered immediately if you can cope with ownership changes). * it is unclear if a client can grab for pointer + touch, both actively and passively. this is an issue for dependent device, especially because touch events are withheld during pointer grabs. I think the event mask should be honoured during grabs if valid. * a device that emulates pointer events must also initialize valuators though they may serve no other purpose. should there be a mapping field in the TouchAxisClass to say which valuator this one maps to in case of pointer emulation? for
Re: [PATCH synaptics] Add synaptics orientation support
Hi Aapo,
I noticed this patch in the synaptics repo today. Unfortunately, it needs
a bit more work, so I've reverted it for now. Please find my comments
inline.
fwiw, patches to synatics should go to the xorg-devel list first for public
review.
On Fri, Mar 18, 2011 at 04:26:46PM +1000, Peter Hutterer wrote:
This patch allows usage of synclient Orientation=0 (values from 0 to
3). It will rotate the touchpad similar to xrandr -o. Original patch
was extended for alps and ps2.
Signed-off-by: Christoph Brill egore...@egore911.de
---
include/synaptics-properties.h |3 +++
man/synaptics.man |6 ++
src/alpscomm.c | 29 +
src/eventcomm.c| 22 --
src/properties.c |8
src/ps2comm.c | 36 +---
src/synaptics.c|2 ++
src/synapticsstr.h |1 +
tools/synclient.c |1 +
9 files changed, 95 insertions(+), 13 deletions(-)
diff --git a/include/synaptics-properties.h b/include/synaptics-properties.h
index bdb2112..0b4e570 100644
--- a/include/synaptics-properties.h
+++ b/include/synaptics-properties.h
@@ -158,4 +158,7 @@
/* 32 Bit Integer, 2 values, horizontal hysteresis, vertical hysteresis */
#define SYNAPTICS_PROP_NOISE_CANCELLATION Synaptics Noise Cancellation
+/* 32 bit, 4 values, normal, inverted, left, right */
+#define SYNAPTICS_ORIENTATION Synaptics Orientation
why not use degrees here?
this opens the way for a unified rotation property for devices that need a
rotation outside of 90 degree values.
left doesn't have a clear meaning. 90 degrees clockwise is less
ambiguous
orientation vs rotation?
I'm more of a fan of the latter, but can be convinced otherwise.
+
#endif /* _SYNAPTICS_PROPERTIES_H_ */
diff --git a/man/synaptics.man b/man/synaptics.man
index 0a35883..44d1c27 100644
--- a/man/synaptics.man
+++ b/man/synaptics.man
@@ -510,6 +510,12 @@ AreaBottomEdge option to any integer value other than
zero. If supported by the
server (version 1.9 and later), the edge may be specified in percent of
the total height of the touchpad. Property: Synaptics Area
.
+.TP
+.BI Option \*qOrientation\*q \*q integer \*q
+Rotate the touchpad similar to xrandr -o.
+.
+The orientation can be 0 (normal), 1(left), 2 (inverted) or 3(right).
+.
same here, just because xrandr uses 0-3 doesn't make it a good idea ;)
.SH CONFIGURATION DETAILS
.SS Area handling
diff --git a/src/alpscomm.c b/src/alpscomm.c
index dc76655..7d5cda2 100644
--- a/src/alpscomm.c
+++ b/src/alpscomm.c
@@ -149,11 +149,12 @@ ALPS_get_packet(struct CommData *comm, InputInfoPtr
pInfo)
* reflects left,right,down,up in lef1,rig1,mid1,up1.
*/
static void
-ALPS_process_packet(unsigned char *packet, struct SynapticsHwState *hw)
+ALPS_process_packet(SynapticsPrivate *priv, unsigned char *packet, struct
SynapticsHwState *hw)
{
int x = 0, y = 0, z = 0;
int left = 0, right = 0, middle = 0;
int i;
+SynapticsParameters *para = priv-synpara;
x = (packet[1] 0x7f) | ((packet[2] 0x78) (7-3));
y = (packet[4] 0x7f) | ((packet[3] 0x70) (7-4));
@@ -172,8 +173,27 @@ ALPS_process_packet(unsigned char *packet, struct
SynapticsHwState *hw)
hw-multi[i] = FALSE;
if (z 0) {
- hw-x = x;
- hw-y = y;
+ if (para-orientation==0)
+ hw-x = x;
+ else if (para-orientation==2)
self-explanatory enums please, not magic numbers.
else if (para-orientation == ROTATION_90CW)
is much easier to read.
(also, spaces before/after ==)
+ hw-x = priv-maxx + priv-minx - x;
+ else if (para-orientation==3)
+ hw-y = (priv-maxx - x) * (priv-maxy - priv-miny) / (priv-maxx
- priv-minx) + priv-miny;
+ else if (para-orientation==1)
+ hw-y = (x - priv-minx) * (priv-maxy - priv-miny) / (priv-maxx
- priv-minx) + priv-miny;
+ else
+ hw-x = x;
+
+ if (para-orientation==0)
+ hw-y = y;
+ else if (para-orientation==2)
+ hw-y = priv-maxy + priv-miny - y;
+ else if (para-orientation==3)
+ hw-x = (y - priv-miny) * (priv-maxx - priv-minx) / (priv-maxy
- priv-miny) + priv-minx;
+ else if (para-orientation==1)
+ hw-x = (priv-maxy - y) * (priv-maxx - priv-minx) / (priv-maxy
- priv-miny) + priv-minx;
+ else
+ hw-y = y;
this needs to be done in a function to avoid duplicating the code.
}
hw-z = z;
hw-numFingers = (z 0) ? 1 : 0;
@@ -210,11 +230,12 @@ ALPSReadHwState(InputInfoPtr pInfo,
{
unsigned char *buf = comm-protoBuf;
struct SynapticsHwState *hw = (comm-hwState);
+SynapticsPrivate *priv = (SynapticsPrivate *)pInfo-private;
if (!ALPS_get_packet(comm, pInfo))
return FALSE;
-ALPS_process_packet(buf, hw);
+
Re: [PATCH util/macros] Add sed pattern for __xorgconfd__ (xorg.conf.d).
Twas brillig at 10:53:54 18.03.2011 UTC+10 when peter.hutte...@who-t.net did gyre and gimble: The Xorg xorg.conf substitutions are leftover from the transitional period where some distros were building our sources with the XFree86 and XF86config names until they had time to adjust the rest of their packages/installer/config code to the new names. PH probably not, I'm fine either way but right now the man pages have PH text like blah blah __xconfigfile__ or xorg.conf.d which is a bit PH asymmetrical. So why not fix it to by symmetrical in other way 'round, by substituting __xconfigfile__ back? -- http://fossarchy.blogspot.com/ pgpzOzUszfZEq.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: [PATCH util/macros] Add sed pattern for __xorgconfd__ (xorg.conf.d).
On Fri, Mar 18, 2011 at 08:17:03AM +0100, Mikhail Gusarov wrote: Twas brillig at 10:53:54 18.03.2011 UTC+10 when peter.hutte...@who-t.net did gyre and gimble: The Xorg xorg.conf substitutions are leftover from the transitional period where some distros were building our sources with the XFree86 and XF86config names until they had time to adjust the rest of their packages/installer/config code to the new names. PH probably not, I'm fine either way but right now the man pages have PH text like blah blah __xconfigfile__ or xorg.conf.d which is a bit PH asymmetrical. So why not fix it to by symmetrical in other way 'round, by substituting __xconfigfile__ back? because there's a lot more uses of __xconfigfile__ and I'd have to replace all of them ;) 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: xserver without DDX video driver.
Hi Dave, Thanks for the reply. a) Are you suggesting that Vesa always uses swrast for 3D rendering? Was reading some articles on the net and it seems like vesa driver can be used with a DRI based 3D Hardware driver also. Would really appreciate if you could elaborate here a little. b) Assuming i setup the vesa driver to work with DRI based 3D swrast driver for 3D, would i be able to run 3D OpenGL apps on this setup (which is using software components for both 3D and 2D drivers)? Are there are limitations on the resolutions that would be supported? c) what is the difference between a vesa driver and a dummy driver? Can i use a dummy driver instead of the vesa driver in the above setup? (will the answer for question (b) above be any different if i use dummy driver instead of vesa driver?) d) Does any of these drivers (Vesa and Dummy) use DRM? Thx K a. Can all openGL Apps be run on the setup with the vesa driver? Are there any restrictions on the reslolution supported? b. Will the dummy driver based config also do the same? i.e. swrast usage for all OGL and GLX calls? On Fri, 2011-03-18 at 10:09 +1000, Dave Airlie wrote: Are the above two configs valid? If so, could you also throw some hints as to how to build these configs (in the sense what changes need to be done to the xorg.conf file to achieve these configs?) pretty much what you get if you just load vesa driver. it should use swrast for all GLX. 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] [xorg/xserver] config: handle device change event properly
wakeup_handler in udev.c wasn't dealing with udev change events.
There are situations when a device can gain its input capabilities
after it has been added to the system and therefore the change events
must be handled as well.
The change is handled as a consecutive device removal and addition.
Signed-off-by: Erkki Seppälä erkki.sepp...@vincit.fi
Signed-off-by: Stefan Kost stefan.k...@nokia.com
---
Stefan, please ask a proper Reported-by tag for the bug from the
original reporter.
config/udev.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/config/udev.c b/config/udev.c
index a2f5710..c120747 100644
--- a/config/udev.c
+++ b/config/udev.c
@@ -246,6 +246,10 @@ wakeup_handler(pointer data, int err, pointer read_mask)
device_added(udev_device);
else if (!strcmp(action, remove))
device_removed(udev_device);
+else if (!strcmp(action, change)) {
+device_removed(udev_device);
+device_added(udev_device);
+}
}
udev_device_unref(udev_device);
}
--
1.7.0.4
___
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 util/macros] Add sed pattern for __xorgconfd__ (xorg.conf.d).
On Fri, 2011-03-18 at 10:23 +1000, Peter Hutterer wrote: Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- xorg-macros.m4.in |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 44038e1..1476971 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -187,6 +187,7 @@ MAN_SUBSTS=\ -e 's|__xorgversion__|\\$(PACKAGE_STRING)\ \\$(XORG_MAN_PAGE)\|' \ -e 's|__xservername__|Xorg|g' \ -e 's|__xconfigfile__|xorg.conf|g' \ + -e 's|__xorgconfdir__|xorg.conf.d|g' \ -e 's|__projectroot__|\$(prefix)|g' \ -e 's|__apploaddir__|\$(appdefaultdir)|g' \ -e 's|__appmansuffix__|\$(APP_MAN_SUFFIX)|g' \ I ran into this while reworking the server man pages. The value of the dir is hard coded: XF86CONFIGDIR=xorg.conf.d In the manpages.am xserver manpages.am: -e 's|__xconfigdir__|$(__XCONFIGDIR__)|g' \ I would prefer not adding cruft, even if it completes a pattern. Once in there, it will have to remain there forever. You did not mention where this pattern would be used. I searched all man pages and could not find any xorg.conf.d. Would that be for new text? ___ 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: xserver without DDX video driver.
On 03/18/11 05:15 AM, kumar vemuri wrote: c) what is the difference between a vesa driver and a dummy driver? VESA drives a hardware graphics device, using the least common denominator VESA standard - you'll see its output on your monitor. Dummy just allocates some virtual memory and draws pictures there, never interacting with any graphics hardware, so the output isn't displayed anywhere. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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 util/macros] Add sed pattern for __xorgconfd__ (xorg.conf.d).
On Fri, 2011-03-18 at 17:32 +1000, Peter Hutterer wrote: On Fri, Mar 18, 2011 at 08:17:03AM +0100, Mikhail Gusarov wrote: Twas brillig at 10:53:54 18.03.2011 UTC+10 when peter.hutte...@who-t.net did gyre and gimble: The Xorg xorg.conf substitutions are leftover from the transitional period where some distros were building our sources with the XFree86 and XF86config names until they had time to adjust the rest of their packages/installer/config code to the new names. PH probably not, I'm fine either way but right now the man pages have PH text like blah blah __xconfigfile__ or xorg.conf.d which is a bit PH asymmetrical. So why not fix it to by symmetrical in other way 'round, by substituting __xconfigfile__ back? because there's a lot more uses of __xconfigfile__ and I'd have to replace all of them ;) XF86CONFIGFILE=xorg.conf There are 166 instances in 56 files. Not an unreasonable task. We won't be able to take out __xconfigfile__ but we can add a comment not to use it. I'll add as a TODO. 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 signature.asc Description: This is a digitally signed message part ___ 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] Fix XWin compilation after commit 769531b9
commit 769531b9 Add mode field to pointer movement hooks changes the function signature of miPointerSetPosition() to include the movement mode which resulted in the pointer position Update use of miPointerSetPosition() in winEnqueueMotion() appropriately (See http://tinderbox.freedesktop.org/builds/2011-03-16-0008/logs/xserver/#build) Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- hw/xwin/winmouse.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/xwin/winmouse.c b/hw/xwin/winmouse.c index ee93d8f..080e096 100644 --- a/hw/xwin/winmouse.c +++ b/hw/xwin/winmouse.c @@ -372,7 +372,7 @@ void winEnqueueMotion(int x, int y) ValuatorMask mask; EventListPtr events; - miPointerSetPosition(g_pwinPointer, x, y); + miPointerSetPosition(g_pwinPointer, POINTER_RELATIVE, x, y); valuators[0] = x; valuators[1] = y; -- 1.7.4 ___ 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: xserver without DDX video driver.
On 3/17/11 6:54 PM, kumar vemuri wrote: Thanks Alan and Adam for the replies. Have another related question: i want to build a software based 3D and 2D renderer system with DRI with the following. So you want to use the DRI to get direct hardware access... a. I dont wish to use the GPU for 3D or 2D acceleration (so dont want to use the 3D/2D driver of my GPU). Instead, want to use the dummy driver that you are suggesting. ... but you don't have any hardware to directly access. Either I'm confused about what you're trying to accomplish, or you are. - ajax ___ 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 inputproto] Add minimal asciidoc syntax
On Fri, 2011-03-18 at 10:07 +1000, Peter Hutterer wrote: I don't disagree and I certainly haven't use asciidoc in anything more complex than a man page. just one comment that I found from a quick search, suggesting that olink _may_ be possible in asciidoc. http://groups.google.com/group/asciidoc/browse_thread/thread/4ff80242da4a3634 btw, git uses asciidoc and has some extensive asciidoc.conf. might be worthwhile to get some tips and tricks from there. Thanks for the pointer. We may be victim of the pendulum syndrome. The too many formats replaced with one size fits all. It would be better for the project if there were some consistency in the chosen format. It should not be random or based on what the developer happens to be more familiar with. Some heuristics based on content type, size, etc... Perhaps doxygen should also be considered in some cases. I have not given any thoughts yet, but protocols are heavy on public api so they seem to be good candidates. Having the code and the docs in the source could go a long way in terms keeping them in sync. signature.asc Description: This is a digitally signed message part ___ 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 xserver 2/3] Add generalized unit test support using util-macros.
Gaetan Nadon mems...@videotron.ca (14/03/2011): A handful of modules have begun adding unit test programs. These macros will help providing a consistent interface which will help package builders and developers to manage the functionality. XORG_ENABLE_UNIT_TESTS will turn on/off unit testing, regardless of how it is implemented. The default (yes/no) can be specified by each module. It can be used by itself if glib or -wrap support is not needed. XORG_WITH_GLIB will probe the system for glib-2.0. A different version can be specified in each module. It will consult XORG_ENABLE_UNIT_TESTS but can be used by itself in contexts other then unit testing. The default (yes/no) can be specified by each module. XORG_LD_WRAP will probe the linker for -wrap support. It will consult XORG_ENABLE_UNIT_TESTS but can be used by itself in contexts other then unit testing. than Thanks for your work on unit tests, for the series: Acked-by: Cyril Brulebois k...@debian.org KiBi. signature.asc Description: Digital 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: [PATCH xserver 2/3] Add generalized unit test support using util-macros.
Hi, sorry, missed that second thread while replying to the first one. Gaetan Nadon mems...@videotron.ca (17/03/2011): A handful of modules have begun adding unit test programs. These macros will help providing a consistent interface which will help package builders and developers to manage the functionality. XORG_ENABLE_UNIT_TESTS will turn on/off unit testing, regardless of how it is implemented. The default (yes/no) can be specified by each module. It can be used by itself if glib or -wrap support is not needed. XORG_WITH_GLIB will probe the system for glib-2.0. A different version can be specified in each module. It will consult XORG_ENABLE_UNIT_TESTS but can be used by itself in contexts other then unit testing. The default (yes/no) can be specified by each module. XORG_LD_WRAP will probe the linker for -wrap support. It will consult XORG_ENABLE_UNIT_TESTS but can be used by itself in contexts other then unit testing. than Thanks for your work on unit tests, for the series: Acked-by: Cyril Brulebois k...@debian.org KiBi. signature.asc Description: Digital 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
[PATCH joystick] Remove old input ABI leftovers from jstkCoreUnInit
From: Timo Aaltonen timo.aalto...@canonical.com
Fixes crashes on device unplug:
https://bugs.freedesktop.org/show_bug.cgi?id=35391
Signed-off-by: Timo Aaltonen timo.aalto...@canonical.com
---
src/jstk.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/src/jstk.c b/src/jstk.c
index 9796a46..41cace7 100644
--- a/src/jstk.c
+++ b/src/jstk.c
@@ -622,13 +622,6 @@ jstkCoreUnInit(InputDriverPtrdrv,
{
JoystickDevPtr device = (JoystickDevPtr) pInfo-private;
-if (device-keyboard_device != NULL)
-{
-xf86DisableDevice(device-keyboard_device-dev, TRUE);
-device-keyboard_device = NULL;
-}
-
-free (device);
pInfo-private = NULL;
xf86DeleteInput(pInfo, 0);
}
--
1.7.4.1
___
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: Please revert Re: [PATCH 1/4] dix: Remove usage_class from pixmaps, store it in -drawable.class
On Fri, 18 Mar 2011 14:35:01 +1000, Dave Airlie airl...@gmail.com wrote: Please revert 1564c82417d201de5b9a5ec5e7aa4ef14c45fbad (commit for this patch). Merged. d5b16b037b8fe12ba85c68c8289b6a8cc5e3a09d -- keith.pack...@intel.com pgp063pmEhgfw.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: [PATCH xserver 1/3] config: group document related XORG_ macros together
On Thu, 17 Mar 2011 19:26:35 -0400, Gaetan Nadon mems...@videotron.ca wrote: config: group document related XORG_ macros together Add generalized unit test support using util-macros. test: git ignore the list test executable Merged. dc9ce69..efcb727 master - master Note that this series requires that the latest util/macros package be installed. -- keith.pack...@intel.com pgpGRDaip4Hcw.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: Please revert Re: [PATCH 1/4] dix: Remove usage_class from pixmaps, store it in -drawable.class
On 3/18/11 12:35 AM, Dave Airlie wrote: Hi Keith, Please revert 1564c82417d201de5b9a5ec5e7aa4ef14c45fbad (commit for this patch). The drivers used the top bits of the usage_hint to store driver private flags (intel, radeon, nouveau). With EXA we need to get at this data so if we migrate the pixmap we can create the correct type of pixmap in the driver, however this commit truncates the usage_hint into 8-bit class and loses all the good stuff. Weak. I feel like there should be some cleaner way to do that. - ajax ___ 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 util/macros] Add sed pattern for __xorgconfd__ (xorg.conf.d).
On Fri, Mar 18, 2011 at 10:50:34AM -0400, Gaetan Nadon wrote: On Fri, 2011-03-18 at 10:23 +1000, Peter Hutterer wrote: Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- xorg-macros.m4.in |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 44038e1..1476971 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -187,6 +187,7 @@ MAN_SUBSTS=\ -e 's|__xorgversion__|\\$(PACKAGE_STRING)\ \\$(XORG_MAN_PAGE)\|' \ -e 's|__xservername__|Xorg|g' \ -e 's|__xconfigfile__|xorg.conf|g' \ + -e 's|__xorgconfdir__|xorg.conf.d|g' \ -e 's|__projectroot__|\$(prefix)|g' \ -e 's|__apploaddir__|\$(appdefaultdir)|g' \ -e 's|__appmansuffix__|\$(APP_MAN_SUFFIX)|g' \ I ran into this while reworking the server man pages. The value of the dir is hard coded: XF86CONFIGDIR=xorg.conf.d In the manpages.am xserver manpages.am: -e 's|__xconfigdir__|$(__XCONFIGDIR__)|g' \ I would prefer not adding cruft, even if it completes a pattern. Once in there, it will have to remain there forever. You did not mention where this pattern would be used. I searched all man pages and could not find any xorg.conf.d. Would that be for new text? yeah, updating some of the driver man pages to point to xorg.conf.d. I remember writing at least one of them, so I think one driver (wacom maybe?) should already have some mention. or not, can't remember if that got pushed :) 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
[PATCH xorg-server] adds nouveau as standard driver for linux systems
nouveau+drm is since the linux kernel version 2.6.34 integrated by default.So since it supports more cards like fermi (sadly not old river nv03 cards) it would be best to set nouveau as standard Signed-off-by: Thomas Schneider maxmust...@gmail.com --- hw/xfree86/common/xf86pciBus.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/hw/xfree86/common/xf86pciBus.c b/hw/xfree86/common/xf86pciBus.c index 447b192..b20b2e4 100644 --- a/hw/xfree86/common/xf86pciBus.c +++ b/hw/xfree86/common/xf86pciBus.c @@ -1123,7 +1123,12 @@ videoPtrToDriverList(struct pci_device *dev, break; case 0x102b:driverList[0] = mga; break; case 0x10c8:driverList[0] = neomagic; break; - case 0x10de: case 0x12d2: driverList[0] = nv; break; + case 0x10de: case 0x12d2: + #ifdef __linux__ + driverList[0] = nouveau; break; + #else + driverList[0] = nv; break; + #endif case 0x1106:driverList[0] = openchrome; break; case 0x1b36: driverList[0] = qxl; break; case 0x1163:driverList[0] = rendition; break; -- 1.7.4.1 ___ 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: Please revert Re: [PATCH 1/4] dix: Remove usage_class from pixmaps, store it in -drawable.class
On Fri, 18 Mar 2011 14:56:45 -0400, Adam Jackson a...@nwnk.net wrote: Weak. I feel like there should be some cleaner way to do that. No argument here. The usage_hint is the only spot to stick driver-specific data in the create_pixmap call. -- keith.pack...@intel.com pgpX1hXx3T9ct.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: [GSOC] greetings
Welcome - we're glad to have students showing interest in our GSoC projects, and got official confirmation today that X.Org has been accepted as a mentoring organization into the GSoC program this year. I've cc'ed the xorg-devel mailing list, since you'll have a much easier time connecting with the developers there than on the general end-user support mailing list of xorg@... Those projects probably also cross over into the area covered by the dri-devel mailing list as well, since the DRI/DRM drivers on the kernel side are covered there. -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System On 03/16/11 03:42 PM, Антонов Николай wrote: Hello, all! I am Antonov Nikolay. I am s third year student of Computer Science in Kostroma State Technological University, Russian Federation. And I would like to take part in GSOC 2011 in xorg project. I realy like 2 ideas: 1) Open Source PRIME multi-gpu support 2) Support Graphics Card hot-switch. Both have similar idea but different implementation. First already have pice of code(it would be a nice start point!). But I think that copying data from one video card to another is bad idea(it is slowdown performance and integrate card never poweroff). So, second idea looks better (but it seems harder). I didn't take part in well-known opensources project yet. But I have own opensource project[1] written in C (it is pidgin/libpurple protocol-plugin for russian IM service). I have experience with svn/git and mailing lists ;-) PS: in xorg gsoc wiki[2] 2010 Ideas meets twice. This is confusing. [1] http://code.google.com/p/mrim-prpl/ [2] http://xorg.freedesktop.org/wiki/SummerOfCodeIdeas Antonov Nikolay ___ x...@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: alan.coopersm...@oracle.com ___ 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
