[Fwd: xorg Digest, Vol 36, Issue 20]

Regina regina.apel at gmx.de
Thu Jul 3 02:40:36 PDT 2008



-------- Original-Nachricht --------
Betreff: 	xorg Digest, Vol 36, Issue 20
Datum: 	Thu, 03 Jul 2008 02:27:56 -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. [Fwd: xorg Digest, Vol 36, Issue 16] (Regina)
   2. [Fwd: xorg Digest, Vol 36, Issue 17] (Regina)
   3. [Fwd: xorg Digest, Vol 36, Issue 18] (Regina)


----------------------------------------------------------------------

Message: 1
Date: Thu, 03 Jul 2008 11:26:41 +0200
From: Regina <regina.apel at gmx.de>
Subject: [Fwd: xorg Digest, Vol 36, Issue 16]
To: xorg at lists.freedesktop.org
Message-ID: <486C9B51.3060902 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed



-------- Original-Nachricht --------
Betreff: 	xorg Digest, Vol 36, Issue 16
Datum: 	Wed, 02 Jul 2008 14:58:57 -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: Further notes on 7.4 (Tuomo Valkonen)
   2. Re: Further notes on 7.4 (Daniel Stone)
   3. Re: ati-6.9.0 unstable dualhead (Alex Deucher)
   4. Re: Further notes on 7.4 (Adam Jackson)
   5. Re: Patch to not fork/exec xkbcomp on X Server initialization
      (Paulo Cesar Pereira de Andrade)


----------------------------------------------------------------------

Message: 1
Date: Wed, 2 Jul 2008 20:47:52 +0000 (UTC)
From: Tuomo Valkonen <tuomov at iki.fi>
Subject: Re: Further notes on 7.4
To: xorg at freedesktop.org
Message-ID: <slrng6nqbo.2ci.tuomov at jolt.modeemi.cs.tut.fi>

On 2008-06-30, Daniel Stone <daniel at fooishbar.org> wrote:
> Why not? People who go out of their way to install legacy apps can also
> go out of the way to install legacy fonts, surely? The vast majority of
> users can just go on, content.

As long as fontconfig/Xft remains blur-fascist [1, 2], my software
will require core fonts. If core fonts are removed, I will implement
bitmapped fonts internally in my software. I will not support
blur-fascist font systems such as fontconfig/Xft.

In other news, Xrandr was also ruined by making it Xinerama shit.
I will have my telly as a completely separate screen, thank you.
I only ever run mplayer on it, and don't want other programs to
even know about it. (Fuck Xinerama-style kludges, that only provide
multiple views to a single display model, instead of a multi-display
model like traditional X multihead. Just remove the artificial 
reparenting restrictions, make root windows like any other windows,
creatable dynamically with XCreateWindow, and resizable with 
XResizeWindow etc.)

It really is time to switch back to Windows. The only thing keeping
me in this FOSS crap is the support for window managers. Probably
you'll remove that too soon... already many apps are not playing
by the ICCCM.

  [1]: http://iki.fi/tuomov/b/archives/2008/03/20/T13_47_17/

  [2]: http://iki.fi/tuomov/b/archives/2006/03/17/T20_15_31/

-- 
Tuomo



------------------------------

Message: 2
Date: Thu, 3 Jul 2008 00:02:17 +0300
From: Daniel Stone <daniel at fooishbar.org>
Subject: Re: Further notes on 7.4
To: Tuomo Valkonen <tuomov at iki.fi>
Cc: xorg at freedesktop.org
Message-ID: <20080702210217.GA3272 at fooishbar.org>
Content-Type: text/plain; charset="iso-8859-1"

On Wed, Jul 02, 2008 at 08:47:52PM +0000, Tuomo Valkonen wrote:
> On 2008-06-30, Daniel Stone <daniel at fooishbar.org> wrote:
> > Why not? People who go out of their way to install legacy apps can also
> > go out of the way to install legacy fonts, surely? The vast majority of
> > users can just go on, content.
> 
> As long as fontconfig/Xft remains blur-fascist [1, 2], my software
> will require core fonts. If core fonts are removed, I will implement
> bitmapped fonts internally in my software. I will not support
> blur-fascist font systems such as fontconfig/Xft.

OK.

> It really is time to switch back to Windows. The only thing keeping
> me in this FOSS crap is the support for window managers. Probably
> you'll remove that too soon... already many apps are not playing
> by the ICCCM.

