Re: [PRQ#38009] Deletion Request for memtest86-efi
Hey, You confuse two different projects: - memtest86*+* (https://www.memtest.org/) under GPL2, actually in [Testing] - memtest86 (https://www.memtest86.com/) from PassMark, the one on the AUR I maintain To quote the first one: "Memtest86+ is unrelated to 'Memtest86', a closed-source `Freemium` software released in 2013 by PassMark Software Pty Ltd." "This conflicts" absolutely not! Package contents are very different and I do not see any file in common between both packages. Please reject this deletion request. Le 26/10/2022 à 17:43, not...@aur.archlinux.org a écrit : yochananmarqos [1] filed a deletion request for memtest86-efi [2]: This conflicts with the new memtest86+-efi split package: https://github.com/archlinux/svntogit- packages/commit/7ae8c1eb9bfa6a681fa821d65ed258c277472843 [1]https://aur.archlinux.org/account/yochananmarqos/ [2]https://aur.archlinux.org/pkgbase/memtest86-efi/
Re: [arch-general] Thunderbird 78
Is it possible to update it in [testing] at least? Le 15/08/2020 à 09:52, Archange via arch-general a écrit : Le 15 août 2020 11:32:51 GMT+04:00, Franck STAUFFER a écrit : Shouldn't it be the opposite? This is not Debian Stable, packages should be up-to-date and if people want older package they have to package it themselves in AUR. Am I wrong? Not when a feature expected by many Arch users is broken.
[arch-general] Thunderbird 78
Hi, Thunderbird 78 is available since 1 month (https://www.thunderbird.net/en-US/thunderbird/78.0/releasenotes). Is there any reason the package is stuck to version 68? Can someone update this package? Thank in advance.
Re: XShmCreatePixmap() as copy dest for XCopyArea()
On Wed, Jul 08, 2020 at 11:27:32AM -0400, Adam Jackson wrote:
> On Tue, 2020-07-07 at 13:13 -0700, x...@pengaru.com wrote:
> > Hello list,
> >
> > I'm trying to use XShmCreatePixmap() in combination with XCopyArea()
> > to achieve something resembling an XShmGetSubImage() for copying
> > damaged areas piecemeal out of the root window into a shmseg for a
> > screencap tool.
>
> MIT-SHM pixmap support is optional, and often not supported because for
> most modern X drivers it's a pessimization. I think there happens to be
> a bug in glamor where we claim to support shm pixmaps but don't
> actually implement it correctly; does your test case work if you
> disable acceleration in xorg.conf?
>
I'd tried intel and modesetting drivers with the same results, just
now tried noaccel on intel and it seems to not matter. But see below,
I think I've figured out my problem.
> > It seems like no matter what I do, the XCopyArea() never actually
> > writes to the shmseg. If instead I use XShmGetImage() with the same
> > source drawable (root) and an XShmImage created from the very same
> > shminfo as the XShmPixmap, my shmseg gets written to just fine - but
> > it fills the entire XShmImage on every update which I'd like to
> > avoid.
>
> XShmGetImage is an awkward API, yeah. The width and height of the image
> to download are derived from the XImage, not the drawable; if you
> create a shm segment exactly as large as the region you want to copy
> it'll do what you want. See the source (sigh) for more details:
>
> https://gitlab.freedesktop.org/xorg/lib/libxext/-/blob/master/src/XShm.c#L373
>
> Strictly speaking, you can just munge image->{width,height} before
> sending the request instead of creating a new one, you'll just have to
> compensate for that when you read the pixels back out of it.
>
The trouble with the ShmGetImage request is it doesn't supply a
destination stride, so you can't possibly coax it into copying small
damage areas into a larger mirror maintained directly in the shmseg.
I'd basically have to treat the shmseg as a pipe instead, and do a
second copy client-side out of the shmseg into the larger mirror
buffer, for every damaged area. Which is undesirable when the whole
goal is to minimize copying.
While replying to your email I realized something: I'm not using a
composited desktop, and don't have a wallpaper or anything, so my root
window is blank.
Thinking again about how XCopyArea() takes a GC and XShmGetImage()
doesn't, I toggled compositing and re-ran the XCopyArea() test now
that compositing would be putting everything into the root window.
It worked! The XCopyArea() was producing the expected contents.
So maybe this is just a matter of setting IncludeInferiors on the
copying GC, does that sound right?
While I've got your attention, do you know of a more efficient means
of getting this data out of the X server for screencap purposes? I'm
currently encoding video directly from the shmseg, XShmGetImage()
works fine for full-frame captures without using damage but I need the
XCopyArea() w/XShmPixmap for the damage-tracking mode. Maybe I can
throw all of this away if there's an entirely different superior
approach...
Thanks a lot for the feedback, it indirectly was quite helpful in
making me think more about my code and less about potential Xorg bugs
to see noaccel make no difference.
Cheers,
Vito Caputo
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
XShmCreatePixmap() as copy dest for XCopyArea()
Hello list, I'm trying to use XShmCreatePixmap() in combination with XCopyArea() to achieve something resembling an XShmGetSubImage() for copying damaged areas piecemeal out of the root window into a shmseg for a screencap tool. It seems like no matter what I do, the XCopyArea() never actually writes to the shmseg. If instead I use XShmGetImage() with the same source drawable (root) and an XShmImage created from the very same shminfo as the XShmPixmap, my shmseg gets written to just fine - but it fills the entire XShmImage on every update which I'd like to avoid. Does this sound familiar to anyone experienced using XShmCreatePixmap() with XCopyArea()? Do I need to do something special with the GC to make things happen? I'm using the DefaultGC from the same root window as the CopyArea source, which is also the drawable supplied to XShmCreatePixmap(). I'm not seeing any errors, the XCopyArea() seems to be happening, but the shmseg just isn't being modified. My server reports ZPixmap as the supported XShmPixmapFormat(), it's a garden variety xorg-modesetting on i915. Thanks, Vito Caputo ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: RFC: automatic _NET_WM_PID setting for local clients
On Wed, Jul 24, 2019 at 01:34:37AM +0100, Carsten Haitzler wrote: > On Tue, 23 Jul 2019 13:57:01 -0700 x...@pengaru.com said: > > Hello folks, > > > > I'd like to propose that Xorg set the _NET_WM_PID property on new > > windows for local clients @ window create time whenever possible. > > > > This is something I added localy years ago to more reliably have this > > property set with uncooperative clients that didn't set it. My window > > manager integrates client process monitoring and relies on this property > > for acquiring the PID of connected clients. > > > > At the time, it was just a few X clients that were problematic, stuff > > like xpdf and other smaller programs using less popular toolkits or no > > toolkit at all. It wasn't such a big deal, so I promptly forgot about > > it and stopped building my own Xorg debs with the patch, living with the > > absent monitoring overlays on those windows. > > > > Fast-forward to today; I'm using systemd-nspawn for running X clients - > > particularly network-facing clients like FireFox where I _strongly_ > > prefer isolating the client from accessing things like my home directory > > for obvious reasons (ssh keys, etc). > > > > These programs are cooperative and set _NET_WM_PID, but the PID they set > > is from the perspective of the container namespace. The display server > > is running in the global host namespace, where this PID has zero > > relevance. The same goes for my window manager, it to runs in the > > host's namespace, so when it gets this PID and tries to monitor the > > process subtree rooted at that PID in /proc, it either finds nothing or > > the entirely wrong tree. > > > > So again I'm wishing the display server would just set this property for > > local clients immediately when creating the window, which would not only > > make the property more reliable but now it would also set it from the > > PIDNS of the Xorg server, that I would argue is far more meaningful. > > > > I happened to still have the old patch I was using to do this back in > > the day, and have attached it as-is for discussion purposes. > > > > Thanks, > > Vito Caputo > > it'd be much more reliable to set _NET_STARTUP_ID to the content of whatever > the DESKTOP_STARTUP_ID env var has and enforce this in xlib itself. this can > be > inherited down the chain through your launching/containers/whatever and passed > in for that launch instance. assuming your wm of course can do this and track > every launch instance it started off and map it back to that instance... but > it > can know reliably then "THIS action of launching here resulted in that window > over there". much better than _NET_WM_PID because the pid here may not be the > pid of whatever was forked - but some other child process or even unrelated > other pid. > > -- > - Codito, ergo sum - "I code, therefore I am" -- > Carsten Haitzler - ras...@rasterman.com These aren't mutually exclusive proposals and in my opinion are somewhat complementary. Consider that in my workflow I am often launching X clients manually from bash via xterm. These won't have new startup IDs allocated to them, so the monitoring overlays would reflect those of the top-level WM-launched xterm. If the client PID matches somewhere deeper in the heirarchy rooted by the startup ID, I'd default to narrowing the scope to that level. It's /probably/ going to be the right thing, so I'd still want the X client PID. Speaking from years of experience using this scheme, keying off the PID alone has been perfectly functional until namespaces came along. Maybe it should be on a different property, like _UNIX_WM_PID or something, just to not step on the existing sematics of _NET_WM_PID. But I think it's perfectly reasonable to have the X server make this client identifier as viewed by the X server more reliably accessible when possible, considering it's the X server with the AF_UNIX socket and associated creds at its disposal. Thanks, Vito Caputo ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
RFC: automatic _NET_WM_PID setting for local clients
Hello folks,
I'd like to propose that Xorg set the _NET_WM_PID property on new
windows for local clients @ window create time whenever possible.
This is something I added localy years ago to more reliably have this
property set with uncooperative clients that didn't set it. My window
manager integrates client process monitoring and relies on this property
for acquiring the PID of connected clients.
At the time, it was just a few X clients that were problematic, stuff
like xpdf and other smaller programs using less popular toolkits or no
toolkit at all. It wasn't such a big deal, so I promptly forgot about
it and stopped building my own Xorg debs with the patch, living with the
absent monitoring overlays on those windows.
Fast-forward to today; I'm using systemd-nspawn for running X clients -
particularly network-facing clients like FireFox where I _strongly_
prefer isolating the client from accessing things like my home directory
for obvious reasons (ssh keys, etc).
These programs are cooperative and set _NET_WM_PID, but the PID they set
is from the perspective of the container namespace. The display server
is running in the global host namespace, where this PID has zero
relevance. The same goes for my window manager, it to runs in the
host's namespace, so when it gets this PID and tries to monitor the
process subtree rooted at that PID in /proc, it either finds nothing or
the entirely wrong tree.
So again I'm wishing the display server would just set this property for
local clients immediately when creating the window, which would not only
make the property more reliable but now it would also set it from the
PIDNS of the Xorg server, that I would argue is far more meaningful.
I happened to still have the old patch I was using to do this back in
the day, and have attached it as-is for discussion purposes.
Thanks,
Vito Caputo
--- xorg-server-1.12.4/dix/window.c 2012-05-17 10:09:02.0 -0700
+++ xorg-server-1.12.4.hacked/dix/window.c 2014-06-04 18:54:33.570855708
-0700
@@ -840,6 +840,20 @@
event.u.createNotify.override = pWin->overrideRedirect;
DeliverEvents(pParent, , 1, NullWindow);
}
+
+if (pScreen->root == pParent) {
+/* top-level windows with local connections can reliably get
_NET_WM_PID set by the server */
+LocalClientCredRec *lcc;
+if (GetLocalClientCreds(client, ) != -1)
+if (lcc->fieldsSet & LCC_PID_SET) {
+Atom prop;
+
+prop = MakeAtom("_NET_WM_PID", strlen("_NET_WM_PID"), TRUE);
+dixChangeWindowProperty(client, pWin, prop,
+XA_CARDINAL, 32, PropModeReplace,
+1, >pid, FALSE);
+}
+}
return pWin;
}
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xorg Digest, Vol 163, Issue 8
Hi Chris, My xKeyboard-config is version 2.23.1-1 (so it is the most recent version). This keyboard issue seems pretty common for Nedit users, which is why Nedit lists it in the "Help->Problems/Defects" option. I am quoting the text here: QUOTE P: Dialogs don't automatically get keyboard focus when they pop up. S: Most X Window managers allow you to choose between two categories of keyboard focus models: pointer focus, and explicit focus. Pointer focus means that as you move the mouse around the screen, the window under the mouse automatically gets the keyboard focus. NEdit users who use this focus model should set "Popups Under Pointer" in the Default Settings sub menu of the preferences menu in NEdit. Users with the explicit focus model, in some cases, may have problems with certain dialogs, such as Find and Replace. In MWM this is caused by the mwm resource startupKeyFocus being set to False (generally a bad choice for explicit focus users). NCDwm users should use the focus model "click" instead of "explicit", again, unless you have set it that way to correct specific problems, this is the appropriate setting for most explicit focus users. UNQUOTE So I followed this advice and tried to set the "Popups under pointer" option, but it was selected by default. Then why am I facing this problem? Anyway, I unselect it and restart Nedit, but this does NOT solve the problem. So I set the "popups under pointer" option AGAIN and restart Nedit. This time, It works FINE and all dialogs automatically have keyboard focus when opened. HOWEVER, when I open a second file in a second tab, the problem resurfaces. Is this a bug in NEdit? Thanks,Akshay On Saturday, February 16, 2019, 4:50:26 AM GMT+5:30, Chris Sorenson wrote: On 02/15/2019 11:48 AM, akshay chavan wrote: > > Hi, > Nedit's "version" option shows the following information: > NEdit 5.6 > Jul 5, 2010 > > Built on: Win32, x86-64, GNU C > Built at: Jun 30 2015, 16:55:01 > With Motif: (Untested) 2.3.4 [@(#)Motif Version 2.3.4] > Running Motif: 2.3 [unknown] > Server: The Cygwin/X Project 12001000 > Visual: 24-bit TrueColor (ID 0x21, Default) > Locale: en_US > > I did not build NEdit from source. I simply installed it through > Cygwin. > > Can you offer any suggestions to deal with this problem? > > Regards,Akshay > Hmm, it's probably a keyboard error then, are you using a funky keyboard? What version of xkeyboard-config do you have? You'll want to make sure it's the most recent version, from February 2018: https://cygwin.com/packages/x86_64/xkeyboard-config/ https://freedesktop.org/wiki/Software/XKeyboardConfig/ ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xorg Digest, Vol 163, Issue 8
Hi, Nedit's "version" option shows the following information: NEdit 5.6 Jul 5, 2010 Built on: Win32, x86-64, GNU C Built at: Jun 30 2015, 16:55:01 With Motif: (Untested) 2.3.4 [@(#)Motif Version 2.3.4] Running Motif: 2.3 [unknown] Server: The Cygwin/X Project 12001000 Visual: 24-bit TrueColor (ID 0x21, Default) Locale: en_US I did not build NEdit from source. I simply installed it through Cygwin. Can you offer any suggestions to deal with this problem? Regards,Akshay On Friday, February 15, 2019, 6:45:52 AM GMT+5:30, Chris Sorenson wrote: > Message: 1 > Date: Mon, 11 Feb 2019 18:14:27 + (UTC) > From: akshay chavan > To: "xorg@lists.x.org" > Subject: Problems using an X-Window application on Cygwin > Message-ID: <844242032.1743315.1549908867...@mail.yahoo.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I have installed a X-Window text editor called NEdit 5.6 on Windows 10 > using Cygwin. I have installed all the required X packages such as > xorg-server, xinit, etc required to run X-Window applications > > I have noticed that whenever I open ANY dialog, such as "Goto line > number", "save as" or "open", the keyboard input does NOT show in the > dialog's textbox. > > For instance, if I open the "goto line number" dialog, and type > something, the entered number does not show up in the dialog's textbox > . Similarly, when I open the "save as" dialog, I CANNOT type in the > "Directory" field. > > These problems are NOT observed when I press and hold the middle mouse > click on the textbox. As long as I hold the middle mouse click, the > textbox shows the characters typed in. When I release the mouse click, > I can no longer enter anything in the textbox. > > Is this issue related to xinit? I tried searching online for a > solution but didn't find anything. > > Thanks, > > Akshay > That's probably a Motif problem not an Nedit problem, what version of Motif is your Cygwin using? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: [PATCH xf86-video-savage] Disable EXA acceleration for now
On 2019-02-13 03:36 PM, Kevin Brace wrote:
>> Date: Wed, 13 Feb 2019 14:03:02 -0500
>> From: Connor Behan
>> To: xorg-devel@lists.x.org
>> Subject: Re: [PATCH xf86-video-savage] Disable EXA acceleration for
>> now
>> Message-ID:
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>> On 2019-02-11 12:02 PM, Kevin Brace wrote:
>>> EXA acceleration architecture code is currently broken on X Server
>>> 1.19, so it should be disabled until it is fixed.
>>>
>>> Signed-off-by: Kevin Brace
>>> ---
>>> src/savage_driver.c | 23 +++
>>> 1 file changed, 19 insertions(+), 4 deletions(-)
>> Is this because the rendering is wrong? Or does the X server crash
>> before you can test?
>>> diff --git a/src/savage_driver.c b/src/savage_driver.c
>>> index 01fc0bc..e26b0f1 100644
>>> --- a/src/savage_driver.c
>>> +++ b/src/savage_driver.c
>>> @@ -1273,14 +1273,29 @@ static Bool SavagePreInit(ScrnInfoPtr pScrn, int
>>> flags)
>>> psav->useEXA = FALSE;
>>> } else if(!xf86NameCmp(strptr,"EXA")) {
>>>from = X_CONFIG;
>>> - psav->useEXA = TRUE;
>>> + psav->NoAccel = TRUE;
>>> + psav->useEXA = FALSE;
>>> + xf86DrvMsg(pScrn->scrnIndex, X_INFO,
>>> + "EXA acceleration architecture is "
>>> + "permanently disabled for this version.\n");
>>> }
>>> }
>>> #else
>>> - psav->useEXA = TRUE;
>>> + psav->NoAccel = TRUE;
>>> + psav->useEXA = FALSE;
>>> + xf86DrvMsg(pScrn->scrnIndex, X_INFO,
>>> + "EXA acceleration architecture is "
>>> + "permanently disabled for this version.\n");
>>> #endif
>>> - xf86DrvMsg(pScrn->scrnIndex, from, "Using %s acceleration
>>> architecture\n",
>>> - psav->useEXA ? "EXA" : "XAA");
>>> +
>>> + if (!psav->NoAccel) {
>>> + xf86DrvMsg(pScrn->scrnIndex, from,
>>> + "Using %s acceleration architecture\n",
>>> + psav->useEXA ? "EXA" : "XAA");
>>> + } else {
>>> + xf86DrvMsg(pScrn->scrnIndex, X_INFO,
>>> + "Hardware acceleration is disabled.\n");
>>> + }
>>> }
>>>
>>> if ((s = xf86GetOptValString(psav->Options, OPTION_OVERLAY))) {
>> -- next part --
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 488 bytes
>> Desc: OpenPGP digital signature
>> URL:
>> <https://lists.x.org/archives/xorg-devel/attachments/20190213/46e5c8ba/attachment-0001.sig>
> Hi Connor,
>
> The code is broken, and that's why I disabled EXA.
> I tested the code on Xubuntu 16.04.5 (X Server 1.19.6).
> It can draw the initial login screen, but as soon as it gets past that, the
> screen will go black (not blank) and nothing happens.
> The result is consistent across several S3 Savage cards (Savage IX, several
> Savage 4s, and Savage 2000) I tested.
> Only disabling acceleration works around the bug.
> Activating --disable-dri for the compilation script makes no difference, at
> least for the stock Linux 4.15 kernel Canonical ships with (Savage DRM is
> disabled).
> The code might have a hard DRI1 dependency for the proper functioning of EXA.
> I was thinking of releasing xf86-video-savage DDX Version 2.4 on Thursday.
> If you can figure out what's wrong with the code, the fix can go for the
> hypothetical Version 2.5 sometime in the future.
The savage driver doesn't attempt to use EXA for composites so that
rules out most of what I had in mind. The only other thing I would try
is disabling the UploadToScreen hook. If that doesn't help, there's no
reason to delay a release :).
signature.asc
Description: OpenPGP digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86EnableIO & ExtendedEnabled vs. the input thread
On 01/31/19 07:23 AM, Adam Jackson wrote:
On Wed, 2019-01-23 at 14:22 -0800, Alan Coopersmith wrote:
Is there any reason we just don't drop ExtendedEnabled altogether and
just always pass the calls through to the kernel? That'd leave us
still needing to call xf86EnableIO() in the input thread on Solaris,
unlike Linux, but that's more sensible than forcing a DisableIO()
first just to reset the ExtendedEnabled state.
I can't think of a good reason to track ExtendedEnabled, no. All of the
implementations look like they're idempotent (though I had to read the
weird Linux ppc thing twice to be sure). The ExtendedEnabled logic
itself seems to predate XFree86 4.0, which is back far enough in the
dark ages that I don't think we'd ever find a useful changelog for its
motivation. I say nuke it.
Okay, I'll do that - but that then leaves the problem of how to enable it in
the input thread, since the input thread is in the core/shared X server code,
but needs to call a routine in the XFree86 DDX.
My current unclean solution is:
index 97e59d21f..8c8bf090a 100644
--- a/os/inputthread.c
+++ b/os/inputthread.c
@@ -39,6 +39,10 @@
#include "opaque.h"
#include "osdep.h"
+#ifdef __sun
+#include
+#endif
+
#if INPUTTHREAD
Bool InputThreadEnable = TRUE;
@@ -326,6 +330,16 @@ InputThreadDoWork(void *arg)
pthread_setname_np ("InputThread");
#endif
+#ifdef __sun
+{
+Bool (*enableIO)(void) = (Bool (*)(void))
+dlsym(RTLD_PROBE, "xf86EnableIO");
+
+if (enableIO != NULL)
+(*enableIO)();
+}
+#endif
+
ospoll_add(inputThreadInfo->fds, hotplugPipeRead,
ospoll_trigger_level,
InputThreadPipeNotify,
but I'm guessing instead we should have some sort of callback or ddx-specific
initialization called from inputthread, that happens to be an empty stub
everywhere but the xf86 ddx for Solaris.
Thoughts on that?
Thanks,
-alan-
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xorg Digest, Vol 163, Issue 8
On 02/15/2019 11:48 AM, akshay chavan wrote: Hi, Nedit's "version" option shows the following information: NEdit 5.6 Jul 5, 2010 Built on: Win32, x86-64, GNU C Built at: Jun 30 2015, 16:55:01 With Motif: (Untested) 2.3.4 [@(#)Motif Version 2.3.4] Running Motif: 2.3 [unknown] Server: The Cygwin/X Project 12001000 Visual: 24-bit TrueColor (ID 0x21, Default) Locale: en_US I did not build NEdit from source. I simply installed it through Cygwin. Can you offer any suggestions to deal with this problem? Regards,Akshay Hmm, it's probably a keyboard error then, are you using a funky keyboard? What version of xkeyboard-config do you have? You'll want to make sure it's the most recent version, from February 2018: https://cygwin.com/packages/x86_64/xkeyboard-config/ https://freedesktop.org/wiki/Software/XKeyboardConfig/ ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[ANNOUNCE] xcursor-themes 1.0.6
This is a default set of cursor themes for use with libXcursor, originally created for the XFree86 Project, and now shipped as part of the X.Org software distribution. This release adds some symlinks to the whiteglass cursor theme to provide additional cursor names that gnome-shell expects, so that gnome-shell doesn't crash when using trying to use those cursors. Alan Coopersmith (3): Update README for gitlab migration Update configure.ac bug URL for gitlab migration xcursor-themes 1.0.6 Paul Hebble (1): Add missing symlinks for whiteglass git tag: xcursor-themes-1.0.6 https://xorg.freedesktop.org/archive/individual/data/xcursor-themes-1.0.6.tar.bz2 MD5: aea14eabf40528ec4db18f1cfcf5c458 xcursor-themes-1.0.6.tar.bz2 SHA1: b56fd5bf5b1ada0532a85c27db0d296e392168c5 xcursor-themes-1.0.6.tar.bz2 SHA256: ee1ec574741293abcf66ac14ce7e74add7ac6be7deb8b38179ef010d22354999 xcursor-themes-1.0.6.tar.bz2 SHA512: 2ad3586a5571a5ddc0001187362b54b839644916164834213af98e58698044aec4392dd6e1e42f1794fda85c8fedf259b09214a9636bd0e71a1629c710f198d3 xcursor-themes-1.0.6.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/data/xcursor-themes-1.0.6.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/data/xcursor-themes-1.0.6.tar.gz MD5: 76f7f7706118e8faa53ba2901762391d xcursor-themes-1.0.6.tar.gz SHA1: 916ef26cd1b41f12f80d0ad5ec7f176277b60267 xcursor-themes-1.0.6.tar.gz SHA256: 22638f7bd6257adf889d25af9c8a7b2cfdcf5a5e18339d25fbb092dbf6c663c1 xcursor-themes-1.0.6.tar.gz SHA512: 6afe6a3126f9104f3cbf2001c2a972dfdf615660ec57ad455ea24f79b12c493b8eeec542edf7293b34083d1669baeb6b9ad9cb303f646c6704a67675aa3cfb9c xcursor-themes-1.0.6.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/data/xcursor-themes-1.0.6.tar.gz.sig -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc signature.asc Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.x.org https://lists.x.org/mailman/listinfo/xorg-announce
Re: xorg Digest, Vol 163, Issue 8
Message: 1 Date: Mon, 11 Feb 2019 18:14:27 + (UTC) From: akshay chavan To: "xorg@lists.x.org" Subject: Problems using an X-Window application on Cygwin Message-ID: <844242032.1743315.1549908867...@mail.yahoo.com> Content-Type: text/plain; charset="utf-8" Hi, I have installed a X-Window text editor called NEdit 5.6 on Windows 10 using Cygwin. I have installed all the required X packages such as xorg-server, xinit, etc required to run X-Window applications I have noticed that whenever I open ANY dialog, such as "Goto line number", "save as" or "open", the keyboard input does NOT show in the dialog's textbox. For instance, if I open the "goto line number" dialog, and type something, the entered number does not show up in the dialog's textbox . Similarly, when I open the "save as" dialog, I CANNOT type in the "Directory" field. These problems are NOT observed when I press and hold the middle mouse click on the textbox. As long as I hold the middle mouse click, the textbox shows the characters typed in. When I release the mouse click, I can no longer enter anything in the textbox. Is this issue related to xinit? I tried searching online for a solution but didn't find anything. Thanks, Akshay That's probably a Motif problem not an Nedit problem, what version of Motif is your Cygwin using? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[ANNOUNCE] xcursor-themes 1.0.6
This is a default set of cursor themes for use with libXcursor, originally created for the XFree86 Project, and now shipped as part of the X.Org software distribution. This release adds some symlinks to the whiteglass cursor theme to provide additional cursor names that gnome-shell expects, so that gnome-shell doesn't crash when using trying to use those cursors. Alan Coopersmith (3): Update README for gitlab migration Update configure.ac bug URL for gitlab migration xcursor-themes 1.0.6 Paul Hebble (1): Add missing symlinks for whiteglass git tag: xcursor-themes-1.0.6 https://xorg.freedesktop.org/archive/individual/data/xcursor-themes-1.0.6.tar.bz2 MD5: aea14eabf40528ec4db18f1cfcf5c458 xcursor-themes-1.0.6.tar.bz2 SHA1: b56fd5bf5b1ada0532a85c27db0d296e392168c5 xcursor-themes-1.0.6.tar.bz2 SHA256: ee1ec574741293abcf66ac14ce7e74add7ac6be7deb8b38179ef010d22354999 xcursor-themes-1.0.6.tar.bz2 SHA512: 2ad3586a5571a5ddc0001187362b54b839644916164834213af98e58698044aec4392dd6e1e42f1794fda85c8fedf259b09214a9636bd0e71a1629c710f198d3 xcursor-themes-1.0.6.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/data/xcursor-themes-1.0.6.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/data/xcursor-themes-1.0.6.tar.gz MD5: 76f7f7706118e8faa53ba2901762391d xcursor-themes-1.0.6.tar.gz SHA1: 916ef26cd1b41f12f80d0ad5ec7f176277b60267 xcursor-themes-1.0.6.tar.gz SHA256: 22638f7bd6257adf889d25af9c8a7b2cfdcf5a5e18339d25fbb092dbf6c663c1 xcursor-themes-1.0.6.tar.gz SHA512: 6afe6a3126f9104f3cbf2001c2a972dfdf615660ec57ad455ea24f79b12c493b8eeec542edf7293b34083d1669baeb6b9ad9cb303f646c6704a67675aa3cfb9c xcursor-themes-1.0.6.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/data/xcursor-themes-1.0.6.tar.gz.sig -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc signature.asc Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
random X server crashes (with backtrace), any clues?
Hi. After a dist-upgrade on my debian installation I'm experiencing "random" crashes of the X server, always with the backtrace that you can find at the end of this email. The dist-upgrade was rather large and a lot of components were updated, like the X server, mesa and kde. I don't think it's kernel related, as the crashes happen with various kernel versions that I was using before the upgrade. Can anyone offer any clue? Thanks john [205311.015] (EE) [205311.016] (EE) Backtrace: [205311.019] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55a45f37afc9] [205311.021] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7fc476b116bf] [205311.022] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x10b) [0x7fc47697385b] [205311.024] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x121) [0x7fc47695e535] [205311.026] (EE) unw_get_proc_name failed: no unwind info found [-10] [205311.026] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7fc47695e400] [205311.028] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) [0x7fc47696c0a2] [205311.037] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_nouveau_vieux+0x414f63) [0x7fc4757748e3] [205311.038] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_nouveau_vieux+0x4154d5) [0x7fc475774e85] [205311.040] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_i915+0x136b7b) [0x7fc47500dd8b] [205311.041] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_i915+0x1370e7) [0x7fc47500eab7] [205311.042] (EE) 10: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_i915+0x12f041) [0x7fc474ffe711] [205311.044] (EE) 11: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_i915+0x11a2dc) [0x7fc474fd452c] [205311.046] (EE) 12: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_nouveau_vieux+0x1ccc7a) [0x7fc4752e429a] [205311.047] (EE) 13: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_nouveau_vieux+0x1cd54c) [0x7fc4752e545c] [205311.048] (EE) 14: /usr/lib/xorg/modules/libglamoregl.so (glamor_finish+0x967) [0x7fc4759f2117] [205311.050] (EE) 15: /usr/lib/xorg/modules/libglamoregl.so (glamor_finish+0xde7) [0x7fc4759f2d97] [205311.050] (EE) 16: /usr/lib/xorg/Xorg (miCopyRegion+0x96) [0x55a45f358a96] [205311.050] (EE) 17: /usr/lib/xorg/Xorg (miDoCopy+0x466) [0x55a45f359156] [205311.052] (EE) 18: /usr/lib/xorg/modules/libglamoregl.so (glamor_finish+0x1824) [0x7fc4759f43c4] [205311.052] (EE) 19: /usr/lib/xorg/Xorg (DamageRegionAppend+0x3946) [0x55a45f303a36] [205311.053] (EE) 20: /usr/lib/xorg/modules/libglamoregl.so (glamor_egl_exchange_buffers+0x2c8) [0x7fc4759eed08] [205311.055] (EE) 21: /usr/lib/xorg/modules/libglamoregl.so (glamor_egl_fd_from_pixmap+0x1e) [0x7fc4759eee8e] [205311.055] (EE) 22: /usr/lib/xorg/Xorg (dri3_send_open_reply+0x55d) [0x55a45f34ad1d] [205311.055] (EE) 23: /usr/lib/xorg/Xorg (drm_format_for_depth+0x93b) [0x55a45f34a44b] [205311.055] (EE) 24: /usr/lib/xorg/Xorg (SendErrorToClient+0x35e) [0x55a45f21c9ee] [205311.055] (EE) 25: /usr/lib/xorg/Xorg (InitFonts+0x3b6) [0x55a45f220976] [205311.057] (EE) 26: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xeb) [0x7fc47696009b] [205311.057] (EE) 27: /usr/lib/xorg/Xorg (_start+0x2a) [0x55a45f20a68a] [205311.057] (EE) [205311.057] (EE) Fatal server error: [205311.057] (EE) Caught signal 6 (Aborted). Server aborting [205311.057] (EE) [205311.057] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [205311.057] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [205311.057] (EE) [205311.059] (II) AIGLX: Suspending AIGLX clients for VT switch [205311.159] (EE) Server terminated with error (1). Closing log file. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload
On 2/13/19 2:32 PM, Andy Ritger wrote:
On Wed, Feb 13, 2019 at 12:15:02PM -0700, Kyle Brenneman wrote:
On 02/12/2019 01:58 AM, Michel Dänzer wrote:
On 2019-02-11 5:18 p.m., Andy Ritger wrote:
On Mon, Feb 11, 2019 at 12:09:26PM +0100, Michel Dänzer wrote:
On 2019-02-08 11:43 p.m., Kyle Brenneman wrote:
Also, is Mesa the only client-side vendor library that works with the
Xorg GLX module? I vaguely remember that there was at least one other
driver that did, but I don't remember the details anymore.
AFAIK, the amdgpu-pro OpenGL driver can work with the Xorg GLX module
(or its own forked version of it).
Maybe the amdgpu-pro OpenGL driver uses a fork of the Xorg GLX module
(or sets the "GlxVendorLibrary" X configuration option?), but it doesn't
look to me like the in-tree Xorg GLX module could report anything other
than "mesa" for GLX_VENDOR_NAMES_EXT, without custom user configuration.
GLX_VENDOR_NAMES_EXT, which client-side glvnd uses to pick the
libGLX_${vendor}.so to load, is implemented in the Xorg GLX module
with this:
xserver/glx/glxcmds.c:__glXDisp_QueryServerString():
case GLX_VENDOR_NAMES_EXT:
if (pGlxScreen->glvnd) {
ptr = pGlxScreen->glvnd;
break;
}
pGlxScreen->glvnd appears to be assigned here, defaulting to "mesa",
though allowing an xorg.conf override via the "GlxVendorLibrary" option:
xserver/glx/glxdri2.c:__glXDRIscreenProbe():
xf86ProcessOptions(pScrn->scrnIndex, pScrn->options, options);
glvnd = xf86GetOptValString(options, GLXOPT_VENDOR_LIBRARY);
if (glvnd)
screen->base.glvnd = xnfstrdup(glvnd);
free(options);
if (!screen->base.glvnd)
screen->base.glvnd = strdup("mesa");
And swrast unconditionally sets pGlxScreen->glvnd to "mesa":
xserver/glx/glxdriswrast.c:__glXDRIscreenProbe():
screen->base.glvnd = strdup("mesa");
Is there more to this that I'm missing?
I don't think so, I suspect we were just assuming slightly different
definitions of "works". :)
That should get fixed, but since that applies to the libglvnd's normal
vendor selection, I'd say it's orthogonal to GPU offloading. Off the top of
my head, the "GlxVendorLibrary" option ought to work regardless of which
__GLXprovider it finds. I think it would be possible to add a function to
let a driver override the GLX_VENDOR_NAMES_EXT string, too.
I think the point, though, is that thus far, libGLX_mesa.so is the only
glvnd client-side GLX implementation that will be loaded for use with
Xorg's GLX. Thus, it doesn't seem to refute ajax's comment from earlier
in the thread:
I don't see that those are related. The GLX_VENDOR_NAMES_EXT string
tells libglvnd which vendor to use by default. GPU offloading, more or
less by definition, means using something other than the default.
At the other extreme, the server could do nearly all the work of
generating the possible __GLX_VENDOR_LIBRARY_NAME strings (with the
practical downside of each server-side GLX vendor needing to enumerate
the GPUs it can drive, in order to generate the hardware-specific
identifiers).
I don't think this downside is much of a burden? If you're registering
a provider other than Xorg's you're already doing it from the DDX
driver
-Kyle
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload
On Wed, Feb 13, 2019 at 12:15:02PM -0700, Kyle Brenneman wrote:
> On 02/12/2019 01:58 AM, Michel Dänzer wrote:
> > On 2019-02-11 5:18 p.m., Andy Ritger wrote:
> > > On Mon, Feb 11, 2019 at 12:09:26PM +0100, Michel Dänzer wrote:
> > > > On 2019-02-08 11:43 p.m., Kyle Brenneman wrote:
> > > > > Also, is Mesa the only client-side vendor library that works with the
> > > > > Xorg GLX module? I vaguely remember that there was at least one other
> > > > > driver that did, but I don't remember the details anymore.
> > > > AFAIK, the amdgpu-pro OpenGL driver can work with the Xorg GLX module
> > > > (or its own forked version of it).
> > > Maybe the amdgpu-pro OpenGL driver uses a fork of the Xorg GLX module
> > > (or sets the "GlxVendorLibrary" X configuration option?), but it doesn't
> > > look to me like the in-tree Xorg GLX module could report anything other
> > > than "mesa" for GLX_VENDOR_NAMES_EXT, without custom user configuration.
> > >
> > > GLX_VENDOR_NAMES_EXT, which client-side glvnd uses to pick the
> > > libGLX_${vendor}.so to load, is implemented in the Xorg GLX module
> > > with this:
> > >
> > >xserver/glx/glxcmds.c:__glXDisp_QueryServerString():
> > >
> > > case GLX_VENDOR_NAMES_EXT:
> > > if (pGlxScreen->glvnd) {
> > > ptr = pGlxScreen->glvnd;
> > > break;
> > > }
> > >
> > > pGlxScreen->glvnd appears to be assigned here, defaulting to "mesa",
> > > though allowing an xorg.conf override via the "GlxVendorLibrary" option:
> > >
> > >xserver/glx/glxdri2.c:__glXDRIscreenProbe():
> > >
> > > xf86ProcessOptions(pScrn->scrnIndex, pScrn->options, options);
> > > glvnd = xf86GetOptValString(options, GLXOPT_VENDOR_LIBRARY);
> > > if (glvnd)
> > > screen->base.glvnd = xnfstrdup(glvnd);
> > > free(options);
> > >
> > > if (!screen->base.glvnd)
> > > screen->base.glvnd = strdup("mesa");
> > >
> > > And swrast unconditionally sets pGlxScreen->glvnd to "mesa":
> > >
> > >xserver/glx/glxdriswrast.c:__glXDRIscreenProbe():
> > >
> > > screen->base.glvnd = strdup("mesa");
> > >
> > > Is there more to this that I'm missing?
> > I don't think so, I suspect we were just assuming slightly different
> > definitions of "works". :)
> >
> >
> That should get fixed, but since that applies to the libglvnd's normal
> vendor selection, I'd say it's orthogonal to GPU offloading. Off the top of
> my head, the "GlxVendorLibrary" option ought to work regardless of which
> __GLXprovider it finds. I think it would be possible to add a function to
> let a driver override the GLX_VENDOR_NAMES_EXT string, too.
I think the point, though, is that thus far, libGLX_mesa.so is the only
glvnd client-side GLX implementation that will be loaded for use with
Xorg's GLX. Thus, it doesn't seem to refute ajax's comment from earlier
in the thread:
>>> At the other extreme, the server could do nearly all the work of
>>> generating the possible __GLX_VENDOR_LIBRARY_NAME strings (with the
>>> practical downside of each server-side GLX vendor needing to enumerate
>>> the GPUs it can drive, in order to generate the hardware-specific
>>> identifiers).
>> I don't think this downside is much of a burden? If you're registering
>> a provider other than Xorg's you're already doing it from the DDX
>> driver
> -Kyle
>
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xfree86/modes: Add "NoOutputInitialSize" option
OUTPUT_DEFAULT_WIDTH &&
-height < NO_OUTPUT_DEFAULT_HEIGHT) {
-width = NO_OUTPUT_DEFAULT_WIDTH;
-height = NO_OUTPUT_DEFAULT_HEIGHT;
+if (width < no_output_width &&
+height < no_output_height) {
+width = no_output_width;
+height = no_output_height;
}
}
diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h
index 1d1124a1be81..427c6bff497f 100644
--- a/hw/xfree86/modes/xf86Crtc.h
+++ b/hw/xfree86/modes/xf86Crtc.h
@@ -964,6 +964,10 @@ extern _X_EXPORT void
extern _X_EXPORT ScreenInitRetType xf86CrtcScreenInit(ScreenPtr pScreen);
+extern _X_EXPORT void
+xf86AssignNoOutputInitialSize(ScrnInfoPtr scrn, const OptionInfoRec *options,
+ int *no_output_width, int *no_output_height);
+
extern _X_EXPORT Bool
xf86InitialConfiguration(ScrnInfoPtr pScrn, Bool canGrow);
--
2.19.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload
On 02/12/2019 01:58 AM, Michel Dänzer wrote:
On 2019-02-11 5:18 p.m., Andy Ritger wrote:
On Mon, Feb 11, 2019 at 12:09:26PM +0100, Michel Dänzer wrote:
On 2019-02-08 11:43 p.m., Kyle Brenneman wrote:
Also, is Mesa the only client-side vendor library that works with the
Xorg GLX module? I vaguely remember that there was at least one other
driver that did, but I don't remember the details anymore.
AFAIK, the amdgpu-pro OpenGL driver can work with the Xorg GLX module
(or its own forked version of it).
Maybe the amdgpu-pro OpenGL driver uses a fork of the Xorg GLX module
(or sets the "GlxVendorLibrary" X configuration option?), but it doesn't
look to me like the in-tree Xorg GLX module could report anything other
than "mesa" for GLX_VENDOR_NAMES_EXT, without custom user configuration.
GLX_VENDOR_NAMES_EXT, which client-side glvnd uses to pick the
libGLX_${vendor}.so to load, is implemented in the Xorg GLX module
with this:
xserver/glx/glxcmds.c:__glXDisp_QueryServerString():
case GLX_VENDOR_NAMES_EXT:
if (pGlxScreen->glvnd) {
ptr = pGlxScreen->glvnd;
break;
}
pGlxScreen->glvnd appears to be assigned here, defaulting to "mesa",
though allowing an xorg.conf override via the "GlxVendorLibrary" option:
xserver/glx/glxdri2.c:__glXDRIscreenProbe():
xf86ProcessOptions(pScrn->scrnIndex, pScrn->options, options);
glvnd = xf86GetOptValString(options, GLXOPT_VENDOR_LIBRARY);
if (glvnd)
screen->base.glvnd = xnfstrdup(glvnd);
free(options);
if (!screen->base.glvnd)
screen->base.glvnd = strdup("mesa");
And swrast unconditionally sets pGlxScreen->glvnd to "mesa":
xserver/glx/glxdriswrast.c:__glXDRIscreenProbe():
screen->base.glvnd = strdup("mesa");
Is there more to this that I'm missing?
I don't think so, I suspect we were just assuming slightly different
definitions of "works". :)
That should get fixed, but since that applies to the libglvnd's normal
vendor selection, I'd say it's orthogonal to GPU offloading. Off the top
of my head, the "GlxVendorLibrary" option ought to work regardless of
which __GLXprovider it finds. I think it would be possible to add a
function to let a driver override the GLX_VENDOR_NAMES_EXT string, too.
-Kyle
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xf86-video-savage] Disable EXA acceleration for now
On 2019-02-11 12:02 PM, Kevin Brace wrote:
> EXA acceleration architecture code is currently broken on X Server
> 1.19, so it should be disabled until it is fixed.
>
> Signed-off-by: Kevin Brace
> ---
> src/savage_driver.c | 23 +++
> 1 file changed, 19 insertions(+), 4 deletions(-)
Is this because the rendering is wrong? Or does the X server crash
before you can test?
> diff --git a/src/savage_driver.c b/src/savage_driver.c
> index 01fc0bc..e26b0f1 100644
> --- a/src/savage_driver.c
> +++ b/src/savage_driver.c
> @@ -1273,14 +1273,29 @@ static Bool SavagePreInit(ScrnInfoPtr pScrn, int
> flags)
> psav->useEXA = FALSE;
> } else if(!xf86NameCmp(strptr,"EXA")) {
> from = X_CONFIG;
> -psav->useEXA = TRUE;
> +psav->NoAccel = TRUE;
> +psav->useEXA = FALSE;
> +xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> +"EXA acceleration architecture is "
> +"permanently disabled for this version.\n");
> }
> }
> #else
> - psav->useEXA = TRUE;
> + psav->NoAccel = TRUE;
> + psav->useEXA = FALSE;
> + xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> + "EXA acceleration architecture is "
> + "permanently disabled for this version.\n");
> #endif
> - xf86DrvMsg(pScrn->scrnIndex, from, "Using %s acceleration
> architecture\n",
> - psav->useEXA ? "EXA" : "XAA");
> +
> + if (!psav->NoAccel) {
> + xf86DrvMsg(pScrn->scrnIndex, from,
> + "Using %s acceleration architecture\n",
> + psav->useEXA ? "EXA" : "XAA");
> + } else {
> + xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> + "Hardware acceleration is disabled.\n");
> + }
> }
>
> if ((s = xf86GetOptValString(psav->Options, OPTION_OVERLAY))) {
signature.asc
Description: OpenPGP digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload
On 02/11/2019 02:51 PM, Andy Ritger wrote:
On Fri, Feb 08, 2019 at 03:43:25PM -0700, Kyle Brenneman wrote:
On 2/8/19 2:33 PM, Andy Ritger wrote:
On Fri, Feb 08, 2019 at 03:01:33PM -0500, Adam Jackson wrote:
On Fri, 2019-02-08 at 10:19 -0800, Andy Ritger wrote:
(1) If configured for PRIME GPU offloading (environment variable or
application profile), client-side libglvnd could load the possible
libGLX_${vendor}.so libraries it finds, and call into each to
find which vendor (and possibly which GPU) matches the specified
string. Once a vendor is selected, the vendor library could optionally
tell the X server which GLX vendor to use server-side for this
client connection.
I'm not a huge fan of the "dlopen everything" approach, if it can be
avoided.
Yes, I agree.
I'm pretty sure libglvnd could avoid unnecessarily loading vendor libraries
without adding nearly so much complexity.
If libglvnd just has a list of additional vendor library names to try, then
you could just have a flag to tell libglvnd to check some server string for
that name before it loads the vendor. If a client-side vendor would need a
server-side counterpart to work, then libglvnd can check for that. The
server only needs to keep a list of names to send back, which would be a
trivial (and backward-compatible) addition to the GLXVND interface.
Also, even without that, I don't think the extra dlopen calls would be a
problem in practice. It would only ever happen in applications that are
configured for offloading, which are (more-or-less by definition)
heavy-weight programs, so an extra millisecond or so of startup time is
probably fine.
But why incur that loading if we don't need to?
As I noted, we can still avoid loading extra loads even with an (almost)
strictly client-based design. You don't need to do any sort of
server-based device enumeration, all you need is something in the server
to add a string to a list that the client can query.
But, there's no reason that query can't be optional, and there's no
reason it has to be coupled with anything else.
I think I'd rather have a new enum for GLXQueryServerString
that elaborates on GLX_VENDOR_NAMES_EXT (perhaps GLX_VENDOR_MAP_EXT),
with the returned string a space-delimited list of :.
libGL could accept either a profile or a vendor name in the environment
variable, and the profile can be either semantic like
performance/battery, or a hardware selector, or whatever else.
This would probably be a layered extension, call it GLX_EXT_libglvnd2,
which you'd check for in the (already per-screen) server extension
string before trying to actually use.
That all sounds reasonable to me.
At the other extreme, the server could do nearly all the work of
generating the possible __GLX_VENDOR_LIBRARY_NAME strings (with the
practical downside of each server-side GLX vendor needing to enumerate
the GPUs it can drive, in order to generate the hardware-specific
identifiers).
I don't think this downside is much of a burden? If you're registering
a provider other than Xorg's you're already doing it from the DDX
driver (I think? Are y'all doing that from your libglx instead?), and
when that initializes it already knows which device it's driving.
Right. It will be easy enough for the NVIDIA X driver + NVIDIA server-side GLX.
Kyle and I were chatting about this, and we weren't sure whether people
would object to doing that for the Xorg GLX provider: to create the
hardware names, Xorg's GLX would need to enumerate all the DRM devices
and list them all as possible : pairs for the Xorg
GLX-driven screens. But, now that I look at it more closely, it looks
like drmGetDevices2() would work well for that.
So, if you're not concerned with that burden, I'm not. I'll try coding
up the Xorg GLX part of things and see how it falls into place.
That actually is one of my big concerns: I'd like to come up with something
that can give something equivalent to Mesa's existing DRI_PRIME setting, and
requiring that logic to be in the server seems like a very poor match. You'd
need to take all of the device selection and enumeration stuff from Mesa and
transplant it into the Xorg GLX module, and then you'd need to define some
sort of protocol to get that data back into Mesa where you actually need it.
Or else you need to duplicate it between the client and server, which seems
like the worst of both worlds.
Is this actually a lot of code? I'll try to put together a prototype so
we can see how much it is, but if it is just calling drmGetDevices2() and
then building PCI BusID-based names, that doesn't seem unreasonable to me.
The fact that it's required *at all* tells you that a server-based
design doesn't match the reality of existing drivers. I've also seen
ideas for GLX implementations based on EGL or Vulkan, which probably
wouldn't be able to work with server-side device enumeration.
And like I pointed out, adding that requirement doesn't give you
Re: RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload
ets a list of alternate vendor libraries from an app profile (config file, environment variable, whatever) * For each vendor in that list, libglvnd will load the vendor and call a new callback function, which asks the vendor to set up offloading. This call applies to the whole display, so the vendor can do all of its display initialization here. * If that callback succeeds, then libglvnd calls a second function to check which screens the vendor actually supports offloading on. Libglvnd assigns the vendor to those screens. * For any remaining screens, libglvnd will use its current selection logic. The entire interface is defined in an extension to the libglvnd GLX vendor library interface. That means the interface itself is entirely client-side, but a driver is free to use whatever combination of client- and server-side logic it wants. For example, a driver can implement device enumeration in the client vendor library (like Mesa does), or it could do that in the server and communicate the results back to the client. You could also have a multiple client vendor libraries that all work with a single server-side library, or even a client vendor library that doesn't have a server-side counterpart at all. The profile that libglvnd uses is just a list of vendor library names that libglvnd should try before it falls back to its normal vendor selection. Along with each vendor name, the profile can also optionally have some vendor-specific configuration data. That extra data can be used to select a specific device. For Mesa, for example, you could use the same string that you'd otherwise specify by setting the DRI_PRIME environment variable. The config file format I put together is JSON-based. It contains a list of profiles (selected based on the executable name of the process), and each profile contains a list of vendors. In addition to naming a vendor directly, a profile can list a generic descriptor, which acts like a macro that expands out to a list of vendors. Drivers can install config files to provide profiles and to provide definitions for those descriptors. Libglvnd will merge the vendor lists in profiles and descriptors from different files so that multiple drivers don't clobber each other. As a result, it should be possible for vendors (or distros) to provide reasonable default behavior, but still allow a user to override any profile or descriptor if they want to. I think a client-based interface like this is a strict functional superset of anything that requires server-side device enumeration. GLXVND would have to rely on the server-side vendor libraries to do that enumeration, and that same logic could just as easily be an implementation detail between a client and server library. The one exception is that this interface doesn't allow offloading to different vendors on different screens if no single vendor can handle all of them, but in order to run into that case, you'd need at least two X screens and at least four different GPU vendors. That's still not a client versus server limitation, though, that's just a limitation of libglvnd selecting a single offload vendor and letting it initialize the whole display all at once. Since this seems to be a sticking point, there's also an option to avoid unnecessarily loading extra client-side vendor libraries. If a client vendor needs a server-side counterpart, then libglvnd can filter it out based on a really simple server query. Right now, it just checks the GLX_VENDOR_NAMES_EXT string (since that was easy to test), but we may want to define some new string for this. This is the closest that libglvnd gets to the server at any point in this process, and even this part is optional and should be a pretty trivial extension to the GLXVND interface in the server. -Kyle ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload
On Fri, Feb 08, 2019 at 03:43:25PM -0700, Kyle Brenneman wrote:
> On 2/8/19 2:33 PM, Andy Ritger wrote:
> > On Fri, Feb 08, 2019 at 03:01:33PM -0500, Adam Jackson wrote:
> > > On Fri, 2019-02-08 at 10:19 -0800, Andy Ritger wrote:
> > >
> > > > (1) If configured for PRIME GPU offloading (environment variable or
> > > > application profile), client-side libglvnd could load the possible
> > > > libGLX_${vendor}.so libraries it finds, and call into each to
> > > > find which vendor (and possibly which GPU) matches the specified
> > > > string. Once a vendor is selected, the vendor library could
> > > > optionally
> > > > tell the X server which GLX vendor to use server-side for this
> > > > client connection.
> > > I'm not a huge fan of the "dlopen everything" approach, if it can be
> > > avoided.
> > Yes, I agree.
> I'm pretty sure libglvnd could avoid unnecessarily loading vendor libraries
> without adding nearly so much complexity.
>
> If libglvnd just has a list of additional vendor library names to try, then
> you could just have a flag to tell libglvnd to check some server string for
> that name before it loads the vendor. If a client-side vendor would need a
> server-side counterpart to work, then libglvnd can check for that. The
> server only needs to keep a list of names to send back, which would be a
> trivial (and backward-compatible) addition to the GLXVND interface.
>
> Also, even without that, I don't think the extra dlopen calls would be a
> problem in practice. It would only ever happen in applications that are
> configured for offloading, which are (more-or-less by definition)
> heavy-weight programs, so an extra millisecond or so of startup time is
> probably fine.
But why incur that loading if we don't need to?
> > > I think I'd rather have a new enum for GLXQueryServerString
> > > that elaborates on GLX_VENDOR_NAMES_EXT (perhaps GLX_VENDOR_MAP_EXT),
> > > with the returned string a space-delimited list of :.
> > > libGL could accept either a profile or a vendor name in the environment
> > > variable, and the profile can be either semantic like
> > > performance/battery, or a hardware selector, or whatever else.
> > >
> > > This would probably be a layered extension, call it GLX_EXT_libglvnd2,
> > > which you'd check for in the (already per-screen) server extension
> > > string before trying to actually use.
> > That all sounds reasonable to me.
> >
> > > > At the other extreme, the server could do nearly all the work of
> > > > generating the possible __GLX_VENDOR_LIBRARY_NAME strings (with the
> > > > practical downside of each server-side GLX vendor needing to enumerate
> > > > the GPUs it can drive, in order to generate the hardware-specific
> > > > identifiers).
> > > I don't think this downside is much of a burden? If you're registering
> > > a provider other than Xorg's you're already doing it from the DDX
> > > driver (I think? Are y'all doing that from your libglx instead?), and
> > > when that initializes it already knows which device it's driving.
> > Right. It will be easy enough for the NVIDIA X driver + NVIDIA server-side
> > GLX.
> >
> > Kyle and I were chatting about this, and we weren't sure whether people
> > would object to doing that for the Xorg GLX provider: to create the
> > hardware names, Xorg's GLX would need to enumerate all the DRM devices
> > and list them all as possible : pairs for the Xorg
> > GLX-driven screens. But, now that I look at it more closely, it looks
> > like drmGetDevices2() would work well for that.
> >
> > So, if you're not concerned with that burden, I'm not. I'll try coding
> > up the Xorg GLX part of things and see how it falls into place.
> That actually is one of my big concerns: I'd like to come up with something
> that can give something equivalent to Mesa's existing DRI_PRIME setting, and
> requiring that logic to be in the server seems like a very poor match. You'd
> need to take all of the device selection and enumeration stuff from Mesa and
> transplant it into the Xorg GLX module, and then you'd need to define some
> sort of protocol to get that data back into Mesa where you actually need it.
> Or else you need to duplicate it between the client and server, which seems
> like the worst of both worlds.
Is this actually a lot of code? I'll try to put together a prototype so
we can see how much it is, but if it is just calling drmGetDevices2() and
then building PCI BusID-based names, that doesn't seem un
Re: XRender / XComposite Documentation
On Mon, Oct 29, 2018 at 04:04:08PM -0400, Patrick Herbst wrote: > Hello, > > I'm desperately trying to find documentation on these extensions. Can > someone point me in the right direction? Am I missing something? Any > pointers? > https://www.x.org/archive/X11R7.5/doc/libXrender/libXrender.txt https://www.x.org/archive/X11R7.5/doc/renderproto/renderproto.txt https://www.x.org/archive/X11R7.5/doc/compositeproto/compositeproto.txt The docs also tend to get installed under /usr/share/doc/$packagename On Debian I have: /usr/share/doc/libxrender-dev/libXrender.txt.gz /usr/share/doc/x11proto-render-dev/renderproto.txt.gz /usr/share/doc/x11proto-composite-dev/compositeproto.txt.gz Regards, Vito Caputo ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: [arch-general] Please update VLC to v3.0.0
On 02/23/2018 07:25 AM, Eli Schwartz via arch-general wrote: On 02/23/2018 07:03 AM, Xorg via arch-general wrote: Hi everybody, I hope it's the good mailing list to request package update (the bug tracker only says 'the Mailing List'), and I'm sorry if I'm wrong. VLC has been flagged out-of-date on 2018-02-07 (2 weeks ago). Can you update it to v3.0.0, please? Thank you in advance! PS: Sorry for task #57595. VLC is already updated. It is currently in staging. As you can see, I wrote my post at 12:03:28 UTC, and commit 8fcde2c at 12:30:29 UTC. I was tracking the Git activity for this package, and I would never have posted if it was already the case. :) Yes, sometimes even Arch Linux takes longer than 47 minutes after an upstream release to update packages. Two weeks for a major version update that changes lots of dependencies including a move from Qt4 to Qt5, *and* provides libraries against which *other* packages need to be rebuilt? Yeah, this takes time. I'm sorry if my intention was misunderstood. I know it can take time after a major upstream update. Simply, due to no sign of activity for v3.0.0 on staging/testing, I thought it had been forgotten. I *really* appreciate work done by mainteners, and it was not a reproach. Thank you Levente Polyak for the update.
[arch-general] Please update VLC to v3.0.0
Hi everybody, I hope it's the good mailing list to request package update (the bug tracker only says 'the Mailing List'), and I'm sorry if I'm wrong. VLC has been flagged out-of-date on 2018-02-07 (2 weeks ago). Can you update it to v3.0.0, please? Thank you in advance! PS: Sorry for task #57595.
Re: X is consuming ~100 GiB of RAM(!)
On Thu, Dec 07, 2017 at 11:22:30AM -0500, Ewen Chan wrote: > Hi-Angel: > > > Yes, now it should be using CPU for rendering. > > Hmmm...I am not so sure if that was really what I want. > > It just reminds me of the adage of where you fix a leak/problem at one > part/section of a pipe, but then create another one problem somewhere else > down the pipe. > > > That's one more of beauties of open source > > The thing that I can think of that would be even more beautiful than that > would be if this didn't happen at all in the first place. :D > > This "memory leak" or high consumption of memory from the subsystem that > draws/renders the desktop/GUI doesn't happen at all with Windows no matter > how many times I run the same analysis script. > > My early subjective analysis (with this mgag200 blacklist) puts the time it > takes to run the simulations now on par with Windows and Windows just > worked (properly) like this from the get go. > > People keep talking about great and wonderful Linux is, but this experience > has been anything but. > > I think that I've spent about as much time trying to find a resolution to > this issue as I have had doing my actual analysis work. > > Pros (for Linux): It's faster when it is running at runlevel 3. > > Cons: Can't use the GUI (because if I blacklist the driver for runlevel 5, > then the performance is about the same as it is in Windows, at which point, > why not just use Windows? The set up of a Windows system to get it up and > running to this same level/state is significantly faster.) > > Such a pity really that this has the potential to be **A**, if not **THE** > solution to this problem. > > Hmmmit's been interesting. > > I can still try other stuff (like iomem=relaxed), both either with the > mgag200 or without it. > For the record, the mga driver is quite old, pre-dating x86_64 and most of its life was even pre hardware 3D acceleration. Prior to these transitions Matrox Milleniums were some of the best supported graphics cards in Linux/X. It would not surprise me if the problem you're experiencing is a relatively trivial bug in the mga driver on x86_64. It's been uncommon to have such a configuration AFAIK, frankly I was a little surprised to see someone mentioning some modern G200 use case. Now I'm curious, what exactly is it you're doing? Is your task actually using the GUI or is it a console thing running in a terminal and scrolling output? Is there any visual output at all during the analysis? Are you just using a heavyweight desktop shell like gnome shell and that's what is contending for CPU now that it's unaccelerated? - If the slowdown is just due to scrolling terminal text, redirect output to a file rather than having X display it all realtime. - If it's a fancy composited desktop environment hogging CPU when unaccelerated, try using something lightweight like xfce or twm. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: `pkg-config --static --libs x11` unusable for static linking?
On Wed, Mar 15, 2017 at 02:01:06PM +0100, walter harms wrote: > you are aware the glibc does not support static linking ? > > re, > wh The glibc caveats surrounding static linking are completely orthogonal to what is happening here. The library order in the link phase matters and `pkg-config --static --libs x11` is outputting options both incomplete and ordered incorrectly. The value of static linking in this case is producing a binary which doesn't require graphical dependencies to be installed on what may otherwise be headless systems having little more than glibc and ssh installed. Please note that the smoke test below passes, after using the fixed up link command mentioned previously to produce the static binary, with glibc on debian jessie amd64: # mkdir /tmp/foo # mkdir /tmp/foo/tmp # mount --bind /tmp /tmp/foo/tmp # for X socket # mkdir /tmp/foo/proc # mount --bind /proc /tmp/foo/proc # what the program monitors # mkdir /tmp/foo/home # mount --bind /home /tmp/foo/home # for ~/.Xauthority and static test program # chroot /tmp/foo /tmp/foo/home/vc/src/vmon-static The program works just fine in that ad-hoc root with absolutely zero .so dependencies present, there isn't an /etc/nsswitch.conf, this is desirable. This program may be run on any amd64 linux box to successfully monitor it without any concern for what is installed, even tunneled over `ssh -X` provided the DISPLAY environment variable is amended to use 127.0.0.1 instead of localhost to avoid the name resolution glibc caveat. There's also the musl-libc route for when glibc's dynamic dependencies are unignorable, but this is all off-topic. This is fundamentally about static linking the X dependencies, not glibc. It would be appreciated if `pkg-config --static --libs x11` actually output a usable set of flags. Playing libc roullette is completely orthogonal and a decision left up to the user not us, and the current situation blocks users from even taking a spin. It turns out the odds of winning are actually in the user's favor, why are we interfering? Is it so difficult to make pkg-config output the correct things? Isn't this the whole point of pkg-config? Regards, Vito Caputo ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
`pkg-config --static --libs x11` unusable for static linking?
/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_xid.o): In function `_xcb_xid_destroy': (.text+0x1b8): undefined reference to `pthread_mutex_destroy' /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_auth.o): In function `_xcb_get_auth_info': (.text+0x536): undefined reference to `pthread_mutex_lock' /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_auth.o): In function `_xcb_get_auth_info': (.text+0x557): undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `__register_frame_info_bases': (.text+0x16f7): undefined reference to `pthread_mutex_lock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `__register_frame_info': (.text+0x1792): undefined reference to `pthread_mutex_lock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `__register_frame': (.text+0x1834): undefined reference to `pthread_mutex_lock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `__register_frame_info_table_bases': (.text+0x18bb): undefined reference to `pthread_mutex_lock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `__deregister_frame_info_bases': (.text+0x195e): undefined reference to `pthread_mutex_lock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `__deregister_frame_info_bases': (.text+0x19f8): undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `_Unwind_Find_FDE': (.text+0x1ac6): undefined reference to `pthread_mutex_lock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `_Unwind_Find_FDE': (.text+0x1b16): undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `_Unwind_Find_FDE': (.text+0x1c00): undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `__register_frame_info_bases': (.text+0x1716): undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `__register_frame_info': (.text+0x17b1): undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `__register_frame': (.text+0x1858): undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o):(.text+0x18da): more undefined references to `pthread_mutex_unlock' follow collect2: error: ld returned 1 exit status Makefile:388: recipe for target 'vwm' failed make[2]: *** [vwm] Error 1 make[2]: Leaving directory '/home/vc/src/vwm/src' Makefile:674: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/vc/src/vwm/src' Makefile:381: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1 --- The output of `pkg-config --static --libs x11` here (Debian jessie amd64) is: -lX11 -lpthread -lxcb -lXau -lXdmcp -ldl is not present, and -lpthread appears before -lxcb. If I manually perform the link with these tweaked, linking is successful and the program functions fine: $ gcc -g -O2 -static -o vwm vwm-clickety.o vwm-composite.o vwm-context.o vwm-desktop.o vwm-key.o vwm-launch.o vwm-logo.o vwm-overlays.o vwm-screen.o vwm-vwm.o vwm-window.o vwm-xevent.o vwm-xserver.o vwm-xwindow.o -lXinerama -lXrandr -lXext -lXcomposite -lXdamage -lXfixes -lXrender -lX11 -ldl -lxcb -lpthread -lXau -lXdmcp libvmon/libvmon.a /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.a(CrGlCur.o): In function `open_library': (.text+0x32): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.a(xim_trans.o): In function `_XimXTransSocketINETConnect': (.text+0xe32): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking --- Shouldn't `pkg-config --static --libs` be emitting usable output for static linking? Thanks, Vito Caputo ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Multiplexing general windows similar to terminator
I believe fluxbox has had tabbed windows for quite some time, and in i3 you can also put multiple windows in the same tile and tab between them. Maybe those could help you get what you want? Best, - Timo ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: [aur-dev] [PATCH] Update french translation
Done. Thanks to have added me. Is it possible to change wiki links? They refer to english wiki, but some wiki pages are translated. Le 16/06/2015 14:10, Lukas Fleischer a écrit : On Tue, 16 Jun 2015 at 11:12:54, Xorg wrote: Hi. Because I'm not a member of french team on Transifex, I can't push the updated translation on Transifex. This is my first patch-send on a mailing-list, sorry if I'm wrong. I added you to the French team on Transifex. You should be able to submit your changes there now. Thanks!
[aur-dev] [PATCH] Update french translation
Hi. Because I'm not a member of french team on Transifex, I can't push the updated translation on Transifex. This is my first patch-send on a mailing-list, sorry if I'm wrong. --- a/po/fr.po 2015-06-13 10:26:08.017665000 +0200 +++ b/po/fr.po 2015-06-16 11:03:10.436817224 +0200 @@ -14,8 +14,8 @@ msgstr Project-Id-Version: Arch User Repository (AUR)\n Report-Msgid-Bugs-To: https://bugs.archlinux.org/index.php?project=2\n; -POT-Creation-Date: 2015-06-11 23:45+0200\n -PO-Revision-Date: 2015-06-11 21:46+\n +POT-Creation-Date: 2015-06-14 21:56+0200\n +PO-Revision-Date: 2015-06-16 10:53+\n Last-Translator: Lukas Fleischer transi...@cryptocrack.de\n Language-Team: French (http://www.transifex.com/projects/p/aur/language/; fr/)\n @@ -32,11 +32,12 @@ msgstr Désolé, la page que vous avez demandée nâexiste pas. msgid Service Unavailable -msgstr +msgstr Service indisponible msgid Don't panic! This site is down due to maintenance. We will be back soon. msgstr +Ne paniquez pas ! Le site est fermé pour maintenance. Nous serons bientôt de retour. msgid Account msgstr Compte @@ -116,7 +117,7 @@ msgstr Soumettre msgid Manage Co-maintainers -msgstr +msgstr Gérer les co-mainteneurs msgid Home msgstr Accueil @@ -156,48 +157,78 @@ Les paquets non supportés sont produits par des utilisateurs. Toute utilisation des fichiers fournis se fait à vos propres risques. +msgid Learn more... +msgstr En apprendre plus... + msgid Support -msgstr +msgstr Soutien msgid Package Requests -msgstr +msgstr Requêtes de paquet #, php-format msgid There are three types of requests that can be filed in the %sPackage Actions %s box on the package details page: msgstr +Il existe trois types de requêtes qui peuvent être soumises dans la boîte %sActions du paquet +%s sur la page des détails d'un paquet : msgid Orphan Request -msgstr +msgstr Requête de destitution msgid Request a package to be disowned, e.g. when the maintainer is inactive and the package has been flagged out-of-date for a long time. msgstr +Demande qu'un paquet soit destitué, c'est-à -dire quand le mainteneur est inactif et +que le paquet a été marqué comme périmé depuis un long moment. msgid Deletion Request -msgstr +msgstr Requête de suppression msgid Request a package to be removed from the Arch User Repository. Please do not use this if a package is broken and can be fixed easily. Instead, contact the package maintainer and file orphan request if necessary. msgstr +Demande qu'un paquet soit supprimé d'AUR. Prière de ne pas +l'utiliser si un paquet est cassé et que le problème peut être réglé facilement. à la place, contactez +le mainteneur du paquet, et soumettez une requête de destitution si nécessaire. msgid Merge Request -msgstr +msgstr Requête de fusion msgid Request a package to be merged into another one. Can be used when a package needs to be renamed or replaced by a split package. msgstr +Demande que le paquet soit fusionné dans un autre. Peut être utilisé quand un paquet +a besoin d'être renommé ou bien remplacé par un paquet splitté. #, php-format msgid If you want to discuss a request, you can use the %saur-requests%s mailing list. However, please do not use that list to file requests. msgstr +Si vous voulez débattre d'une requête, vous pouvez utiliser la mailing-list %saur-requests%s. +Cependant, merci de ne pas utiliser cette liste pour soumettre des requêtes. + +msgid Submitting Packages +msgstr Soumission de paquets + +#, php-format +msgid +Git over SSH is now used to submit packages to the AUR. See the %sSubmitting +packages%s section of the Arch User Repository ArchWiki page for more +details. +msgstr +Git par-dessus SSH est maintenant utilisé pour soumettre des paquets sur AUR. Voir la section %sSoumettre +des paquets%s sur la page Arch User Repository du wiki pour plus de +détails. + +msgid The following SSH fingerprints are used for the AUR: +msgstr Les empreintes SSH suivantes sont utilisées pour AUR : msgid Discussion msgstr Discussion @@ -208,6 +239,10 @@ structure takes place on %saur-general%s. For discussion relating to the development of the AUR web interface, use the %saur-dev%s mailing list. msgstr +Les discussions générales en rapport avec AUR (Arch User Repository, dépôt des utilisateurs dâArch Linux) +et les TU (Trusted User, utilisateurs de confiance) +ont lieu sur %saur-general%s. Pour les discussions en rapport +avec le développement de l'interface web d'AUR, utilisez la mailing-list %saur-dev.%s msgid Bug Reporting msgstr Rapports de bug @@ -219,6 +254,9 @@ report packaging bugs contact the package maintainer or leave a comment on the appropriate package page. msgstr +Si vous trouvez un bug dans l'interface web d'AUR, merci de remplir un rapport de bug sur +le %sbug tracker%s. Nâutilisez le tracker %sque%s pour les bugs de AUR. +Pour signaler un
[aur-general] [AUR4] Error when upload a update pkgbuild : remote: error: missing install file: avidemux.install
I have the same problem with package libreoffice-faenza-mod: remote: error: The following error occurred when parsing commit remote: error: 2b5e403e908f51617b188c49a11def1ae4d9bf27: remote: error: missing install file: libreoffice-faenza-mod.install remote: error: hook declined to update refs/heads/master To ssh://a...@aur4.archlinux.org/libreoffice-faenza-mod. PKGBUILD is here: https://aur.archlinux.org/packages/li/libreoffice-faenza-mod/PKGBUILD .install file is: libreoffice-faenza-mod.install
Re: [aur-general] [AUR4] Error when upload a update pkgbuild : remote: error: missing install file: avidemux.install
Yes, sure. This package was on AUR-DEV previously. I have re-push all my packages, I have a problem only with libreoffice-faenza-mod. Le 08/06/2015 12:06, Andrejs Mivreņiks a écrit : Hi! Are you sure you added and commited the install file before push? Check your git status output.
Re: [aur-general] [AUR4] Error when upload a update pkgbuild : remote: error: missing install file: avidemux.install
I do a new clone, move pckages files into the new directory, commit and push, that works. Solved for libreoffice-faenza-mod [1]. Thanks. [1] https://aur4.archlinux.org/packages/libreoffice-faenza-mod/ Le 08/06/2015 12:06, Andrejs Mivreņiks a écrit : Hi! Are you sure you added and commited the install file before push? Check your git status output.
Glamor wiki page is obsolete
Consider updating or deleting it: http://www.freedesktop.org/wiki/Software/Glamor/ Thanks. ___ 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: [aur-general] Merge request: dmg2dir-git
Le 18/05/2014 22:50, Evgeniy Alekseev a écrit : On Saturday 17 May 2014 12:02:04 Xorg wrote: Hi. I'm the dev of dmg2dir https://github.com/X0rg/dmg2dir, and the maintainer of package dmg2dir-git https://aur.archlinux.org/packages/dmg2dir-git/. Because it is not interessant to have git version (~1commit/version), I've created on AUR dmg2dir https://aur.archlinux.org/packages/dmg2dir/, and I want to merge dmg2dir-git https://aur.archlinux.org/packages/dmg2dir-git/ in dmg2dir https://aur.archlinux.org/packages/dmg2dir/. Can you merge [1] in [2] ? [1] https://aur.archlinux.org/packages/dmg2dir-git/ [2] https://aur.archlinux.org/packages/dmg2dir/ Done, thank you. Thank to you.
[aur-general] Merge request: dmg2dir-git
Hi. I'm the dev of dmg2dir https://github.com/X0rg/dmg2dir, and the maintainer of package dmg2dir-git https://aur.archlinux.org/packages/dmg2dir-git/. Because it is not interessant to have git version (~1commit/version), I've created on AUR dmg2dir https://aur.archlinux.org/packages/dmg2dir/, and I want to merge dmg2dir-git https://aur.archlinux.org/packages/dmg2dir-git/ in dmg2dir https://aur.archlinux.org/packages/dmg2dir/. Can you merge [1] in [2] ? [1] https://aur.archlinux.org/packages/dmg2dir-git/ [2] https://aur.archlinux.org/packages/dmg2dir/ Thank in advance. X0rg.
[Ubuntu-x-swat] ubuntu-x-swat deactivated by sarvatt
Hello Ubuntu-X, The membership status of Ubuntu-X (ubuntu-x-swat) in the team xorg crack pushers (xorg-edgers) was changed by Robert Hooker (sarvatt) from Approved to Deactivated. https://launchpad.net/~xorg-edgers ___ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
Bug#732687: debian-maintainers: Gnome doesn't work after update.
Package: debian-maintainers Severity: normal Dear Maintainer, *** Please consider answering these questions, where appropriate *** Hello, yesterday I installed debian security updates 7, which saw several of Xorg is included. Well today to start as usual gnome told me that he had not charged either. I had the new desk, and now only charge me the classic. Other problem is that when I enter facebook or similar sites, the session is closed and no further leads me to the home screen of debian. I have a nvidia gt320m graphics and have installed the private driver before upgrading and worked very well. I searched to see if someone else happened to him and I have found no results. *** End of the template - remove these lines *** -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[aur-general] Massive remove request
Hi. I want to remove many packages, if it is possible. First, the group lib32-gnustep-clang-svn: lib32-gnustep-base-clang-svn https://aur.archlinux.org/packages/lib32-gnustep-base-clang-svn/ lib32-gnustep-corebase-clang-svn https://aur.archlinux.org/packages/lib32-gnustep-corebase-clang-svn/ lib32-gnustep-gui-clang-svn https://aur.archlinux.org/packages/lib32-gnustep-gui-clang-svn/ lib32-gnustep-libobjc2-clang-svn https://aur.archlinux.org/packages/lib32-gnustep-libobjc2-clang-svn/ lib32-gnustep-make-clang-svn https://aur.archlinux.org/packages/lib32-gnustep-make-clang-svn/ - Because it was dependencies of darling-multilib-git https://aur.archlinux.org/packages/darling-multilib-git/. Before, darling-multilib-git depended of group gnustep-clang-svn lib32-gnustep-clang-svn, and today, it depends only of gnustep-multilib-clang-svn (a new group which replaces both). Second, it is packages from The Northfield Project (an old fork of Wayland Project): northfield-git https://aur.archlinux.org/packages/northfield-git/ (Wayland fork) norwood-git https://aur.archlinux.org/packages/norwood-git/ (Weston fork) - Because Scott Moreau (A.K.A. soreau), the main dev, has not yet commited since 7 months! This fork is died, his activity (https://github.com/soreau?tab=activity) shows he continues to work on Wayland (and not Northfield). So I don't known if we can build these packages, because nobody uses these on Arch. And last, it's about Psensor: psensor-catalyst https://aur.archlinux.org/packages/psensor-catalyst/ - Psensor (Catalyst) is Psensor, but with AMD proprietary driver support. Nobody uses it, I was alone, but I don't use more Catalyst. And I think it is bad to add the AMD Display Library (ADL) SDK in a package. Thanks in advance, X0rg.
Re: [aur-general] Merge request : php-gtk
Le 10/07/2013 11:23, Maxime GAUDUIN a écrit : We tend to leave packages in the AUR as placeholders as long as the source can still be obtained. Were upstream completely vanished and source gone, I'd remove it, but that is not the case here. End of story. That's ok, I didn't know it until today. Thanks for your answer. I'm sorry to have disturb AUR-general to nothing. Have a nice day... X0rg.
Re: [aur-general] Merge/Remove Request : libkqueue
Le 05/07/2013 23:01, Maxime GAUDUIN a écrit : On Fri, Jul 5, 2013 at 10:49 PM, Pedro Alejandro López-Valencia palop...@gmail.com wrote: On vie, 5 de jul 2013 a las 1:34 PM, Maxime GAUDUIN aluc...@gmail.com wrote: On Fri, Jul 5, 2013 at 8:22 PM, SJ_UnderWater webmaster0...@rcn.com wrote: On Wed, Jul 3, 2013 at 3:11 PM, Pedro Alejandro López-Valencia palop...@gmail.com wrote: 2013/7/3 Xorg xorgbrea...@gmail.com I will disown libkqueue in 2 weeks time provided there is no answer from niQo, then you can adopt it and we will proceed with the merge. Cheers, -- Maxime Just a precision, the OP is Xorg. The ball is in his field. :-) (I have no practical use for libkqueue myself, consider me last-resort adopter). Don't worry, I was replying to SJ_UnderWater :P Sorry to answer now. Yes, I have made this request, because I think (like Lukas) libkqueue0 is a duplicate package (from libkqueue, which is flagged out-of-date). I use libkqueue only as /darling-git/'s dependency. So I think SJ_UnderWater's package is the best package for libkqueue. Then, I read you, and I conclude the best solution is that niQo orphans his package, SJ_UnderWater adopts it and sends a new request to delete libkqueue0. About libkqueue-svn, OK, I didn't know svn still exist. SJ_UnderWater, do you want to adopt it ? I'm not interested by, but I can adopt it in last-resort. Thanks. X0rg.
[aur-general] Merge/Remove Request : libkqueue
Hi everybody. There are 3 /libkqueue/... https://aur.archlinux.org/packages/libkqueue/ https://aur.archlinux.org/packages/libkqueue-svn/ https://aur.archlinux.org/packages/libkqueue0/ libkqueue and libkqueue-svn are flagged out-of-date, and don't respect Arch Packaging Standards (URL : https://wiki.archlinux.org/index.php/Arch_Packaging_Standards) : no package() function, BSD license is missing. Developers don't use svn today (I have downloaded source from svn, we can see 2010-09-18 v1.0 r344 the latest date in ChangeLog). So, only libkqueue0 appears to be good. I suggest to merge libkqueue and libkqueue-svn into libkqueue0, and then rename libkqueue0 into libkqueue, for example. Thanks.
Re: [aur-general] Merge request : php-gtk
Le 01/07/2013 09:46, Maxime Gauduin a écrit : On Sun, 2013-06-30 at 16:29 +0200, Xorg wrote: Hello, Please merge php-gtk (package is old, orphan, dependencies are bad and package can't compile) into php-gtk-git. https://aur.archlinux.org/packages/php-gtk/ https://aur.archlinux.org/packages/php-gtk-git/ Best Regards X0rg I'd leave it like this for the moment, project seems to be active still, there might be a new release at some point. Cheers, -- Maxime As you wish. But it is php-gtk-*2*.0.1 the latest version (http://gtk.php.net/download.php), released 15-May-2008. GitHub page is here : https://github.com/php/php-gtk-src - latest commit, 8 months ago. So I don't know. If you don't merge php-gtk into php-gtk-git, I will probably adopt php-gtk and remake a PKGBUILD for version 2.0.1. 2008, it is far... Thanks. X0rg
Re: [aur-general] [AUR] man-pages-*fr
Le 02/07/2013 08:34, Bartłomiej Piotrowski a écrit : On 2013-06-29 11:34, Xorg wrote: Hi. I think many packages about man-pages in French are outdated. List of packages : - man-pages-fr : v3.03.0 ; last update : 2008-07-18 19:35 == the 2013-05-20 at 15:15, I had written a comment to say the package created is empty. - man-pages-extras-fr : v0.8.1 ; last update : 2008-07-18 19:36 == the 2013-05-20 at 15:19, I had written a comment to say the package created is empty, too. - man-pages-sup-fr : v20080606 ; last update : 2008-08-19 22:11 == PKGBUILD don't have a function package(), so package will be empty too. I have found this (in French, in perkamon-fr directory, README.fr file) : - Christophe Blaess URL:http://www.blaess.fr/christophe/ : 1996-2005 - Alain Portal URL:http://manpagesfr.free.fr/ : 2005 - Thomas Huriaux et Denis Barbier URL:http://po4a.alioth.debian.org/ : 2006-2009 They used po4a for Debian. - Denis Barbier URL:http://perkamon.alioth.debian.org/ : 2010 Perkamon project, to be not only for Debian. - Denis Barbier URL:http://www.traduc.org/perkamon/ : since 2011 I think only *man-pages-fr *is useful today, but it need to be based on Perkamon project. Now, man-pages-fr can be found here : https://alioth.debian.org/frs/?group_id=100455release_id=1879#man-pages-fr-_3.51-1-title-content The latest version is man-pages-fr-3.51-1 So I think man-pages-extras-fr and man-pages-sup-fr are very obsolete and deprecated today, but man-pages-fr need an upgrade. Thanks in advance. X0rg Merged, thanks. So can you orphan man-pages-fr, I want to adopt it, because marc[i1] seems to be inactive since 2009... Thanks. X0rg.
Re: [aur-general] [AUR] man-pages-*fr
Le 02/07/2013 11:44, Bartłomiej Piotrowski a écrit : On 2013-07-02 11:33, Xorg wrote: Le 02/07/2013 08:34, Bartłomiej Piotrowski a écrit : On 2013-06-29 11:34, Xorg wrote: Hi. I think many packages about man-pages in French are outdated. List of packages : - man-pages-fr : v3.03.0 ; last update : 2008-07-18 19:35 == the 2013-05-20 at 15:15, I had written a comment to say the package created is empty. - man-pages-extras-fr : v0.8.1 ; last update : 2008-07-18 19:36 == the 2013-05-20 at 15:19, I had written a comment to say the package created is empty, too. - man-pages-sup-fr : v20080606 ; last update : 2008-08-19 22:11 == PKGBUILD don't have a function package(), so package will be empty too. I have found this (in French, in perkamon-fr directory, README.fr file) : - Christophe Blaess URL:http://www.blaess.fr/christophe/ : 1996-2005 - Alain Portal URL:http://manpagesfr.free.fr/ : 2005 - Thomas Huriaux et Denis Barbier URL:http://po4a.alioth.debian.org/ : 2006-2009 They used po4a for Debian. - Denis Barbier URL:http://perkamon.alioth.debian.org/ : 2010 Perkamon project, to be not only for Debian. - Denis Barbier URL:http://www.traduc.org/perkamon/ : since 2011 I think only *man-pages-fr *is useful today, but it need to be based on Perkamon project. Now, man-pages-fr can be found here : https://alioth.debian.org/frs/?group_id=100455release_id=1879#man-pages-fr-_3.51-1-title-content The latest version is man-pages-fr-3.51-1 So I think man-pages-extras-fr and man-pages-sup-fr are very obsolete and deprecated today, but man-pages-fr need an upgrade. Thanks in advance. X0rg Merged, thanks. So can you orphan man-pages-fr, I want to adopt it, because marc[i1] seems to be inactive since 2009... Thanks. X0rg. Done. A big thank, your response was very fast ! Thanks a lot, have a nice day. X0rg.
[aur-general] Merge request : php-gtk
Hello, Please merge php-gtk (package is old, orphan, dependencies are bad and package can't compile) into php-gtk-git. https://aur.archlinux.org/packages/php-gtk/ https://aur.archlinux.org/packages/php-gtk-git/ Best Regards X0rg Portion de message joint Description: PGP signature
[aur-general] [AUR] man-pages-*fr
Hi. I think many packages about man-pages in French are outdated. List of packages : - man-pages-fr : v3.03.0 ; last update : 2008-07-18 19:35 == the 2013-05-20 at 15:15, I had written a comment to say the package created is empty. - man-pages-extras-fr : v0.8.1 ; last update : 2008-07-18 19:36 == the 2013-05-20 at 15:19, I had written a comment to say the package created is empty, too. - man-pages-sup-fr : v20080606 ; last update : 2008-08-19 22:11 == PKGBUILD don't have a function package(), so package will be empty too. I have found this (in French, in perkamon-fr directory, README.fr file) : - Christophe Blaess URL:http://www.blaess.fr/christophe/ : 1996-2005 - Alain Portal URL:http://manpagesfr.free.fr/ : 2005 - Thomas Huriaux et Denis Barbier URL:http://po4a.alioth.debian.org/ : 2006-2009 They used po4a for Debian. - Denis Barbier URL:http://perkamon.alioth.debian.org/ : 2010 Perkamon project, to be not only for Debian. - Denis Barbier URL:http://www.traduc.org/perkamon/ : since 2011 I think only *man-pages-fr *is useful today, but it need to be based on Perkamon project. Now, man-pages-fr can be found here : https://alioth.debian.org/frs/?group_id=100455release_id=1879#man-pages-fr-_3.51-1-title-content The latest version is man-pages-fr-3.51-1 So I think man-pages-extras-fr and man-pages-sup-fr are very obsolete and deprecated today, but man-pages-fr need an upgrade. Thanks in advance. X0rg
[Ubuntu-x-swat] ubuntu-x-swat approved by tormodvolden
Hello Ubuntu-X, The membership status of Ubuntu-X (ubuntu-x-swat) in the team xorg crack pushers (xorg-edgers) was changed by Tormod Volden (tormodvolden) from Proposed to Approved. https://launchpad.net/~xorg-edgers ___ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
Re: Blurry image with nouveau over VGA, ok with nvidia driver
On Tue, Nov 06, 2012 at 13:58:31 +0100, tino.keitel+x...@tikei.de wrote: On Tue, Nov 06, 2012 at 13:45:26 +0100, Łukasz Maśko wrote: [...] Your report is very similar to mine. I'm also using 1600x1200 resolution. My machine has DVI, but monitor does not. So I'm also using VGA connector. And I also have problems, but its font rendering in my case. I'm not sure it is only about font rendering. I think icons also look blurry. What happens, if you switch to 1280x1024 or 1024x768 (if your monitor supports such resolution)? It's an LCD, so resolutions other than the native resolution (1600x1200) look much worse. I just tried 1400x1050 and 1024x768 just in case. Hi, nevermind. The whole desktop got currupted after a few hours of use, so I reverted back to the Nvidia binary drivers. Regards, Tino ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Blurry image with nouveau over VGA, ok with nvidia driver
On Tue, Nov 06, 2012 at 13:45:26 +0100, Łukasz Maśko wrote: [...] Your report is very similar to mine. I'm also using 1600x1200 resolution. My machine has DVI, but monitor does not. So I'm also using VGA connector. And I also have problems, but its font rendering in my case. I'm not sure it is only about font rendering. I think icons also look blurry. What happens, if you switch to 1280x1024 or 1024x768 (if your monitor supports such resolution)? It's an LCD, so resolutions other than the native resolution (1600x1200) look much worse. I just tried 1400x1050 and 1024x768 just in case. Regards, Tino ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[Intel-gfx] Tearing video on Sandy Bridge
Hi, the tearing video issue with XV output seemed to be fixed on my old computer with i945 graphics at some point. Last year I upgraded to a box with i5-2400, and got bitten again by tearing video. Currently I use kernel 3.4-rc5, Xserver 1.12 and xorg-intel 2.18. I use gnome3 and gnome-shell on my desktop, and tried several players (mplayer, vlc, mythtv). Am I just doing something wrong, or is smooth video playback not the scope of the Sandy Bridge development? Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Tearing video on Sandy Bridge
On Thu, May 03, 2012 at 21:46:37 +0200, Daniel Vetter wrote: On Thu, May 03, 2012 at 09:34:28PM +0200, Tino Keitel wrote: On Thu, May 03, 2012 at 20:43:01 +0200, Daniel Vetter wrote: [...] The only way to get tear-free screen updates on snb is with pageflips, which requires a opengl compositor Thanks. What do you mean with opengl compositor? Isn't the Gnome3 desktop providing this? Well, it needs to do vsync'ed updates, and to work correctly, the client Is this in the dri config file? Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Tearing video on Sandy Bridge
On Thu, May 03, 2012 at 16:32:47 -0400, Chun-Yu Shei wrote: On 05/03/2012 03:51 PM, tino.keitel+x...@tikei.de wrote: On Thu, May 03, 2012 at 21:46:37 +0200, Daniel Vetter wrote: On Thu, May 03, 2012 at 09:34:28PM +0200, Tino Keitel wrote: On Thu, May 03, 2012 at 20:43:01 +0200, Daniel Vetter wrote: [...] The only way to get tear-free screen updates on snb is with pageflips, which requires a opengl compositor Thanks. What do you mean with opengl compositor? Isn't the Gnome3 desktop providing this? Well, it needs to do vsync'ed updates, and to work correctly, the client Is this in the dri config file? I've had tear-free video (finally!) in GNOME 3 for a while now, using the following in my ~/.xsession (and launching that from GDM instead of GNOME directly): CLUTTER_PAINT=disable-clipped-redraws:disable-culling /etc/X11/Sessions/Gnome Thanks, I'll try that. When I goggled for that, I also found people using CLUTTER_VBLANK=True. Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] system freeze with kernel 3.2-rc7
On Mon, Dec 26, 2011 at 16:54:18 -0800, Keith Packard wrote: On Mon, 26 Dec 2011 11:59:04 +0100, Kai Krakow hurikha...@gmail.com wrote: North Bridge Configuration: VT-d This doesn't exist That's odd. I don't understand all of the SNB CPU variations; perhaps there's a desktop version that has VT-d fused out or something? The K variants of SandyBridge CPUs don't have VT-d. Here is the product page for the 2500K: http://ark.intel.com/products/52210/ Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] kernel BUG at drivers/gpu/drm/i915/i915_gem
On Thu, Dec 15, 2011 at 19:54:15 +0100, tino.keitel+x...@tikei.de wrote: On Wed, Dec 14, 2011 at 20:57:51 +0100, tino.keitel+x...@tikei.de wrote: [...] it looks I stumbled over the same: [88399.844150] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:1952! 2011-12-14_19:28:56.93083 0[88399.844182] invalid opcode: [#1] SMP While doing this I was running a 32 bit photo software (Bibble 5 pro) in fullscreen on an otherwise 64 bit system. The full log including the trace is attached. I'll try with the patch applied. I just got the same hang again with the patch applied. Hum, could this be related to the RC6 vs. IOMMU issue? I have CONFIG_INTEL_IOMMU enabled in 3.2, and disabled in 3.1, and boot with i915.i915_enable_rc6=1. Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Bug#652146: hwinfo crash with segfault
Package: hwinfo Version: 16.0-2.1 Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: wheezy/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=sk_SK.UTF-8, LC_CTYPE=sk_SK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages hwinfo depends on: ii libc62.13-21 ii libhd16 16.0-2.1 hwinfo recommends no packages. hwinfo suggests no packages. -- no debconf information hwinfo already chrash with segfault. 'dmesg | grep hwinfo' output [ 6750.021903] hwinfo[25037]: segfault at 503 ip 7fa9ba15a1e1 sp 7fff641fdb20 error 4 in libhd.so.16.0[7fa9ba12d000+bb000] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Intel-gfx] kernel BUG at drivers/gpu/drm/i915/i915_gem
On Wed, Dec 14, 2011 at 02:47:33 +0100, Daniel Vetter wrote: On Mon, Dec 12, 2011 at 10:16, Rocko Requin rockoreq...@hotmail.com wrote: If you can wire up netconsole you should be able to gather the full backtrace and that would be really useful. Otherwise can you please confirm by reverting that commit from your current tree that it is indeed the culprit? Otherwise please bisect the issue. I built 3.2-rc5 with the patch from commit eb1711bb94991e93669c5a1b5f84f11be2d51ea1 reversed, and have been using it now for a day and a half without any i915_gem issues. So at this stage it does seem likely it is the culprit, based on the fact that I had at least 2 and probably 3 i915_gem crashes in around 12 hours with the commit applied. When I get some free time I'll reapply the patch and see if I can reproduce the crash and get a netconsole dump. Backtraces from another reporter seriously look like we're hitting some ugly use-after free. Can you please test whether the patch drm/i915: Only clear the GPU domains upon a successful finish by Chris Wilson fixes anything for you? You can grab it from http://cgit.freedesktop.org/~danvet/drm/patch/?id=389a55581e30607af0fcde6cdb4e54f189cf46cf Hi, it looks I stumbled over the same: [88399.844150] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:1952! 2011-12-14_19:28:56.93083 0[88399.844182] invalid opcode: [#1] SMP While doing this I was running a 32 bit photo software (Bibble 5 pro) in fullscreen on an otherwise 64 bit system. The full log including the trace is attached. I'll try with the patch applied. Regards, Tino [88399.844150] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:1952! 2011-12-14_19:28:56.93083 0[88399.844182] invalid opcode: [#1] SMP [88399.844210] CPU 3 [88399.844222] Modules linked in: bluetooth cpufreq_stats fuse ipv6 loop snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm dvb_usb_vp7045 dvb_usb dvb_core rc_core snd_timer xhci_hcd snd_page_alloc evdev [88399.844368] [88399.844380] Pid: 8959, comm: Xorg Not tainted 3.2.0-rc5-1-g3aae701 #24 /DH67BL [88399.844439] RIP: 0010:[813804d6] [813804d6] i915_wait_request+0x516/0x530 [88399.844491] RSP: 0018:88020b3cbbe8 EFLAGS: 00010246 [88399.844519] RAX: 88021661e800 RBX: 880216692038 RCX: 5250 [88399.844555] RDX: 8802166923f8 RSI: RDI: 880216692038 [88399.844591] RBP: 880216692000 R08: 0010 R09: 0002 [88399.844627] R10: 88021661e800 R11: 005a R12: [88399.844664] R13: R14: R15: 88021661e800 [88399.844700] FS: 7fbef0355880() GS:88021fb8() knlGS: [88399.844741] CS: 0010 DS: ES: CR0: 8005003b [88399.844770] CR2: 7f2c5ed0200c CR3: 000216748000 CR4: 000406e0 [88399.844806] DR0: DR1: DR2: [88399.844842] DR3: DR6: 0ff0 DR7: 0400 [88399.844879] Process Xorg (pid: 8959, threadinfo 88020b3ca000, task 8801f0eee110) 2011-12-14_19:28:56.93093 0[88399.844919] Stack: [88399.844932] 88021661e800 813ac08c 0042 0042 [88399.844977] 8802166922f8 8138056e 8802166923f8 0042 [88399.845023] 88020b3cbd10 81385c01 880216692038 2011-12-14_19:28:56.93094 0[88399.845068] Call Trace: [88399.845087] [813ac08c] ? blt_ring_flush+0xdc/0x110 [88399.845120] [8138056e] ? i915_gem_flush_ring+0x4e/0x210 [88399.845154] [81385c01] ? i915_gem_execbuffer_relocate_entry+0x171/0x300 [88399.845193] [81386d0c] ? i915_gem_do_execbuffer.isra.8+0xb3c/0x13d0 [88399.845233] [81381ed8] ? i915_gem_object_set_to_gtt_domain+0xd8/0x1d0 [88399.845272] [81387a4e] ? i915_gem_execbuffer2+0x9e/0x260 [88399.845307] [8135883c] ? drm_ioctl+0x3ec/0x4a0 [88399.845336] [813879b0] ? i915_gem_execbuffer+0x410/0x410 [88399.845371] [8110c9a6] ? do_vfs_ioctl+0x96/0x550 [88399.845402] [810fc50d] ? vfs_read+0x14d/0x170 [88399.845430] [8110cea9] ? sys_ioctl+0x49/0x80 [88399.845460] [8156327b] ? system_call_fastpath+0x16/0x1b 2011-12-14_19:28:56.93100 0[88399.845491] Code: ff ff 0f 1f 00 45 31 e4 e9 de fc ff ff 0f 1f 84 00 00 00 00 00 41 bc f0 ff ff ff e9 cb fc ff ff 41 bc f4 ff ff ff e9 8a fb ff ff 0f 0b 41 bc 00 fe ff ff eb 91 45 85 e4 0f 84 5e fb ff ff e9 a8 2011-12-14_19:28:56.93101 kern.alert: [88399.845744] RIP [813804d6] i915_wait_request+0x516/0x530 [88399.845781] RSP 88020b3cbbe8 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.16.902
On Mon, Nov 14, 2011 at 08:16:35 +0100, tino.keitel+x...@tikei.de wrote: On Sun, Nov 13, 2011 at 11:27:29 +, Chris Wilson wrote: This is the second release candidate in preparation for the upcoming 2.17.0 release. We will appreciate any feedback we can get from Hi, this does not show up in git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel yet. Is this the correct repository? Oops, I checked the wrong remote in my git tree. Sorry for the noise. Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.16.902
On Sun, Nov 13, 2011 at 11:27:29 +, Chris Wilson wrote: This is the second release candidate in preparation for the upcoming 2.17.0 release. We will appreciate any feedback we can get from Hi, this does not show up in git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel yet. Is this the correct repository? Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Tearing video with Sandy Bridge
Hi, I upgraded from a computer with i945 to a Sandy Bridge box with a i5-2400 CPU. Whereas the video tearing issue with XV output seemed to be solved with the i945 graphics, I now have heavy tearing again. I tried both mplayer -vo xv and mplayer -vo vaapi. I also upgraded to Mesa 7.11, Xserver 1.11 and intel-xorg 2.16, I don't know if any of these is connected to the tearing issue. I use kernel 3.0.4, and gnome-shell 3.0.2 for the desktop. Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel 2011Q3 release
On Wed, Aug 10, 2011 at 09:39:53 +0800, Jin, Gordon wrote: Hi, We'd like to announce Intel 2011Q3 graphics package (note there's no 2011Q2 release), with bug fixes as usual, and Alpha support for Ivy Bridge (Intel 2012 platforms). Hi, the Q3 release is missing in the NEWS section on http://intellinuxgraphics.org/. I also saw no announcement for the release candidate für 2.16 on this list, as it was done in the past. The documentation reads We will appreciate any feedback we can get from testing of this snapshot.. I think there would be more feedback if it would be announced somewhere. Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Question about Double Buffering
Hi List, I am trying to setup my xorg server (1.10.3) to use double buffering. I have the Nvidia 9600 video card and am using the proprietary nvidia driver. When I run glxinfo, I see 'None' and 'Ncons' in the right most column. I do not see any entry with a 'P' (to indicate support for OpenGL pixel buffers). I have the 'DBE' module being loaded (xorg.0.log confirms that it loads). Some research I've done leads me to believe that DBE cannot co-exist with XINERAMA. I have tried the 'nvidia' and 'vesa' drivers both while having no reference to 'Xinerama' in my configuration file, yet the xorg.0.log file still shows 'Xinerama' (a built in extension) being loaded. -- Thanks, Dyweni ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [Intel-gfx] 3 monitor setup - Sandy Bridge coexisting with an NVidia adapter?
On Thu, Jun 23, 2011 at 12:16:58 -0700, Mark Knecht wrote: Hi, We've been having some minor startup issues getting a 3 monitor multi-head setup running where two digital monitors are driven by an NVidia adapter and the 3rd analog monitor is driven by the VGA output on a Z68/Sandy Bridge Asus motherboard. AFAIK you need to use the open source NVidia driver for this (nouveau). Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Confirm subscription to opensuse-x...@opensuse.org
Hi, this is the mlmmj program managing the mailinglist opensuse-x...@opensuse.org To confirm you want the address archive@mail-archive.com added to this list, please send a reply to opensuse-xorg+confsub-66dc3f1c1c09c51e-archive=mail-archive@opensuse.org This confirmation serves two purposes. It tests that mail can be sent to your address. Secondly it makes sure someone else did not try and subscribe your emailaddress without your permission. Your mailer may automatically reply to the confirmation address when you hit the reply button. The subject and the body of the mail can be anything.
Bug#569523: xserver-xorg-input-evtouch is not installable in sid
Package: xserver-xorg-input-evtouch Severity: normal -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Installation report: ntb1:/lib/udev/rules.d# aptitude install xserver-xorg-input-evtouch Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information... Done Initializing package states... Done Reading task descriptions... Done The following NEW packages will be installed: xserver-xorg-input-evtouch 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 28.3kB of archives. After unpacking 143kB will be used. The following packages have unmet dependencies: xserver-xorg-core: Conflicts: xserver-xorg-input-4 which is a virtual package. The following actions will resolve these dependencies: Keep the following packages at their current version: 1) xserver-xorg-input-evtouch [Not Installed] Tier: Cancel all user actions (2) Accept this solution? [Y/n/q/?] n *** No more solutions available *** The following actions will resolve these dependencies: Keep the following packages at their current version: 1) xserver-xorg-input-evtouch [Not Installed] Tier: Cancel all user actions (2) Accept this solution? [Y/n/q/?] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569523: xserver-xorg-input-evtouch is not installable in sid
Package: xserver-xorg-input-evtouch Severity: normal -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Installation report: ntb1:/lib/udev/rules.d# aptitude install xserver-xorg-input-evtouch Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information... Done Initializing package states... Done Reading task descriptions... Done The following NEW packages will be installed: xserver-xorg-input-evtouch 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 28.3kB of archives. After unpacking 143kB will be used. The following packages have unmet dependencies: xserver-xorg-core: Conflicts: xserver-xorg-input-4 which is a virtual package. The following actions will resolve these dependencies: Keep the following packages at their current version: 1) xserver-xorg-input-evtouch [Not Installed] Tier: Cancel all user actions (2) Accept this solution? [Y/n/q/?] n *** No more solutions available *** The following actions will resolve these dependencies: Keep the following packages at their current version: 1) xserver-xorg-input-evtouch [Not Installed] Tier: Cancel all user actions (2) Accept this solution? [Y/n/q/?] -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Mod4 ignored?
Seriously, noone? Can't believe this is a difficult problem to solve. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Mod4 ignored?
Hello. I'm having a very strange problem with regards to the Mod4 key. Currently, it's mapped to the windows key: $ xmodmap -pm xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Alt_L (0x40), Alt_R (0x71), Meta_L (0x9c) mod2Num_Lock (0x4d) mod3 mod4Super_L (0x7f), Hyper_L (0x80) mod5Mode_switch (0x5d), ISO_Level3_Shift (0x7c) ~/.xmodmaprc: keycode 115 = Super_L keycode 116 = Super_R add Mod4 = Super_L add Mod4 = Super_R Unfortunately, I can't seem to get any wm to listen to Mod4. I can use the following in ~/.fluxbox/keys, for example: Mod4 Right :NextWorkspace Mod4 Left :PrevWorkspace ...pressing Mod4 + left or Mod4 + right does nothing. No key setting involving Mod4 does anything. xev shows the key event occuring (in other words, if I hold 'T', for example, and then tap the windows key, a few of the fields change for the 'T' key event - suggesting a modifier key is being pressed). Any ideas? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
confirm 32e8ff5fec8cdbda25f5b26ecfd1bf06bbb525a8
Mailing list subscription confirmation notice for mailing list xorg-devel We have received a request from archive@mail-archive.com for subscription of your email address, archive@mail-archive.com, to the xorg-de...@lists.x.org mailing list. To confirm that you want to be added to this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: http://lists.x.org/mailman/confirm/xorg-devel/32e8ff5fec8cdbda25f5b26ecfd1bf06bbb525a8 Or include the following line -- and only the following line -- in a message to xorg-devel-requ...@lists.x.org: confirm 32e8ff5fec8cdbda25f5b26ecfd1bf06bbb525a8 Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional Re: text in the Subject: is okay). If you do not wish to be subscribed to this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to xorg-devel-ow...@lists.x.org.
confirm d8adea14b58fd0745c54a4d00cb344a86ea01c48
Mailing list subscription confirmation notice for mailing list xorg-devel We have received a request from archive@mail-archive.com for subscription of your email address, archive@mail-archive.com, to the xorg-de...@lists.x.org mailing list. To confirm that you want to be added to this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: http://lists.x.org/mailman/confirm/xorg-devel/d8adea14b58fd0745c54a4d00cb344a86ea01c48 Or include the following line -- and only the following line -- in a message to xorg-devel-requ...@lists.x.org: confirm d8adea14b58fd0745c54a4d00cb344a86ea01c48 Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional Re: text in the Subject: is okay). If you do not wish to be subscribed to this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to xorg-devel-ow...@lists.x.org.
confirm 3cf60fac655eeaeb52a81a3fb7d0f25684bde251
Mailing list subscription confirmation notice for mailing list xorg We have received a request from 58.38.110.140 for subscription of your email address, archive@mail-archive.com, to the [EMAIL PROTECTED] mailing list. To confirm that you want to be added to this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: http://lists.freedesktop.org/mailman/confirm/xorg/3cf60fac655eeaeb52a81a3fb7d0f25684bde251 Or include the following line -- and only the following line -- in a message to [EMAIL PROTECTED]: confirm 3cf60fac655eeaeb52a81a3fb7d0f25684bde251 Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional Re: text in the Subject: is okay). If you do not wish to be subscribed to this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to [EMAIL PROTECTED]
confirm c6bd693f8dc3360533cc8f1c4aefc5620f19f18a
Mailing list subscription confirmation notice for mailing list Xorg-driver-geode We have received a request from archive@mail-archive.com for subscription of your email address, archive@mail-archive.com, to the [EMAIL PROTECTED] mailing list. To confirm that you want to be added to this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: http://lists.x.org/mailman/confirm/xorg-driver-geode/c6bd693f8dc3360533cc8f1c4aefc5620f19f18a Or include the following line -- and only the following line -- in a message to [EMAIL PROTECTED]: confirm c6bd693f8dc3360533cc8f1c4aefc5620f19f18a Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional Re: text in the Subject: is okay). If you do not wish to be subscribed to this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to [EMAIL PROTECTED]
confirm bc3412bf238fd1e9dd982c5b086c0dac47895362
Mailing list subscription confirmation notice for mailing list Xorg-driver-geode We have received a request from archive@mail-archive.com for subscription of your email address, archive@mail-archive.com, to the [EMAIL PROTECTED] mailing list. To confirm that you want to be added to this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: http://lists.x.org/mailman/confirm/xorg-driver-geode/bc3412bf238fd1e9dd982c5b086c0dac47895362 Or include the following line -- and only the following line -- in a message to [EMAIL PROTECTED]: confirm bc3412bf238fd1e9dd982c5b086c0dac47895362 Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional Re: text in the Subject: is okay). If you do not wish to be subscribed to this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to [EMAIL PROTECTED]
confirm 8c3e0b1218732a3f77f12654d8181948f7991a59
Mailing list subscription confirmation notice for mailing list xorg-driver-ati We have received a request from archive@mail-archive.com for subscription of your email address, archive@mail-archive.com, to the [EMAIL PROTECTED] mailing list. To confirm that you want to be added to this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: http://lists.x.org/mailman/confirm/xorg-driver-ati/8c3e0b1218732a3f77f12654d8181948f7991a59 Or include the following line -- and only the following line -- in a message to [EMAIL PROTECTED]: confirm 8c3e0b1218732a3f77f12654d8181948f7991a59 Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional Re: text in the Subject: is okay). If you do not wish to be subscribed to this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to [EMAIL PROTECTED]
confirm 4f060d63b387ba9d1d366ec784267e010f490887
Mailing list subscription confirmation notice for mailing list xorg-driver-ati We have received a request from archive@mail-archive.com for subscription of your email address, archive@mail-archive.com, to the [EMAIL PROTECTED] mailing list. To confirm that you want to be added to this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: http://lists.x.org/mailman/confirm/xorg-driver-ati/4f060d63b387ba9d1d366ec784267e010f490887 Or include the following line -- and only the following line -- in a message to [EMAIL PROTECTED]: confirm 4f060d63b387ba9d1d366ec784267e010f490887 Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional Re: text in the Subject: is okay). If you do not wish to be subscribed to this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to [EMAIL PROTECTED]
