Re: [PATCH xdm] Implement ConsoleKit support.
Hello, 2011/5/4 Alan Coopersmith : > On 05/ 4/11 02:45 AM, Cyril Brulebois wrote: [...] >> I guess it would be nice to have the original authors(s) of that patch >> to sign off on it before it can be merged. >> >> Please note that I didn't check the actual patch yet, but I might give >> it a try soon-ish. I'm sorry for not having replied sooner, I've been really swamped these days. I'll only be able to work on this after June 17th, unfortunately. That is, if ConsoleKit is still relevant by then... > Of course, I may change my mind given that I've just read systemd plans > to force consolekit out of the system and make it impossible to run the > desktop on non-Linux systems. Yay! Please, may I have more pain? Yes, it looks like ConsoleKit is going away. I believe ConsoleKit integration wouldn't be a bad thing even if CK is going away, as it seems that the systemd replacement will be backwards compatible. Also, I don't see Ubuntu switching to systemd any time soon. So, to wrap it up, by the second half of June I'll probably have time to work on this if CK support is still relevant by then. Thanks a lot for the review, Dan, I'll address all those issues. Please keep Cc'ing me as I'm not in the list anymore. Regards, ___ 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] xf86xvmc: Once hooked into CloseScreen, defer the free after init errors
After hooking ourselves into the CloseScreen callback, we will attempt
to double-free pAdapt if we free it upon a failure to initialise the
XvMC adaptor and then during CloseScreen. Rather than rearrange the code
to only hook ourselves into CloseScreen, or to disentangle the callback
along a failure path, just defer the free until the end.
Signed-off-by: Chris Wilson
---
hw/xfree86/common/xf86xvmc.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/xfree86/common/xf86xvmc.c b/hw/xfree86/common/xf86xvmc.c
index e6464a5..f9249fb 100644
--- a/hw/xfree86/common/xf86xvmc.c
+++ b/hw/xfree86/common/xf86xvmc.c
@@ -199,7 +199,6 @@ Bool xf86XvMCScreenInit(
}
if(!pAdapt[i].xv_adaptor) {
/* no adaptor by that name */
- free(pAdapt);
return FALSE;
}
pAdapt[i].num_surfaces = (*adaptors)->num_surfaces;
--
1.7.5.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: [PATCH xdm] Implement ConsoleKit support.
On 05/14/11 07:30 PM, Fernando Lemos wrote: > 2011/5/4 Alan Coopersmith : >> Of course, I may change my mind given that I've just read systemd plans >> to force consolekit out of the system and make it impossible to run the >> desktop on non-Linux systems. Yay! Please, may I have more pain? > > Yes, it looks like ConsoleKit is going away. I believe ConsoleKit > integration wouldn't be a bad thing even if CK is going away, as it > seems that the systemd replacement will be backwards compatible. Also, > I don't see Ubuntu switching to systemd any time soon. Agreed. After the initial annoyance over more API churn, that does seem to be what's falling out of this recent announcement. As long as the ConsoleKit support stays optional, I think having it would still be better than not having it, given the issues some distros have hit without it. End of June is fine - I'm slowly working towards some changes I've wanted to get in for a while to the config file layout, and then given all that's changed in the tree, will probably call the next release 1.2.0, and adding ConsoleKit support would fit nicely in there, but I've also got a ton of day job things to do before then too. -- -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 libX11] XCB: Add more friendly error messages for common asserts
On Fri, May 13, 2011 at 12:03:54PM +0200, Daniel Stone wrote:
> This patch adds more friendly error messages for three common classes of
> assertion:
> - missed sequence numbers due to being griefed by another thread
> - unknown requests in queue due to being griefed by another thread
> - extensions dequeuing too much or too little reply data
>
> It adds error messages offering advice (e.g. call XInitThreads() first)
> on stderr, but still generates actual assertions. Hopefully this means
> it's a little more Googleable and a little less frightening.
>
> Signed-off-by: Daniel Stone
> ---
xcb_io.c seems to use tabs for indenting, your code uses spaces. might want
to check that up first.
maybe it's better to use a macro for the "broken X extension library" error
as well instead of copy/paste.
that said, still
Reviewed-by: Peter Hutterer
> src/xcb_io.c | 105
> +-
> 1 files changed, 89 insertions(+), 16 deletions(-)
>
> diff --git a/src/xcb_io.c b/src/xcb_io.c
> index 8930736..4dadc88 100644
> --- a/src/xcb_io.c
> +++ b/src/xcb_io.c
> @@ -15,6 +15,7 @@
> #ifdef HAVE_INTTYPES_H
> #include
> #endif
> +#include
> #include
> #include
> #include
> @@ -22,6 +23,16 @@
> #include
> #endif
>
> +#define throw_thread_fail_assert(_message, _var) { \
> +unsigned int _var = 1; \
> +fprintf(stderr, "[xcb] " _message "\n"); \
> +fprintf(stderr, \
> +"Most likely this is a multi-threaded client and XInitThreads " \
> +"has not been called\n"); \
"This error occurs when multi-threaded clients did not call XInitThreads"?
> +fprintf(stderr, "Aborting, sorry about that.\n"); \
but honestly, are we _really_ sorry about it? :)
Cheers,
Peter
> +assert(!_var); \
> +}
> +
> static void return_socket(void *closure)
> {
> Display *dpy = closure;
> @@ -51,9 +62,14 @@ static void require_socket(Display *dpy)
>* happens while Xlib does not own the socket. A
>* complete fix would be to make XCB's public API use
>* 64-bit sequence numbers. */
> - assert(!(sizeof(unsigned long) > sizeof(unsigned int)
> - && dpy->xcb->event_owner == XlibOwnsEventQueue
> - && (sent - dpy->last_request_read >= (UINT64_C(1) <<
> 32;
> + if ((sizeof(unsigned long) > sizeof(unsigned int) &&
> + dpy->xcb->event_owner == XlibOwnsEventQueue &&
> + (sent - dpy->last_request_read >= (UINT64_C(1) <<
> 32 {
> +throw_thread_fail_assert("Sequence number wrapped beyond
> "
> + "32 bits while Xlib did not own
> "
> + "the socket",
> + xcb_xlib_seq_number_wrapped);
> +}
> dpy->xcb->last_flushed = dpy->request = sent;
> dpy->bufmax = dpy->xcb->real_bufmax;
> }
> @@ -125,9 +141,19 @@ static PendingRequest *append_pending_request(Display
> *dpy, unsigned long sequen
> node->reply_waiter = 0;
> if(dpy->xcb->pending_requests_tail)
> {
> -
> assert(XLIB_SEQUENCE_COMPARE(dpy->xcb->pending_requests_tail->sequence, <,
> node->sequence));
> - assert(dpy->xcb->pending_requests_tail->next == NULL);
> - dpy->xcb->pending_requests_tail->next = node;
> +if
> (XLIB_SEQUENCE_COMPARE(dpy->xcb->pending_requests_tail->sequence,
> + >=, node->sequence))
> +{
> +throw_thread_fail_assert("Unknown sequence number while "
> + "appending request",
> + xcb_xlib_seq_number_wrapped);
> +}
> +if (dpy->xcb->pending_requests_tail->next != NULL) {
> +throw_thread_fail_assert("Unknown request in queue while "
> + "appending request",
> + xcb_xlib_seq_number_wrapped);
> +}
> + dpy->xcb->pending_requests_tail->next = node;
> }
> else
> dpy->xcb->pending_requests = node;
> @@ -137,15 +163,30 @@ static PendingRequest *append_pending_request(Display
> *dpy, unsigned long sequen
>
> static void dequeue_pending_request(Display *dpy, PendingRequest *req)
> {
> - assert(req == dpy->xcb->pending_requests);
> + if (req != dpy->xcb->pending_requests)
> +{
> +throw_thread_fail_assert("Unknown request in queue while "
> + "dequeuing",
> + xcb_xlib_seq_number_wrapped);
> +}
> dpy->xcb->pending_requests = req->next;
> if(!dpy->xcb->pending_requests)
> {
> - assert(req == dpy->xcb->pending_request
Re: xclock/oclock endian mismatch in Xfbdev [SOLVED]
On 3/05/2011 11:45 AM, dushara.jayasin...@hydrix.com wrote: Hi all, I'm Working on an iMX.25 (ARM) based embedded platform with xserver_xorg-server-1.7.5. I had to make the following mods to servermd.h to reflect the hardware. #define FBNOPIXADDR #define IMAGE_BYTE_ORDERMSBFirst #define BITMAP_BIT_ORDERMSBFirst This setup works with xlogo and oclock (The image looks correct). However when running xclock and a 3rd party gtk based app, the BIT/BYTE_ORDER is incorrect. Are there instances where these defines are ignored? Any ideas on where I should start looking? Ok figured it out. It stems from the fact that the CPU endianness (arm being LITTLE endian) doesn't match the endianness of the LCD peripheral (big). So even though I configured the FB, pixman was setting the endianness via the configure script. Which brings me to my next question, shouldn't pixman, xserver (and anything else that I may not have encountered yet) have this setting configured in a single place? Dushara ___ 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 updated] input: Don't implicitly define verify_internal_event
On Sat, May 14, 2011 at 04:23:59PM -0700, Jeremy Huddleston wrote:
>
> From 2f6a3c12b2d344e6cb38c89423f1227453e9a0b4 Mon Sep 17 00:00:00 2001
> From: Jeremy Huddleston
> Date: Sat, 14 May 2011 12:23:44 -0700
> Subject: [PATCH] input: Don't implicitly define verify_internal_event
>
> Fixes regression introduced by 56901998020b6f443cbaa5eb303100d979e81b22
pulled in, thanks
Cheers,
Peter
>
> mieq.c:159:5: error: implicit declaration of function 'verify_internal_event'
> is invalid in C99 [-Wimplicit-function-declaration,Semantic Issue]
> verify_internal_event(e);
> ^
> 1 error generated.
>
> Also includes some other warning cleanups in events.c we're there.
>
> events.c:2198:24: warning: equality comparison with extraneous parentheses
> [-Wparentheses,Semantic Issue]
> else if ((type == MotionNotify))
> ~^~~
> events.c:2198:24: note: remove extraneous parentheses around the comparison
> to silence this warning [Semantic Issue]
> else if ((type == MotionNotify))
> ~ ^ ~
> events.c:2198:24: note: use '=' to turn this equality comparison into an
> assignment [Semantic Issue]
> else if ((type == MotionNotify))
>^~
>=
> events.c:2487:5: error: implicit declaration of function
> 'verify_internal_event' is invalid in C99
> [-Wimplicit-function-declaration,Semantic Issue]
> verify_internal_event(event);
> ^
> events.c:5909:22: warning: declaration shadows a local variable
> [-Wshadow,Semantic Issue]
> DeviceIntPtr it = inputInfo.devices;
> ^
> events.c:5893:18: note: previous declaration is here
> DeviceIntPtr it = inputInfo.devices;
> ^
> 3 warnings and 1 error generated.
>
> events.c:2836:27: warning: incompatible pointer types passing 'DeviceEvent *'
> (aka 'struct _DeviceEvent *') to parameter of type
> 'const InternalEvent *' (aka 'const union _InternalEvent *')
> verify_internal_event(ev);
> ^~
> ../include/inpututils.h:40:56: note: passing argument to parameter 'ev' here
> extern void verify_internal_event(const InternalEvent *ev);
>^
> 1 warning generated.
>
> Found-by: yuffie tinderbox (-Werror=implicit)
> Signed-off-by: Jeremy Huddleston
> ---
> dix/events.c |7 ---
> mi/mieq.c|1 +
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/dix/events.c b/dix/events.c
> index 14f6f90..b60c299 100644
> --- a/dix/events.c
> +++ b/dix/events.c
> @@ -112,6 +112,7 @@ Equipment Corporation.
> #include
> #include "windowstr.h"
> #include "inputstr.h"
> +#include "inpututils.h"
> #include "scrnintstr.h"
> #include "cursorstr.h"
>
> @@ -2195,7 +2196,7 @@ DeliverEventsToWindow(DeviceIntPtr pDev, WindowPtr
> pWin, xEvent
> */
> if (!grab && ActivateImplicitGrab(pDev, client, pWin, pEvents,
> deliveryMask))
> /* grab activated */;
> -else if ((type == MotionNotify))
> +else if (type == MotionNotify)
> pDev->valuator->motionHintWindow = pWin;
> else if (type == DeviceMotionNotify || type == DeviceButtonPress)
> CheckDeviceGrabAndHintWindow (pWin, type,
> @@ -2832,7 +2833,7 @@ CheckMotion(DeviceEvent *ev, DeviceIntPtr pDev)
> WindowPtr prevSpriteWin, newSpriteWin;
> SpritePtr pSprite = pDev->spriteInfo->sprite;
>
> -verify_internal_event(ev);
> +verify_internal_event((InternalEvent *)ev);
>
> prevSpriteWin = pSprite->win;
>
> @@ -5906,7 +5907,7 @@ PickPointer(ClientPtr client)
>
> if (!client->clientPtr)
> {
> -DeviceIntPtr it = inputInfo.devices;
> +it = inputInfo.devices;
> while (it)
> {
> if (IsMaster(it) && it->spriteInfo->spriteOwner)
> diff --git a/mi/mieq.c b/mi/mieq.c
> index 031b11a..fc3738a 100644
> --- a/mi/mieq.c
> +++ b/mi/mieq.c
> @@ -43,6 +43,7 @@ in this Software without prior written authorization from
> The Open Group.
> # include "windowstr.h"
> # include "pixmapstr.h"
> # include "inputstr.h"
> +# include "inpututils.h"
> # include "mi.h"
> # include "mipointer.h"
> # include "scrnintstr.h"
> --
> 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: [PATCH] input: Fix format string for verify_internal_event
On Sat, May 14, 2011 at 04:31:10PM -0700, Jeremy Huddleston wrote:
>
> inpututils.c:577:25: warning: conversion specifies type 'unsigned short' but
> the argument has type 'unsigned char' [-Wformat,Format String Issue]
> ErrorF("%02hx ", *data);
> ^~
> %02hhx
> 1 warning generated.
>
> Signed-off-by: Jeremy Huddleston
> ---
> dix/inpututils.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/dix/inpututils.c b/dix/inpututils.c
> index aeace6e..49e1758 100644
> --- a/dix/inpututils.c
> +++ b/dix/inpututils.c
> @@ -574,7 +574,7 @@ void verify_internal_event(const InternalEvent *ev)
>
> for (i = 0; i < sizeof(xEvent); i++, data++)
> {
> -ErrorF("%02hx ", *data);
> +ErrorF("%02hhx ", *data);
>
> if ((i % 8) == 7)
> ErrorF("\n");
> --
> 1.7.4.1
merged, thanks.
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 Fri, May 13, 2011 at 09:51:02AM +0200, Mauro Carvalho Chehab wrote: > Em 12-05-2011 08:05, Peter Hutterer escreveu: > > On Thu, May 12, 2011 at 03:36:47AM +0200, Mauro Carvalho Chehab wrote: > >> Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: > >>> Em 12-05-2011 02:37, Anssi Hannula escreveu: > >> > I don't see any other places: > $ git grep 'REP_PERIOD' . > dvb/dvb-usb/dvb-usb-remote.c: input_dev->rep[REP_PERIOD] = > d->props.rc.legacy.rc_interval; > >>> > >>> Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we > >>> should change it to something like 125ms, for example, as 33ms is too > >>> short, as it takes up to 114ms for a repeat event to arrive. > >>> > >> IMO, the enclosed patch should do a better job with repeat events, without > >> needing to change rc-core/input/event logic. > >> > >> - > >> > >> Subject: Use a more consistent value for RC repeat period > >> From: Mauro Carvalho Chehab > >> > >> The default REP_PERIOD is 33 ms. This doesn't make sense for IR's, > >> as, in general, an IR repeat scancode is provided at every 110/115ms, > >> depending on the RC protocol. So, increase its default, to do a > >> better job avoiding ghost repeat events. > >> > >> Signed-off-by: Mauro Carvalho Chehab > >> > >> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c > >> index f53f9c6..ee67169 100644 > >> --- a/drivers/media/rc/rc-main.c > >> +++ b/drivers/media/rc/rc-main.c > >> @@ -1044,6 +1044,13 @@ int rc_register_device(struct rc_dev *dev) > >> */ > >>dev->input_dev->rep[REP_DELAY] = 500; > >> > >> + /* > >> + * As a repeat event on protocols like RC-5 and NEC take as long as > >> + * 110/114ms, using 33ms as a repeat period is not the right thing > >> + * to do. > >> + */ > >> + dev->input_dev->rep[REP_PERIOD] = 125; > >> + > >>path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL); > >>printk(KERN_INFO "%s: %s as %s\n", > >>dev_name(&dev->dev), > > > > so if I get this right, a XkbSetControls(.. XkbRepeatKeysMask ...) by a > > client to set the repeat rate would provide the same solution - for those > > clients/devices affected. > > Yes, if we preserve the same logic. The above will probably still generate > ghost repeats if the user keeps the IR pressed for a long time, as we're using > a separate timer at the rc-core logic than the one used inside evdev. > > > The interesting question is how clients would identify the devices that are > > affected by this (other than trial and error). > > That is easy. I've added a logic that detects it on Xorg evdev on some RFC > patches > I've prepared in the past to allow using a keycode with more than 247 for > IR's. > I'll work on a new version for it and submit again when I have some time. > Anyway, I'm enclosing a patch with the old version. Note that "clients" refers to X clients, i.e. applications. While it's usually trivial to add new functionality to evdev or other drivers, exposing information to the actual client requires some protocol extension or additions to existing extensions. While we have mechanisms in place for devices to be labelled, we don't have anyone to actually read this information (or even some standard on how to apply the labels). >From the implementation-side, we not only need to flag the devices in the driver (like you've outlined in the patch below), we then need to get this information into the X server so that the server doesn't repeat. XKB has a per-key-repeat flag which we may be able to use but we need to also override client-side key repeat setting (for this device only). XKB doesn't allow for a repeat rate change request to fail, so we have to essentially tell client they have succeeded in setting their repeat rate while using a completely different one. Technically, you can override the repeat setting requested by the client if you simply send out an event when you change it back to the hardware setting. This then looks like some other client has changed it but the danger is that it may send stubborn clients into an infinite loop. How much that really matters I don't know. Letting clients know which device is an RC control at least means that the overriding should be expected, but that brings us back to the labelling issue. But either way, to even get this to the "override" stage you need three patches: - evdev: recognise and flag the devices - X server: introduce an API to pass this information on to the server - X server: fixes to the XKB system to disable autorepeat for devices flagged accordingly and override requests to change the repeat rate. 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: xorg fbdev support for < 8 bits per pixel
On 13/05/2011 9:31 AM, Dushara Jayasinghe wrote: On 12/05/2011 11:31 PM, Jonathan Morton wrote: On Thu, 2011-05-12 at 17:58 +1000, Dushara Jayasinghe wrote: Anyway, just would like to find out, how much effort it would take to add support for devices with 1/2 bits/pixel depth. I noticed that the current xorg-fbdev implementation doesn't support these depths. Just to add context to the question, I'm working on an embedded device with a monochrome LCD. The CPU can generate grayscale images by upping the frame-rate and modulating the pixels but the hardware implementation limits the max FR so I can only support about 2 bits per pixel depth. Would it be sufficient to use an 8bpp greyscale framebuffer and simply ignore the low-order bits on scanout? Thanks for you reply Jonathan. Maybe I'm a bit out of my depth (hehe) here, could you elaborate on this please? The CPU (iMX.25) LCD peripheral (LCDC module) uses a chunk of memory to scan out and the bit depth is determined by the video mode used. My understanding is, the X FB drv writes directly to this chunk of memory (please correct me if I'm wrong). What step are you referring to as scanout? Just curious. Why is it that whenever I ask for things to be elaborated, the thread hits dead end? Am I posting to the wrong list? ___ 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