Hyv?.

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/20080703/3f52680d/attachment-0001.pgp 

------------------------------

Message: 3
Date: Wed, 2 Jul 2008 17:22:07 -0400
From: "Alex Deucher" <alexdeucher at gmail.com>
Subject: Re: ati-6.9.0 unstable dualhead
To: "Simon Thum" <simon.thum at gmx.de>
Cc: Sebastian Glita <glseba at yahoo.com>, xorg at lists.freedesktop.org
Message-ID:
	<a728f9f90807021422h6ba0f174r8e82c9215b710b1 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jul 2, 2008 at 4:47 PM, Simon Thum <simon.thum at gmx.de> wrote:
> Alex Deucher wrote:
>>
>> When you say LCD, do you mean LVDS or an LCD connected via VGA/DVI?
>> How is it screwed?
>
> Ahh crap. Git server + faily recent ati (6.8.191) does not exhibit the
> behaviour.
>
> Well, I meant DVI in a rush of believing DVI was LVDS-based. It frequently
> switches off and on backlight, plus small visible tearings all along. Very
> seldom, also noise came up.
> I had this in varying degrees, more with my old LCD, less with my new, but
> 6.3 to 6.8 were definetely useable (about once a week it came back. After a
> mode-switch or two it was fixed). Windows never exposed comparable problems
> (except for the noise).
>
> But 6.9 + 1.4.2 was worst yet. Impossible to use.
>

Are you saying the xserver makes a difference?  One thing you might
try is choosing a different mode if several variations are available
for your monitor.  A lot of DVI monitors are pretty picky about the
timings they like.  if you post your xorg log I'll take a look.  If
you see differences between 6.8.191 and 6.8.192/6.9.0 let me know, as
I made some changes to the pll code.

Alex


------------------------------

Message: 4
Date: Wed, 02 Jul 2008 17:51:56 -0400
From: Adam Jackson <ajax at nwnk.net>
Subject: Re: Further notes on 7.4
To: Tuomo Valkonen <tuomov at iki.fi>
Cc: xorg at freedesktop.org
Message-ID: <1215035516.24769.231.camel at localhost.localdomain>
Content-Type: text/plain

On Wed, 2008-07-02 at 20:47 +0000, Tuomo Valkonen wrote:
> On 2008-06-30, Daniel Stone <daniel at fooishbar.org> wrote:
> > Why not? People who go out of their way to install legacy apps can also
> > go out of the way to install legacy fonts, surely? The vast majority of
> > users can just go on, content.
> 
> As long as fontconfig/Xft remains blur-fascist [1, 2], my software
> will require core fonts. If core fonts are removed, I will implement
> bitmapped fonts internally in my software. I will not support
> blur-fascist font systems such as fontconfig/Xft.

"DOS as a simple and manageable system was the high point of computing."

Also, time is actually of a cubic nature.

> In other news, Xrandr was also ruined by making it Xinerama shit.
> I will have my telly as a completely separate screen, thank you.
> I only ever run mplayer on it, and don't want other programs to
> even know about it. (Fuck Xinerama-style kludges, that only provide
> multiple views to a single display model, instead of a multi-display
> model like traditional X multihead. Just remove the artificial 
> reparenting restrictions, make root windows like any other windows,
> creatable dynamically with XCreateWindow, and resizable with 
> XResizeWindow etc.)

"Just".

- ajax



------------------------------

Message: 5
Date: Wed, 02 Jul 2008 18:34:26 -0300
From: Paulo Cesar Pereira de Andrade <pcpa at mandriva.com.br>
Subject: Re: Patch to not fork/exec xkbcomp on X Server initialization
To: Daniel Stone <daniel at fooishbar.org>, 	Peter Hutterer
	<peter.hutterer at who-t.net>, xorg at lists.freedesktop.org
Message-ID: <486BF462.10300 at mandriva.com.br>
Content-Type: text/plain; charset="iso-8859-1"

Daniel Stone wrote:
>> 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.
>
> The thing is that this still forks, so you're still screwed on startup,
> and you still have the XKM mess.  All it does is cache the output
> somewhere.

  I am attaching a more complete patch. Now it creates a SHA1 of the
contents of the .tmp file. It still creates a temporary file because
the functions require outputing to a file. This could be reworked to
avoid "using the filesystem" to send parameters from one function
to another; just not added to this patch because almost everything
is a fprintf and not so trivial to wrap to using a temp buffer.

  It also requires snprintf, openssl and linking the X Server with -lcrypto.
