[Fwd: xorg Digest, Vol 36, Issue 1] | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
-------- Original-Nachricht -------- Betreff: xorg Digest, Vol 36, Issue 1 Datum: Tue, 01 Jul 2008 06:31:10 -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: [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@xxxxxxxxxxxx> Subject: Re: [ANNOUNCE] xf86-video-nv 2.1.10 To: Aaron Plattner <aplattner@xxxxxxxxxx> Cc: xorg-announce@xxxxxxxxxxxxxxxxxxxxx, xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <4869D65C.707@xxxxxxxxxxxx> 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@xxxxxxxxxx> Subject: Re: [ANNOUNCE] xserver 1.4.99.905 To: xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <4869DFD8.1050106@xxxxxxxxxx> 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@xxxxxx remi@xxxxxxxxxx ------------------------------ Message: 3 Date: Tue, 1 Jul 2008 18:09:14 +1000 From: "Dave Airlie" <airlied@xxxxxxxxx> Subject: [announce] libdrm 2.3.1 To: "xorg announce" <xorg-announce@xxxxxxxxxxxxxxxxxxxxx>, xorg <xorg@xxxxxxxxxxxxxxxxxxxxx>, dri-devel <dri-devel@xxxxxxxxxxxxxxxxxxxxx> Message-ID: <21d7e9970807010109l1afb0361ncec0aab0515c736e@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> Subject: RE: Max resolution of Intel Graphics Chipsets To: "Jin, Gordon" <gordon.jin@xxxxxxxxx> Cc: xorg <xorg@xxxxxxxxxxxxxxxxxxxxx> Message-ID: <1214901044.20839.82.camel@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> Subject: Re: Resolution indpendence To: xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <87tzfat318.fsf@xxxxxxxxx> Content-Type: text/plain; charset=utf-8 Steven J Newbury <steve@xxxxxxxxxxxxxxx> writes: > On Mon, 2008-06-30 at 15:29 +0200, Eirik Byrkjeflot Anonsen wrote: >> David De La Harpe Golden <david.delaharpe.golden@xxxxxxxxx> 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@xxxxxxxxx> Subject: Re: Resolution indpendence To: xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <87prpyt259.fsf@xxxxxxxxx> Content-Type: text/plain; charset=us-ascii David De La Harpe Golden <david.delaharpe.golden@xxxxxxxxx> 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@xxxxxxxxxxx> Subject: Re: Constant DPI regardless of resolution To: "Nikos Chantziaras" <realnc@xxxxxxxx> Cc: xorg@xxxxxxxxxxxxxxx Message-ID: <14184.192.54.193.59.1214905096.squirrel@xxxxxxxxxxxxxxxxxxx> 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@xxxxxx> Subject: Re: [ANNOUNCE] xf86-video-nv 2.1.10 To: Aaron Plattner <aplattner@xxxxxxxxxx> Cc: xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <Pine.LNX.4.64.0807011338020.6260@xxxxxxxxxxxxx> 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@xxxxxxxxx> Subject: Re: Further notes on 7.4 To: "Alan Coopersmith" <Alan.Coopersmith@xxxxxxx> Cc: xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <91705d080807010558oa6d1db1t6dd756b4866e5263@xxxxxxxxxxxxxx> Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 30, 2008 at 7:34 PM, Alan Coopersmith <Alan.Coopersmith@xxxxxxx> 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@xxxxxxxxx> Subject: Re: synaptics touchpad. reconnect not supported To: Nicol? Chieffo <84yelo3@xxxxxxxxx> Cc: xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <20080701133059.GA7161@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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/xorg End of xorg Digest, Vol 36, Issue 1 *********************************** _______________________________________________ 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]