[Fwd: xorg Digest, Vol 36, Issue 1]
Regina
regina.apel at gmx.de
Thu Jul 3 02:34:00 PDT 2008
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 36, Issue 1
Datum: Tue, 01 Jul 2008 06:31:10 -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: [ANNOUNCE] xf86-video-nv 2.1.10 (Rene Rebe)
2. Re: [ANNOUNCE] xserver 1.4.99.905 (R?mi Cardona)
3. [announce] libdrm 2.3.1 (Dave Airlie)
4. RE: Max resolution of Intel Graphics Chipsets (Erwin Rol)
5. Re: Resolution indpendence (Eirik Byrkjeflot Anonsen)
6. Re: Resolution indpendence (Eirik Byrkjeflot Anonsen)
7. Re: Constant DPI regardless of resolution (Nicolas Mailhot)
8. Re: [ANNOUNCE] xf86-video-nv 2.1.10 (Kai-Uwe Behrmann)
9. Re: Further notes on 7.4 (Dan Nicholson)
10. Re: synaptics touchpad. reconnect not supported (Peter Hutterer)
----------------------------------------------------------------------
Message: 1
Date: Tue, 01 Jul 2008 09:01:48 +0200
From: Rene Rebe <rene at exactcode.de>
Subject: Re: [ANNOUNCE] xf86-video-nv 2.1.10
To: Aaron Plattner <aplattner at nvidia.com>
Cc: xorg-announce at lists.freedesktop.org, xorg at lists.freedesktop.org
Message-ID: <4869D65C.707 at exactcode.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
does still not survive a suspend/resume cycle on my GeForce 8600M GT,
MacBook Pro.
Any suggestions? Patches, or better register specs welcome :-)
Aaron Plattner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> This release adds chip names for the GeForce 9 mobile chips and the GeForce GTX
> GPUs. It also adds code to read DDC-based EDIDs for LVDS panels that have such
> a thing.
>
> - -- Aaron
>
>
> Aaron Plattner (9):
> GeForce 9 mobile chips.
> GeForce GTX 280 and 260 chip names.
> Replace copyright notices with stock MIT X11 boilerplate.
> Add new chips to the man page and fix capitalization of "Quadro".
> Add a note that MODE_PANEL really means "larger than BIOS-programmed panel size".
> G80: Handle extended I2C ports and LVDS panels with DDC-based EDIDs.
> Fix build by using CARD32 instead of uint32_t, like we do everywhere else.
> More G8x chips.
> Bump to 2.1.10.
>
> git tag: nv-2.1.10
>
> http://xorg.freedesktop.org/archive/individual/driver/xf86-video-nv-2.1.10.tar.bz2
> MD5: bbee6df3e66d31a7da1afda59b40777d xf86-video-nv-2.1.10.tar.bz2
> SHA1: 03545be9634a043b68438dae2a3266c41af60e7e xf86-video-nv-2.1.10.tar.bz2
>
> http://xorg.freedesktop.org/archive/individual/driver/xf86-video-nv-2.1.10.tar.gz
> MD5: 894fea928c2e2f548c28b9ff413a6cc6 xf86-video-nv-2.1.10.tar.gz
> SHA1: 7d412f87a4a2ee3d62719b71465fb62912aba5e1 xf86-video-nv-2.1.10.tar.gz
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJIaW82AAoJEHYgpP6LHaLQgc8H/0T7D37kqoGBpfxt7G2+oP+i
> pqBS6GqGhClabnxqfu7HG1BxoagB5stJ70+87M/IHO+JKyczgizQw3/KUkA25TgM
> Pv+4DrXOB5KpB/tBqfaXEb2JAZmjAiFPLQdGI39G9XiX5z83oMYxvmozhxFSmtE4
> IfEcxSHu/v1W7W1KOdadq1Bz6yoE2CFyNR3n8DVg2rMgu9cIdvwDBBFSsLewehYB
> 6czQ5065HAHONtfLWV+zPCygzeUClO0iwfQuLOVWArPhW05p2cF0HE1KAs/zQBc/
> FRCxu1Kew2gcVRJ+0b74HK7kxzAxO07DpfTxukSqTtC7YG7TAR+vx9OXKCXfeEE=
> =eMKb
> -----END PGP SIGNATURE-----
--
Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
------------------------------
Message: 2
Date: Tue, 01 Jul 2008 09:42:16 +0200
From: R?mi Cardona <remi at gentoo.org>
Subject: Re: [ANNOUNCE] xserver 1.4.99.905
To: xorg at lists.freedesktop.org
Message-ID: <4869DFD8.1050106 at gentoo.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Adam Jackson a ?crit :
> git tag: xorg-server-1.4.99.905
I think you forgot to push the tag.
Cheers :)
--
R?mi Cardona
LRI, INRIA
remi.cardona at lri.fr
remi at gentoo.org
------------------------------
Message: 3
Date: Tue, 1 Jul 2008 18:09:14 +1000
From: "Dave Airlie" <airlied at gmail.com>
Subject: [announce] libdrm 2.3.1
To: "xorg announce" <xorg-announce at lists.freedesktop.org>, xorg
<xorg at lists.freedesktop.org>, dri-devel
<dri-devel at lists.sourceforge.net>
Message-ID:
<21d7e9970807010109l1afb0361ncec0aab0515c736e at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Update libdrm to 2.3.1.
include new APIs for Mesa 7.1 and Xorg 1.5 to build against.
This doesn't include any TTM or GEM apis yet.
http://dri.freedesktop.org/libdrm/libdrm-2.3.1.tar.gz
MD5: 19c0a11aad1eaf3966120bdf11277efa libdrm-2.3.1.tar.gz
SHA1: 007903c738df3bc2a3cdab0289635baa95a2ed7a libdrm-2.3.1.tar.gz
http://dri.freedesktop.org/libdrm/libdrm-2.3.1.tar.bz2
MD5: 620fe7dd02c3236c3e9881a3a238173d libdrm-2.3.1.tar.bz2
SHA1: 775dc69fcabb324552b0b9fe3a67eceb324be194 libdrm-2.3.1.tar.bz2
I'd include a real changelog but really..
Dave Airlie:
Stuff changed - you need this for Mesa 7.1, and Xorg 1.5
Deal with it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkhp5WQACgkQ6acWQe8WxxpOWACgmoSLWVxiuWMNn1agjJMI0yzg
hFMAmwbKarSVBYNKkmSe5l0iW+wtvQar
=Rput
-----END PGP SIGNATURE-----
------------------------------
Message: 4
Date: Tue, 01 Jul 2008 10:30:44 +0200
From: Erwin Rol <mailinglists at erwinrol.com>
Subject: RE: Max resolution of Intel Graphics Chipsets
To: "Jin, Gordon" <gordon.jin at intel.com>
Cc: xorg <xorg at lists.freedesktop.org>
Message-ID: <1214901044.20839.82.camel at eir.home.erwinrol.com>
Content-Type: text/plain
On Tue, 2008-07-01 at 11:12 +0800, Jin, Gordon wrote:
> Erwin Rol wrote on Tuesday, July 01, 2008 7:55 AM:
> > On Tue, 2008-07-01 at 01:26 +0200, Tomas Carnecky wrote:
> >> Erwin Rol wrote:
> >>> Hello all,
> >>>
> >>> I am looking for a solution where I can connect two TFT's of
> >>> 1440x900, and display different images on those TFT's.
> >>>
> >>> Most Intel chipsets support two independent outputs, but it seems
> >>> that the internal framebuffer is the limiting factor here. I would
> >>> need 2880x900 or 1440x1800 (the layout is not important).
> >>>
> >>> For example, do I understand correct that for example the Intel 915
> >>> chipset does support two outputs of 1440x900 (or even larger), but
> >>> that the internal framebuffer only can be 2048x1536?
> >>>
> >>> I checked several Intel chipsets and they all seem to be "limited"
> >>> to 2048x1536. Are there Intel chipsets that can do for example
> >>> 2048x2048, so it can fit a 1440x1800 resolution?
> >>
> >> $ xrandr
> >> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 4096 x
> >> 1440 ...
> >>
> >
> > Weird the datasheet mentions a maximum resolution of ;
> > - Supports flat panels up to 2048x1536 @ 60 Hz or digital CRT/HDTV at
> > 1920x1080 @ 85 Hz
>
> This is talking about one output, not frame buffer.
>
> The framebuffer 2048x2048 can work on your 915. If you need larger frame
> buffer AND 3d (dri), you need 965.
> For this limitation, see
> https://bugs.freedesktop.org/show_bug.cgi?id=10479.
>
> -Gordon
Everybody thanks for the help, the i915 should do fine for my
application.
- Erwin
------------------------------
Message: 5
Date: Tue, 01 Jul 2008 10:35:47 +0200
From: Eirik Byrkjeflot Anonsen <eirik at opera.com>
Subject: Re: Resolution indpendence
To: xorg at lists.freedesktop.org
Message-ID: <87tzfat318.fsf at opera.com>
Content-Type: text/plain; charset=utf-8
Steven J Newbury <steve at snewbury.org.uk> writes:
> On Mon, 2008-06-30 at 15:29 +0200, Eirik Byrkjeflot Anonsen wrote:
>> David De La Harpe Golden <david.delaharpe.golden at gmail.com> writes:
>>
>> > Nicolas Mailhot wrote:
>> >
>> >> (That's discounting all the people that disagree with your "unless
>> >> it's 300+dpi there's nothing to do" stance)
>> >>
>> >
>> > Of course, RGB subpixels of a 100DPI color display are already 300DPI in
>> > one axis.
>>
>> Which doesn't really help, since all the subpixel anti-aliasing I've
>> seen looks horrible.
> ?Then the pixel order was incorrect in the cases you've seen.
No, the other pixel order(s) looked far worse. (I've spent quite some
time experimenting with this. Both on windows and on linux).
>
>> The only good thing I can say about it is that
>> it makes windows at least stop horribly deforming the glyphs.
> As far as I know Windows relies on the bytecode in cleartype fonts to
> perform the hinting, so it depends on the quality of the font. Somebody
> correct me if I'm wrong.
Maybe. Or maybe they're running a final pass with a strong
auto-hinter to eliminate as much grays as possible. Anyway, the end
result is that turning off sub-pixel anti-aliasing makes windows
horribly deform the glyphs. Some people think that's a feature. I
tend to disagree.
eirik
------------------------------
Message: 6
Date: Tue, 01 Jul 2008 10:54:58 +0200
From: Eirik Byrkjeflot Anonsen <eirik at opera.com>
Subject: Re: Resolution indpendence
To: xorg at lists.freedesktop.org
Message-ID: <87prpyt259.fsf at opera.com>
Content-Type: text/plain; charset=us-ascii
David De La Harpe Golden <david.delaharpe.golden at gmail.com> writes:
> David De La Harpe Golden wrote:
>
[...]
> But wait! in principle that the 2D folder bitmap image need not have
> been a bitmap image - the primary reason it's clearer at low res is
> because it's less "busy", not because it's a bitmap. An alternative
> _vector_ icon in 2D style could have been supplied for the lores
> display, that could essentially match the 16x16 icon for clarity
> (especially given hinting...), AND would have the advantage of rendering
> at 15x15, 17x17, 18x18 and so on.
That's a simple application of nyquist. Features smaller than 2
pixels can not be accurately represented (under the standard
assumptions of regular grid and no grid-fitting, of course).
eirik
------------------------------
Message: 7
Date: Tue, 1 Jul 2008 11:38:16 +0200 (CEST)
From: "Nicolas Mailhot" <nicolas.mailhot at laposte.net>
Subject: Re: Constant DPI regardless of resolution
To: "Nikos Chantziaras" <realnc at arcor.de>
Cc: xorg at freedesktop.org
Message-ID:
<14184.192.54.193.59.1214905096.squirrel at rousalka.dyndns.org>
Content-Type: text/plain;charset=utf-8
Le Mar 1 juillet 2008 05:10, Nikos Chantziaras a ?crit :
>
> David De La Harpe Golden wrote:
>> Nikos Chantziaras wrote:
>>
>>> The DPI does not change (only the resolution changes.)
>>
>> Terminology: DPI measures the resolution...
>
> Sorry, I should have clarified; with "resolution" I mean the width and
> height of the picture in pixels. Changing those on a DFP that always
> operates at a fixed native resolution won't change the DPI value
The DPI you see in software in the DPI it controls. Any auto-scaling
done by the hardware behind its back is beyond the software control.
What you really want with a DFP is to always operate it at native
resolution without this kind of scaling, which requires for the
software ot be able to adapt to this resolution (whatever it is)
without trying to force bogus values such as 96dpi.
As you noted forcing a fixed dpi value regardless of hardware
capabilities has a scaling effect that depends on the hardware real
dpi, and is not guaranteed to be what the user wanted.
Redards,
--
Nicolas Mailhot
------------------------------
Message: 8
Date: Tue, 1 Jul 2008 13:43:15 +0200 (CEST)
From: Kai-Uwe Behrmann <ku.b at gmx.de>
Subject: Re: [ANNOUNCE] xf86-video-nv 2.1.10
To: Aaron Plattner <aplattner at nvidia.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <Pine.LNX.4.64.0807011338020.6260 at sirius.rasena>
Content-Type: TEXT/PLAIN; charset=US-ASCII
This version builds here without trouble for xorg7.2. Dualhead basically
works and at least one LCD EDID is visible.
xrandr can not differenciate the attached two monitors.
Xinerama seems dead, as placement is like on one big device.
Do I need to set some special Options?
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org
Am 30.06.08, 16:41 -0700 schrieb Aaron Plattner:
> This release adds chip names for the GeForce 9 mobile chips and the GeForce GTX
> GPUs. It also adds code to read DDC-based EDIDs for LVDS panels that have such
> a thing.
------------------------------
Message: 9
Date: Tue, 1 Jul 2008 05:58:50 -0700
From: "Dan Nicholson" <dbn.lists at gmail.com>
Subject: Re: Further notes on 7.4
To: "Alan Coopersmith" <Alan.Coopersmith at sun.com>
Cc: xorg at lists.freedesktop.org
Message-ID:
<91705d080807010558oa6d1db1t6dd756b4866e5263 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jun 30, 2008 at 7:34 PM, Alan Coopersmith
<Alan.Coopersmith at sun.com> wrote:
> Brian Paul wrote:
>> I don't recall other C compilers having a dependency generator option
>> like gcc.
>
> Sun cc does - we had a script form of makedepend that wrapped it in the past,
> much like the old gccmakedep script.
Is there any online documentation for Sun cc? I got this mostly
working with gcc last night. Actually, looking at automake, it seems
this is pretty common in compilers.
--
Dan
------------------------------
Message: 10
Date: Tue, 1 Jul 2008 23:00:59 +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: <20080701133059.GA7161 at emu>
Content-Type: text/plain; charset=iso-8859-1
On Mon, Jun 30, 2008 at 04:26:25PM +0200, Nicol? Chieffo wrote:
> I have a laptop that has a problem with the touchpad: if hitting a key
> combination the synaptics touchpad loses the synchronization and it
> reconnects.
> this is the log output in kern.log:
>
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPadat isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: issuing reconnect request
> Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1a0b1, caps: 0xa04713/0x200000
> input: SynPS/2 Synaptics TouchPad as /class/input/input19
>
> The windows driver is smarter, and can handle device disconnections,
> while the synaptics xorg driver (I have version 0.14.6) once the
> device is disconnected, it treats it as a normal mouse after the
> reconnection (no scroll, different acceleration, no finger
> combinations,...)
what server version are you running?
could be that on reconnect the touchpad is actually connected through evdev,
which would deprive you of all synaptics features.
Cheers,
Peter
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 36, Issue 1
***********************************
More information about the xorg
mailing list