This is a prototype patch, and for server-1.4-branch...

>> 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.
>
> Yeah, I'm still happy to try the smashing-xkbcomp-in-its-current-form-in
> thing again.
>
> Cheers,
> Daniel

Paulo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Don-t-fork-exec-xkbcomp-if-a-cache-file-exists.patch
Type: text/x-patch
Size: 22653 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080702/fba9c06b/attachment.bin 

------------------------------

_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

End of xorg Digest, Vol 36, Issue 16
************************************




------------------------------

Message: 2
Date: Thu, 03 Jul 2008 11:27:12 +0200
From: Regina <regina.apel at gmx.de>
Subject: [Fwd: xorg Digest, Vol 36, Issue 17]
To: xorg at lists.freedesktop.org
Message-ID: <486C9B70.6040406 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed



-------- Original-Nachricht --------
Betreff: 	xorg Digest, Vol 36, Issue 17
Datum: 	Wed, 02 Jul 2008 15:06:50 -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: Further notes on 7.4 (Dan Nicholson)
   2. cairo with glitz vs Xrender (Mohan Parthasarathy)
   3. Re: ati-6.9.0 unstable dualhead (Simon Thum)


----------------------------------------------------------------------

Message: 1
Date: Wed, 2 Jul 2008 15:00:21 -0700
From: "Dan Nicholson" <dbn.lists at gmail.com>
Subject: Re: Further notes on 7.4
To: " R?mi Cardona " <remi at gentoo.org>
Cc: xorg at lists.freedesktop.org
Message-ID:
	<91705d080807021500i5ab3f858h331b3be812f74a97 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jul 2, 2008 at 8:11 AM, R?mi Cardona <remi at gentoo.org> wrote:
>
> Would it be advisable to tell all those packages to use only pkg-config,
> ie through a formal deprecation of the AC_PATH_X macros?

Fallback on AC_PATH_X and friends. It's pretty straightforward.
Without actually testing:

PKG_CHECK_EXISTS([x11],
    [PKG_CHECK_MODULES([X], [x11])],
    [AC_PATH_XTRA])

That would give you $X_CFLAGS and $X_LIBS in both cases. There'd
probably be a little more error checking, but that's the gist of it.

--
Dan


------------------------------

Message: 2
Date: Wed, 2 Jul 2008 15:02:03 -0700
From: "Mohan Parthasarathy" <suruti94 at gmail.com>
Subject: cairo with glitz vs Xrender
To: xorg at lists.freedesktop.org
Message-ID:
	<89dd3da60807021502m619443ecs6c9a7ebd0a10da5d at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

I understand that Cairo uses Xrender and on the server side EXA provides the
acceleration. I also see that
glitz, which is not actively developed any more, used GLX with OpenGL on the
server side for acceleration.
I am trying to understand as to whether one is better over the other. As we
already use the 3D driver on
the Xserver today for other purposes, it might be possible that we use that
instead of EXA.  I miss a lot
of history. So, can someone provide insight into this ?

thanks
mohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xorg/attachments/20080702/2a7da097/attachment-0001.htm 

------------------------------

Message: 3
Date: Thu, 03 Jul 2008 00:06:44 +0200
From: Simon Thum <simon.thum at gmx.de>
Subject: Re: ati-6.9.0 unstable dualhead
To: Alex Deucher <alexdeucher at gmail.com>
Cc: Sebastian Glita <glseba at yahoo.com>, xorg at lists.freedesktop.org
Message-ID: <486BFBF4.2000407 at gmx.de>
Content-Type: text/plain; charset="iso-8859-1"

Alex Deucher wrote:
> On Wed, Jul 2, 2008 at 4:47 PM, Simon Thum <simon.thum at gmx.de> wrote:
>> But 6.9 + 1.4.2 was worst yet. Impossible to use.
>>
> 
> Are you saying the xserver makes a difference?  One thing you might
No, that just happens to reflect day-to-day and development instances.

> for your monitor.  A lot of DVI monitors are pretty picky about the
> timings they like.  if you post your xorg log I'll take a look.  If
> you see differences between 6.8.191 and 6.8.192/6.9.0 let me know, as
> I made some changes to the pll code.
Saw that. FWIW, the first start with git ati .192 made my LCD do 
something I never saw: A box telling me that the mode needs to be below 
1280x1024/75 hz. However this was unreproduceable. Aside from that, it 
seems to work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 67556 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080703/b5f589f4/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.1.log
Type: text/x-log
Size: 33882 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080703/b5f589f4/attachment-0001.bin 

