Re: [Xpert]Resize and Rotate extension progress report

2002-09-24 Thread Achim Bohnet

On Tuesday 24 September 2002 04:25, Keith Packard wrote:
 Around 19 o'clock on Sep 23, Andy Isaacson wrote:
 
  I just plain don't understand why PseudoColor emulation has to be so
  expensive.  Can't you just do it in the same manner as the ShadowFB
  layer, whereby the screen representation is updated only every 10 ms or
  whatever? 
 
 Yes, that's the usual implementation (although there are others).  The 
 problem is applications expect that updates to the colormap are cheap, 
 but sending the entire frame buffer over the AGP bus is quite expensive,
 as you say, optimizations are possible, but it takes some clever code to 
 take advantage of any kind of pipelining on the AGP bus while skipping the 
 large unmodified parts of the screen.
 
 One thought I just had was that Xlib/Xnest style hacks could give every 
 client a private colormap.  This would limit the damage to that clients 
 windows instead of forcing a scan of the whole screen.
 
 The RandR question remains though -- if this approach is sufficient to 
 resolve the needs of 80% of the clients, is the ability to swap which 
 visuals are mapped directly to the hardware interesting enough to spend 
 significant effort on in the near future?  Or should we just leave RandR 
 as the resize/rotate extension and leave hardware visual swaps for some 
 future extension if we ever need it ?

Hello Keith,

FWIF:  resize is the most needed/requested feature here since laptops
are more and more common. rotate is nice to have.  Visual and
depth switching would be helpful in some cases, but unitl it is
be implemented the old hardware will be replaced with new one ;)

Achim

Achim
 
 Keith PackardXFree86 Core TeamHP Cambridge Research Lab
 
 
 ___
 Xpert mailing list
 [EMAIL PROTECTED]
 http://XFree86.Org/mailman/listinfo/xpert
 
 

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert



[Xpert]Radeon 7500 with 1600x1200 via DVI offset problem/bug

2002-04-10 Thread Achim Bohnet

Hello Xperts,

we'll try to get an Radeon 7500 + 19'' 1600x1200 TFT via DVI working
but fail so far (Redhat i386 Linux 7.2 + rawhide XFree 4.2.0 rpms from
1-Apr: *-4.2.0-6.52).

VGA connectior works but TFT is hard/impossible to sync with the gfx card
signal.

Best DVI result is with

Option  NoDDC
Option  PanelSize 1600x1200

Without NoDDC screen is simply black and the OSM shows a sync to 720x400@70Hz.
Without PanelSize option Radeon driver insists that resolution bigger than
1024x768 are not possible.

With PanelSize 1600x1200 and NoDDC the resolutions of 1600x1200 and 1024x768
via DVI behave like:

Xreturn gives a screen with the lower ~ 16.5 cm okay but the upper
~ 19.5 cm flicker like hell.   Further there's a ghost image of the
mouse cursor:  If the mouse cursor is at the bottom the ghost cursor
is at the border of the  non- and flicker area (only the upper half
of the cross is visible just as for the real mouse cursor).  The
host cursor is always ~ 18 cm to the right and ~ 16.5 cm above the
real cursor.

Without panelsize the resolution 1024x768 is correctly displayed as
perfect as possible on a 1600x1200 TFT panel ;)

Appended are the config and log log files, one with NoDDC and one
without NoDDC.

Do we miss another options?  Driver bug?

Thx,
Achim
-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
  -- [EMAIL PROTECTED]


XF86Config-4.gz
Description: GNU Zip compressed data


XFree86.0.log.ddc.gz
Description: GNU Zip compressed data


XFree86.0.log.noddc.gz
Description: GNU Zip compressed data