[Fwd: xorg Digest, Vol 36, Issue 10] | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 36, Issue 10
Datum: Wed, 02 Jul 2008 00:37:23 -0700
Von: xorg-request@xxxxxxxxxxxxxxxxxxxxx
Antwort an: xorg@xxxxxxxxxxxxxxxxxxxxx
An: xorg@xxxxxxxxxxxxxxxxxxxxx
Send xorg mailing list submissions to
xorg@xxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
xorg-owner@xxxxxxxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of xorg digest..."
Today's Topics:
1. Re: Further notes on 7.4 (Gene Heskett)
2. Re: Further notes on 7.4 (Alan Coopersmith)
3. Re: Patch to not fork/exec xkbcomp on X Server initialization
(Peter Hutterer)
4. Re: Disable auto repeat for non standard keys? (Simon Thum)
5. Re: ati-6.9.0 unstable dualhead (Simon Thum)
6. RE: error while running Xorg on ARM platform (Azza Kamal)
7. Re: radeon EXA performance questions (Michel D?nzer)
8. Re: Further notes on 7.4 (R?mi Cardona)
9. Re: Resolution indpendence (Eirik Byrkjeflot Anonsen)
----------------------------------------------------------------------
Message: 1
Date: Tue, 01 Jul 2008 23:46:08 -0400
From: Gene Heskett <gene.heskett@xxxxxxxxxxx>
Subject: Re: Further notes on 7.4
To: xorg@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <200807012346.08627.gene.heskett@xxxxxxxxxxx>
Content-Type: text/plain; charset=iso-8859-1
On Tuesday 01 July 2008, Adam Jackson wrote:
>On Mon, 2008-06-30 at 15:22 -0700, Dan Nicholson wrote:
>> - twm/xdm: Certainly legacy in the window/display manager world, but
>> it seems strange to install X without one of each. Also, the default
>> xinitrc runs twm, xclock and xterm, none of which would be available
>> with the core X installation.
>
>That's really just tempting me to remove startx from the list as well.
>
>- ajax
>
Please don't, unless replacing it with a work-a-like. I've been logging in on
level 3, no gui, and doing a startx from there for a decade now.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Sic transit gloria mundi.
[So passes away the glory of this world.]
-- Thomas `a Kempis
------------------------------
Message: 2
Date: Tue, 01 Jul 2008 20:59:35 -0700
From: Alan Coopersmith <Alan.Coopersmith@xxxxxxx>
Subject: Re: Further notes on 7.4
To: Gene Heskett <gene.heskett@xxxxxxxxxxx>
Cc: xorg@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <486AFD27.2000206@xxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1
Gene Heskett wrote:
> On Tuesday 01 July 2008, Adam Jackson wrote:
>> That's really just tempting me to remove startx from the list as well.
>>
> Please don't, unless replacing it with a work-a-like. I've been logging in on
> level 3, no gui, and doing a startx from there for a decade now.
Just to be clear, the list isn't "modules allowed to exist" - but modules
that we consider to be the core X Window System that you get when you download
the whole X11R7.x set & build it.
The other modules aren't deleted, just relegated to a status more like the
old X Consortium "contrib" - X.Org will still host the git repos, bugzilla,
& ftp sites for them, just won't make sure that they are still building with
current releases and included in the X11R7.x "katamari" releases. Whether
they continue to be updated or buildable depends on how many people show
enough interest to fix issues that crop up.
For many of the old modules like xinit, you get a bit of a ride from OS's
and distros like mine, for which the effort to declare something deprecated
and remove it is a little higher than the cost to do a commit & release
every year or two to fix any issues that crept in. (And many of the
modules have had no changes worthy of a new release since X11R7.0, and
the basic libX11/libXext interfaces are unlikely to be broken, ever,
just have newer alternatives like libxcb be recommended instead, so some
may never need another release, or just get a new tarball kicked out
a couple times a decade to get the latest autoconf script updates for new
platforms.)
--
-Alan Coopersmith- alan.coopersmith@xxxxxxx
Sun Microsystems, Inc. - X Window System Engineering
------------------------------
Message: 3
Date: Wed, 2 Jul 2008 13:31:48 +0930
From: Peter Hutterer <peter.hutterer@xxxxxxxxx>
Subject: Re: Patch to not fork/exec xkbcomp on X Server initialization
To: Daniel Stone <daniel@xxxxxxxxxxxxx>, Paulo Cesar Pereira de
Andrade <pcpa@xxxxxxxxxxxxxxx>, xorg@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <20080702040148.GB19341@emu>
Content-Type: text/plain; charset=us-ascii
[Haven't looked at the actual patch yet]
On Wed, Jul 02, 2008 at 02:40:54AM +0300, Daniel Stone wrote:
> 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.
A rewrite may be a better option, but is there any reason we can't put
paulo's patch into master for the time being? Worse comes to worst it's
reverted (or removed) when the rewrite happens. Trying to debug xkb startup is
a pain right now, and removing the fork may just convince my gdb not to die
the death of a thousand sins.
and the thing with rewrites is that they tend to always take longer than
expected, so if there's an interim solution I'm not the one to complain.
Cheers,
Peter
------------------------------
Message: 4
Date: Wed, 02 Jul 2008 08:15:26 +0200
From: Simon Thum <simon.thum@xxxxxx>
Subject: Re: Disable auto repeat for non standard keys?
To: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
Cc: xorg@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <486B1CFE.90600@xxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Matthew Garrett wrote:
> I can't think of any straightforward way to do so, sadly. If the user
> needs to hit the key twice, the damage has already been done.
Which one is worse?
If a user needs to hit twice, he may be inclined to check logs. Ideally
that gives him a strong hint.
(That's not to say I wouldn't prefer kernel-based hacks.)
------------------------------
Message: 5
Date: Wed, 02 Jul 2008 08:31:39 +0200
From: Simon Thum <simon.thum@xxxxxx>
Subject: Re: ati-6.9.0 unstable dualhead
To: Alex Deucher <alexdeucher@xxxxxxxxx>
Cc: Sebastian Glita <glseba@xxxxxxxxx>, xorg@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <486B20CB.7000304@xxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Alex Deucher wrote:
> On Tue, Jul 1, 2008 at 11:45 AM, Sebastian Glita <glseba@xxxxxxxxx> wrote:
>> I'm using dualhead an ASUS with ATI Radeon Xpress 1100 200M against a Belinea SVGA monitor.
>> The latest version now of xf86-video-ati drives the second monitor in an unstable state of shivering, trembling, flickering very fast (or something like that).
>
> Please try git master. There was a problem with the DAC setup on
> RS4xx chips in 6.9.0. I may roll a 6.9.1 soon to pickup the fallout
> from 6.9.0 testing.
I have a RV280 + LVDS, and 6.9.0 screwed my LCD worse than pre-6.3 did.
So it can't be only DAC. (6.8.0 is fine!)
Also, though EXA improved a lot, there arew still lots of (fairly
unpredictable, but generally likely during tab or window switches)
occassions where it seems to spin. XAA still has better perf for me.
For some reason I can't switch on AGP fast writes. May this be the cause?
If you want I can send logs etc.
Regards,
Simon
------------------------------
Message: 6
Date: Wed, 2 Jul 2008 06:34:34 +0000
From: Azza Kamal <eng_azza_kamal@xxxxxxxxxxx>
Subject: RE: error while running Xorg on ARM platform
To: Daniel Stone <daniel@xxxxxxxxxxxxx>, Adam Jackson <ajax@xxxxxxxx>
Cc: xorg@xxxxxxxxxxxxxxx
Message-ID: <BLU122-W44040E8039BA7FFE302648C9990@xxxxxxx>
Content-Type: text/plain; charset="windows-1252"
I checked your posts on the mailig list in 2005 but I didn't find anything that help to fix my problem. The Xorg version that I used is 6.8.2.
Have any one any idea about that problem. Is it a problem in the configurations I specified in host.def file or what?? also I cross compile Xorg on a pc that has Fedora Core 3 linux while my target platform has Montavista kernel, does this matter??
Have any one succeeded in cross compiling Xorg6.8.2 successfully before and run it on his target board. If so can he please send me that successful sccenario.
Thanks very much in advance.
Azza
> Date: Wed, 2 Jul 2008 02:35:58 +0300> From: daniel@xxxxxxxxxxxxx> To: ajax@xxxxxxxx> CC: eng_azza_kamal@xxxxxxxxxxx; xorg@xxxxxxxxxxxxxxx> Subject: Re: error while running Xorg on ARM platform> > 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
_________________________________________________________________
The i?m Talkaton. Can 30-days of conversation change the world?
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_ChangeWorld
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xorg/attachments/20080702/4ca383e5/attachment-0001.html
------------------------------
Message: 7
Date: Wed, 02 Jul 2008 08:52:25 +0200
From: Michel D?nzer <michel@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: radeon EXA performance questions
To: Ross Vandegrift <ross@xxxxxxxxxxx>
Cc: xorg@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <1214981545.22068.180.camel@xxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8
On Tue, 2008-07-01 at 18:14 -0400, Ross Vandegrift wrote:
> On Tue, Jul 01, 2008 at 11:53:29AM -0400, Ross Vandegrift wrote:
> > That was only a slightly educated guess :)
> > My Xorg.0.log reports Xserver 1.4.0.90, and radeon module 4.3.0.
> >
> > If I get the time today, I'll try upgrading the Xorg in Debian
> > unstable.
>
> Debian unstable's versions were only marginally newer, reporting the
> same version in Xorg.log.
Yeah, you'd have to wait for 1.5 (RCs) to enter experimental or try an
upstream snapshot.
> (WW) RADEON(0): Failed to set up write-combining range (0xc0000000,0x10000000)
Looks like there's no write combining for video RAM. That certainly
doesn't help, but it shouldn't be a huge problem; there shouldn't be too
many direct CPU writes to video RAM. It definitely doesn't explain any
difference between EXA and XAA.
--
Earthling Michel D?nzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
------------------------------
Message: 8
Date: Wed, 02 Jul 2008 09:31:21 +0200
From: R?mi Cardona <remi@xxxxxxxxxx>
Subject: Re: Further notes on 7.4
To: xorg@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <486B2EC9.50803@xxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Dan Nicholson a ?crit :
> I remembered a good reason why these should still be installed. Tons
> of autotooled X programs (certainly in GNOME) use the autoconf macros
> AC_PATH_X or AC_PATH_XTRA to find the X installation.
Having looked at a good number of Gnome packages' configure.ac scripts,
I don't recall seeing any of those macros being called for a long time.
In fact, I think it'd be good favor for everyone not to include these in
the base X distribution. Those apps that break can either fix their
configure code or install the correct package.
It's not like asking to migrate all current Xlib-using code to XCB...
Cheers
--
R?mi Cardona
LRI, INRIA
remi.cardona@xxxxxx
remi@xxxxxxxxxx
------------------------------
Message: 9
Date: Wed, 02 Jul 2008 09:37:15 +0200
From: Eirik Byrkjeflot Anonsen <eirik@xxxxxxxxx>
Subject: Re: Resolution indpendence
To: xorg@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <87prpwrb2s.fsf@xxxxxxxxx>
Content-Type: text/plain; charset=us-ascii
David De La Harpe Golden <david.delaharpe.golden@xxxxxxxxx> writes:
> Eirik Byrkjeflot Anonsen wrote:
>
>> That's a simple application of nyquist. Features smaller than 2
>> pixels can not be accurately represented
>
> That's a bit simplistic: that'll tell you which
> features will be accurately preserved. It doesn't tell you if those
> features were important to preserve to make the reduced icon
> sufficiently visually distinctive and recognisable to remain useful in
> context.
True enough, but it does explain why a "less busy" icon "looks better"
at a small pixel count, with a fairly high degree of precision :)
And note that the problem isn't just "being preserved". The problem
with aliasing is not that features "disappear", but that they appear
to be something different than what they really are. And that is much
worse.
(If you're just using a naive rasterizer to render an image, nyquist
can be used to automatically detect features prone to aliasing. And
it seems the opinion among people who have investigated is that in
general it is very hard to do better than a naive rasterizer.)
eirik
------------------------------
_______________________________________________
xorg mailing list
xorg@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 36, Issue 10
************************************
_______________________________________________
xorg mailing list
xorg@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/xorg
[X Forum] [Devices] [XFree86] [XFree86 Newbie] [Site Home] [IETF Annouce] [Security] [Fontconfig] [Bugtraq] [Rubini] [Photo] [Yosemite] [MIPS Linux] [ARM Linux] [Linux Security] [Video for Linux] [Linux RAID] [Linux Resources]