------------------------------

_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

End of xorg Digest, Vol 36, Issue 17
************************************




------------------------------

Message: 3
Date: Thu, 03 Jul 2008 11:27:51 +0200
From: Regina <regina.apel at gmx.de>
Subject: [Fwd: xorg Digest, Vol 36, Issue 18]
To: xorg at lists.freedesktop.org
Message-ID: <486C9B97.7050101 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed



-------- Original-Nachricht --------
Betreff: 	xorg Digest, Vol 36, Issue 18
Datum: 	Thu, 03 Jul 2008 02:04:22 -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: ati-6.9.0 unstable dualhead (Alex Deucher)
   2. Re: [mythtv-users] stuttering video in LiveTV with greedy2x
      and	yadif2x (Tino Keitel)
   3. Re: cairo with glitz vs Xrender (KAMALNEET SINGH)
   4. Re: synaptics touchpad. reconnect not supported (Steven J Newbury)
   5. Re: ati-6.9.0 unstable dualhead (Simon Thum)
   6. DWIM (was: Resolution indpendence) (olafBuddenhagen at gmx.net)
   7. Re: Resolution indpendence (olafBuddenhagen at gmx.net)
   8. How to build DRI2 with xorg-server 1.5? (Stefan Dirsch)


----------------------------------------------------------------------

Message: 1
Date: Wed, 2 Jul 2008 18:30:36 -0400
From: "Alex Deucher" <alexdeucher at gmail.com>
Subject: Re: ati-6.9.0 unstable dualhead
To: "Simon Thum" <simon.thum at gmx.de>
Cc: xorg at lists.freedesktop.org
Message-ID:
	<a728f9f90807021530x3b11a5ccmb886a0e09ed39011 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jul 2, 2008 at 6:06 PM, Simon Thum <simon.thum at gmx.de> wrote:
> Alex Deucher wrote:
>>
>> On Wed, Jul 2, 2008 at 4:47 PM, Simon Thum <simon.thum at gmx.de> wrote:
>>>
>>> But 6.9 + 1.4.2 was worst yet. Impossible to use.
>>>
>>
>> Are you saying the xserver makes a difference?  One thing you might
>
> No, that just happens to reflect day-to-day and development instances.
>
>> for your monitor.  A lot of DVI monitors are pretty picky about the
>> timings they like.  if you post your xorg log I'll take a look.  If
>> you see differences between 6.8.191 and 6.8.192/6.9.0 let me know, as
>> I made some changes to the pll code.
>
> Saw that. FWIW, the first start with git ati .192 made my LCD do something I
> never saw: A box telling me that the mode needs to be below 1280x1024/75 hz.
> However this was unreproduceable. Aside from that, it seems to work.
>

Are you saying it's working ok now?

Which log is which?  Does one version of the driver work better than
the other?  You'll notice they are each using different pll dividers:
Xorg.0.log is using:
freq: 108000000
best_freq: 108000000
best_feedback_div: 96
best_ref_div: 12
best_post_div: 2

while Xorg.1.log is using:
freq: 108000000
best_freq: 108000000
best_feedback_div: 16
best_ref_div: 2
best_post_div: 2

Alex


------------------------------

Message: 2
Date: Thu, 3 Jul 2008 00:11:26 +0200
From: Tino Keitel <tino.keitel+xorg at tikei.de>
Subject: Re: [mythtv-users] stuttering video in LiveTV with greedy2x
	and	yadif2x
To: xorg at lists.freedesktop.org
Message-ID: <20080702221126.GA2632 at x61>
Content-Type: text/plain; charset=us-ascii

Hi folks,

I had stuttering video in MythTV and now found the culprit. It seems to
be caused by a strange Xorg behaviour (or bug?). I set the refresh rate
to 60 Hz using xrandr --rate 60. However, if I check xvidtune, it still
shows 50 Hz. After running xrandr --rate 60 again, xvidtune shows 60
Hz.

And after running xrandr --rate 60 a second time, the stuttering video
doesn't seem to occur anymore.

I tried again and was able to reproduce that. Here is what I did:

$ xrandr --rate 50
$ xrandr --rate 50
$ xrandr -q | grep "  1024"
   1024x768       50.0*+   60.0     40.0

