[Fwd: xorg Digest, Vol 36, Issue 26]
Regina
regina.apel at gmx.de
Thu Jul 3 02:52:21 PDT 2008
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 36, Issue 26
Datum: Thu, 03 Jul 2008 02:34:05 -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 35, Issue 129] (Regina)
2. [Fwd: xorg Digest, Vol 36, Issue 1] (Regina)
----------------------------------------------------------------------
Message: 1
Date: Thu, 03 Jul 2008 11:33:12 +0200
From: Regina <regina.apel at gmx.de>
Subject: [Fwd: xorg Digest, Vol 35, Issue 129]
To: xorg at lists.freedesktop.org
Message-ID: <486C9CD8.5070604 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 35, Issue 129
Datum: Mon, 30 Jun 2008 23:58:00 -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: Constant DPI regardless of resolution
(David De La Harpe Golden)
2. Re: Constant DPI regardless of resolution (Nikos Chantziaras)
3. RE: Max resolution of Intel Graphics Chipsets (Jin, Gordon)
4. Re: Resolution indpendence (David De La Harpe Golden)
5. per-device xkb rules? (Mikhail Gusarov)
6. Re: Constant DPI regardless of resolution
(David De La Harpe Golden)
7. Re: Constant DPI regardless of resolution (Keith Packard)
8. Re: per-device xkb rules? (Peter Hutterer)
9. Re: the OLPC XO grab button (triggering mouse scrolling using
a keypress) (Peter Hutterer)
----------------------------------------------------------------------
Message: 1
Date: Tue, 01 Jul 2008 03:54:32 +0100
From: David De La Harpe Golden <david.delaharpe.golden at gmail.com>
Subject: Re: Constant DPI regardless of resolution
To: Nikos Chantziaras <realnc at arcor.de>
Cc: xorg at freedesktop.org
Message-ID: <48699C68.30207 at googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1
Nikos Chantziaras wrote:
> The DPI does not change (only the resolution changes.)
Terminology: DPI measures the resolution...
> If there is a way, how can I force a constant DPI regardless of resolution?
AFAIK the xrandr command line tool should allow you to override with
--dpi , given xrandr 1.2, if you use it for mode changing rather than
the GUI tools.
If you're using nvidia at the moment you may not be able to do this,
I dunno.
------------------------------
Message: 2
Date: Tue, 01 Jul 2008 06:10:05 +0300
From: Nikos Chantziaras <realnc at arcor.de>
Subject: Re: Constant DPI regardless of resolution
To: xorg at freedesktop.org
Message-ID: <g4c76h$ali$1 at ger.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
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 (for
example when changing from 1280x1024 to 1024x768 the picture gets
smaller which means that the resolution actually stays the same; it's
still 1280x1024 but with black borders around a central picture of size
1024x768).
>> If there is a way, how can I force a constant DPI regardless of resolution?
>
> AFAIK the xrandr command line tool should allow you to override with
> --dpi , given xrandr 1.2, if you use it for mode changing rather than
> the GUI tools.
>
> If you're using nvidia at the moment you may not be able to do this,
> I dunno.
I'm on VESA for running natively and xf86-vmware for running in a VM. I
was hoping for a "set and forget" option either in xorg's arguments or
xorg.conf rather than having to open the CLI and call xrandr each time I
switch resolution.
------------------------------
Message: 3
Date: Tue, 1 Jul 2008 11:12:06 +0800
From: "Jin, Gordon" <gordon.jin at intel.com>
Subject: RE: Max resolution of Intel Graphics Chipsets
To: "Erwin Rol" <mailinglists at erwinrol.com>, "Tomas Carnecky"
<tom at dbservice.com>
Cc: xorg <xorg at lists.freedesktop.org>
Message-ID:
<70F95043FD1E5B40B3872B8784B9EB75017A34C0 at pdsmsx414.ccr.corp.intel.com>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
Message: 4
Date: Tue, 01 Jul 2008 05:00:04 +0100
From: David De La Harpe Golden <david.delaharpe.golden at gmail.com>
Subject: Re: Resolution indpendence
To: Steven J Newbury <steve at snewbury.org.uk>
Cc: Glynn Clements <glynn at gclements.plus.com>,
xorg at lists.freedesktop.org
Message-ID: <4869ABC4.6020205 at googlemail.com>
Content-Type: text/plain; charset="iso-8859-1"
David De La Harpe Golden wrote:
> I'd say that would depend on the how "busy" the vector icon is and the
> quality of the renderer. It's certainly _possible_
Attached please find (not sure it'll get through to the list)
folder_html16x16i.png - 16x16 *untweaked* .png export from inkscape of
the well-known crystal [1] theme html-folder .svg icon. Not a complete
blur.
folder_html16x16s.png - 16x6 from a 32x33 [source svg not quite square I
guess] export from inkscape passed through sublcd for some simple
subpixel improvement (for viewing on usual horiz. rgb-order lcd screen).
Quite noticeably better than the non-subpixel one.
folder_html16x16t.png - 16x16 from a 256x261 export from inkscape,
contrast-boosted in gimp by 10 whatever-the-heck-the-gimp-units-mean
then resized with gimp to 32x33, then passed through sublcd.
I'd be willing to concede that the more stylised 2D folder bitmap image
(as IIRC actually used in the crystal theme at 16x16 ish, visible in
[1]) is clearer from a UI perspective than any of those naively scaled
icons, but the attached files aren't _terrible_.
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.
(Hmm. even on a hi-res display, people's unaided visual system has
limits. So the less "busy" icon might still be preferred below a
certain _physical_ size [and viewing distance of course] too.)
[1]
http://www.kde-look.org/content/preview.php?preview=2&id=8341&file1=8341-1.jpg&file2=8341-2.jpg&file3=8341-3.jpg&name=Crystal+SVG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: folder_html16x16i.png
Type: image/png
Size: 875 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080701/d4dd7874/attachment-0003.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: folder_html16x16s.png
Type: image/png
Size: 762 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080701/d4dd7874/attachment-0004.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: folder_html16x16t.png
Type: image/png
Size: 751 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080701/d4dd7874/attachment-0005.png
------------------------------
Message: 5
Date: Tue, 01 Jul 2008 11:08:07 +0700
From: Mikhail Gusarov <dottedmag at dottedmag.net>
Subject: per-device xkb rules?
To: xorg at freedesktop.org
Message-ID: <8763rqdz6g.fsf at frontier.dottedmag.net>
Content-Type: text/plain; charset="us-ascii"
Hello.
Is it possible to have xkb configuration on the per-device level?
I used to keep all per-keyboard quirks I like (remapping
Ctrl/Option/Command -> Ctrl/Win/Alt on Apple keyboard, moving ~ and
russian 'io' to the proper place, not the one decided by keyboard
manufacturer etc), but with more than one keyboard regularely
attached/detached it became a burden.
Or maybe this is inapropriate level for such manipulations? Where do
they belong then?
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080701/edc6656b/attachment-0001.pgp
------------------------------
Message: 6
Date: Tue, 01 Jul 2008 06:40:50 +0100
From: David De La Harpe Golden <david.delaharpe.golden at gmail.com>
Subject: Re: Constant DPI regardless of resolution
To: Nikos Chantziaras <realnc at arcor.de>
Cc: xorg at freedesktop.org
Message-ID: <4869C362.7050801 at googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1
Nikos Chantziaras wrote:
> I'm on VESA for running natively and xf86-vmware for running in a VM. I
> was hoping for a "set and forget" option either in xorg's arguments or
> xorg.conf rather than having to open the CLI and call xrandr each time I
> switch resolution.
(I don't know enough about X.org to know if there's any such
option lurking, anyway...)
Workaround suggestion: command line tools can be wrapped very
easily indeed with tcl/tk to give a throwaway GUI tool (e.g.
wish script below!).
Maybe a feature request to an existing nicer xrandr gui tool
like krandrtray is a better long term option, of course -
there are quite a lot of devices with the behaviour you described.
(On unix/linux, once something has a command line interface, it
can typically have a minimal gui flung together for it in minutes.
tcl/tk is not necessarily pretty, but it works. Though
to be fair, tk recently had a makeover (8.5 uses nonsucky font
drawing on linux), and can be used with quite a few languages
besides tcl.)
#!/usr/bin/wish
set dpi "86"
set pxsizes { "1280x1024" "1024x768" "640x480" }
foreach pxsize $pxsizes {
button .$pxsize -text $pxsize \
-command "exec xrandr -s $pxsize --dpi $dpi ; exit"
pack .$pxsize
}
------------------------------
Message: 7
Date: Mon, 30 Jun 2008 22:53:17 -0700
From: Keith Packard <keithp at keithp.com>
Subject: Re: Constant DPI regardless of resolution
To: Nikos Chantziaras <realnc at arcor.de>
Cc: xorg at freedesktop.org
Message-ID: <1214891597.4285.127.camel at koto.keithp.com>
Content-Type: text/plain; charset="us-ascii"
On Tue, 2008-07-01 at 06:10 +0300, Nikos Chantziaras wrote:
> I'm on VESA for running natively and xf86-vmware for running in a VM. I
> was hoping for a "set and forget" option either in xorg's arguments or
> xorg.conf rather than having to open the CLI and call xrandr each time I
> switch resolution.
RandR 1.2 passes the physical screen size from the client to the X
server whenever the pixel size is set. If you want to fix the DPI,
you'll need to fix whatever tool you use that sets the screen size.
--
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080630/91636b6d/attachment-0001.pgp
------------------------------
Message: 8
Date: Tue, 1 Jul 2008 16:07:11 +0930
From: Peter Hutterer <peter.hutterer at who-t.net>
Subject: Re: per-device xkb rules?
To: Mikhail Gusarov <dottedmag at dottedmag.net>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080701063711.GB9371 at emu>
Content-Type: text/plain; charset=us-ascii
On Tue, Jul 01, 2008 at 11:08:07AM +0700, Mikhail Gusarov wrote:
> Is it possible to have xkb configuration on the per-device level?
yes.
setxkbmap -device for run-time manipulation, otherwise if you're using the
evdev driver + hotplug, you can adjust hal's fdi file to merge the appropriate
xkb options depending on.. well, whatever. the server just picks it up then.
Cheers,
Peter
------------------------------
Message: 9
Date: Tue, 1 Jul 2008 15:52:09 +0930
From: Peter Hutterer <peter.hutterer at who-t.net>
Subject: Re: the OLPC XO grab button (triggering mouse scrolling using
a keypress)
To: Erik Garrison <erik at laptop.org>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080701062209.GA9371 at emu>
Content-Type: text/plain; charset=us-ascii
On Mon, Jun 30, 2008 at 07:35:16PM -0400, Erik Garrison wrote:
> The keyboard has two buttons which are marked with a hand. The
> interested may see a schematic at
> http://wiki.laptop.org/go/OLPC_Keyboard_layouts. It was intended at
> design time that pressing either of these buttons (Super_L and Super_R)
> and simultaneously moving the mouse would trigger x and y scrolling in
> X11 applications.
>
> I'm curious if anyone knows of ways in which similar functionality has
> been implemented elsewhere. In general I'd like some advice about the
> best place to implement this feature.
Just put a passive grab on the keys to receive the key press event and then,
depending on what you mean by scrolling:
- mouse wheel emulation
put a (sync) grab on the mouse and use XTestFakeButtonEvent on buttons
4/5/6/7 for to scroll. you'll need to mess around a bit with XAllowEvents,
but it should work.
- viewport scrolling
XWarpPointer seems the only way, I don't see any other callers for
xf86SetViewport that could be used directly.
Cheers,
Peter
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 35, Issue 129
*************************************
------------------------------
Message: 2
Date: Thu, 03 Jul 2008 11:34:00 +0200
From: Regina <regina.apel at gmx.de>
Subject: [Fwd: xorg Digest, Vol 36, Issue 1]
To: xorg at lists.freedesktop.org
Message-ID: <486C9D08.9000203 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
-------- 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
***********************************
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 36, Issue 26
************************************
More information about the xorg
mailing list