[ANNOUNCE] libdrm 2.4.20
New version includes a few fixes relative to 2.4.19.
Ben Skeggs (4):
nouveau: remove unused field from nouveau_bo
nouveau: fix segfault in nouveau_bo_new_tile() failure path
nouveau: fix annoying compiler warning
Fix pkgconfig includes for /usr/include/drm
Chris Wilson (2):
intel: Propagate some more error returns
intel: Repeat execbuffer if interrupted by signal
Eric Anholt (3):
intel: Only align Y-tiling pitch to the Y tile width.
intel: Align untiled buffer pitch to 64B.
intel: Install the header file in the libdrm/ directory.
Francisco Jerez (4):
nouveau: Update nouveau_class.h.
nouveau: Small lighting related addition to nouveau_class.h.
nouveau: Fix up the stride of NV20TCL_LIGHT_BACK_*.
nouveau: Regenerate nouveau_class.h.
Jerome Glisse (1):
drm/radeon: tab/whitespace cleanup
Jesse Barnes (2):
modetest: add optional select codepath
libdrm: bump version number to 2.4.20 for release
Julien Cristau (3):
libdrm_intel.pc: don't include ${includedir}/drm
libdrm_nouveau requires libdrm
Install headers to $(includedir)/libdrm
Pauli Nieminen (4):
libdrm: Move intel_atomic.h to libdrm core for sharing.
libdrm_radeon: Optimize cs_gem_reloc to do less looping.
libdrm: Fix error message if libdrm_intel|radeon is disabled and there is
no atomic ops.
Check HAVE_RADEON only after checking for atomic operations.
git tag: 2.4.20
http://dri.freedesktop.org/libdrm/libdrm-2.4.20.tar.bz2
MD5: 3c56e03172b236e14905ef9a68ba2f97 libdrm-2.4.20.tar.bz2
SHA1: f1448ac0f1c7a5f74a86d2fb50941fc12dc932db libdrm-2.4.20.tar.bz2
http://dri.freedesktop.org/libdrm/libdrm-2.4.20.tar.gz
MD5: dcbf9aa0497c84c7e4af15adb0021955 libdrm-2.4.20.tar.gz
SHA1: e492e292df048566f910244bf5e0a9a8f07039b6 libdrm-2.4.20.tar.gz
___
xorg-announce mailing list
xorg-announce@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-fbdev 0.4.2
One bug fix, and a number of build system and other janitorial updates. The shortlog from 0.4.1 follows. Cheers, Julien Adam Jackson (1): Remove afb support Alan Coopersmith (1): Update Sun license notices to current X.Org standard form Gaetan Nadon (6): .gitignore: use common defaults with custom section # 24239 Several driver modules do not have a ChangeLog target in Makefile.am #23814 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES configure.ac: remove unused sdkdir=$(pkg-config...) statement Julien Cristau (3): fbdev: add missing shadowRemove in CloseScreen() configure: require xorg-macros 1.4 for XORG_INSTALL Bump to 0.4.2 git tag: xf86-video-fbdev-0.4.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-fbdev-0.4.2.tar.bz2 MD5: 53a533d9e0c2da50962282526bace074 xf86-video-fbdev-0.4.2.tar.bz2 SHA1: c8562f997d56c9fec50df6ca9892f39f43ff4c2c xf86-video-fbdev-0.4.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-fbdev-0.4.2.tar.gz MD5: a94011aac77eb9cd6d46bf0af0dbc631 xf86-video-fbdev-0.4.2.tar.gz SHA1: 96efa03db8229b83c1545c4c53fb9bf0adcab5a6 xf86-video-fbdev-0.4.2.tar.gz signature.asc Description: Digital signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Turning off graphics card
Hello, my computer is running 24/7. Normally there's nothing difficult to do for the graphics card so the built-in motherboard-graphics card is sufficient. Sometimes I need some more graphics-power. In that case I'd like to turn on the PCIe graphics card, run a 2nd x-server on it and some power-consuming app (game) on that 2nd x-server. Finished with that app I want to stop the 2nd x-server and turn off the PCIe graphics card again. Running the PCIe graphics card (e.g. Radeon 4670) all the time would be a waste of energy and would make the fans run quicker and louder. Can I turn off (and on) a PCIe graphics card while the computer is running? If that's the wrong place to ask this, please point me to the right direction (perhaps the kernel-ML?). TIA Til PS: The computer is running Debian Lenny. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: CLIPBOARD selection doesn't save content
Hi,
If you can, try it under gnome too
That's quite easy to do - I'm already working under GNOME, I never tried
KDE.
as the last time I worked with any
clipboard code, I found its clipboard manager more cooperative at saving
non-standard data-types than when testing under KDE.
Is text a non-standard data type? I can't believe this.
Also, the clipboard manager in gnome will only request the clipboard
contents and take over from my app when the app closes. We explicitly
call gtk_clipboard_store() as we tear down the app.
Sounds reasonable, but that's GTK-specific. Since I'm writing a
general-purpose extension, it should work wherever X11 is installed. I
looked at your code, and then tried to integrate this into my function
by only using Xlib's functions. This is how it looks now:
---
/*
*call-seq:
* Clipboard.write(clipboard, text) == nil
*
*Writes +text+ to the specified clipboard.
*/
static VALUE m_write(VALUE self, VALUE rclipboard, VALUE rtext) /*VALUE
is a Ruby object*/
{
Display * p_display;
Window win;
XEvent xevt, xevt2;
Atom targets[4];
int res;
/*Open default display*/
p_display = XOpenDisplay(NULL);
/*Let Ruby handle protocol errors*/
XSetErrorHandler(handle_x_errors);
/*This are the TARGETS we support*/
targets[0] = XInternAtom(p_display, TARGETS, True);
targets[1] = UTF8_ATOM;
targets[2] = XA_STRING;
targets[3] = XInternAtom(p_display, TIMESTAMP, True); /*TODO:
Implement this request*/
if (CLIPBOARD_MANAGER_ATOM == None)
printf(FAIL\n);
/*Output some useful information*/
printf(PID: %i\n, getpid());
printf(Owner of CLIPBOARD_MANAGER: %lu\n,
XGetSelectionOwner(p_display, CLIPBOARD_MANAGER_ATOM));
/*Create a window for copying into CLIPBOARD*/
win = CREATE_REQUESTOR_WIN;
if (XGetSelectionOwner(p_display, CLIPBOARD_MANAGER_ATOM) == None)
rb_raise(XError, No owner for the CLIPBOARD_MANAGER selection!);
/*Throw Ruby error*/
res = XChangeProperty(p_display, win, CLIPBOARD_ATOM, XA_ATOM, 32,
PropModeReplace, (unsigned char *) targets, 4);
printf(res = %i\n, res);
res = XConvertSelection(p_display, CLIPBOARD_MANAGER_ATOM,
SAVE_TARGETS_ATOM, CLIPBOARD_ATOM, win, CurrentTime);
printf(res = %i\n, res);
/*Get control of the CLIPBOARD*/
XSetSelectionOwner(p_display, CLIPBOARD_ATOM, win, CurrentTime);
for (;;)
{
XNextEvent(p_display, xevt);
if (xevt.type == SelectionRequest)
{
printf(SelectionRequest event; Requested target: %s\n,
XGetAtomName(p_display, xevt.xselectionrequest.target));
printf(Requestor: %lu\n, xevt.xselectionrequest.requestor);
}
else if (xevt.type == SelectionNotify)
{
printf(SelectionNotify event; property: %s\n,
XGetAtomName(p_display, xevt.xselection.property));
printf(Requestor: %lu\n, xevt.xselection.requestor);
}
if (xevt.type == SelectionRequest) /*selection-related event*/
{
if (xevt.xselectionrequest.target == XInternAtom(p_display,
TARGETS, True)) /*TARGETS information requested*/
{
/*Write supported TARGETS into the requestor*/
XChangeProperty(p_display, xevt.xselectionrequest.requestor,
xevt.xselectionrequest.property, XA_ATOM, 32, PropModeReplace, (unsigned
char *) targets, 4);
/*Notify the requestor we have set its requested property*/
xevt2.xselection.type = SelectionNotify;
xevt2.xselection.display = xevt.xselectionrequest.display;
xevt2.xselection.requestor = xevt.xselectionrequest.requestor;
xevt2.xselection.selection = xevt.xselectionrequest.selection;
xevt2.xselection.target = xevt.xselectionrequest.target;
xevt2.xselection.time = xevt.xselectionrequest.time;
xevt2.xselection.property = xevt.xselectionrequest.property;
XSendEvent(p_display, xevt.xselectionrequest.requestor, False,
NoEventMask, xevt2);
}
else if (xevt.xselectionrequest.target == UTF8_ATOM ||
xevt.xselectionrequest.target == XA_STRING) /*UTF-8 or ASCII requested*/
{
/*Write the string TEST into the requestor*/
XChangeProperty(p_display, xevt.xselectionrequest.requestor,
xevt.xselectionrequest.property, xevt.xselectionrequest.target, 8,
PropModeReplace, (unsigned char *) TEST, 4);
/*Notify the requestor we've finished*/
xevt2.xselection.type = SelectionNotify;
xevt2.xselection.display = xevt.xselectionrequest.display;
xevt2.xselection.requestor = xevt.xselectionrequest.requestor;
xevt2.xselection.selection = xevt.xselectionrequest.selection;
xevt2.xselection.target = xevt.xselectionrequest.target;
xevt2.xselection.time = xevt.xselectionrequest.time;
xevt2.xselection.property = xevt.xselectionrequest.property;
XSendEvent(p_display, xevt.xselectionrequest.requestor, False,
NoEventMask, xevt2);
break; /*For debugging, prevents infinite loop*/
}
else /*No supported request*/
{
Re: CLIPBOARD selection doesn't save content
On Sat, 2010-04-03 at 11:09 +0200, Quintus wrote: Hi, If you can, try it under gnome too That's quite easy to do - I'm already working under GNOME, I never tried KDE. Ok, I was tired, and misread Ubuntu Karmic for Kbuntu for some reason! as the last time I worked with any clipboard code, I found its clipboard manager more cooperative at saving non-standard data-types than when testing under KDE. Is text a non-standard data type? I can't believe this. No, but our app uses some, such as application/x-geda-schematic. This saves fine under Gnome, but appeared to have issues saving after program close under KDE last time someone tested it. Also, the clipboard manager in gnome will only request the clipboard contents and take over from my app when the app closes. We explicitly call gtk_clipboard_store() as we tear down the app. Sounds reasonable, but that's GTK-specific. Since I'm writing a general-purpose extension, it should work wherever X11 is installed. I looked at your code, and then tried to integrate this into my function by only using Xlib's functions. Its GTK specific of course.. our app uses GTK, you could look how GTK implemented these functions. I was vaguely curious, so I already posted some of that code. This is how it looks now: Sorry - the xlib code is too low level for me to follow easily - there is a reason I use GTK / GDK for this kind of stuff ;) Maybe I don't get the idea, but when I call XConvertSelection() I'm always sent a SelectionNotify event as a completion notify. Have I to react to this in any way besides checking for success? I don't think so, but then... What's achieved with the call? As far as I understood, you first check wheather there is a clipoard manager. If so, you change the CLIPBOARD property of my window to the list of supported targets. Why? In the call to XConvertSelection() you request that the CLIPBOARD_MANAGER selection is converted to SAVE_TARGETS which then is written to my window as the CLIPBOARD property. This doesn't make any sense to me, CLIPBOARD_MANAGER holds a text string, and not a list of targets and therefore doesn't request the clipboard manager to take responsibility for the CLIPBOARD selection. ...is at least my interpretation of your code correct? Not my code.. a paste from GTK/GDK's sources. I'm not that familiar with all the internal details. [snip] As you can see, I had to kill the process since it never completed the for loop. I'm quite sure I'm only missing a little detail, but what is it? And where does the MULTIPLE request suddenly come from? I think you need to take a look at the ICCCM spec: http://tronche.com/gui/x/icccm/sec-2.html Regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Error building intel driver
I'm getting the following error building the intel driver. I've cleaned out all of the old code, cloned the git repositories, and started fresh to make sure it's not some old cruft. Does anyone have any idea what I'm missing? libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/libdrm -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 -Wold-style-definition -Wdeclaration-after-statement -fvisibility=hidden -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/libdrm -I/usr/local/include/X11/dri -I/usr/local/include -I/usr/local/include -I../uxa -I../src/render_program -g -O2 -MT i830_video.lo -MD -MP -MF .deps/i830_video.Tpo -c i830_video.c -fPIC -DPIC -o .libs/i830_video.o i830_video.c: In function ‘drmmode_has_overlay’: i830_video.c:219: error: ‘I915_PARAM_HAS_OVERLAY’ undeclared (first use in this function) i830_video.c:219: error: (Each undeclared identifier is reported only once i830_video.c:219: error: for each function it appears in.) i830_video.c: In function ‘drmmode_overlay_update_attrs’: i830_video.c:230: error: storage size of ‘attrs’ isn’t known i830_video.c:233: error: ‘I915_OVERLAY_UPDATE_ATTRS’ undeclared (first use in this function) i830_video.c:245: error: ‘DRM_I915_OVERLAY_ATTRS’ undeclared (first use in this function) i830_video.c:230: warning: unused variable ‘attrs’ i830_video.c: In function ‘drmmode_overlay_off’: i830_video.c:255: error: storage size of ‘request’ isn’t known i830_video.c:260: error: ‘DRM_I915_OVERLAY_PUT_IMAGE’ undeclared (first use in this function) i830_video.c:255: warning: unused variable ‘request’ i830_video.c: In function ‘drmmode_overlay_put_image’: i830_video.c:276: error: storage size of ‘request’ isn’t known i830_video.c:281: error: ‘I915_OVERLAY_ENABLE’ undeclared (first use in this function) i830_video.c:319: error: ‘I915_OVERLAY_YUV_PLANAR’ undeclared (first use in this function) i830_video.c:319: error: ‘I915_OVERLAY_YUV420’ undeclared (first use in this function) i830_video.c:321: error: ‘I915_OVERLAY_YUV_PACKED’ undeclared (first use in this function) i830_video.c:321: error: ‘I915_OVERLAY_YUV422’ undeclared (first use in this function) i830_video.c:323: error: ‘I915_OVERLAY_Y_SWAP’ undeclared (first use in this function) i830_video.c:326: error: ‘DRM_I915_OVERLAY_PUT_IMAGE’ undeclared (first use in this function) i830_video.c:276: warning: unused variable ‘request’ make[3]: *** [i830_video.lo] Error 1 make[3]: Leaving directory `/home/src/xorg/xorg/driver/xf86-video-intel/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/src/xorg/xorg/driver/xf86-video-intel/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/src/xorg/xorg/driver/xf86-video-intel' make: *** [all] Error 2 -- o__ ,/'_ o__ (_)\(_) ,/'_ o__ A day may come (_)\(_) ,/'_ o__ when the courage of men fails, (_)\(_) ,/'_ when we forsake our friends and break all (_)\(_) bonds of fellowship, but it is not this day. It is not this day! This day we ride! ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Error building intel driver
On Sat, Apr 3, 2010 at 07:22:48 -0700, Yan Seiner wrote: I'm getting the following error building the intel driver. I've cleaned out all of the old code, cloned the git repositories, and started fresh to make sure it's not some old cruft. Does anyone have any idea what I'm missing? You need newer drm headers (i915_drm.h), either from a recent libdrm or from linux 2.6.33. Cheers, Julien ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Error building intel driver
Julien Cristau wrote: On Sat, Apr 3, 2010 at 07:22:48 -0700, Yan Seiner wrote: I'm getting the following error building the intel driver. I've cleaned out all of the old code, cloned the git repositories, and started fresh to make sure it's not some old cruft. Does anyone have any idea what I'm missing? You need newer drm headers (i915_drm.h), either from a recent libdrm or from linux 2.6.33. HAH! Thanks. I had conflicting headers, in drm/i915_drm.h and libdrm/i915_drm.h . Deleted the older headers in drm and all is well. --Yan -- o__ ,/'_ o__ (_)\(_) ,/'_ o__ A day may come (_)\(_) ,/'_ o__ when the courage of men fails, (_)\(_) ,/'_ when we forsake our friends and break all (_)\(_) bonds of fellowship, but it is not this day. It is not this day! This day we ride! ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-fbdev 0.4.2
One bug fix, and a number of build system and other janitorial updates. The shortlog from 0.4.1 follows. Cheers, Julien Adam Jackson (1): Remove afb support Alan Coopersmith (1): Update Sun license notices to current X.Org standard form Gaetan Nadon (6): .gitignore: use common defaults with custom section # 24239 Several driver modules do not have a ChangeLog target in Makefile.am #23814 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES configure.ac: remove unused sdkdir=$(pkg-config...) statement Julien Cristau (3): fbdev: add missing shadowRemove in CloseScreen() configure: require xorg-macros 1.4 for XORG_INSTALL Bump to 0.4.2 git tag: xf86-video-fbdev-0.4.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-fbdev-0.4.2.tar.bz2 MD5: 53a533d9e0c2da50962282526bace074 xf86-video-fbdev-0.4.2.tar.bz2 SHA1: c8562f997d56c9fec50df6ca9892f39f43ff4c2c xf86-video-fbdev-0.4.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-fbdev-0.4.2.tar.gz MD5: a94011aac77eb9cd6d46bf0af0dbc631 xf86-video-fbdev-0.4.2.tar.gz SHA1: 96efa03db8229b83c1545c4c53fb9bf0adcab5a6 xf86-video-fbdev-0.4.2.tar.gz signature.asc Description: Digital signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.8.0
On Fri, Apr 2, 2010 at 2:29 PM, Dan Nicholson dbn.li...@gmail.com wrote:
On Fri, Apr 2, 2010 at 2:25 PM, Julien Cristau jcris...@debian.org wrote:
On Fri, Apr 2, 2010 at 14:10:47 -0700, Dan Nicholson wrote:
On Fri, Apr 02, 2010 at 01:20:26PM -0700, Keith Packard wrote:
On Fri, 2 Apr 2010 21:01:30 +0200, Julien Cristau jcris...@debian.org
wrote:
And I'll be using /usr/lib/X11/xorg.conf.d/ because using /etc for the
default make my xserver work snippets just seems wrong (and /usr
allows me to make sure they're in sync with the packages, not conflated
with configuration which is the admin's domain).
Yeah, that's why I picked the 'secondary' path supported by the server
so that a directory in /etc/X11 would completely override these files.
Sounds like we need to fix the server config file search path to look in
a sensible place rather than $(prefix)/etc/X11
This is untested, but I think the patch below is all it would take to
add support for a second system directory in $prefix/lib/X11 with
lowest priority.
This is already in {USER,ROOT}_CONFIGDIRPATH, shouldn't it be removed
from there if we add a new search path?
Yeah, probably. It was more of a proof of concept patch. Now would be
the best time to look at those standard search paths and make them
sane. There's no real reason to repeat the nonsense in the xorg.conf
searching.
I posted a patch series which addresses most of these shortcomings, I
think. See 1270312431-11197-1-git-send-email-dbn.li...@gmail.com.
http://lists.freedesktop.org/archives/xorg-devel/2010-April/006846.html
Let me know what you think.
--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building intel driver: where's xcb-aux?
Yan Seiner y...@seiner.com wrote: I'm not a git expert but this is the link that http://cgit.freedesktop.org/xcb/util/ shows for xcb-util: r...@mythtvrt:/home/src/xorg# git pull git://anongit.freedesktop.org/xcb/util fatal: Not a git repository I've tried various combinations of git/xcb/xcb-util, git/xcb/util, and so on. That repostitory doesn't seem to exist. Where can I get xcb-util? This will do the trick: git clone git://anongit.freedesktop.org/xcb/util.git Thanks, --Yan ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: CLIPBOARD selection doesn't save content
I think I'm facing a window manager problem. When I try to get into how the GTK functions solve the CLIPBOARD problem and even if I could implement this in my function: If somebody now tries this on a KDE distro like Kubuntu or openSUSE or on one with Xfce - that wouldn't work. It seems like I would have to implement that for every single window manager... If that's the case, I'll stop here. That would become unmaintainable for a single person. Am I correct with this thought? Marvin Peter Clifton schrieb: I think you need to take a look at the ICCCM spec: http://tronche.com/gui/x/icccm/sec-2.html Regards, ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Howto limit agp aperture size?
Hi, Is there any way, to limit agp aperture size, maybe by passing a parameter to the agpgart module? The bios doesn't provide any setting unfourtunatly :/ Background: I am using a quite old version of nouveau (that one shipped with Fedora-11), and nouveau seems to reserve the whole apg aperture (256mb) instead of using it on-demand. That means half of the system's ram is statically dedicated to nouveau. Thank you in advance, Clemens ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: CLIPBOARD selection doesn't save content
Quintus wrote: Now, I'm trying to implement writing, only for the CLIPBOARD selection, since that one's contents should persist across program death.I know, I have to acquire CLIPBOARD's ownership; afterwards the xclipboard process would send me a TARGETS request asking me what data I provide. I answer this with TARGETS, UTF8_STRING, XA_STRING and TIMESTAMP, which should cause xclipboard to ask me for UTF8_STRING or XA_STRING, but... It doesn't. Instead, if I try to paste the copied text into an application, my program gets a request from that application rather than from xclipboard. Further more, when my program finishes, the data is gone. So I suppose, something is wrong at my side. X itself doesn't have a persistent clipboard. If you want the clipboard contents to persist after the application terminates, a clipboard manager must be running. Clipboard managers are something of a mixed blessing, so not everyone uses one. Whether a clipboard manager is in use and its exact behaviour are dependent upon the desktop environment. All that your program can do is to implement the relevant protocols; the rest is beyond its control. Apart from implementing the CLIPBOARD selection, the application should implement the SAVE_TARGETS protocol for optimum behaviour with modern clipboard managers. For details, see: http://www.freedesktop.org/wiki/ClipboardManager If a compliant clipboard manager is running, this should cause it to take over the clipboard (ownership and contents) from the terminating process. Older clipboard managers (and clients) don't support the SAVE_TARGETS protocol, which means that the clipboard manager must retrieve the clipboard contents whenever the clipboard changes, which can be inefficient if the data is large and/or if there are many targets (some of which may be computationally expensive to generate). -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Display corruption on 1.8.0/Mesa 7.8
I'm having a nasty amount of corruption on DG965WH, Linux 2.6.33.2, xorg-server 1.8.0, Mesa 7.8, libdrm 2.4.20. The same with 1.7.6 and 7.7 works fine. All built from release tarballs and unmodified (except a two-line backport of symbols KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8 and KMS_BO_TYPE_SCANOUT_X8R8G8B8 to get 7.7 to compile against 2.4.19/20). Most things are okay. I am experiencing a lot of corruption on vertical scrolling; some rectangular areas of the display don't redraw. This is particularly ugly when editing a source file, because I am never sure where I am clicking or selecting. It is most noticeable on a small scroll such as you get with the scroll wheel. I see it also when scrolling a web page in a browser. It tends to be reproducible if you scroll down and then up one scroll wheel click. If I bring up a .jpg in the browser, I get some rectangular areas where the image is white. If I then do a back and forward to get it redrawn, it is completely drawn. I know this is not the best description, but I am looking for guidance on where to look first. I have had to revert this to 1.7.6/7.7 in order to keep working, but if anyone has an idea which component it is, I could do some bisecting; unless someone has an aha! moment and can solve it just from the description. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Intel, h264 and XvMC
I'm trying to understand if Intel XvMC can be used with h264 material. If not, is there any way to use Intel hardware acceleration with h264 source? Thanks. --Yan -- o__ ,/'_ o__ (_)\(_) ,/'_ o__ A day may come (_)\(_) ,/'_ o__ when the courage of men fails, (_)\(_) ,/'_ when we forsake our friends and break all (_)\(_) bonds of fellowship, but it is not this day. It is not this day! This day we ride! ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel, h264 and XvMC
On 04/04/2010 06:30 AM, Yan Seiner wrote: I'm trying to understand if Intel XvMC can be used with h264 material. If not, is there any way to use Intel hardware acceleration with h264 source? VA-API does h264 bitstream decoding on the GPU, not XvMC. XvMC is only for motion compensation (which is what MC stands for.) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