$ xvidtune -show
"1024x768"     54.16   1024 1048 1184 1344    768  771  777  806 -hsync -vsync

$ mythfrontend -> stutter happens

$ xrandr --rate 60
$ xrandr -q | grep "  1024"
   1024x768       50.0 +   60.0*    40.0
                           ^^^^^
                        reported 60 Hz
$ xvidtune -show
"1024x768"     54.16   1024 1048 1184 1344    768  771  777  806 -hsync -vsync
               ^^^^^
           but no real changes

$ mythfrontend -> stutter happens

$ xrandr --rate 60
$ xrandr -q | grep "  1024"
   1024x768       50.0 +   60.0*    40.0

$ xvidtune -show
"1024x768"     65.00   1024 1048 1184 1344    768  771  777  806 -hsync -vsync
               ^^^^^
        now it really changed

$ mythfrontend -> no stutter happens

I use Xorg server 1.4.2 and the Intel driver 2.3.2 on a i965GM chipset.

Regards,
Tino


------------------------------

Message: 3
Date: Thu, 03 Jul 2008 01:20:50 +0000 (GMT)
From: KAMALNEET SINGH <kamalneet.s at samsung.com>
Subject: Re: cairo with glitz vs Xrender
To: Mohan Parthasarathy <suruti94 at gmail.com>
Cc: "xorg at lists.freedesktop.org" <xorg at lists.freedesktop.org>
Message-ID: <7950059.509471215048050725.JavaMail.weblogic at epml06>
Content-Type: text/plain; charset=windows-1252

Mohan Parthasarathy wrote:
> Hi,
> 
> I understand that Cairo uses Xrender and on the server side EXA provides 
> the acceleration. I also see that
> glitz, which is not actively developed any more, used GLX with OpenGL on 
> the server side for acceleration.
> I am trying to understand as to whether one is better over the other. As 
> we already use the 3D driver on
> the Xserver today for other purposes, it might be possible that we use 
> that instead of EXA.  I miss a lot
> of history. So, can someone provide insight into this ?
> 

Also depends on where do you want to use it. On embedded, where you have
only ES version of OpenGL, it may be better to implement KAA/EXA instead
of porting glitz to OpenGL ES. And if hardware+drivers can run OpenVG
fast, OpenVG backend is a very compelling choice.

> thanks
> mohan

------------------------------

Message: 4
Date: Thu, 03 Jul 2008 03:09:20 +0100
From: Steven J Newbury <steve at snewbury.org.uk>
Subject: Re: synaptics touchpad. reconnect not supported
To: Nicol? Chieffo <84yelo3 at gmail.com>
Cc: xorg at lists.freedesktop.org
Message-ID:
	<1215050960.4710.4.camel at infinity.southview.snewbury.org.uk>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, 2008-07-02 at 13:19 +0200, Nicol? Chieffo wrote:
> Maybe I need some help, I'm not so expert in this stuff... I edited
> the fdi file and I copied it to
> /usr/share/hal/fdi/policy/20thirdparty/
> then I rebooted but the problem persists. Do I have to add some
> xorg.conf tweak? or the udev rule too?
> Thank you
Local fdi policy files should really go in /etc/hal/fdi/policy

You should have something in your X server log to show what's happening.




------------------------------

Message: 5
Date: Thu, 03 Jul 2008 08:34:18 +0200
From: Simon Thum <simon.thum at gmx.de>
Subject: Re: ati-6.9.0 unstable dualhead
To: Alex Deucher <alexdeucher at gmail.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <486C72EA.2040300 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Alex Deucher wrote:
> On Wed, Jul 2, 2008 at 6:06 PM, Simon Thum <simon.thum at gmx.de> wrote:
>> Alex Deucher wrote:
>> Saw that. FWIW, the first start with git ati .192 made my LCD do something I
>> never saw: A box telling me that the mode needs to be below 1280x1024/75 hz.
>> However this was unreproduceable. Aside from that, it seems to work.
>>
> 
> Are you saying it's working ok now?
Aside from a single failed startup *per server instance*, I must admit 
there isn't much to reproduce. In each it was the first time that 
horribly failed (and/or looked like earlier issues), since then it 
worked OK (for now).

The only thing I can imagine is check for something the PLL code might 
depend on, which would be persited or somehow randomly fails (though I'm 
yet to see a second failure). Sounds a bit like a memory hole to me, but 
really I'm out of ideas what it could have been.

