NetBSD Problem Report #6973

Received: (qmail 6123 invoked from network); 9 Feb 1999 16:04:05 -0000
Message-Id: <>
Date: Tue, 9 Feb 1999 11:02:03 -0500 (EST)
From: "Charles M. Hannum" <>
Subject: Problems with X on the Shark
X-Send-Pr-Version: 3.95

>Number:         6973
>Category:       port-shark
>Synopsis:       Problems with X on the Shark
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-shark-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 09 08:05:00 +0000 1999
>Last-Modified:  Mon Mar 29 19:31:04 +0000 2004
>Originator:     Charles M. Hannum
>Release:        -current

There are several problems with X on the Shark:

0) First and foremost, the necessary modifications to the X source
   tree have not been committed.  The CyberPro code isn't even
   available from a NetBSD server; it can only be found on the Digital
   Shark pages.

1) As reported previously, the hardware cursor does not appear to be
   turned off when entering DGA mode.  It leaves a large square on the

2) When using a cursor with the hotpoint not at the top, when the
   cursor approaches the top of the screen it actually moves lower
   (seems like a sign inversion).  Similarly for the left edge of the
   screen.  This is easy to reproduce with the standard X root window

3) There is some very strange behavior with private colormaps:

   a) When using 1280x1024 at 80Hz (see below for modelines), the
      private colormap seems to be mostly black; e.g. using `xv
      -owncmap -8', if I put the cursor in the display window, the
      picture is nearly black, although sometimes a few colors are

   b) At 48Hz, the colormap appears to be set correctly when I put the
      cursor in the window, but the image quickly fades toward blue.

   c) At 47Hz, the image fades more slowly toward red.

   d) At 46Hz, the image is stable and appears to be correct.

   Interesting things to note here:

   e) This does *not* appear to happen when using the global colormap;
      `xv -8' displays images correctly, although *sometimes* one or
      two colors do not appear to `stick' after they're set.

   f) The point at which it loses appears to be related directly with
      the overall dot-clock.  Similar dot-clocks at different
      resolutions appear to have (or not have) similar problems.

   g) Ignatios suggested that this might be related to refreshing the
      palette memory -- but it should be static RAM, and even if it
      were DRAM, why would it not lose for the global colormap?  AFAIK
      they use the same VGA register file.

   h) I noticed in the CyberPro code that it does not appear to be
      careful with write buffer flushing when updating the color of
      the cursor.  This may or may not be related; I have no idea

In order:
0) Try to build a Shark X server.
1) Use xmame in DGA mode; be annoyed that you can't see part of the
   game display.
2) Move the cursor around.
3) Use xv with the various modelines below.  (Obviously the lower
   frequencies will flicker.  This is not the point of the test.)

ModeLine "1280x1024"  145.725  1280 1312 1456 1712  1024 1027 1030 1064 # 80Hz
ModeLine "1280x1024"   87.435  1280 1312 1456 1712  1024 1027 1030 1064 # 48Hz
ModeLine "1280x1024"   85.614  1280 1312 1456 1712  1024 1027 1030 1064 # 47Hz
ModeLine "1280x1024"   83.792  1280 1312 1456 1712  1024 1027 1030 1064 # 46Hz

None provided (yet).

Responsible-Changed-From-To: port-arm32-maintainer->port-shark-maintainer 
Responsible-Changed-By: bjh21 
Responsible-Changed-When: Sun Apr 7 07:42:31 PDT 2002 
This is a shark bug. 

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.