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

[Regina <regina.apel@xxxxxx>]

-------- Original-Nachricht --------
Betreff: 	xorg Digest, Vol 36, Issue 16
Datum: 	Wed, 02 Jul 2008 14:58:57 -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 (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@xxxxxx>
Subject: Re: Further notes on 7.4
To: xorg@xxxxxxxxxxxxxxx
Message-ID: <slrng6nqbo.2ci.tuomov@xxxxxxxxxxxxxxxxxxxxxx>

On 2008-06-30, Daniel Stone <daniel@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
Subject: Re: Further notes on 7.4
To: Tuomo Valkonen <tuomov@xxxxxx>
Cc: xorg@xxxxxxxxxxxxxxx
Message-ID: <20080702210217.GA3272@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx> 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@xxxxxxxxx>
Subject: Re: ati-6.9.0 unstable dualhead
To: "Simon Thum" <simon.thum@xxxxxx>
Cc: Sebastian Glita <glseba@xxxxxxxxx>, xorg@xxxxxxxxxxxxxxxxxxxxx
Message-ID:
	<a728f9f90807021422h6ba0f174r8e82c9215b710b1@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jul 2, 2008 at 4:47 PM, Simon Thum <simon.thum@xxxxxx> 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@xxxxxxxx>
Subject: Re: Further notes on 7.4
To: Tuomo Valkonen <tuomov@xxxxxx>
Cc: xorg@xxxxxxxxxxxxxxx
Message-ID: <1215035516.24769.231.camel@xxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain

On Wed, 2008-07-02 at 20:47 +0000, Tuomo Valkonen wrote:
> On 2008-06-30, Daniel Stone <daniel@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx>
Subject: Re: Patch to not fork/exec xkbcomp on X Server initialization
To: Daniel Stone <daniel@xxxxxxxxxxxxx>, 	Peter Hutterer
	<peter.hutterer@xxxxxxxxx>, xorg@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <486BF462.10300@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/xorg

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


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