So basically yes.

Regards,
Simon


------------------------------

Message: 6
Date: Wed, 2 Jul 2008 10:07:31 +0200
From: <olafBuddenhagen at gmx.net>
Subject: DWIM (was: Resolution indpendence)
To: xorg at lists.freedesktop.org
Message-ID: <20080702080727.GF1596 at alien.local>
Content-Type: text/plain; charset=us-ascii

Hi,

On Mon, Jun 30, 2008 at 09:05:12PM +0100, Glynn Clements wrote:

> The interface between software components needs to be rigid, but the
> interface between the computer and a human less so. Users are normally
> asking for more DWIM, not less.

Well, they are asking for that, but that doesn't mean that it really
helps when they get it... For my own view on this matter, see

   http://tri-ceps.blogspot.com/2008/06/smartass-software.html

-antrik-


------------------------------

Message: 7
Date: Thu, 3 Jul 2008 08:38:29 +0200
From: <olafBuddenhagen at gmx.net>
Subject: Re: Resolution indpendence
To: xorg at lists.freedesktop.org
Message-ID: <20080703063825.GG1596 at alien.local>
Content-Type: text/plain; charset=us-ascii

Hi,

On Fri, Jun 27, 2008 at 01:32:18PM -0400, Behdad Esfahbod wrote:

> There are two points of physical information:
> 
>   A) Dots per inch on the display surface (LCD panel, TV screen,
>   projector screen, The Wall, ...)
> 
>   B) Viewing distance
> 
> Those two are very real and can be measured.  If we have both, we can
> compute a third value:
> 
>   C) Normalized dpi / angular resolution / whatever you call it.
>   Physical dpi times viewing distance does the job.
> 
> 
> At the end, C is all the application developers care about.  That's
> why I suggest we redefine application DPIs to be that.
> 
> Next question is where to get A and B from.  A is already coming from
> X and EDID info and many devices have buggy values.  B is nonexistent.
> The solution to both is already there: HAL device info files.  These
> are small XML files setting A and a default value for B depending on
> the manufacturer and model of the display device.  The user can set
> both. This is just about defaults.

First of all, we do usually have two information points: Resolution and
display size. From these, I think we can make a pretty good guess at the
viewing distance/angular resolution -- no need for an enormous database.

The viewing distance normally depends mostly on the display size. For
anything from the size of a desktop monitor upwards, it should usually
be roughly proportional to the display size. For smaller displays, it
will obviously not be proportional, but rather approximate some minimum
realistic distance, say 25 cm or so.

The resolution also plays some role: With a higher resolution display we
will generally tend to get closer so we see better, while with a lower
resolution one there is no use so we won't.

Of course, this relation isn't linear either. With higher resolutions,
the display size becomes more dominant.

Note however that the viewing distance/angular resolution alone is not
really an ideal base. To determine the optimal effective resolution used
for size calculations, there are other factors to take into account.

For one, while I do not agree with Glynn that for today's typical
resolution it's *only* the pixel grid matters, it's certainly true that
with a better resolution, things remain legible at a slightly smaller
physical size. (And in fact subjectively look bigger than at a lower
resolution.) The truth is somewhere in between.

Also, with very small displays, we are usually ready to accept smaller
size even at the expense of some legibility, because, well, the display
being tiny, it just can't be helped...

The bottom line is that finding the effective resolution involves many
parameters, which all have nonlinear effects. Yet the result is a
relatively simple two parameter function on display size and resolution.
Starting with a number of data points found by experiment, it should be
possible to fit a function that pretty well models typical user's
expectations about effective resolution.

Now what to do with this effective resolution? I'm quite ambivalent
about the suggestion to redefine DPI. On one hand, it just feels wrong;
it must result in even more breakage and confusion... It surely would be
more elegant to change applications to explicitely use effective
resolution, or a scaling factor on top of the physical DPI.

>>>From a pragmatical point though it doesn't sound like a terribly bad
idea. The truth is that the "everthing is 96 DPI" hack is often
considered a good thing, because such a fixed resolution is actually
closer to the effective resolution than the physical resolution in many
important real-world use cases. (60" projector or large TV, tiny 200-300
DPI devices.)

It would still be a hack, but unlike the fixed resolution one, it would
actually take into account the true resolution -- in a manner that meets
users' expectations fairly well, unlike just scaling to the physical
resolution no matter what. It would Just Work (TM) with those
applications that already scale depending on DPI. I wonder how much
support this approach could gain?

