[Fwd: xorg Digest, Vol 36, Issue 9]
Regina
regina.apel at gmx.de
Thu Jul 3 02:23:21 PDT 2008
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 36, Issue 9
Datum: Tue, 01 Jul 2008 20:45:32 -0700
Von: xorg-request at lists.freedesktop.org
Antwort an: xorg at lists.freedesktop.org
An: xorg at lists.freedesktop.org
Send xorg mailing list submissions to
xorg at lists.freedesktop.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/xorg
or, via email, send a message with subject or body 'help' to
xorg-request at lists.freedesktop.org
You can reach the person managing the list at
xorg-owner at lists.freedesktop.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of xorg digest..."
Today's Topics:
1. Re: error while running Xorg on ARM platform (Daniel Stone)
2. Re: Patch to not fork/exec xkbcomp on X Server initialization
(Daniel Stone)
3. Current tinderbox regression (xserver) (Chris Ball)
4. Re: Current tinderbox regression (xserver) (Chris Ball)
5. Re: Patch to not fork/exec xkbcomp on X Server initialization
(pcpa at mandriva.com.br)
6. Re: synaptics touchpad. reconnect not supported (Peter Hutterer)
7. Re: XvMC and Intel G33 (Zhenyu Wang)
8. Re: synaptics touchpad. reconnect not supported (Peter Hutterer)
9. Re: [Patch] AllowEmptyInput with no ServerLayout (Peter Hutterer)
----------------------------------------------------------------------
Message: 1
Date: Wed, 2 Jul 2008 02:35:58 +0300
From: Daniel Stone <daniel at fooishbar.org>
Subject: Re: error while running Xorg on ARM platform
To: Adam Jackson <ajax at nwnk.net>
Cc: xorg at freedesktop.org
Message-ID: <20080701233558.GB31339 at fooishbar.org>
Content-Type: text/plain; charset="us-ascii"
On Tue, Jul 01, 2008 at 12:53:33PM -0400, Adam Jackson wrote:
> On Tue, 2008-07-01 at 15:44 +0000, Azza Kamal wrote:
> > Hello all,
> > I nearly have successed in cross cmpiling Xorg for ARM platform but
> > unfortunately I got this error when trying to execute Xorg on the
> > target board
> >
> > Fatal server error:xf86EnableIOPorts: Failed to set IOPL for I/O
>
> ARM doesn't even have i/o space, does it?
No, and I swear I merged this patch when I shoved all the Debian/Ubuntu
stuff upstream in something like 2005 ...
Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080702/3d4d569c/attachment-0001.pgp
------------------------------
Message: 2
Date: Wed, 2 Jul 2008 02:40:54 +0300
From: Daniel Stone <daniel at fooishbar.org>
Subject: Re: Patch to not fork/exec xkbcomp on X Server initialization
To: Paulo Cesar Pereira de Andrade <pcpa at mandriva.com.br>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080701234054.GC31339 at fooishbar.org>
Content-Type: text/plain; charset="us-ascii"
On Tue, Jul 01, 2008 at 02:05:11PM -0300, Paulo Cesar Pereira de Andrade wrote:
> I talked with Peter Hutterer in the weekend about a patch I was working
> on, to not fork/exec xkbcomp.
>
> I worked on it, because after some profiling, it seems xkb initialization
> takes around 60% of the time required to start the X Server. Initially I
> wrote it as an optional patch for server 1.4 branch, but yesterday I rewrote
> it almost from scratch, to not be optional and also adapted it to git
> master.
Hi,
Yes, I was expecting around 50% or so. If this is tested and working
fine for you, I'm perfectly happy for you to recommend this to people
who need it, but I'm definitely not merging it. In theory, xkbcomp
should just be xkbcomp(), which hands us back the XkbDescRec it
generates while parsing anyway.
I smashed this together last year and it was phenomenally ugly, but then
I decided to give my laptop (as well as my sunglasses, earphones,
camera, cash, etc) away to some people who kindly let themselves into
our house, and I really don't want to be doing it twice. But it's high
on my todo list, so let's see what these holidays produce.
FWIW, xkbcomp is getting rewritten at some stage as well. I'm willing
to believe that alone will cut a huge swathe of time out: that code is
worse, both in design and implementation, than anything else in XKB.
Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080702/19fafa61/attachment-0001.pgp
------------------------------
Message: 3
Date: Tue, 01 Jul 2008 19:50:47 -0400
From: Chris Ball <cjb at laptop.org>
Subject: Current tinderbox regression (xserver)
To: xorg at lists.freedesktop.org
Message-ID: <86d4lx9nag.fsf at pullcord.laptop.org>
Content-Type: text/plain; charset=us-ascii
http://tinderbox.x.org/builds/2008-07-01-0033/
http://tinderbox.x.org/builds/2008-07-01-0033/logs/xserver/#build
koffscreen.c: In function 'KdOffscreenMarkUsed':
koffscreen.c:315: warning: implicit declaration of function 'KaaPixmapPriv'
koffscreen.c:315: warning: nested extern declaration of 'KaaPixmapPriv'
koffscreen.c:319: error: 'pKaaPixmap' undeclared (first use in this function)
koffscreen.c:319: error: (Each undeclared identifier is reported only once
koffscreen.c:319: error: for each function it appears in.)
--
Chris Ball <cjb at laptop.org>
------------------------------
Message: 4
Date: Tue, 01 Jul 2008 20:18:54 -0400
From: Chris Ball <cjb at laptop.org>
Subject: Re: Current tinderbox regression (xserver)
To: Adam Jackson <ajax at redhat.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <868wwl9lzl.fsf at pullcord.laptop.org>
Content-Type: text/plain; charset=us-ascii
Hi,
> koffscreen.c:319: error: 'pKaaPixmap' undeclared
Since kdOffscreenMarkUsed()'d callers are gone, I think this is the
right idea, and it fixes the build:
diff --git a/hw/kdrive/src/kdrive.h b/hw/kdrive/src/kdrive.h
index 3e5af3a..212e016 100644
--- a/hw/kdrive/src/kdrive.h
+++ b/hw/kdrive/src/kdrive.h
@@ -843,9 +843,6 @@ KdOffscreenArea *
KdOffscreenFree (ScreenPtr pScreen, KdOffscreenArea *area);
void
-KdOffscreenMarkUsed (PixmapPtr pPixmap);
-
-void
KdOffscreenSwapOut (ScreenPtr pScreen);
void
diff --git a/hw/kdrive/src/koffscreen.c b/hw/kdrive/src/koffscreen.c
index f6ef52f..24ba7ff 100644
--- a/hw/kdrive/src/koffscreen.c
+++ b/hw/kdrive/src/koffscreen.c
@@ -309,29 +309,6 @@ KdOffscreenFree (ScreenPtr pScreen, KdOffscreenArea *area)
return area;
}
-void
-KdOffscreenMarkUsed (PixmapPtr pPixmap)
-{
- KaaPixmapPriv (pPixmap);
- KdScreenPriv (pPixmap->drawable.pScreen);
- static int iter = 0;
-
- if (!pKaaPixmap->area)
- return;
-
- /* The numbers here are arbitrary. We may want to tune these. */
- pKaaPixmap->area->score += 100;
- if (++iter == 10) {
- KdOffscreenArea *area;
- for (area = pScreenPriv->off_screen_areas; area != NULL;
- area = area->next)
- {
- if (area->state == KdOffscreenRemovable)
- area->score = (area->score * 7) / 8;
- }
- }
-}
-
Bool
KdOffscreenInit (ScreenPtr pScreen)
{
- Chris.
--
Chris Ball <cjb at laptop.org>
------------------------------
Message: 5
Date: Tue, 01 Jul 2008 22:39:03 -0300
From: pcpa at mandriva.com.br
Subject: Re: Patch to not fork/exec xkbcomp on X Server initialization
To: Daniel Stone <daniel at fooishbar.org>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080701223903.1qrut1dhfqqs0oo0 at webmail.conectiva.com.br>
Content-Type: text/plain; charset=ISO-8859-1; format="flowed"
Quoting Daniel Stone <daniel at fooishbar.org>:
> On Tue, Jul 01, 2008 at 02:05:11PM -0300, Paulo Cesar Pereira de
> Andrade wrote:
>> I talked with Peter Hutterer in the weekend about a patch I was working
>> on, to not fork/exec xkbcomp.
>>
>> I worked on it, because after some profiling, it seems xkb initialization
>> takes around 60% of the time required to start the X Server. Initially I
>> wrote it as an optional patch for server 1.4 branch, but yesterday I rewrote
>> it almost from scratch, to not be optional and also adapted it to git
>> master.
>
> Hi,
> Yes, I was expecting around 50% or so. If this is tested and working
> fine for you, I'm perfectly happy for you to recommend this to people
> who need it, but I'm definitely not merging it. In theory, xkbcomp
> should just be xkbcomp(), which hands us back the XkbDescRec it
> generates while parsing anyway.
>
> I smashed this together last year and it was phenomenally ugly, but then
> I decided to give my laptop (as well as my sunglasses, earphones,
> camera, cash, etc) away to some people who kindly let themselves into
> our house, and I really don't want to be doing it twice. But it's high
> on my todo list, so let's see what these holidays produce.
>
> FWIW, xkbcomp is getting rewritten at some stage as well. I'm willing
> to believe that alone will cut a huge swathe of time out: that code is
> worse, both in design and implementation, than anything else in XKB.
>
> Cheers,
> Daniel
>
------------------------------
Message: 6
Date: Wed, 2 Jul 2008 11:28:30 +0930
From: Peter Hutterer <peter.hutterer at who-t.net>
Subject: Re: synaptics touchpad. reconnect not supported
To: Nicol? Chieffo <84yelo3 at gmail.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080702015830.GB6042 at emu>
Content-Type: text/plain; charset=iso-8859-1
On Tue, Jul 01, 2008 at 08:32:45PM +0200, Nicol? Chieffo wrote:
> I'm using xserver-xorg version 1.4.1~git20080131-1ubuntu12 (the ubuntu
> developing version) but also Hardy version
> (1.4.1~git20080131-1ubuntu9.2)
> how can I see if the driver gets connected through evdev?
if it's 1.4 or above it's most likely hotplugged through evdev.
just check the log files, it should tell you on reconnect.
Cheers,
Peter
------------------------------
Message: 7
Date: Wed, 2 Jul 2008 10:00:19 +0800
From: Zhenyu Wang <zhenyu.z.wang at intel.com>
Subject: Re: XvMC and Intel G33
To: "R. G. Newbury" <newbury at mandamus.org>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080702020018.GA27707 at zhen-devel.sh.intel.com>
Content-Type: text/plain; charset="us-ascii"
On 2008.06.30 18:56:48 -0400, R. G. Newbury wrote:
> Try playing your file using mplayer -vo xvmc -vc ffmepg12mc ( or some of
> the other filters listed by 'mplayer -vc help')
>
> Note that xvmc only works for surfaces (frames) up to 720x568 in
> size....Well it *does* work above that size, but something else is
> munged and the picture is overlaid and pixelated with a bright green
> image. Nobody seems to know what causes this.. At least, no-one has
> jumped forward with an answer.. Zhenyu has done great work on xvmc but
> this is NOT xvmc and I don't think he gets paid to play with this even
> though he does work for Intel!
>
I don't know why high level fails in rendering now, with some HD
(720p, 1080i) clips I tried, first 'I' frame picture is already corrupt
in those larger size, Y component seems right but UV is totally wrong,
although the render pattern (you can set INTEL_XVMC_DUMP to get
'intel_xvmc_dump' file on rendering details) is identical in main level.
I'm seeking ways to clarify this problem.
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080702/18d84a49/attachment-0001.pgp
------------------------------
Message: 8
Date: Wed, 2 Jul 2008 11:41:02 +0930
From: Peter Hutterer <peter.hutterer at who-t.net>
Subject: Re: synaptics touchpad. reconnect not supported
To: Nicol? Chieffo <84yelo3 at gmail.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080702021102.GC6042 at emu>
Content-Type: text/plain; charset=iso-8859-1
On Tue, Jul 01, 2008 at 11:14:53PM +0200, Nicol? Chieffo wrote:
> Thank you very much for the attachment. I will test it.
>
> I cannot understand where is the problem. Is it a kernel problem?
> because the input device should be connected to the same dev file?
> Or anything else?
this isn't really related to the kernel. what happens is that the device gets
a read error and the synaptics driver shuts down (IIRC). when the new device
is created by the kernel, HAL sends a message to the X server that the new
device is available. By default this device is then added with the evdev
driver, because that is what the default fdi file states and hence what HAL
tells X to do.
so even if it is the same device file every time, evdev wins. Unless you
change your settings to add different drivers (see Steven's email).
Cheers,
Peter
------------------------------
Message: 9
Date: Wed, 2 Jul 2008 13:15:22 +0930
From: Peter Hutterer <peter.hutterer at who-t.net>
Subject: Re: [Patch] AllowEmptyInput with no ServerLayout
To: Sascha Hlusiak <saschahlusiak at arcor.de>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080702034522.GA19341 at emu>
Content-Type: text/plain; charset="us-ascii"
Sascha:
On Tue, Jul 01, 2008 at 04:20:08PM +0200, Sascha Hlusiak wrote:
> when not using a layout section in xorg.conf, the function
> checkCoreInputDevices is called too early, when option AllowEmptyInput has
> not been parsed, so I end up with the default keyboard and default pointer
> being added.
>
> The function checkCoreInputDevices is called later anyway so I felt free to
> remove the call in configImpliedLayout.
how about this one?
In master, checkCoreInputDevices was only called in configImpliedLayout (was
removed ages ago). This patch applies your changes and resurrects checkInput.
AllowEmptyInput is enabled if AutoAddDevices and AutoEnableDevices is enabled,
otherwise it's disabled.
Cheers,
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-xfree86-AllowEmptyInput-is-now-enabled-by-default-i.patch
Type: text/x-diff
Size: 3132 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080702/c4d8458b/attachment.patch
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 36, Issue 9
***********************************
More information about the xorg
mailing list