Re: [PATCH v3] Support LED and tap-on-LED feature
On Fri, Apr 23, 2010 at 05:40:41PM +0200, Takashi Iwai wrote: > This patch adds the control of the embedded LED on the top-left corner > of new Synaptics devices. For LED control, it requires the patch to > Linux synaptics input driver, > https://patchwork.kernel.org/patch/92434/ > > When a sysfs file /sys/class/leds/psmouse::synaptics exists, the driver > assumes it supports the embeded LED control. This corresponds to the > touchpad-off state. When touchpad is disabled, LED is turned on. > > For linking between the touchpad state and the LED state, a new callback > UpdateHardware is introduced. Only eventcomm.c supports this (naturally). > > A new feature for the LED-equipped device is that user can double-tap > on the LED to toggle the touchpad state on the fly. This is also linked > with the touchpad-off state. > > There is a new parameter for controlling the LED double-tap behavior, too. > It specifies the double-tap time. Passing zero disables the double-tap > feature. > > Signed-off-by: Takashi Iwai > --- > > v2->v3: Fix a fd leak in write error path in eventcomm.c thanks for the update. as I said in my last email, I think these patches should be split out into multiple features. I had a look at the synaptics code and its current features, so here's my summary of the whole lot. I'm aware that you might not like this since it's a lot more work than the current patch. We have two distinct capabilities that are implemented here. First, we have a LED on the touchpad. Second, clicking onto this LED disables the touchpad on Windows (note that I do _not_ believe that this should be the only action, just because Windows does exactly this). So just tacking on this like it is means that any other use of the LED requires adding other properties and then you run into conflicts when both are enabled, etc. So a nice fix for now, but painful in the not-too-distant future. (Remember that properties are not strictly API but close enough. We can't change them too willy-nilly since clients depend on them) Here's what I think the full patch set should do: LED handling: - has_led should be exposed in the synaptics capabilities so that clients can query it. - the LED brightness should be its own property. This way clients can use it for other things as well, e.g. imagine the LED going on when you have new mail (though for most of us that'd probably just mean the LED is permanently on). if has_led is false, the property doesn't need to be initialized. (It might be worth making this a 0 - 1024 or so range that scales into whatever the kernel might provide in the future. Since you wrote the kernel patches, maybe you can comment on whether 255 will be enough for the X driver?) Tap handling: - We have an existing infrastructure to detect corner presses and rather than in_led_toggle_area we _should_ be able to use the left-top corner area for triggering the action. SelectTapButton() does this detection for us, so we only need to pick a tap action to happen. (The existing corner buttons can be extended to also support a double-tap feature. So instead of Option "RTCornerButton" "3", it can allow "RTCornerButton" "3 2", for single and double-tap) - We already have MaxDoubleTapTime in the driver, this should be reused here. - The tapping in the corner is close enough to a gesture, so you can add that toggle into the Synaptics Gestures property. Now, those were the easy bits. They give us control over the LED and integrate the tap handling into the existing code. The main problem we have now though: - If the LED is hooked directly to the touchpad on/off state, this means it will flash all the time if syndaemon is running. This has the potential to be quite annoying. That's all I came up with so far. I don't have any comments about the code at the moment, because the patch itself is fine. It's just the integration I'm worried about. Cheers, Peter > include/synaptics-properties.h |3 + > man/synaptics.man | 13 ++ > src/eventcomm.c| 32 ++- > src/properties.c | 26 > src/synaptics.c| 85 > +++- > src/synapticsstr.h |6 +++ > src/synproto.h |1 + > tools/synclient.c |1 + > 8 files changed, 164 insertions(+), 3 deletions(-) > > diff --git a/include/synaptics-properties.h b/include/synaptics-properties.h > index cf330d8..d24ed9e 100644 > --- a/include/synaptics-properties.h > +++ b/include/synaptics-properties.h > @@ -155,4 +155,7 @@ > /* 32 bit, 4 values, left, right, top, bottom */ > #define SYNAPTICS_PROP_AREA "Synaptics Area" > > +/* 32 bit */ > +#define SYNAPTICS_PROP_LED_DOUBLE_TAP "Synaptics LED Double Tap" > + > > #endif /* _SYNAPTICS_PROPERTIES_H_ */ > diff --git a/man/synaptics.man b/man/synaptics.man > index 59fbaac..0c79721 100644 > --- a/man/synaptics.man >
How the Server do the SW rendering?
I trace the server rendering process using geode driver. When the picture format is not in PICT_a4 or PICT_a8, the rendering work is done by Software. More concretely, the fbComposite(). But when the fbComposite() is done, the rendering work result has not been displayed on the screen. Can you guys told me in which function the real rending process is done? Thanks, Frank ___ 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: Smooth scrolling
On Fri, Apr 30, 2010 at 01:17:42PM +0200, Max Schwarz wrote: > > not really, all valuators sent to the clients are always absolute (with the > > exception of the ones in RawEvents). so even though the driver posts events > > as relative, they're just added to the current value and sent as absolute > > anyway. > What's the point of relative valuators on the driver-side then? > Seems over-complicated to me. some devices only have relative valuators. for a mouse it's a lot easier to just post -1/-1 than trying to figure out what the current pointer position is (given pointer acceleration, clipping, etc.) > I could listen to RawEvents, but those are only sent to root windows, which > makes checking if they are meant for my window a little tricky. > > Do you think it is easier to modify Xorg itself to send relative events or > should I interpret the absolute values on the client side? Overflow detection > is possible, but not very nice as the values are doubles... > Clearly, the right way would be to report relative events. > I will start looking into Xorg where this addition of relative events takes > place. to get relative valuators into events you'd have to bump the XI2 protocol and add it to the events. that isn't that hard per se, but quite a fair bit of work. I guess one approach might be to add the relative valuators (for applicable axes) after the valuator data to the XIDeviceEvents. that scales and is compatible to the current protocol. 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: [PATCH 00/10] Clean up and reorganize BUS configuration code
On Sun, May 02, 2010 at 01:07:36PM -0700, Tiago Vignatti wrote: > Hi, > > Following there are a couple of trivial fixes, mostly related with bus > configuration in Xorg. Besides a lot of clean up in the code, the most > apparently benefit is that xf86Init is now decoupled from PCI code. > > The API is being changed in xf86.h (hi Aaron) by removing xf86EnableAccess. Thanks for the heads up. The NVIDIA driver doesn't use any of this stuff. > For the open-source ones I can see only four (old - no up to date) drivers > using it. For these, I think we can go and simply wrap with #ifndef > XSERVER_LIBPCIACCESS the xf86EnableAccess function (this macro initially was > used when libpciaccess entered on scene but seems that lost its original > purpose on the middle of its life). Opinions? > > Please, review the patches. The work lives here also: > > git://anongit.freedesktop.org/~vignatti/xserver [bus-cleanup] > > > Thanks, > > Tiago > > > Tiago Vignatti (10): > xfree86: remove unused xf86AccessInit() > xfree86: bus: fix Enter/Leave accesses behaviour > xfree86: bus: reuse already assigned variable when fb driver claimed > xfree86: bus: rework xf86PostProbe logic and remove useless log info > xfree86: bus: enable sparc code usage as its definition > xfree86: bus: simplify entity related hooks > xfree86: bus: fb drivers might want to use vga arbitration either > xfree86: bus: remove SetSIGIOForState and simplify the code > xfree86: remove xf86EnableAccess > xfree86: remove PCI dependency from InitOutput > > hw/xfree86/common/xf86.h |1 - > hw/xfree86/common/xf86Bus.c | 289 +++ > hw/xfree86/common/xf86Configure.c |2 - > hw/xfree86/common/xf86Init.c | 313 > + > hw/xfree86/common/xf86Priv.h |3 +- > hw/xfree86/common/xf86pciBus.c| 160 +++ > hw/xfree86/common/xf86pciBus.h|3 + > 7 files changed, 327 insertions(+), 444 deletions(-) ___ 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
Congratulations and thanks on behalf of the X Window System, and all those who contributed to it.
Rob, Please forward this to all in Red Hat and Novell, Gibson Dunn, and others who contributed to the defense of the X Window System and Linux in the IP Innovations suit. The X Window System that Bob Scheifler and I started in 1984 rapidly became a community effort that has sustained it to this day. On behalf of these thousands of contributors over all these years, I would like to thank all of you for all your efforts and hard work as part of this community. You may not know us, and we may not know you, but we continue to form an extended community. From the community you are now part of, THANK YOU! Jim Gettys ___ 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/4] glxdri2: Hard-code the extension version we need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
> If we use the #define'd version from dri_interface.h, the server will
> require at least that version of the extension. If we're compiling against
> a dri_interface.h with a newer version we don't really require, glxdri2
> will require a too high version of the extension.
>
> The right approach is to just hard-code the version we need instead of
> using the #defines.
>
> Signed-off-by: Kristian Høgsberg
Reviewed-by: Ian Romanick
It seems like we keep fixing instances of this problem throughout the
server. :(
> ---
> glx/glxdri2.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/glx/glxdri2.c b/glx/glxdri2.c
> index 74d6ebc..c34e29a 100644
> --- a/glx/glxdri2.c
> +++ b/glx/glxdri2.c
> @@ -653,7 +653,7 @@ initializeExtensions(__GLXDRIscreen *screen)
>
> #ifdef __DRI2_FLUSH
> if (strcmp(extensions[i]->name, __DRI2_FLUSH) == 0 &&
> - extensions[i]->version >= __DRI2_FLUSH_VERSION) {
> + extensions[i]->version >= 3) {
> screen->flush = (__DRI2flushExtension *) extensions[i];
> }
> #endif
> @@ -713,11 +713,11 @@ __glXDRIscreenProbe(ScreenPtr pScreen)
>
> for (i = 0; extensions[i]; i++) {
> if (strcmp(extensions[i]->name, __DRI_CORE) == 0 &&
> - extensions[i]->version >= __DRI_CORE_VERSION) {
> + extensions[i]->version >= 1) {
> screen->core = (const __DRIcoreExtension *) extensions[i];
> }
> if (strcmp(extensions[i]->name, __DRI_DRI2) == 0 &&
> - extensions[i]->version >= __DRI_DRI2_VERSION) {
> + extensions[i]->version >= 1) {
> screen->dri2 = (const __DRIdri2Extension *) extensions[i];
> }
> }
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvfGCEACgkQX1gOwKyEAw85GACfd2WpiXpONJfV/kDjqgtyhvjp
bvQAn0vh3sIikOP075Laa4HhxQTgt9hI
=L4cg
-END 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: Per-output DPMS?
On Mon, May 3, 2010 at 10:55 AM, Richard Hughes wrote: > I get quite a few bug reports from people using gnome-power-manager > who want to turn off the internal laptop panel when docked, and turn > the external panel on. On idle, the external panel should then blank, > and then just the external panel should return to life when the mouse > is moved. > > Ideally I could set a per-output DPMS setting, although I guess the > same affect could be done with XRandr and turning the output off, > although this takes a few seconds to come back on, and upsets the > screen geometry. What's a sane thing to do in this case? Do I really > want to switch off the output? It sounds like you want to have the panel off in that case. I think you do want the geometry changed, otherwise you have a dead area where some of your content is that is more or less impossible to access until you manually unblank that output. Assuming you want something automatic to happen with docking, I think you could add a check box to the gnome display tool or gpm; something like "disable internal panel when docked" which would query the connected outputs and disable the internal panel when an external monitor is connected when a dock event was received from the kernel. Per-output dpms would be useful for things like media players where you might want to playback a movie on one head an have the other ones blank when playback starts, but come back to life at the end or when the mouse was moved. Alex ___ 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: Per-output DPMS?
On Mon, 2010-05-03 at 17:33 +0200, Michel Dänzer wrote: > On Mon, 2010-05-03 at 16:26 +0100, Matthew Garrett wrote: > > On Mon, May 03, 2010 at 03:55:23PM +0100, Richard Hughes wrote: > > > Ideally I could set a per-output DPMS setting, although I guess the > > > same affect could be done with XRandr and turning the output off, > > > although this takes a few seconds to come back on, and upsets the > > > screen geometry. What's a sane thing to do in this case? Do I really > > > want to switch off the output? > > > > If they want the internal display to be turned off when they're docked > > then I suspect that they also want the geometry changed. > > And even if not, turning off an output doesn't require changing the > geometry from the RandR POV. Although true (kinda), neither the Gnome UI nor xrandr(1) make it obvious how to achieve this. - ajax 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: [PULL] DRI2 XID confusion fixes
On Sun, 2010-05-02 at 17:57 -0700, Kristian Høgsberg wrote: > Here's a pull request for the four patches I sent out earlier. The > dix resource patch has been updated to also update the element count > for FreeClientNeverRetainResources() and FreeClientResources(), which > also didn't keep the count up to date. Also in the patch is a fix for > LookupClientResourceComplex() and FreeClientNeverRetainResources() > reentrancy. These two functions didn't check the element count and > restart if changed after the callback, which makes them non-reentrant. > > Owen, I added a Tested-by from you for the DRI2 XID fix since we were > working on that together and you were testing the patch in the fedora > X server. I hope that's OK. Yes, it worked well in my testing, and I built it for Fedora and reports from people trying that have been positive as well. - Owen ___ 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: Help With setting Window Borders
On 2010-05-03 12:40, John Eke wrote: > Thanks a lot for your response Peter, is there any way around this > though? I can get the window to render without decorations, but will > this suffice? Depends on the window manager. You can always set "override-redirect" on your window, which will bypass the window manager entirely. But your users won't appreciate it if you override-redirect anything that isn't a brief splash screen or a simple popup menu. If you really want a solid frame of a particular colour inside your window, you can always paint one by hand. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ 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: Help With setting Window Borders
Thanks a lot for your response Peter, is there any way around this though? I can get the window to render without decorations, but will this suffice? - John E Peter Harris wrote: On 2010-05-03 11:58, John Eke wrote: Please help I am slightly confused. What does the border width, and border pixel properties do? I have an X11 client that sends a CreateWindow request, where I set values for border width and border color. I am not sure why I see no effect, could someone please let me know what I am doing wrong? Also how does a window border relate to the window managers decorations. Most window managers remove the border of your toplevel window. So setting border-width is only going to be visible on your internal subwindows in most cases. Peter Harris ___ 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: Fixing devPrivates
On Mon, 03 May 2010 10:50:37 -0400, Adam Jackson wrote: > To be clear: "blocks" here are "devPrivates hanging off some object" and > "bytes" are "number of bytes in those blocks" ? yes. With devPrivates automatically allocated now, you always get one even if no-one ever stores something in a particular object. However, they're smaller as they don't have to track any state. -- keith.pack...@intel.com pgpLlF8R4JDrj.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: Help With setting Window Borders
On 2010-05-03 11:58, John Eke wrote: > Please help I am slightly confused. What does the border width, and > border pixel properties do? I have an X11 client that sends a > CreateWindow request, where I set values for border width and border > color. I am not sure why I see no effect, could someone please let me > know what I am doing wrong? Also how does a window border relate to the > window managers decorations. Most window managers remove the border of your toplevel window. So setting border-width is only going to be visible on your internal subwindows in most cases. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ 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
Help With setting Window Borders
Hi, Please help I am slightly confused. What does the border width, and border pixel properties do? I have an X11 client that sends a CreateWindow request, where I set values for border width and border color. I am not sure why I see no effect, could someone please let me know what I am doing wrong? Also how does a window border relate to the window managers decorations. If it helps, I am developing on Ubuntu 8.04, with GNOME WM. Thanks - John E ___ 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 09/10] xfree86: remove xf86EnableAccess
On Mon, 2010-05-03 at 00:43 +0300, Tiago Vignatti wrote: > Not necessarily your driver will want to use the VGA arbitration. The > patch only cares about the removal of this unused API. > > BTW, is the driver that you care open-source? If yes, as I pointed on > the cover letter, it's pretty easy to go and provide some kind of fix > there. But in the other hand, yes, we can stay with a dummy API (like > now) to satisfy other closed or jurassic ones. I have made it a point to fix the drivers consuming API I want to remove, before removing it. For example: http://cgit.freedesktop.org/xorg/driver/xf86-video-vesa/commit/?id=d994a9abbda582ccd6d38447ca2201de10cc36a5 http://cgit.freedesktop.org/xorg/driver/xf86-video-chips/commit/?id=1c51b5495c51306d7c949583050cdba6f1baf5cc It's usually trivial, and it prevents people from complaining. - ajax 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: Per-output DPMS?
On Mon, 2010-05-03 at 16:26 +0100, Matthew Garrett wrote: > On Mon, May 03, 2010 at 03:55:23PM +0100, Richard Hughes wrote: > > > Ideally I could set a per-output DPMS setting, although I guess the > > same affect could be done with XRandr and turning the output off, > > although this takes a few seconds to come back on, and upsets the > > screen geometry. What's a sane thing to do in this case? Do I really > > want to switch off the output? > > If they want the internal display to be turned off when they're docked > then I suspect that they also want the geometry changed. And even if not, turning off an output doesn't require changing the geometry from the RandR POV. -- Earthling Michel Dänzer |http://www.vmware.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: Per-output DPMS?
On Mon, May 03, 2010 at 03:55:23PM +0100, Richard Hughes wrote: > Ideally I could set a per-output DPMS setting, although I guess the > same affect could be done with XRandr and turning the output off, > although this takes a few seconds to come back on, and upsets the > screen geometry. What's a sane thing to do in this case? Do I really > want to switch off the output? If they want the internal display to be turned off when they're docked then I suspect that they also want the geometry changed. -- Matthew Garrett | mj...@srcf.ucam.org ___ 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 3/4] list.h: Add list_for_each_entry_safe()
On Sat, 2010-05-01 at 13:31 -0400, Kristian Høgsberg wrote: > Signed-off-by: Kristian Høgsberg Reviewed-by: Adam Jackson - ajax 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 2/4] glxdri2: Hard-code the extension version we need
On Sat, 2010-05-01 at 13:31 -0400, Kristian Høgsberg wrote: > If we use the #define'd version from dri_interface.h, the server will > require at least that version of the extension. If we're compiling against > a dri_interface.h with a newer version we don't really require, glxdri2 > will require a too high version of the extension. > > The right approach is to just hard-code the version we need instead of > using the #defines. Reviewed-by: Adam Jackson - ajax 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 1/4] dix: Update element count in FreeResourceByType()
On Sun, 2010-05-02 at 16:48 -0700, Keith Packard wrote: > On Sun, 2 May 2010 17:26:58 -0400, Kristian Høgsberg > wrote: > > I guess they don't do it either... bad assumption on my part. But it > > *is* a bug, right? I can fix those too and resend, but I'm just still > > surprised that this bug was in there all the time and not sure if > > instead I'm missing something subtle in the resource code. > > FreeResourceByType was added for X11R4 with this bug in place, long > after the authors of the resource code were gone, so I suspect the whole > 'elements' invariant was lost. I'd love to know why it was added then; > the server didn't use it at all then, and the core code still does not. Incorrect: atropine:/tmp/r4/mit% grep FreeResourceByType **/*.[ch] extensions/server/multibuf.c:FreeResourceByType (pWin->drawable.id, MultibuffersResType, FALSE); server/dix/resource.c:FreeResourceByType(id, type, skipFree) Which makes sense; destroying a window should destroy all the image buffers bound to it. - ajax 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 2/2] Make sure XFixes invisible cursor gets freed on server reset
On Fri, 2010-04-30 at 16:13 -0700, Keith Packard wrote: > This uses the same hack that dix uses for the rootCursor -- allocate > a resource ID for the invisible cursor so that it gets freed at reset > time. This also allows us to unconditionally create it during > extension initialization; necessary as the privates layout may well be > different on subsequent generations. Reviewed-by: Adam Jackson - ajax 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
Per-output DPMS?
I get quite a few bug reports from people using gnome-power-manager who want to turn off the internal laptop panel when docked, and turn the external panel on. On idle, the external panel should then blank, and then just the external panel should return to life when the mouse is moved. Ideally I could set a per-output DPMS setting, although I guess the same affect could be done with XRandr and turning the output off, although this takes a few seconds to come back on, and upsets the screen geometry. What's a sane thing to do in this case? Do I really want to switch off the output? Thanks, Richard. ___ 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 1/2] Fix cursor ref counting mistakes with sprites and xf86Cursor.c
On Fri, 2010-04-30 at 16:13 -0700, Keith Packard wrote: > A few cursor value assignments weren't getting correctly ref counted, > causing leaks of cursor objects. Reviewed-by: Adam Jackson - ajax 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: Fixing devPrivates
On Sat, 2010-05-01 at 01:58 -0700, Keith Packard wrote: > I promised to get some actual numbers. I did before/after comparisons > with three different X server states: > > 1) X server at the root weave > 2) Gnome session started > 3) Gnome session running with iceweasel showing lwn.net's home page > > With the old implementation: > > bytes: blocks: > Startup: 1051633 > Gnome: 178776 582 > lwn.net: 377492 1131 > > And with the new implementation: > > bytes: blocks: > Startup: 122035 > Gnome: 20992 754 > lwn.net: 31312 1529 > > So, I'm getting somewhere around a 90% raw space savings. It's better > than that though -- each of the blocks in the old implementation > represents at least one additional allocated block of memory, any > pre-requested private storage would be another allocated block of > memory. With the new implementation, there are precisely 2 additional > allocations. That's all. To be clear: "blocks" here are "devPrivates hanging off some object" and "bytes" are "number of bytes in those blocks" ? - ajax 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 v2] configure: sha1: check libsha1 using pkg-config instead
Previously the code was using AC_CHECK_LIB, guaranteeing whether the library is correct by tracking sha1_begin function. This paranoic checking is not necessary given there's only one libsha1 in the market, which surely contains such function. Moreover, this patch now improves a bit the sha1 implementation checking behavior using pkg-config to find the right flags that needs to link against. Signed-off-by: Tiago Vignatti --- - fix keith's bug by using Yaakov suggestion configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 6110d8c..8ae6e2c 100644 --- a/configure.ac +++ b/configure.ac @@ -1382,7 +1382,7 @@ if test "x$with_sha1" = xlibmd; then [Use libmd SHA1 functions]) SHA1_LIBS=-lmd fi -AC_CHECK_LIB([sha1], [sha1_begin], [HAVE_LIBSHA1=yes]) +PKG_CHECK_MODULES([LIBSHA1], [sha1], [HAVE_LIBSHA1=yes], [HAVE_LIBSHA1=no]) if test "x$with_sha1" = x && test "x$HAVE_LIBSHA1" = xyes; then with_sha1=libsha1 fi -- 1.6.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