Of course, this will break those few applications (dealing with print
documents) that actually care about the real physical size. As pointed
out by others, these applications will need to be adapted anyways to use
a special interface for querying the real physical resolution, because
of multihead... And also, it's much more realistic to adapt those few
apps rather than all the others. (Especially if for most practical
purposes the starting point is the 96 DPI hack, so with the current way
of handling things they don't really work in most cases anyways...)

-antrik-


------------------------------

Message: 8
Date: Thu, 3 Jul 2008 11:04:19 +0200
From: Stefan Dirsch <sndirsch at suse.de>
Subject: How to build DRI2 with xorg-server 1.5?
To: xorg at freedesktop.org
Message-ID: <20080703090419.GA16834 at suse.de>
Content-Type: text/plain; charset=iso-8859-15

Hi

Since I switched to libdrm 2.3.1 (official release) - which forced me
to current Mesa git (commit 6befdca, instead of Mesa 7.1 RC1) - I
cannot build DRI2 any longer with xorg-server 1.4.99.905. Build works
with "--disable-dri2". libdrm 2.3.1 and Mesa git (commit 6befdca) is
installed when I tried to build xorg-server.

Making all in dri2
make[4]: Entering directory `/usr/src/packages/BUILD/xorg-server-1.4.99.905/hw/xfree86/dri2'
/bin/sh ../../../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../include    -DHAVE_XORG_CONFIG_H -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 -I/usr/include/pixman-1     -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow  -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb  -DHAVE_XORG_CONFIG_H   -DXF86PM     -I/usr/include/drm -I../../../hw/xfree86/common -I../../../hw/xfree86/os-support/bus -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -g -fno-strict-aliasing -MT libdri2_la-dri2.lo -MD -MP -MF .deps/libdri2_la-dri2.Tpo -c -o libdri2_la-dri2.lo `test -f 'dri2.c' || echo './'`dri2.c
mkdir .libs
 gcc -DHAVE_CONFIG_H -I. -I../../../include -DHAVE_XORG_CONFIG_H -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 -I/usr/include/pixman-1 -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DHAVE_XORG_CONFIG_H -DXF86PM -I/usr/include/drm -I../../../hw/xfree86/common -I../../../hw/xfree86/os-support/bus -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -g -fno-strict-aliasing -MT libdri2_la-dri2.lo -MD -MP -MF .deps/libdri2_la-dri2.Tpo -c dri2.c  -fPIC -DPIC -o .libs/libdri2_la-dri2.o
dri2.c:60: error: expected specifier-qualifier-list before 'drmBO'
dri2.c: In function 'DRI2ScreenAllocEvent':
dri2.c:86: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:90: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:90: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:93: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:93: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:95: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:95: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:97: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:100: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:100: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:101: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c: In function 'DRI2ScreenCommitEvents':
dri2.c:109: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:109: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c: In function 'DRI2PostBufferAttach':
dri2.c:195: error: 'struct _DRI2Screen' has no member named 'getPixmapHandle'
dri2.c: In function 'DRI2ClipNotify':
dri2.c:217: error: 'struct _DRI2Screen' has no member named 'locked'
dri2.c:218: error: 'struct _DRI2Screen' has no member named 'beginClipNotify'
dri2.c:219: error: 'struct _DRI2Screen' has no member named 'locked'
dri2.c:222: error: 'struct _DRI2Screen' has no member named 'ClipNotify'
dri2.c:223: error: 'struct _DRI2Screen' has no member named 'ClipNotify'
dri2.c: In function 'DRI2HandleExposures':
dri2.c:238: error: 'struct _DRI2Screen' has no member named 'HandleExposures'
dri2.c:239: error: 'struct _DRI2Screen' has no member named 'HandleExposures'
dri2.c:246: error: 'struct _DRI2Screen' has no member named 'locked'
dri2.c:247: error: 'struct _DRI2Screen' has no member named 'endClipNotify'
dri2.c:248: error: 'struct _DRI2Screen' has no member named 'locked'
dri2.c: In function 'DRI2CloseScreen':
dri2.c:257: error: 'struct _DRI2Screen' has no member named 'ClipNotify'
dri2.c:258: error: 'struct _DRI2Screen' has no member named 'HandleExposures'
dri2.c:260: warning: implicit declaration of function 'drmBOUnmap'
dri2.c:260: warning: nested extern declaration of 'drmBOUnmap'
dri2.c:260: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c:261: warning: implicit declaration of function 'drmBOUnreference'
dri2.c:261: warning: nested extern declaration of 'drmBOUnreference'
dri2.c:261: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c: In function 'DRI2CreateDrawable':
dri2.c:295: error: 'struct _DRI2Screen' has no member named 'nextHandle'
dri2.c:300: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c: In function 'DRI2ReemitDrawableInfo':
dri2.c:344: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c: In function 'DRI2Connect':
dri2.c:361: error: 'struct _DRI2Screen' has no member named 'driverName'
dri2.c:362: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c: In function 'DRI2GetPixmapHandle':
dri2.c:383: error: 'struct _DRI2Screen' has no member named 'getPixmapHandle'
dri2.c: In function 'DRI2SetupSAREA':
dri2.c:393: error: 'struct _DRI2Screen' has no member named 'sareaSize'
dri2.c:394: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:398: error: 'DRM_BO_FLAG_READ' undeclared (first use in this function)
dri2.c:398: error: (Each undeclared identifier is reported only once
dri2.c:398: error: for each function it appears in.)
dri2.c:398: error: 'DRM_BO_FLAG_WRITE' undeclared (first use in this function)
dri2.c:398: error: 'DRM_BO_FLAG_MAPPABLE' undeclared (first use in this function)
dri2.c:399: error: 'DRM_BO_FLAG_MEM_LOCAL' undeclared (first use in this function)
dri2.c:399: error: 'DRM_BO_FLAG_SHAREABLE' undeclared (first use in this function)
dri2.c:401: warning: implicit declaration of function 'drmBOCreate'
dri2.c:401: warning: nested extern declaration of 'drmBOCreate'
dri2.c:401: error: 'struct _DRI2Screen' has no member named 'sareaSize'
dri2.c:401: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c:404: warning: implicit declaration of function 'drmBOMap'
dri2.c:404: warning: nested extern declaration of 'drmBOMap'
dri2.c:404: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c:405: error: 'struct _DRI2Screen' has no member named 'sarea'
dri2.c:406: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c:412: error: 'struct _DRI2Screen' has no member named 'sareaSize'
dri2.c:412: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c:413: error: 'struct _DRI2Screen' has no member named 'sarea'
dri2.c:413: error: 'struct _DRI2Screen' has no member named 'sareaSize'
dri2.c:415: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:415: error: 'struct _DRI2Screen' has no member named 'sarea'
dri2.c:416: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:417: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:419: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:421: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:421: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c: In function 'DRI2ScreenInit':
dri2.c:435: error: 'struct _DRI2Screen' has no member named 'driverName'
dri2.c:436: error: 'struct _DRI2Screen' has no member named 'nextHandle'
dri2.c:438: error: 'struct _DRI2Screen' has no member named 'getPixmapHandle'
dri2.c:439: error: 'struct _DRI2Screen' has no member named 'beginClipNotify'
dri2.c:440: error: 'struct _DRI2Screen' has no member named 'endClipNotify'
dri2.c:442: error: 'struct _DRI2Screen' has no member named 'ClipNotify'
dri2.c:444: error: 'struct _DRI2Screen' has no member named 'HandleExposures'
ICECC[21782] 21:12:38: Compiled on 10.11.0.140
make[4]: *** [libdri2_la-dri2.lo] Error 1
make[4]: Leaving directory `/usr/src/packages/BUILD/xorg-server-1.4.99.905/hw/xfree86/dri2'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/packages/BUILD/xorg-server-1.4.99.905/hw/xfree86'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/packages/BUILD/xorg-server-1.4.99.905/hw/xfree86'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/xorg-server-1.4.99.905/hw'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.87838 (%build)

Any hints? Which bits are missing/wrong this time?

Best regards,
Stefan

Public Key available
------------------------------------------------------
Stefan Dirsch (Res. & Dev.)   SUSE LINUX Products GmbH
Tel: 0911-740 53 0            Maxfeldstra?e 5
FAX: 0911-740 53 479          D-90409 N?rnberg
http://www.suse.de            Germany 
-----------------------------------------------------------------
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
-----------------------------------------------------------------


------------------------------

_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

End of xorg Digest, Vol 36, Issue 18
************************************





------------------------------

_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

End of xorg Digest, Vol 36, Issue 20
************************************






More information about the xorg mailing list