Re: [BUG] crash when trying to add a master XI2 device

[Maxim Levitsky]

On Mon, 2009-08-17 at 12:46 +0300, Maxim Levitsky wrote:
> Hi,
> 
> running 'xinput create-master testdev' crashes X
> 
> Backtrace:
> 0: /usr/local/bin/X(xorg_backtrace+0x3b) [0x80a65db]
> 1: /usr/local/bin/X [0x809e8f5]
> 2: [0xb7f6040c]
> 3: /usr/local/bin/X [0x81194ea]
> 4: /usr/local/bin/X [0x81106c3]
> 5: /usr/local/bin/X [0x807c23f]
> 6: /usr/local/bin/X [0x8067065]
> 7: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7b3a775]
> 8: /usr/local/bin/X [0x8066c21]
> Segmentation fault at address 0x1ba55
> 
> Fatal server error:
> Caught signal 11 (Segmentation fault). Server aborting
> 
> 
> 
> (gdb) l *0x81194ea
> 0x81194ea is in ProcXIChangeHierarchy (xichangehierarchy.c:206).
> 201   xfree(name);
> 202   goto unwind;
> 203   }
> 204   
> 205   ActivateDevice(ptr, FALSE);
> 206   ActivateDevice(keybd, FALSE);
> 207   flags[ptr->id] |= XIMasterAdded;
> 208   flags[keybd->id] |= XIMasterAdded;
> 
> 
> Best regards,
>   Maxim Levitsky
> 
> This is latest X stack from git, happened few days (maybe a week) ago
> 100% reproduceable
> 

Any update on that?

Regards,
Maxim Levitsky

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: File `-lselinux' does not exist.

[Dan Nicholson]

On Thu, Aug 20, 2009 at 12:38 PM, Eamon Walsh wrote:
> On 08/16/2009 09:10 PM, Dan Nicholson wrote:
>>
>> On Sun, Aug 16, 2009 at 6:02 PM, Justin P.
>> Mattock  wrote:
>>
>>>
>>> ooops!
>>> (as you can see my brain is mush, from looking
>>> at this all day). After doing the autoreconf
>>> with your patch finally the xserver compiled all the way through.
>>> (nice catch).
>>>
>>
>> Is Xorg actually linked to libselinux? Just want to make sure before I
>> push the patch.
>>
>
>
> It is when configured with --enable-xselinux
>
> Ack the patch, please push.

Pushed and nominated for 1.6.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[ANNOUNCE] xf86-input-evdev 2.2.5

[Peter Hutterer]

Fixing a regression reported in Bug 23405.
Affected: evdev-2.2.3, evdev-2.2.4.

Details:
A user-configured button map can result in a wrong number of buttons
reported to the X server. e.g. a button mapping of "1 2 3 4 5 6 7 3 2"
for a 5-button mouse will result in only 3 buttons being advertised to
the server. Remapping buttons 8 and 9 with xmodmap or other tools fails
with a BadValue error.

Peter Hutterer (2):
  Only take the driver-internal button mapping to count buttons (#23405)
  evdev 2.2.5

git tag: xf86-input-evdev-2.2.5

http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.2.5.tar.bz2
MD5: e926692d74ee81ed459d0fe89439ff8b  xf86-input-evdev-2.2.5.tar.bz2
SHA1: 2e185413dae1873450622c8b28a631e504d66f6b  xf86-input-evdev-2.2.5.tar.bz2

http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.2.5.tar.gz
MD5: 7132c880e78425960d02da9974668c74  xf86-input-evdev-2.2.5.tar.gz
SHA1: 20474ca9807ceef996bfd5fc56f6adec5947acca  xf86-input-evdev-2.2.5.tar.gz



pgpob4MTx0zHW.pgp
Description: PGP signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: reading a window's content with Xlib's XGetImage reveals portions of overlapping windows even with the backing store attribute set to Always

[Peter Harris]

Amos Tibaldi wrote:
>I am trying to read the content of a portion of a window with the
> function XGetImage:

> but when I read the pixels in anImage->Data, if there is a window that
> overlaps the
> region that I read (0, 0, 200, 200), the content of that window is
> returned in
> "anImage" instead of the original content of the window.
> I have tried to set the backing store attribute of the window desktopWin
> to "Always"
> in order to see if that could help, in fact:

>   3.2.4 Backing Store Attribute
> 
> Some implementations of the X server may choose to maintain the contents
> of InputOutput windows.

Key words "Some", "may", "choose". The BackingStore flag is just a hint.
The server is not required to honour it.

> Unfortunately it has not helped, since overlapping portions of
> other windows are still returned in anImage instead of the original
> content of the window that I want to grab. What could I do to solve
> this matter?

When drawing, draw to a pixmap then CopyArea the pixmap to your window.
Do the GetImage on the pixmap instead of the window. Some toolkits do
this automatically. All you'd have to do in that case is ask your
toolkit for its backing pixmap instead of its window.

Better yet, rework your code so you don't need to call GetImage.
GetImage is very slow.

Peter Harris
-- 
   Open Text Connectivity Solutions Group
Peter Harrishttp://www.opentext.com/connectivity
Research and DevelopmentPhone: +1 905 762 6001
phar...@opentext.comToll Free: 1 877 359 4866
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: File `-lselinux' does not exist.

