Re: [PUSH xf86-video-nested] Driver for nesting X-servers
On 05/09/2011 01:53 AM, Jamey Sharp wrote: On Sun, May 08, 2011 at 11:48:26PM +0200, Stef Bon wrote: On 05/08/2011 05:07 PM, Jamey Sharp wrote: (I think you mean without using Xinerama.) no, I do mean with Xinerama. As I've written before the trick is to link a screen to a display: :99:0 - :0.0 and :99:1 - :1.0 Assuming you meant :99.0 and :99.1, and assuming that :0 and :1 have only one screen each, those are all non-Xinerama configurations. Xinerama just lets you take multiple screens (like an Intel and a Radeon card, or two nested screens, or some other mix) and make them *look* like one screen to clients. Instead, you want the screens on :99 to look like separate screens to clients. I wouldn't have even mentioned it except I don't think you'll get what you're looking for if you're trying to have Xinerama turned on. Hi, yes, you're right, a real Xinerama is different cards combined in one display. See the multiseat setup here: http://beforeafterx.blogspot.com/2011/02/multiseat-setup.html As you see there, it's a multiseat sollution. Well, to be honoust, it's using Twinview, a nvidia extension, which can make two monitors act as one display, and can make it look like Xinerama. why do you think I do not get what I'm looking for?? Stef ___ 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 0/8] Port xf86-video-v4l driver to V4L2 version 2
Hi Mauro, Mauro Carvalho Chehab mche...@redhat.com (11/02/2011): Mauro Carvalho Chehab (8): Port xf86-video-v4l driver to V4L2 thanks for your work on it. Maybe it would be nice to have a release at some point? Mraw, 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: Are we ready to tag release libXext 1.3.0?
Thanks for digging that patch up, but it is incomplete. Let me plug in the missing functions and do a little testing, then I'll post an updated patch. Thanks, -James nvpublic On 5/7/11 9:40 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: Thanks - as you probably saw I pushed libXext 1.3.0, but the equivalent changes for xcb don't seem to be in the git master repo yet - is this: https://github.com/cubanismo/xcbproto/commit/6c022bc1fe34316f80f4c3817bc69a70099c6320 the needed change? Did it get lost in review somewhere? (Sorry, I haven't kept track, and just trying to get everything finished up for integrating the client side of Sync 3.1 to our packages to go along with the Xorg 1.10 integration.) -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System On 05/ 5/11 08:09 PM, James Jones wrote: I'm not aware of any fence sync issues that would hold up a release. Everything should be ready to go. Thanks, -James nvpublic On 5/5/11 7:09 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: It looks like we've still not done a release of libXext with the new XSyncAwaitFence() API yet, even though the proto server were released a while ago - is there anything remaining to do there or any reason not to go ahead and make a libXext 1.3.0 release? -- -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] Make RegionInit() and RegionCreate() take just a box and no size
Daniel Stone dan...@fooishbar.org writes: On Mon, May 02, 2011 at 07:44:15AM -0400, Søren Sandmann wrote: The interface to these function was was very confusing since it gave the impression that they initialized the region from a list of boxes, which they didn't. This patch changes the interface to take just one box and fixes all the callers accordingly. Why not just change all RegionInit(region, box, 1) calls to use RegionInitBoxes(region, box, 1), and add a RegionCreateBoxes() or similar? Advantage of adding a new function are that that it will automatically catch cases where 0 is currently being passed for the number of boxes, and people who haven't paid attention won't be tempted to create new bugs. Soren ___ 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] Make RegionInit() and RegionCreate() take just a box and no size
On Mon, May 09, 2011 at 05:18:29PM +0200, Soeren Sandmann wrote: Daniel Stone dan...@fooishbar.org writes: On Mon, May 02, 2011 at 07:44:15AM -0400, Søren Sandmann wrote: The interface to these function was was very confusing since it gave the impression that they initialized the region from a list of boxes, which they didn't. This patch changes the interface to take just one box and fixes all the callers accordingly. Why not just change all RegionInit(region, box, 1) calls to use RegionInitBoxes(region, box, 1), and add a RegionCreateBoxes() or similar? Advantage of adding a new function are that that it will automatically catch cases where 0 is currently being passed for the number of boxes, and people who haven't paid attention won't be tempted to create new bugs. Sure -- so if you change everyone to use RegionInitBoxes, then happy days, right? Surely that's the API we want, noting that the extent-only case you've implemented with RegionInit(rgn, extents) is possible with RegionInitBoxes(rgn, extents, 1). Seems like it'd be best to just remove the arguments completely rather than making them extent-only, such that they created/initialised to an empty region. That way there's no lingering confusion at all. Cheers, Daniel ___ 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 xrandr] find_mode: Search for the mode closes to the specified rate
Hey Keith, clang found an issue in xrandr that I'd like you to review the fix for. I'm fairly certain this is what you intended. Thanks, Jeremy For reference: http://people.freedesktop.org/~jeremyhu/analyzer/yuffie/20110509-/xrandr/report-gZOzCf.html#EndPath http://cgit.freedesktop.org/xorg/app/xrandr/commit/?id=d9aeb4a7544ad4a33f6f54bc46bff5cdf231a986 --- From 9f1eb72eea2ba5375be9a2db1e193cda8a50a841 Mon Sep 17 00:00:00 2001 From: Jeremy Huddleston jerem...@apple.com Date: Mon, 9 May 2011 09:21:29 -0700 Subject: [PATCH] find_mode: Search for the mode closes to the specified rate This was the intention of d9aeb4a7544ad4a33f6f54bc46bff5cdf231a986, but find_mode was still picking the first string match rather than the match with the closest refresh rate. xrandr.c:740:3: warning: Value stored to 'bestDist' is never read bestDist = dist; ^ Found-by: clang static analyzer Signed-off-by: Jeremy Huddleston jerem...@apple.com --- xrandr.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/xrandr.c b/xrandr.c index 564d4da..10d034d 100644 --- a/xrandr.c +++ b/xrandr.c @@ -740,7 +740,6 @@ find_mode (name_t *name, double refresh) bestDist = dist; best = mode; } - break; } } return best; -- 1.7.4.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 2/6] XKB: Simplify a loop in ProcXkbGetKbdByName
Sorry I'm late but:
Daniel Stone dan...@fooishbar.org (05/05/2011):
Replace:
for (stuff; things; etc) {
if (misc || other) {
[...]
}
}
with:
for (stuff; things; etc) {
if (!misc !other)
continue;
[...]
}
that says nothing about that:
-if ((tmpd == dev) || (!IsMaster(tmpd) GetMaster(tmpd,
MASTER_KEYBOARD) == dev)) {
+if (tmpd != dev GetMaster(tmpd, MASTER_KEYBOARD) != dev)
You're losing one part here; was that on purpose?
Mraw,
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: [PUSH xf86-video-nested] Driver for nesting X-servers
On Mon, May 09, 2011 at 08:56:50AM +0200, Stef Bon wrote: yes, you're right, a real Xinerama is different cards combined in one display. See the multiseat setup here: http://beforeafterx.blogspot.com/2011/02/multiseat-setup.html As you see there, it's a multiseat sollution. Well, to be honoust, it's using Twinview, a nvidia extension, which can make two monitors act as one display, and can make it look like Xinerama. I get it. You don't have :99.0 and :99.1, you just have one protocol screen, and position the Xephyr windows based on your knowledge of the Xinerama or Twinview configuration. Sure, that works too, and should work equally well with the nested driver. I see one of the complaints in netpatia's documentation is difficulty configuring the geometry of the nested windows. A patch to tell the nested driver what window geometry you want should be easy to write and would be welcome. Jamey 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
Call for desktop/graphics/mobile tracks for Linux Plumbers' Conf 2011
We have both desktop (for general graphics/media stuff) and mobile tracks at this year's LPC. So if you're working on a topic related to one of the above areas, especially one that has open issues or spans multiple parts of the stack, please submit a topic for discussion at http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011MC/proposals/new against the appropriate track. Proposals for presentations (track independent talks about a specific topic) are also open until May 15th, so if you have a topic you'd like to present that doesn't fit into an existing track, be sure to submit it soon. Early registration for LPC is open until June 1st, so regardless of whether you're submitting a topic, if you see discussions or proposed talks of interest to you, be sure to register soon to get the discounted rate. Thanks, Jesse Barnes LPC2011 Planning Chair ___ 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: More DRI2 invalidate stuff
On Fri, 6 May 2011 18:18:14 +0300, ville.syrj...@nokia.com wrote: The proposed DRI@ invalidate patch [1] causes a lot more invalidate events to be sent out. That will cause processes to wake up needlessly. Eg. if an unredirected fullscreen app is flipping, each flip will also send an invalidate event to the compositor, since the composite overlay and client window share the same pixmap. Now, assuming that the compositor hasn't done a GetBuffers yet, there's no need to send an invalidate event to it. I took the easy approach and stuck the boolean flag into the DRI2DrawableRec. The optimal solution would have been to put it into DRI2DrawableRefRec and keep track of the invalidate state per reference, but that would require the client's drawable ID and client ID so that the correct ref could be found in GetBuffers. Too much hassle for my taste, and I think this simple approach should provide equal benefit in most cases. Have you measured this to reduce invalidates? I don't see how something that is producing flip requests that produce invalidates will do so without having called getbuffers in between. pgpd9GhWrYcQx.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 rendercheck] Report the success_mask to stdout
On Sat, 7 May 2011 18:20:17 -0700, Jeremy Huddleston jerem...@apple.com wrote:
This was previously computed but never passed on to the caller.
Found-by: clang static analyzer
Signed-off-by: Jeremy Huddleston jerem...@apple.com
Doing something useful with those success flags would be nice, but I
don't think a hex dump of it is that.
---
tests.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests.c b/tests.c
index f722bc6..1b47eee 100644
--- a/tests.c
+++ b/tests.c
@@ -752,7 +752,7 @@ do {
\
free(test_mask);
free(test_dst);
- printf(%d tests passed of %d total\n, tests_passed, tests_total);
+ printf(%d tests passed of %d total (successful groups: 0x%x)\n,
tests_passed, tests_total, success_mask);
return tests_passed == tests_total;
}
--
pgpkqFUSib95s.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: More DRI2 invalidate stuff
On Mon, May 09, 2011 at 01:42:03PM -0700, ext Eric Anholt wrote: On Fri, 6 May 2011 18:18:14 +0300, ville.syrj...@nokia.com wrote: The proposed DRI@ invalidate patch [1] causes a lot more invalidate events to be sent out. That will cause processes to wake up needlessly. Eg. if an unredirected fullscreen app is flipping, each flip will also send an invalidate event to the compositor, since the composite overlay and client window share the same pixmap. Now, assuming that the compositor hasn't done a GetBuffers yet, there's no need to send an invalidate event to it. I took the easy approach and stuck the boolean flag into the DRI2DrawableRec. The optimal solution would have been to put it into DRI2DrawableRefRec and keep track of the invalidate state per reference, but that would require the client's drawable ID and client ID so that the correct ref could be found in GetBuffers. Too much hassle for my taste, and I think this simple approach should provide equal benefit in most cases. Have you measured this to reduce invalidates? Yes, of course. Someone else at Nokia noticed the problem too, since soon after integrating the patch from [1] to our internal X server tree, I got a blocker bug saying that some unrelated processes get woken up while scrolling some list in one app. Good thing I had realized the problem already, so I had the fix ready. I don't see how something that is producing flip requests that produce invalidates will do so without having called getbuffers in between. You're barking up the wrong drawable, so to speak. Of course the drawable being flipped needs its GetBuffers and invalidate events. It's all the other drawables which have a DRI2 drawable and share the same pixmap, that get hammered with the unwanted invalidate events. -- Ville Syrjälä ___ 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: [PUSH xf86-video-nested] Driver for nesting X-servers
On 05/09/2011 06:37 PM, Jamey Sharp wrote: On Mon, May 09, 2011 at 08:56:50AM +0200, Stef Bon wrote: yes, you're right, a real Xinerama is different cards combined in one display. See the multiseat setup here: http://beforeafterx.blogspot.com/2011/02/multiseat-setup.html As you see there, it's a multiseat sollution. Well, to be honoust, it's using Twinview, a nvidia extension, which can make two monitors act as one display, and can make it look like Xinerama. I get it. You don't have :99.0 and :99.1, you just have one protocol screen, and position the Xephyr windows based on your knowledge of the Xinerama or Twinview configuration. Sure, that works too, and should work equally well with the nested driver. I see one of the complaints in netpatia's documentation is difficulty configuring the geometry of the nested windows. A patch to tell the nested driver what window geometry you want should be easy to write and would be welcome. Yes exactly, the problem with the current sollutions with Xephyr is that it only can get the size of the screen, and not the position. This is really strange and not so nice, since - as you can read in the guide at the webpage I've send earlier - it's required to move the second Xephyr window to the second screen. By default it starts at 0,0. If I remember correctly in the past it was possible to add also the position parameters to Xephyr. There is an option -origin, but what it does I do not know. Now that's the trouble with Xephyr. And if you ask me it looks a little bit redundant, if you configure a X display with two screens, one screen for every monitor, and then calculate the position of every monitor in the display, and then move the Xephyr window to the right position, which is exactly the area the screen takes, if you follow me. When I saw that the nested driver uses the display I hoped this also includes the screennumber. When it does, the whole calculation for the position and the moving of windows is not necessary. I do not know enough of the X protocol it's easy to just use the nested driver using the display (including the screen number!!) but is this possible?? Stef ___ 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 rendercheck] Report the success_mask to stdout
Well it's better than nothing... but ok, I'll beautify it.
On May 9, 2011, at 13:47, Eric Anholt wrote:
On Sat, 7 May 2011 18:20:17 -0700, Jeremy Huddleston jerem...@apple.com
wrote:
This was previously computed but never passed on to the caller.
Found-by: clang static analyzer
Signed-off-by: Jeremy Huddleston jerem...@apple.com
Doing something useful with those success flags would be nice, but I
don't think a hex dump of it is that.
---
tests.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests.c b/tests.c
index f722bc6..1b47eee 100644
--- a/tests.c
+++ b/tests.c
@@ -752,7 +752,7 @@ do {
\
free(test_mask);
free(test_dst);
-printf(%d tests passed of %d total\n, tests_passed, tests_total);
+printf(%d tests passed of %d total (successful groups: 0x%x)\n,
tests_passed, tests_total, success_mask);
return tests_passed == tests_total;
}
--
___
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/6] XKB: Simplify a loop in ProcXkbGetKbdByName
Hi,
On Mon, May 09, 2011 at 06:34:09PM +0200, Cyril Brulebois wrote:
Sorry I'm late but:
Daniel Stone dan...@fooishbar.org (05/05/2011):
Replace:
for (stuff; things; etc) {
if (misc || other) {
[...]
}
}
with:
for (stuff; things; etc) {
if (!misc !other)
continue;
[...]
}
that says nothing about that:
-if ((tmpd == dev) || (!IsMaster(tmpd) GetMaster(tmpd,
MASTER_KEYBOARD) == dev)) {
+if (tmpd != dev GetMaster(tmpd, MASTER_KEYBOARD) != dev)
You're losing one part here; was that on purpose?
Yes. I could probably call it out in the commit message if that would
help?
Cheers,
Daniel
___
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 rendercheck] Report which test groups passed successfully
This was previously computed but never passed on to the caller.
Found-by: clang static analyzer
Signed-off-by: Jeremy Huddleston jerem...@apple.com
---
configure.ac |2 +-
main.c| 83 +++--
rendercheck.h |5 +++-
tests.c |2 +
4 files changed, 58 insertions(+), 34 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4fa5a63..09b07bd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@ XORG_DEFAULT_OPTIONS
AC_CHECK_HEADERS([err.h])
# Checks for pkg-config packages
-PKG_CHECK_MODULES(RC, [xrender x11])
+PKG_CHECK_MODULES(RC, [xrender x11 xproto = 7.0.17])
AC_CONFIG_FILES([Makefile
man/Makefile])
diff --git a/main.c b/main.c
index 9a97d72..7fa771c 100644
--- a/main.c
+++ b/main.c
@@ -103,16 +103,55 @@ describe_format(char *desc, int len, XRenderPictFormat
*format)
}
}
+struct {
+int flag;
+const char *name;
+} available_tests[] = {
+{TEST_FILL, fill},
+{TEST_DSTCOORDS, dcoords},
+{TEST_SRCCOORDS, scoords},
+{TEST_MASKCOORDS, mcoords},
+{TEST_TSRCCOORDS, tscoords},
+{TEST_TMASKCOORDS, tmcoords},
+{TEST_BLEND, blend},
+{TEST_COMPOSITE, composite},
+{TEST_CACOMPOSITE, cacomposite},
+{TEST_GRADIENTS, gradients},
+{TEST_REPEAT, repeat},
+{TEST_TRIANGLES, triangles},
+{TEST_BUG7366, bug7366},
+{0, NULL}
+};
+
+void print_tests(FILE *file, int tests) {
+int i, j;
+
+for(i=0, j=0; available_tests[i].name; i++) {
+if(!(available_tests[i].flag tests))
+continue;
+if(j % 5 == 0) {
+if(j != 0)
+putc('\n', stderr);
+putc('\t', stderr);
+} else {
+fprintf(stderr, , );
+}
+fprintf(stderr, %s, available_tests[i].name);
+j++;
+}
+if(j)
+fprintf(file, \n);
+}
+
+_X_NORETURN
static void
usage (char *program)
{
fprintf(stderr, usage: %s [-d|--display display] [-v|--verbose]\n
\t[-t test1,test2,...] [-o op1,op2,...] [-f format1,format2,...]\n
\t[--sync] [--minimalrendering] [--version]\n
-\tAvailable tests: fill,dcoords,scoords,mcoords,tscoords,\n
-
\t\ttmcoords,blend,composite,cacomposite,gradients,repeat,triangles,\n
-\t\tbug7366\n,
- program);
+ Available tests:\n, program);
+print_tests(stderr, ~0);
exit(1);
}
@@ -197,35 +236,15 @@ int main(int argc, char **argv)
enabled_tests = 0;
while ((test = strsep(nextname, ,)) != NULL) {
- if (strcmp(test, fill) == 0) {
- enabled_tests |= TEST_FILL;
- } else if (strcmp(test, dcoords) == 0) {
- enabled_tests |= TEST_DSTCOORDS;
- } else if (strcmp(test, scoords) == 0) {
- enabled_tests |= TEST_SRCCOORDS;
- } else if (strcmp(test, mcoords) == 0) {
- enabled_tests |= TEST_MASKCOORDS;
- } else if (strcmp(test, tscoords) == 0) {
- enabled_tests |= TEST_TSRCCOORDS;
- } else if (strcmp(test, tmcoords) == 0) {
- enabled_tests |= TEST_TMASKCOORDS;
- } else if (strcmp(test, blend) == 0) {
- enabled_tests |= TEST_BLEND;
- } else if (strcmp(test, composite) == 0) {
- enabled_tests |= TEST_COMPOSITE;
- } else if (strcmp(test, cacomposite) == 0) {
- enabled_tests |= TEST_CACOMPOSITE;
- } else if (strcmp(test, gradients) == 0) {
- enabled_tests |= TEST_GRADIENTS;
- } else if (strcmp(test, repeat) == 0) {
- enabled_tests |= TEST_REPEAT;
- } else if (strcmp(test, triangles) == 0) {
- enabled_tests |= TEST_TRIANGLES;
- } else if (strcmp(test, bug7366) == 0) {
- enabled_tests |= TEST_BUG7366;
- } else {
- usage(argv[0]);
+ int i;
+ for(i=0; available_tests[i].name; i++) {
+ if(strcmp(test,
available_tests[i].name) == 0) {
+ enabled_tests |=
available_tests[i].flag;
+ break;
+
Re: [PATCH 20/20] dix: reduce scope of tmp and mult.
On Sun, May 08, 2011 at 03:16:38PM +0200, Simon Thum wrote: On 05/03/2011 03:00 AM, Peter Hutterer wrote: Some more documentation would have helped, I found it hard to get the big picture in my head even with the wiki page. There are too many details that weren't clear immediately and having what's in your brain about the accel methods backed up somewhere would be a benefit :) I could surely add some more doc comments, but beyond that I'll have to rely on some pointer what exactly might have helped you. For example, the direction/octant field is something I bet has no simpler counterpart, but I can understand if people fail to see what it is for anyway. But you seem to have grasped it, so I don't know whether it's documented good or bad? Now that I understand those parts better, it's hard for me to come up with places where to add documentation. The few things that I think could possibl need documentation are: Trackers? what are they, why are they reset to 0? ComputeAcceleration takes the 6 velocity factors, but why? this is one of the things that were confusing. I looked at the code, but it explains what it does, not why it does so. Guess I should have googled for Simpons's rule earlier too. Direction was what threw me off. It's quite prominent in the code but the actual use of it is one line. The documentation for that line could probably be simply as direction changed octant, skip the rest Looking at other people's code is a bit like looking at a painting through a straw. You see a tiny part of it and it's hard to see everything. On the plus side, the chance that there's drinking involved soon is quite high. 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: IR remote control autorepeat / evdev
On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote: Hi all! Most IR/RF remotes differ from normal keyboards in that they don't provide release events. They do provide native repeat events, though. Currently the Linux kernel RC/input subsystems provide a simulated autorepeat for remote controls (default delay 500ms, period 33ms), and X.org server ignores these events and generates its own autorepeat for them. The kernel RC subsystem provides a simulated release event when 250ms has passed since the last native event (repeat or non-repeat) was received from the device. This is problematic, since it causes lots of extra repeat events to be always sent (for up to 250ms) after the user has released the remote control button, which makes the remote quite uncomfortable to use. I got a bit confused reading this description. Does this mean that remotes usually send: key press - repeat - repeat - ... - repeat - silence where the silence indicates that the key has been released? Which the kernel after 250ms translates into a release event. And the kernel discards the repeats and generates it's own on 500/33? Do I get this right so far? If so, I'm not sure how to avoid the 250ms delay since we have no indication from the hardware when the silence will stop, right? Note that the repeat delay and ratio are configurable per-device using XKB, so you could set up the 500/33 in X too. Cheers, Peter Now, IMO something should be done to fix this. But what exactly? Here are two ideas that would remove these ghost repeats: 1. Do not provide any repeat/release simulation in the kernel for RC devices (by default?), just provide both keydown and immediate release events for every native keypress or repeat received from the device. + Very simple to implement - We lose the ability to track repeats, i.e. if a new event was a repeat or a new keypress; holding down a key becomes impossible or 2. Replace kernel autorepeat simulation by passing through the native repeat events (probably filtering them according to REP_DELAY and REP_PERIOD), and have a device property bit (fetchable via EVIOCGPROP) indicating that the keyrelease is simulated, and have the X server use the native repeats instead of softrepeats for such a device. + The userspace correctly gets repeat events tagged as repeats and release events when appropriate (albeit a little late) - Adds complexity. Also, while the kernel part is quite easy to implement, I'm not sure if the X server part is. or 3. Same as 1., but indicate the repeatness of an event with a new additional special event before EV_SYN (sync event). + Simple to implement - Quite hacky, and userspace still can't guess from initial keypress/release if the key is still pressed down or not. 4. Same as 1., but have a new EV_RC with RC_KEYDOWN and RC_KEYUP events, with RC_KEYDOWN sent when a key is pressed down a first time along with the normal EV_KEY event, and RC_KEYUP sent when the key is surely released (e.g. 250ms without native repeat events or another key got pressed, i.e. like the simulated keyup now). + Simple to implement, works as expected with most userspace apps with no changes to them; and if an app wants to know the repeatness of an event or held-down-ness of a key, it can do that. - Repeatness of the event is hidden behind a new API. What do you think? Or any other ideas? 2 and 4 seem nicest to me. (I don't know how feasible 2 would be on X server side, though) -- Anssi Hannula ___ 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 ___ 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: IR remote control autorepeat / evdev
On 10.05.2011 07:11, Peter Hutterer wrote: On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote: Hi all! Most IR/RF remotes differ from normal keyboards in that they don't provide release events. They do provide native repeat events, though. Currently the Linux kernel RC/input subsystems provide a simulated autorepeat for remote controls (default delay 500ms, period 33ms), and X.org server ignores these events and generates its own autorepeat for them. The kernel RC subsystem provides a simulated release event when 250ms has passed since the last native event (repeat or non-repeat) was received from the device. This is problematic, since it causes lots of extra repeat events to be always sent (for up to 250ms) after the user has released the remote control button, which makes the remote quite uncomfortable to use. I got a bit confused reading this description. Does this mean that remotes usually send: key press - repeat - repeat - ... - repeat - silence where the silence indicates that the key has been released? Which the kernel after 250ms translates into a release event. And the kernel discards the repeats and generates it's own on 500/33? Do I get this right so far? Yes. If so, I'm not sure how to avoid the 250ms delay since we have no indication from the hardware when the silence will stop, right? Yes. AFAICS what we need is to not use softrepeat for these devices and instead use the native repeats. The 250ms release delay could then be kept (as it wouldn't cause unwanted repeats anymore) or it could be made 0ms if that is deemed better. I listed some ways to do that below in my original post. Note that the repeat delay and ratio are configurable per-device using XKB, so you could set up the 500/33 in X too. It wouldn't make any difference with the actual issue which is autorepeat happening after physical key released. I guess the reason this hasn't come up earlier is that the unified IR/RC subsystem in the linux kernel is still quite new. It definitely needs to be improved regarding this issue - just trying to figure out the best way to do it. Cheers, Peter Now, IMO something should be done to fix this. But what exactly? Here are two ideas that would remove these ghost repeats: 1. Do not provide any repeat/release simulation in the kernel for RC devices (by default?), just provide both keydown and immediate release events for every native keypress or repeat received from the device. + Very simple to implement - We lose the ability to track repeats, i.e. if a new event was a repeat or a new keypress; holding down a key becomes impossible or 2. Replace kernel autorepeat simulation by passing through the native repeat events (probably filtering them according to REP_DELAY and REP_PERIOD), and have a device property bit (fetchable via EVIOCGPROP) indicating that the keyrelease is simulated, and have the X server use the native repeats instead of softrepeats for such a device. + The userspace correctly gets repeat events tagged as repeats and release events when appropriate (albeit a little late) - Adds complexity. Also, while the kernel part is quite easy to implement, I'm not sure if the X server part is. or 3. Same as 1., but indicate the repeatness of an event with a new additional special event before EV_SYN (sync event). + Simple to implement - Quite hacky, and userspace still can't guess from initial keypress/release if the key is still pressed down or not. 4. Same as 1., but have a new EV_RC with RC_KEYDOWN and RC_KEYUP events, with RC_KEYDOWN sent when a key is pressed down a first time along with the normal EV_KEY event, and RC_KEYUP sent when the key is surely released (e.g. 250ms without native repeat events or another key got pressed, i.e. like the simulated keyup now). + Simple to implement, works as expected with most userspace apps with no changes to them; and if an app wants to know the repeatness of an event or held-down-ness of a key, it can do that. - Repeatness of the event is hidden behind a new API. What do you think? Or any other ideas? 2 and 4 seem nicest to me. (I don't know how feasible 2 would be on X server side, though) -- Anssi Hannula ___ 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 -- Anssi Hannula ___ 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: IR remote control autorepeat / evdev
On Tue, May 10, 2011 at 08:14:30AM +0300, Anssi Hannula wrote: On 10.05.2011 07:11, Peter Hutterer wrote: On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote: Hi all! Most IR/RF remotes differ from normal keyboards in that they don't provide release events. They do provide native repeat events, though. Currently the Linux kernel RC/input subsystems provide a simulated autorepeat for remote controls (default delay 500ms, period 33ms), and X.org server ignores these events and generates its own autorepeat for them. The kernel RC subsystem provides a simulated release event when 250ms has passed since the last native event (repeat or non-repeat) was received from the device. This is problematic, since it causes lots of extra repeat events to be always sent (for up to 250ms) after the user has released the remote control button, which makes the remote quite uncomfortable to use. I got a bit confused reading this description. Does this mean that remotes usually send: key press - repeat - repeat - ... - repeat - silence where the silence indicates that the key has been released? Which the kernel after 250ms translates into a release event. And the kernel discards the repeats and generates it's own on 500/33? Do I get this right so far? Yes. If so, I'm not sure how to avoid the 250ms delay since we have no indication from the hardware when the silence will stop, right? Yes. AFAICS what we need is to not use softrepeat for these devices and instead use the native repeats. The 250ms release delay could then be kept (as it wouldn't cause unwanted repeats anymore) or it could be made 0ms if that is deemed better. I listed some ways to do that below in my original post. Note that the repeat delay and ratio are configurable per-device using XKB, so you could set up the 500/33 in X too. It wouldn't make any difference with the actual issue which is autorepeat happening after physical key released. I guess the reason this hasn't come up earlier is that the unified IR/RC subsystem in the linux kernel is still quite new. It definitely needs to be improved regarding this issue - just trying to figure out the best way to do it. right. we used to have hardware repeats in X a few releases back. I think 1.6 was the first one that shifted to pure software autorepeat. One of the results we saw in the transition period was the clash of hw autorepeat (in X's input system, anything that comes out of the kernel counts as hw) and software repeat. Integrating them back in is going to be a bit iffy, especially since you need the integration with XKB on each device, essentially disallowing the clients from enabling autorepeat. Not 100% what's required there. The evtev part is going to be the simplest part of all that. Cheers, Peter Now, IMO something should be done to fix this. But what exactly? Here are two ideas that would remove these ghost repeats: 1. Do not provide any repeat/release simulation in the kernel for RC devices (by default?), just provide both keydown and immediate release events for every native keypress or repeat received from the device. + Very simple to implement - We lose the ability to track repeats, i.e. if a new event was a repeat or a new keypress; holding down a key becomes impossible or 2. Replace kernel autorepeat simulation by passing through the native repeat events (probably filtering them according to REP_DELAY and REP_PERIOD), and have a device property bit (fetchable via EVIOCGPROP) indicating that the keyrelease is simulated, and have the X server use the native repeats instead of softrepeats for such a device. + The userspace correctly gets repeat events tagged as repeats and release events when appropriate (albeit a little late) - Adds complexity. Also, while the kernel part is quite easy to implement, I'm not sure if the X server part is. or 3. Same as 1., but indicate the repeatness of an event with a new additional special event before EV_SYN (sync event). + Simple to implement - Quite hacky, and userspace still can't guess from initial keypress/release if the key is still pressed down or not. 4. Same as 1., but have a new EV_RC with RC_KEYDOWN and RC_KEYUP events, with RC_KEYDOWN sent when a key is pressed down a first time along with the normal EV_KEY event, and RC_KEYUP sent when the key is surely released (e.g. 250ms without native repeat events or another key got pressed, i.e. like the simulated keyup now). + Simple to implement, works as expected with most userspace apps with no changes to them; and if an app wants to know the repeatness of an event or held-down-ness of a key, it can do that. - Repeatness of the event is hidden behind a new API. What do you think? Or any other ideas? 2 and 4 seem nicest to me. (I don't know how feasible 2 would be on X server side,
[PATCH:twm] Remove unused fallback implementation of putenv()
NOPUTENV was never defined in a modular build, probably because putenv()
is a standard function in Unix98 / SUSv2.
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
src/util.c | 66
1 files changed, 0 insertions(+), 66 deletions(-)
diff --git a/src/util.c b/src/util.c
index 812886d..83f3257 100644
--- a/src/util.c
+++ b/src/util.c
@@ -771,72 +771,6 @@ SetFocus (TwmWindow *tmp_win, Time time)
XSetInputFocus (dpy, w, RevertToPointerRoot, time);
}
-
-#ifdef NOPUTENV
-/**
- * define our own putenv() if the system doesn't have one.
- * putenv(s): place s (a string of the form NAME=value) in
- * the environment; replacing any existing NAME. s is placed in
- * environment, so if you change s, the environment changes (like
- * putenv on a sun). Binding removed if you putenv something else
- * called NAME.
- */
-int
-putenv(char *s)
-{
-char *v;
-int varlen, idx;
-extern char **environ;
-char **newenv;
-static int virgin = 1; /* true while environ is a virgin */
-
-v = index(s, '=');
-if(v == 0)
- return 0; /* punt if it's not of the right form */
-varlen = (v + 1) - s;
-
-for (idx = 0; environ[idx] != 0; idx++) {
- if (strncmp(environ[idx], s, varlen) == 0) {
- if(v[1] != 0) { /* true if there's a value */
- environ[idx] = s;
- return 0;
- } else {
- do {
- environ[idx] = environ[idx+1];
- } while(environ[++idx] != 0);
- return 0;
- }
- }
-}
-
-/* add to environment (unless no value; then just return) */
-if(v[1] == 0)
- return 0;
-if(virgin) {
- register i;
-
- newenv = (char **) malloc((unsigned) ((idx + 2) * sizeof(char*)));
- if(newenv == 0)
- return -1;
- for(i = idx-1; i = 0; --i)
- newenv[i] = environ[i];
- virgin = 0; /* you're not a virgin anymore, sweety */
-} else {
- newenv = (char **) realloc((char *) environ,
- (unsigned) ((idx + 2) * sizeof(char*)));
- if (newenv == 0)
- return -1;
-}
-
-environ = newenv;
-environ[idx] = s;
-environ[idx+1] = 0;
-
-return 0;
-}
-#endif /* NOPUTENV */
-
-
static Pixmap
CreateXLogoPixmap (unsigned *widthp, unsigned *heightp)
{
--
1.7.3.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
