Re: evdev with sun type6 keyboard... also modmap gripes...
On Nov 16, 2008, at 19:51, Peter Hutterer wrote: On Sun, Nov 16, 2008 at 05:52:53PM -0800, Jeremy Huddleston wrote: The keyboard mostly works, but it would probably be better if it were treated as sun6... I just use the "old-fashioned" keyboard driver with: Option "XkbModel""sun6" I looked through the xf86-input-evdev source, but I didn't see an obvious hash table to add this too... could someone tell me where I should start digging to fix this? don't. the point of evdev is that hash-tables like these are in the kernel, and what X sees is standardised already. You can use model sun6 with evdev as well (assuming xkeyboard-config 1.4). yeah... but with the whole "xorg.conf-less" idea... smime.p7s Description: S/MIME cryptographic signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Xinput: Use floats for ConstantDeceleration and AdaptiveDeceleration
On Fri, Nov 14, 2008 at 02:08:24PM -0800, Keith Packard wrote:
> These values need not be constrained to integer values.
>
> Signed-off-by: Keith Packard <[EMAIL PROTECTED]>
> ---
> hw/xfree86/common/xf86Xinput.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
> index f028a25..c785c45 100644
> --- a/hw/xfree86/common/xf86Xinput.c
> +++ b/hw/xfree86/common/xf86Xinput.c
> @@ -130,16 +130,16 @@ ProcessVelocityConfiguration(char* devname, pointer
> list, DeviceVelocityPtr s){
> xf86Msg(X_CONFIG, "%s: (accel) filter stage %i: %.2f ms\n",
> devname, i, 1.0f / (s->filters[i].rdecay));
>
> -tempf = xf86SetIntOption(list, "ConstantDeceleration", 1);
> -if(tempf > 1.0){
> +tempf = xf86SetRealOption(list, "ConstantDeceleration", 1.0);
> +if(tempf != 1.0){
> xf86Msg(X_CONFIG, "%s: (accel) constant deceleration by %.1f\n",
> devname, tempf);
> s->const_acceleration = 1.0 / tempf; /* set reciprocal deceleration
>alias acceleration */
> }
>
> -tempf = xf86SetIntOption(list, "AdaptiveDeceleration", 1);
> -if(tempf > 1.0){
> +tempf = xf86SetRealOption(list, "AdaptiveDeceleration", 1.0);
> +if(tempf != 1.0){
> xf86Msg(X_CONFIG, "%s: (accel) adaptive deceleration by %.1f\n",
> devname, tempf);
> s->min_acceleration = 1.0 / tempf; /* set minimum acceleration */
Signed-off-by: Peter Hutterer <[EMAIL PROTECTED]>
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Mouse button problems using Logitech NX80
On Sat, Nov 15, 2008 at 10:38:33PM +0100, Matija Šuklje wrote: > New problems: > * button mapping for the mouse now works neither in KDE, nor KDM nor Fluxbox > * 'xev' now doesn't even recognise the HWheel buttons (evtest does though) > * synaptics driver using HAL ignores pretty much all the options (which also > makes the 4-side scroll-buttons misbehave — 'xev' reports scroll up as '1', > down as '3', left as '2', right as '8') > please file a bug report, because the information is getting spread across too many emails now and I'm losing track. synaptics and evdev are two different drivers, so you probably have to file two separate bugs. Don't forget to attach your Xorg.log. Oh, and no pastebin links from bugzilla please, makes it harder to find all the stuff. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev with sun type6 keyboard... also modmap gripes...
From: Jeremy Huddleston <[EMAIL PROTECTED]> Date: Sun, 16 Nov 2008 19:49:52 -0800 > > On Nov 16, 2008, at 18:54, David Miller wrote: > >> I have a sun type6 usb keyboard, and evdev treats it as pc105+inet: > > > > That's correct as far as I can tell. > > > > Actually, I'm assuming you're under Linux, and if you are all keyboard > > types emit PC keyboard codes rather than type specific ones. > > Yes, it is under linux (otherwise how would it be using evdev), BSD has copied good ideas from Linux before :-) > but months back, I updated the sun6 keyboard definition to fix bugs when > treating it as a pc105+inet : > > http://gitweb.freedesktop.org/?p=xkeyboard-config.git;a=commitdiff;h=38d2ea83324429aa1406309beb312030a931efcf I really don't think it makes any sense to handle sun keyboard's specially if the kernel is emitting PC scancodes. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev with sun type6 keyboard... also modmap gripes...
On Sun, Nov 16, 2008 at 05:52:53PM -0800, Jeremy Huddleston wrote: > The keyboard mostly works, but it would probably be better if it were > treated as sun6... I just use the "old-fashioned" keyboard driver with: > Option "XkbModel""sun6" > > I looked through the xf86-input-evdev source, but I didn't see an > obvious hash table to add this too... could someone tell me where I > should start digging to fix this? don't. the point of evdev is that hash-tables like these are in the kernel, and what X sees is standardised already. You can use model sun6 with evdev as well (assuming xkeyboard-config 1.4). Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
DMX and Jogl Issues
We're trying to run JOGL on top of DMX, on a 64bit Linux cluster (CentOS 5.2, nVidia Quadro 4600). It runs fine without DMX, but when I try to run it inside DMX I get the following error: java.lang.reflect.InvocationTargetException at java.awt.EventQueue.invokeAndWait(EventQueue.java:1020) at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1348) at com.sun.opengl.util.Animator.display(Animator.java:158) at com.sun.opengl.util.Animator$MainLoop.run(Animator.java:181) at java.lang.Thread.run(Thread.java:674) Caused by: javax.media.opengl.GLException: Error making context current at com.sun.opengl.impl.x11.X11PbufferGLContext.makeCurrentImpl(X11PbufferGLCont ext.java:90) at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:134) at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:182) at com.sun.opengl.impl.GLPbufferImpl.maybeDoSingleThreadedWorkaround(GLPbufferI mpl.java:208) at com.sun.opengl.impl.GLPbufferImpl.display(GLPbufferImpl.java:88) at javax.media.opengl.GLJPanel.paintComponent(GLJPanel.java:659) at javax.swing.JComponent.paint(JComponent.java:1041) at javax.swing.JComponent.paintToOffscreen(JComponent.java:5164) at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java :302) at javax.swing.RepaintManager.paint(RepaintManager.java:1145) at javax.swing.JComponent._paintImmediately(JComponent.java:5112) at javax.swing.JComponent.paintImmediately(JComponent.java:4922) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:740) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:696) at com.sun.opengl.util.Animator$1.run(Animator.java:302) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:225) at java.awt.EventQueue.dispatchEvent(EventQueue.java:602) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java :275) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:20 0) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java :190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177) at java.awt.EventDispatchThread.run(EventDispatchThread.java:138) I'm trying to use the example at the following URL: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6503420 It seems to me it is not a problem with the driver (as is suggested in the bug description) since the program runs outside of DMX. Any hints? Thanks in advance, Andrés Molina Ing. De Sistemas y Computación Universidad de Los Andes Grupo Imagine ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev with sun type6 keyboard... also modmap gripes...
On Nov 16, 2008, at 18:54, David Miller wrote: I have a sun type6 usb keyboard, and evdev treats it as pc105+inet: That's correct as far as I can tell. Actually, I'm assuming you're under Linux, and if you are all keyboard types emit PC keyboard codes rather than type specific ones. Yes, it is under linux (otherwise how would it be using evdev), but months back, I updated the sun6 keyboard definition to fix bugs when treating it as a pc105+inet : http://gitweb.freedesktop.org/?p=xkeyboard-config.git;a=commitdiff;h=38d2ea83324429aa1406309beb312030a931efcf smime.p7s Description: S/MIME cryptographic signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg restarts upon usb-mouse unplug
On Fri, Nov 14, 2008 at 02:08:12PM +0100, (none) wrote: > I'm using Xorg 1.4.2, and when I unplug my Logitech mouse from my > laptop, X restarts and brings me back to the xdm login screen. > > I tried both the evdev and the mouse driver, with the same result (chose > to stay with mouse for now as I couldn't get evdev to work with my > keyboard and configure the tilt-wheel on the mouse properly). please file a bug report on bugs.freedesktop.org and attach your Xorg.log.old after crashing (that's the one that should contain the backtrace). Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev with sun type6 keyboard... also modmap gripes...
From: Jeremy Huddleston <[EMAIL PROTECTED]> Date: Sun, 16 Nov 2008 17:52:53 -0800 > I have a sun type6 usb keyboard, and evdev treats it as pc105+inet: That's correct as far as I can tell. Actually, I'm assuming you're under Linux, and if you are all keyboard types emit PC keyboard codes rather than type specific ones. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
evdev with sun type6 keyboard... also modmap gripes...
I have a sun type6 usb keyboard, and evdev treats it as pc105+inet:
(II) config/hal: Adding input device HID 0430:0005
(**) HID 0430:0005: always reports core events
(**) HID 0430:0005: Device: "/dev/input/event4"
(II) HID 0430:0005: Found keys
(II) HID 0430:0005: Configuring as keyboard
(II) XINPUT: Adding extended input device "HID 0430:0005" (type:
KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) HID 0430:0005: xkb_rules: "evdev"
(**) Option "xkb_model" "pc105+inet"
(**) HID 0430:0005: xkb_model: "pc105+inet"
(**) Option "xkb_layout" "us"
(**) HID 0430:0005: xkb_layout: "us"
---
T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 7 Spd=1.5 MxCh= 0
D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0430 ProdID=0005 Rev= 1.02
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
-
The keyboard mostly works, but it would probably be better if it were
treated as sun6... I just use the "old-fashioned" keyboard driver with:
Option "XkbModel""sun6"
I looked through the xf86-input-evdev source, but I didn't see an
obvious hash table to add this too... could someone tell me where I
should start digging to fix this?
Also, wth is up with the default xmodmap? This should really be
cleaner... wth is Super_{R,L} and Hyper_{R,L}?
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 (0x69)
mod1Alt_L (0x40), Alt_R (0x6c), Meta_L (0xcd)
mod2Num_Lock (0x4d)
mod3
mod4Super_L (0xce), Hyper_L (0xcf)
mod5ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
smime.p7s
Description: S/MIME cryptographic signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Checking out and tracking drm/gem kernel modules
On Sat, Nov 15, 2008 at 11:02:22AM -0800, Dan Nicholson wrote: > On Fri, Nov 14, 2008 at 2:37 PM, garrone <[EMAIL PROTECTED]> wrote: > > In order to build the latest drm/gem kernel modules, > > according to the instructions at www.intellinuxgraphics.org/download.html, > > the git repository at > > git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel > > drm-intel-next branch > > is used. > > When I attempted to clone the repository, similar to the rest of the > > X11 distribution, with the command > > > > $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel > > drm-intel > > > > git wanted to download the best part of a gigabyte. So I set a "depth" > > argument of 2, (--depth 2) after clone, and it merely downloaded the > > source for the linux kernel. Fair enough, for once off. > > Bite the bullet. If you want to track kernel modules, you'll need to > pull a kernel tree. You can keep trying to play games with --depth, > but it will be much easier to just let git get the whole history. Thank you. I am taking this advice. > > > Apologies for this saga. Although there is much git documentation, git is > > not my preferred scm. Bearing in mind my aim is merely to port the 2.6.27 > > code to suse 2.6.25, what is the simplest minimal-bandwidth way to setup > > and to track the linux drm kernel source. > > That doesn't sound like a lot of fun, but why not just grab a 2.6.27 > tarball if that's what you want to do? How would this achieve the outcome of setting up and tracking the drm source? I found module compilation and installation not excessively difficult. I am having initialization and synchronization problems, but this is nothing new. Any comments on why backporting should not be attempted would be most welcome. Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Wrong links, files not where they're supposed to be
On Sun, Nov 16, 2008 at 18:02:21 -0500, Robert Dvoracek wrote:
> * The source directories for 7.4 in the various directories
> /releases/X11R7.4/src/{app,driver,font,lib,proto,util} only contain archives
> for the components which were updated for the new release. The other
> components necessary to build X.Org are missing. Strangely enough they are
> all there in the /releases/X11R7.4/src/everything/ directory.
>
Do you have examples (or, even better, a list of missing files)? I see
some absolute symlinks in X11R7.4/src/app/ on annarchy, which would
probably break on mirrors. What url are you looking at?
Cheers,
Julien
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Fri, Nov 14, 2008 at 01:13:16PM -0800, Keith Packard wrote: > I volunteered to manage an X server 1.6 release, tentatively scheduled > for the end of the year (yes, this year, 2008). This release will > include DRI2 and RandR 1.3 support. I'd like to know how much of the new > Xinput stuff will be ready in time. Input device properties - yes Pointer acceleration- yes X Input 2/MPX - no After the branching, I'll provide patches to disable MPX. We can still use the whole subsystem, but w/o the ability to create new MDs. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exaCopyNtoN calls driver Prepare/Done Copy with no Copy in between
>>> TRACE: RADEONPrepareCopyCP
>>> TRACE: RADEONDoneCopyCP
>>> copy without emission
>>>
>>> Backtrace:
>>> 0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812b9ab]
>>> 1: /usr/lib/xorg/modules/drivers//radeon_drv.so [0xb7c45353]
>>> 2: /usr/lib/xorg/modules//libexa.so(exaCopyNtoN+0x835) [0xb7ba03c5]
>>> 3: /usr/lib/xorg/modules//libfb.so(fbCopyRegion+0x161) [0xb7bbb6c1]
>>> 4: /usr/lib/xorg/modules//libexa.so(exaCopyWindow+0xe0) [0xb7b9fa60]
>>> 5: /usr/bin/Xorg [0x816f680]
>>> 6: /usr/bin/Xorg [0x811b244]
>>> 7: /usr/bin/Xorg(compCopyWindow+0xb4) [0x813ccd4]
>>> 8: /usr/bin/Xorg(miSlideAndSizeWindow+0x743) [0x8123043]
>>> 9: /usr/bin/Xorg(compResizeWindow+0xb8) [0x813d1d8]
>>> 10: /usr/bin/Xorg(ConfigureWindow+0xa91) [0x8072251]
>>> 11: /usr/bin/Xorg(ProcConfigureWindow+0x92) [0x8085412]
>>> 12: /usr/bin/Xorg(Dispatch+0x34f) [0x8085e6f]
>>> 13: /usr/bin/Xorg(main+0x47d) [0x806b6ed]
>>> 14: /lib/libc.so.6(__libc_start_main+0xe5) [0xb7d286d5]
>>> 15: /usr/bin/Xorg [0x806aad1]
>>> TRACE: RADEONMarkSyncCP
>>>
>>>
>>> I hacked up my exa driver to report these and I get a fair few of them
>>> at startup
>>>
>>> miClearToBackground and miSlideAndSizeWindow seems to be main entry
>>> points into the issue
>>>
>>> I also see some from exaFillRegionTiled
>>
>> Sounds like maybe exaCopyNtoN and exaFillRegionTiled should bail early
>> if nbox == 0. Or maybe that should really be done higher up, e.g. the
>> damage layer could not call down unless really necessary.
>
> Okay one of them was from CopyNtoN getting nbox == 0, so I just made
> it bail, simple patch so I checked it in.
>
> The other is from the tiled code doing the second pass for leftover areas.
>
> Initial patch is attached it just prechecks if the copies will be
> needed and avoids them if they aren't, this one I thought
> might need some review.
>
Obligatory logic error.
Updated patch.
Dave.
From 8c09ec2da9e8f4e1445b26dcb23051a7b8ff8a30 Mon Sep 17 00:00:00 2001
From: Dave Airlie <[EMAIL PROTECTED]>
Date: Mon, 17 Nov 2008 10:28:48 +1000
Subject: [PATCH] exa: avoid doing prepare/done without intervening copies in exaFillRegionTiled
This does a precursor check to make sure the copies are required before
entering the prepare/done code.
---
exa/exa_accel.c | 61 ++
1 files changed, 38 insertions(+), 23 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index ccef744..850272e 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -1233,36 +1233,51 @@ exaFillRegionTiled (DrawablePtr pDrawable,
*/
if (alu != GXcopy)
ret = TRUE;
- else if ((*pExaScr->info->PrepareCopy) (pPixmap, pPixmap, 1, 1, alu,
- planemask)) {
- for (i = 0; i < nbox; i++)
- {
+ else {
+ Bool more_copy = FALSE;
+
+ for (i = 0; i < nbox; i++) {
int dstX = pBox[i].x1 + tileWidth;
int dstY = pBox[i].y1 + tileHeight;
- int width = min(pBox[i].x2 - dstX, tileWidth);
- int height = min(pBox[i].y2 - pBox[i].y1, tileHeight);
-
- while (dstX < pBox[i].x2) {
- (*pExaScr->info->Copy) (pPixmap, pBox[i].x1, pBox[i].y1,
- dstX, pBox[i].y1, width, height);
- dstX += width;
- width = min(pBox[i].x2 - dstX, width * 2);
- }
- width = pBox[i].x2 - pBox[i].x1;
- height = min(pBox[i].y2 - dstY, tileHeight);
+ if ((dstX < pBox[i].x2) || (dstY < pBox[i].y2))
+ more_copy = TRUE;
+ }
- while (dstY < pBox[i].y2) {
- (*pExaScr->info->Copy) (pPixmap, pBox[i].x1, pBox[i].y1,
- pBox[i].x1, dstY, width, height);
- dstY += height;
- height = min(pBox[i].y2 - dstY, height * 2);
+ if (more_copy == FALSE)
+ ret = TRUE;
+
+ if (more_copy && (*pExaScr->info->PrepareCopy) (pPixmap, pPixmap,
+ 1, 1, alu, planemask)) {
+ for (i = 0; i < nbox; i++)
+ {
+ int dstX = pBox[i].x1 + tileWidth;
+ int dstY = pBox[i].y1 + tileHeight;
+ int width = min(pBox[i].x2 - dstX, tileWidth);
+ int height = min(pBox[i].y2 - pBox[i].y1, tileHeight);
+
+ while (dstX < pBox[i].x2) {
+ (*pExaScr->info->Copy) (pPixmap, pBox[i].x1, pBox[i].y1,
+ dstX, pBox[i].y1, width, height);
+ dstX += width;
+ width = min(pBox[i].x2 - dstX, width * 2);
+ }
+
+ width = pBox[i].x2 - pBox[i].x1;
+ height = min(pBox[i].y2 - dstY, tileHeight);
+
+ while (dstY < pBox[i].y2) {
+ (*pExaScr->info->Copy) (pPixmap, pBox[i].x1, pBox[i].y1,
+ pBox[i].x1, dstY, width, height);
+ dstY += height;
+ height = min(pBox[i].y2 - dstY, height * 2);
+ }
}
- }
- (*pExaScr->info->DoneCopy) (pPixmap);
+ (*pExaScr->info->DoneCopy) (pPixmap);
- ret = TRUE;
+ ret = TRUE;
+ }
}
exaMarkSync(pDrawable->pScreen);
--
1.6.0.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libXi 1.1.4
Alan Coopersmith (1): Coverity #743/744: Returned without freeing storage bufp/savp Matthieu Herrb (1): nuke RCS Ids Peter Hutterer (2): GetDeviceControl: calculate the length field correctly. libXi 1.1.4 git tag: libXi-1.1.4 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.1.4.tar.bz2 MD5: 7f68180d47b1c28a44718c502ab3bd52 libXi-1.1.4.tar.bz2 SHA1: ee9fdfc55b44926d76b39c5ee58670f5ab0fafef libXi-1.1.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.1.4.tar.gz MD5: 213bd86da3c61b4a5c30d8cb53ad4921 libXi-1.1.4.tar.gz SHA1: c2785d59ee6d18929d356aaf7ca72a95dc98c350 libXi-1.1.4.tar.gz Cheers, Peter pgpQ02KKJVCAJ.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Wrong links, files not where they're supposed to be
On Sun, Nov 16, 2008 at 18:02:21 -0500, Robert Dvoracek wrote:
> There are a few discrepancies with the files and links on the
> download sites.
>
> * The link to the current version of X.Org at /releases/current points to
> X11R7.3 - Should point to 7.4
>
Fixed.
> * The source directories for 7.4 in the various directories
> /releases/X11R7.4/src/{app,driver,font,lib,proto,util} only contain archives
> for the components which were updated for the new release. The other
> components necessary to build X.Org are missing. Strangely enough they are
> all there in the /releases/X11R7.4/src/everything/ directory.
>
> * It's not an issue, but would it be possible to generate some checksums for
> the source packages so they can be verified after downloading?
>
There are checksums in the announce mails, which are gpg-signed (most of
them, anyway).
Cheers,
Julien
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exaCopyNtoN calls driver Prepare/Done Copy with no Copy in between
On Sat, Nov 15, 2008 at 10:09 PM, Michel Dänzer
<[EMAIL PROTECTED]> wrote:
> On Sat, 2008-11-15 at 12:22 +1000, Dave Airlie wrote:
>> I'm not quite sure what causes it,
>>
>> TRACE: RADEONPrepareCopyCP
>> TRACE: RADEONDoneCopyCP
>> copy without emission
>>
>> Backtrace:
>> 0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812b9ab]
>> 1: /usr/lib/xorg/modules/drivers//radeon_drv.so [0xb7c45353]
>> 2: /usr/lib/xorg/modules//libexa.so(exaCopyNtoN+0x835) [0xb7ba03c5]
>> 3: /usr/lib/xorg/modules//libfb.so(fbCopyRegion+0x161) [0xb7bbb6c1]
>> 4: /usr/lib/xorg/modules//libexa.so(exaCopyWindow+0xe0) [0xb7b9fa60]
>> 5: /usr/bin/Xorg [0x816f680]
>> 6: /usr/bin/Xorg [0x811b244]
>> 7: /usr/bin/Xorg(compCopyWindow+0xb4) [0x813ccd4]
>> 8: /usr/bin/Xorg(miSlideAndSizeWindow+0x743) [0x8123043]
>> 9: /usr/bin/Xorg(compResizeWindow+0xb8) [0x813d1d8]
>> 10: /usr/bin/Xorg(ConfigureWindow+0xa91) [0x8072251]
>> 11: /usr/bin/Xorg(ProcConfigureWindow+0x92) [0x8085412]
>> 12: /usr/bin/Xorg(Dispatch+0x34f) [0x8085e6f]
>> 13: /usr/bin/Xorg(main+0x47d) [0x806b6ed]
>> 14: /lib/libc.so.6(__libc_start_main+0xe5) [0xb7d286d5]
>> 15: /usr/bin/Xorg [0x806aad1]
>> TRACE: RADEONMarkSyncCP
>>
>>
>> I hacked up my exa driver to report these and I get a fair few of them
>> at startup
>>
>> miClearToBackground and miSlideAndSizeWindow seems to be main entry
>> points into the issue
>>
>> I also see some from exaFillRegionTiled
>
> Sounds like maybe exaCopyNtoN and exaFillRegionTiled should bail early
> if nbox == 0. Or maybe that should really be done higher up, e.g. the
> damage layer could not call down unless really necessary.
Okay one of them was from CopyNtoN getting nbox == 0, so I just made
it bail, simple patch so I checked it in.
The other is from the tiled code doing the second pass for leftover areas.
Initial patch is attached it just prechecks if the copies will be
needed and avoids them if they aren't, this one I thought
might need some review.
Dave.
>
>
> --
> Earthling Michel Dänzer | http://tungstengraphics.com
> Libre software enthusiast | Debian, X and DRI developer
>
>
From 7ba8cf885f7df9e13e7367bf60ec8d206a53a98f Mon Sep 17 00:00:00 2001
From: Dave Airlie <[EMAIL PROTECTED]>
Date: Mon, 17 Nov 2008 10:28:48 +1000
Subject: [PATCH] exa: avoid doing prepare/done without intervening copies in exaFillRegionTiled
This does a precursor check to make sure the copies are required before
entering the prepare/done code.
---
exa/exa_accel.c | 61 ++
1 files changed, 38 insertions(+), 23 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index ccef744..6e754b2 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -1233,36 +1233,51 @@ exaFillRegionTiled (DrawablePtr pDrawable,
*/
if (alu != GXcopy)
ret = TRUE;
- else if ((*pExaScr->info->PrepareCopy) (pPixmap, pPixmap, 1, 1, alu,
- planemask)) {
- for (i = 0; i < nbox; i++)
- {
+ else {
+ Bool more_copy = FALSE;
+
+ for (i = 0; i < nbox; i++) {
int dstX = pBox[i].x1 + tileWidth;
int dstY = pBox[i].y1 + tileHeight;
- int width = min(pBox[i].x2 - dstX, tileWidth);
- int height = min(pBox[i].y2 - pBox[i].y1, tileHeight);
-
- while (dstX < pBox[i].x2) {
- (*pExaScr->info->Copy) (pPixmap, pBox[i].x1, pBox[i].y1,
- dstX, pBox[i].y1, width, height);
- dstX += width;
- width = min(pBox[i].x2 - dstX, width * 2);
- }
- width = pBox[i].x2 - pBox[i].x1;
- height = min(pBox[i].y2 - dstY, tileHeight);
+ if ((dstX < pBox[i].x2) && (dstY < pBox[i].y2))
+ more_copy = TRUE;
+ }
- while (dstY < pBox[i].y2) {
- (*pExaScr->info->Copy) (pPixmap, pBox[i].x1, pBox[i].y1,
- pBox[i].x1, dstY, width, height);
- dstY += height;
- height = min(pBox[i].y2 - dstY, height * 2);
+ if (more_copy == FALSE)
+ ret = TRUE;
+
+ if (more_copy && (*pExaScr->info->PrepareCopy) (pPixmap, pPixmap,
+ 1, 1, alu, planemask)) {
+ for (i = 0; i < nbox; i++)
+ {
+ int dstX = pBox[i].x1 + tileWidth;
+ int dstY = pBox[i].y1 + tileHeight;
+ int width = min(pBox[i].x2 - dstX, tileWidth);
+ int height = min(pBox[i].y2 - pBox[i].y1, tileHeight);
+
+ while (dstX < pBox[i].x2) {
+ (*pExaScr->info->Copy) (pPixmap, pBox[i].x1, pBox[i].y1,
+ dstX, pBox[i].y1, width, height);
+ dstX += width;
+ width = min(pBox[i].x2 - dstX, width * 2);
+ }
+
+ width = pBox[i].x2 - pBox[i].x1;
+ height = min(pBox[i].y2 - dstY, tileHeight);
+
+ while (dstY < pBox[i].y2) {
+ (*pExaScr->info->Copy) (pPixmap, pBox[i].x1, pBox[i].y1,
+ pBox[i].x1, dstY, width, height);
+ dstY += height;
+ height = min(pBox[i].y2 - dstY, height * 2);
+ }
}
- }
- (*pExaScr->info->DoneCopy) (pPixmap);
+ (*pExaScr->info->DoneCopy) (pPixmap);
- ret = TRUE;
+ ret = TRUE;
+ }
}
exaMarkSync(pDrawable->pScreen);
--
1.6.0.3
___
xorg m
Wrong links, files not where they're supposed to be
There are a few discrepancies with the files and links on the
download sites.
* The link to the current version of X.Org at /releases/current points to
X11R7.3 - Should point to 7.4
* The source directories for 7.4 in the various directories
/releases/X11R7.4/src/{app,driver,font,lib,proto,util} only contain archives
for the components which were updated for the new release. The other
components necessary to build X.Org are missing. Strangely enough they are
all there in the /releases/X11R7.4/src/everything/ directory.
* It's not an issue, but would it be possible to generate some checksums for
the source packages so they can be verified after downloading?
Sorry to be the bearer of bad news.
Thank you,
Robert
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Fri, 2008-11-14 at 14:03 -0800, Donnie Berkholz wrote: > 1.6_beta1: 11/24 > 1.6_beta2: 12/08 > 1.6_rc1: 12/22 > 1.6_rc2: 12/29 > 1.6: 01/05 Sounds good to me. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Better gradient handling (migration/fallbacks)
We tried to use gradients to skin our application, but performance was so bad we soon gave up (on i855GM). Oprofile showed the majority of time was spent in memcpy. It would be great if these problems could be resolved in the upcoming xserver release. Great to hear code has already been written! thx Joel _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
Le 16/11/2008 02:43, Keith Packard a écrit : > Anything on master is going into 1.6, unless we find regressions. Reading your mail, I was under the impression you'd be starting a 1.6 branch on top of 1.5 and then cherry-picking DRI2 and RR1.3 patches on top of it. I'm glad to hear you'll be using master directly. Thanks ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Switchable graphics
Hello, I just wanted to know if there are any plans to implement the switchable graphics (also "hybrid graphics" and ati- specific: "PowerXpress") under Xorg. I'm not the first one asking this question (http://lists.freedesktop. org/archives/xorg/2008-July/036961.html) but I just wondered if anyone has any news about this topic since it has appeared in this mailing list in July. Thanks! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Reducing fontconfig system calls
Hi, I'm running fontconfig in a sandbox, using ptrace, so each system call by fontconfig has a great cost. Some of these come from file opening, and numerous small file reads. Has anyone looked into reducing system calls and small file reads? Is there a way to configure fontconfig to minimize small reads? Would I need to modify the code? If so, which areas should I be looking at? Also, I'm not using a font cache, and I'm not sure how it works. Does it have any bearing on this problem? Josh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