[Justin P. Mattock]

Eamon Walsh wrote:
> On 08/16/2009 09:10 PM, Dan Nicholson wrote:
>> On Sun, Aug 16, 2009 at 6:02 PM, Justin P.
>> Mattock  wrote:
>>> ooops!
>>> (as you can see my brain is mush, from looking
>>> at this all day). After doing the autoreconf
>>> with your patch finally the xserver compiled all the way through.
>>> (nice catch).
>> Is Xorg actually linked to libselinux? Just want to make sure before I
>> push the patch.
>
>
> It is when configured with --enable-xselinux
>
> Ack the patch, please push.
>
>
>
yes, all other security options
will pass.

Justin P. Mattock
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: File `-lselinux' does not exist.

[Eamon Walsh]

On 08/16/2009 09:10 PM, Dan Nicholson wrote:
> On Sun, Aug 16, 2009 at 6:02 PM, Justin P.
> Mattock  wrote:
>
>> ooops!
>> (as you can see my brain is mush, from looking
>> at this all day). After doing the autoreconf
>> with your patch finally the xserver compiled all the way through.
>> (nice catch).
>>  
> Is Xorg actually linked to libselinux? Just want to make sure before I
> push the patch.
>


It is when configured with --enable-xselinux

Ack the patch, please push.



-- 
Eamon Walsh
National Security Agency

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

reading a window's content with Xlib's XGetImage reveals portions of overlapping windows even with the backing store attribute set to Always

[Amos Tibaldi]

Hello,

   I am trying to read the content of a portion of a window with the
function XGetImage:

XImage 
*XGetImage(*display*, *d*, *x*, *y*, *width*, *height*, *plane_mask*,
*format*)
Display

**display*;
Drawable *d*;
int *x*, *y*;
unsigned int *width*, *height*;
unsigned long *plane_mask*;
int *format*;

so from an already mapped window called desktopWin I successfully
obtain an image with the code:

anImage = XGetImage(dpy, desktopWin, 0, 0, 200, 200, AllPlanes, ZPixmap);

but when I read the pixels in anImage->Data, if there is a window that
overlaps the
region that I read (0, 0, 200, 200), the content of that window is returned
in
"anImage" instead of the original content of the window.
I have tried to set the backing store attribute of the window desktopWin to
"Always"
in order to see if that could help, in fact:

3.2.4 Backing Store Attribute Some implementations of the X server may
choose to maintain the contents of
*InputOutput
* windows. If the X server maintains the contents of a window, the
off-screen saved pixels are known as backing store. The backing store
advises the X server on what to do with the contents of a window. The
backing-store attribute can be set to *NotUseful* (default), *WhenMapped*,
or *Always*.

A backing-store attribute of *NotUseful* advises the X server that
maintaining contents is unnecessary, although some X implementations may
still choose to maintain contents and, therefore, not generate
*Expose
* events. A backing-store attribute of *WhenMapped* advises the X server
that maintaining contents of obscured regions when the window is mapped
would be beneficial. In this case, the server may generate an
*Expose
* event when the window is created. A backing-store attribute of
*Always*advises the X server that maintaining contents even when the
window is
unmapped would be beneficial. Even if the window is larger than its parent,
this is a request to the X server to maintain complete contents, not just
the region within the parent window boundaries. While the X server maintains
the window's contents,
*Expose
* events normally are not generated, but the X server may stop maintaining
contents at any time.

When the contents of obscured regions of a window are being maintained,
regions obscured by noninferior windows are included in the destination of
graphics requests (and source, when the window is the source). However,
regions obscured by inferior windows are not included.


So I have used the code:

attr.backing_store = Always;
valuemask |= CWBackingStore;
XChangeWindowAttributes(dpy, desktopWin, valuemask, &attr);


Unfortunately it has not helped, since overlapping portions of
other windows are still returned in anImage instead of the original
content of the window that I want to grab. What could I do to solve
this matter?

Thanks in advance,


-- 
Amos Tibaldi
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: X using 95% CPU (intel, latest git)

[Andy Neitzke]

On 13 August 2009 Carl Worth wrote:

>   On Thu, Aug 13, 2009 at 06:01:34PM -0400, Andy Neitzke wrote:
> > My problem is that frequently, even when the system should be idle, KDE's
> > CPU monitor applet shows that one of the two processors is fully loaded.
> >  When this happens, "top" blames the X process, showing it using around
> > 95% CPU.

...

> The next step would be to use a profiler, (such as
> sysprof or oprofile), to find out what functions are eating up all of
> the CPU.

Naturally, after recompiling all the X stuff with -O0 and debug info, the 
problem seems to have gone away (or at least become much harder to trigger).   
So I haven't managed to get a profile of the system exhibiting the problem 
yet.  But thank you for the info, and I will report back if I ever succeed!

-Andy
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

detect the screensaver

[Antoine Martin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

What is the official way of detecting when the screensaver is activated?

I thought it might be the "_SCREENSAVER_STATUS" property of the root
window so I tried running:
while true; do xprop -root _SCREENSAVER_STATUS; done
And then starting the screensaver with gnome-screensaver-command -l

Nothing showed up. I must be missing something obvious.
Is this documented anywhere?

Cheers
Antoine

PS: apologies if this is not the correct list, I can't think of a better
one.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREKAAYFAkqNmzMACgkQGK2zHPGK1rs3XACeJoEJQvRDhUbRwmi2QuvfqClb
JekAnj2vRk6oBuCI6jPkMyrktsMhKWwF
=Akrd
-END PGP SIGNATURE-
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Problem: Wait for VSync on pipe A and Wake up on pipe B

[Jesse Barnes]

On Thu, 20 Aug 2009 09:41:28 + (GMT)
Nicolas Cadio  wrote:

> Hello,
> 
> I have an application which must to synchronize with the vertical
> synchronisation of my display. To do this synchronization, I use a
> function of GLX (glXWaitVideoSyncSGI).
> 
> This function call the function DRM to wait the vertical
> synchronization (drmWaitVBlank) and the driver (drm.ko) does a wait
> on the pipe A of my Xserver.
> 
> But my output  (LVDS) of my Xserver is connected to the pipe B and so
> the driver (drm.ko) does a wake up on the pipe B.
> 
> So my applicaton is not synchronized with my display.
> 
> I would like to know how to configure my application for it uses the
> pipe B when it does a wait for the vertical synchronization. Where I
> can configure my application for it uses the pipe B for the VSync ?
> Is it in the xorg.conf or elsewhere?

With DRI2 we don't currently have a way to do this, but we're working
on adding one (along with some other sync

-- 
Jesse Barnes, Intel Open Source Technology Center
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Server crash uploading multiple glyphs at once with XRenderAddGlyphs

[Clemens Eisserer]

Hi Dave,

Should I file a bugreport about this on bugzilla?
What additional data would be useful to track that issue down?
Could this be used as a security whole?

Thanks, Clemens

2009/8/16 Clemens Eisserer 

> Hi Dave,
>
> > Can you get valgrind traces by any chance? not sure we can tell
> > much other than memory got corrupted from this.
>
> It seems at least for this case, sha1_block_data_order is reading data
> from random locations:
>
> ==17163== Invalid read of size 4
> ==17163==at 0x439E91A: sha1_block_data_order (sx86-elf.s:76)
> ==17163==by 0xFA42F463: ???
> ==17163==  Address 0x4815360 is 0 bytes after a block of size 4,096 alloc'd
> ==17163==at 0x4028D7E: malloc (vg_replace_malloc.c:207)
> ==17163==by 0x80AE954: Xalloc (utils.c:1056)
> ==17163==by 0x80AA42D: AllocateInputBuffer (io.c:1017)
> ==17163==by 0x80A9545: InsertFakeRequest (io.c:498)
>
> I had a look at the source but I have a pretty hard time figuring out
> whats going on there :-/
> The crash appears with a quite large framework I am working on, quite
> hard to build your own. I could provide a binary package or wireshark
> protocol if that would help?
>
> The valgrind log is attached, hope it helps a bit.
>
> Thanks, Clemens
>
> PS: I've found another problem when uploading multiple glyphs at once
> causes a memleak. I've attached a short testcase - fills up my 3GB
> pretty quick.
> There's a malloc in CreatePicture which is in some cases never freed,
> called at render.c : 1147.
> But again, I don't understand why it works sometimes and sometimes not :-/
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Problem: Wait for VSync on pipe A and Wake up on pipe B

[Nicolas Cadio]

Hello,

I have an application which must to synchronize with the vertical 
synchronisation of my display. 
To do this synchronization, I use a function of GLX (glXWaitVideoSyncSGI).

This function call the function DRM to wait the vertical synchronization 
(drmWaitVBlank) and the driver (drm.ko) does a wait on the pipe A of my Xserver.

But my output  (LVDS) of my Xserver is connected to the pipe B and so the 
driver (drm.ko) does a wake up on the pipe B.

So my applicaton is not synchronized with my display.

I would like to know how to configure my application for it uses the pipe B 
when it does a wait for the vertical synchronization.
Where I can configure my application for it uses the pipe B for the VSync ?
Is it in the xorg.conf or elsewhere?

Thanks, Nicolas


  ___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: X security query

[Thomi Richards]

Hi,

2009/8/19 Alan Coopersmith :
>
> The auth directory should be constant on a given distro, but the file name
> is a random string that changes every time the X server process is
> restarted.
>
> You can setenv XAUTHORITY to the file name to look for cookies in - if
> your daemon is running as root, it could even be set to the /var/run/...
> file itself.
>

Thank you, you've been very helpful. This is the approach I've taken,
and so far it seems to work flawlessly. Of course, I have not yet
tested this on different distros, so I may yet need to do a bit of
tweaking, but thanks all the same for your help.


Cheers,
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg