Subject: VIDC video driver in 2.2.16-rmk2

From: Chris Rutter <[email-masked]>
Date: Sat, 2 Sep 2000 01:08:04 +0100 (BST)

I've noticed something of an oddity; an fbset-set mode of 1024x768-70
in 16-bit depth (which, under RISC OS, comes out under the safe limit
of 160Mb/s) seems to throw the video display into spasm, suggesting
the VIDC's being strained past its limits.  Anyone know the reason for
this disparity?

Also, with 3.3.5 of the fbdev X server and the said kernel, the problem
where the virtual height is huge still persists.  Is there a fix for
this yet?

c.

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 2 Sep 2000 09:04:54 +0100 (BST)

> the VIDC's being strained past its limits.  Anyone know the reason for

fbset uses a different database from RISC OS - you may want to look in
your fb.modes file to see what the dotclock and other parameters are, and
how they compare to the RISC OS setting.

> where the virtual height is huge still persists.  Is there a fix for

The kernel won't be fixed, because its not a kernel problem.  Its a fbdev
problem, trying to use text mode acceleration on what is obviously a
graphics console.

In other words, someone will have to fix the fbdev X server.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Chris Rutter <[email-masked]>
Date: Sat, 2 Sep 2000 12:57:16 +0100 (BST)

> how they compare to the RISC OS setting.

Indeed.  Well, what my fb.modes says (it's the standard `ATI' one) is:

  #       1024x768, 75Hz, Non-Interlaced (78.75 MHz dotclock)
  #
  # [...]
  
  mode "1024x768-75"
      # D: 78.75 MHz, H: 60.023 kHz, V: 75.03 Hz
      geometry 1024 768 1024 768 8
      timings 12699 176 16 28 1 96 3
      hsync high
      vsync high
  endmode

The 1024x768 @ 75Hz mode I use in RISC OS apparently has a `pixel rate'
of 80310, and a bandwidth of 160MB/sec in 16 bpp, which is stable on my
VIDC.  I'm afraid my knowledge is lacking about the meaning of the
majority of these terms. :-/

> In other words, someone will have to fix the fbdev X server.

Ah, right; I seem to recall a change in the ARM kernel posted a few
months ago titled `virtual height problem fixed' or something: was
that not the whole problem, or unrelated?

I'll try the patch for the userland stuff recently posted to the list.

c.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 2 Sep 2000 13:08:20 +0100 (BST)

> majority of these terms. :-/

Well, that mode is using a pixel rate of 78.746MHz, so it should be within
the bandwidth.  Hmm, I'll look more closely - which kernel version are
you using, and has this been brought on by changing kernel versions?

> that not the whole problem, or unrelated?

It was related; that change was to stop the kernel setting the virtual
height no matter what.  It now only sets it if you want text-mode
acceleration, which, when you're doing graphics should not be enabled.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Chris Rutter <[email-masked]>
Date: Sun, 3 Sep 2000 16:37:13 +0100 (BST)

> you using, and has this been brought on by changing kernel versions?

It's in 2.2.16-rmk2; as I /recall/, earlier 2.2 kernels from a few
months ago did the same thing.

> acceleration, which, when you're doing graphics should not be enabled.

Ah, righty, so the user-land patch is the currently-appropriate one.
Great.

c.