Bug 117695 - Receiving "RENDER" missing on display...
Receiving "RENDER" missing on display...
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-07 06:25 EST by Josh
Modified: 2007-04-18 13:04 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-03-23 20:39:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Josh 2004-03-07 06:25:33 EST
Description of problem:
 

Version-Release number of selected component (if applicable):


How reproducible:
 Always reproducible.

Steps to Reproduce:
1. Connect to server: X -query server
2. Run: "redhat-config-xfree86" or "redhat-config-printer".
3. 
  
Actual results:
 Xlib:  extension "RENDER" missing on display "localhost:10.0".

Expected results:
 None.

Additional info:
 Installed video card:
  driver: Card:ATI Mach64 3D RAGE II
  desc: "ATI|3D Rage IIC 215IIC [Mach64 GT IIC]"
  memory: 4MB
Comment 1 Brent Fox 2004-03-09 23:02:40 EST
Changing component to XFree86 since this sounds like an Xlib problem
to me.  Perhaps the driver for your card doesn't support the Render
extention?
Comment 2 Mike A. Harris 2004-03-10 00:24:45 EST
Some background info, which might be useful in diagnosing:

The RENDER extension is part of the X server, not the drivers,
and it is always present in the XFree86 core X server unless
explicitly disabled by the user in the config file.  RENDER
extension support is not dependant on the video drivers at all.
If a driver does not have RENDER acceleration, then RENDER still
exists, it is just not accelerated.  Instead, software fallbacks
are used.

All of the video drivers we ship with XFree86 do not have RENDER
acceleration support except for mga, which does.

Our tools do not to my knowledge have a way of disabling the RENDER
extension, and so there are only two reasons why a user would ever
see the above messages:

1) They have manually configured the X server config file to
   disable the RENDER extension - (I don't even remember the exact
   method required to do this.  It wasn't possible to disable RENDER
   in 4.2.x IIRC, and it might not be possible to disable it in 4.3.0
   either, but I'd have to doublecheck that to be 100% certain).

or

2) They are not using the XFree86 core X server on the display
   they are looking at.  Some other X server is being used, which
   does not support RENDER, or has it disabled.  Examples of X
   servers which do not support RENDER include:

   - Xnest
   - Xvfb
   - Older versions of the XFree86 core X server (I don't remember
     offhand which version of XFree86 core X server first included
     RENDER support, but I think it was 4.1.0)
   - All versions of VNC that I am aware of

From the initial bug report, the following error message indicates
to me that the X server does not appear to be a local display:

 Xlib:  extension "RENDER" missing on display "localhost:10.0".

"localhost:10.0" is the value that $DISPLAY gets set to by ssh, when
connecting to a remote shell using ssh with X11 forwarding (ssh -X).

My current assumption, is that you are running an X server such as
Xnest, Xvfb, Xvnc, or some other X server, which does not support
the RENDER extension, and then ssh'ing to a remote host which is
running Red Hat Linux 9, and trying to run applications which
require an X server with the RENDER extension, which then fail
because your X server does not support RENDER.

Can you confirm this?

Alternatively, if you are not using a 3rd party X server, nor
VNC/Xnest/etc., and you are using the XFree86 X server on the
host that your X server is running on, please attach the
XFree86 X server log and config file to the bug report as individual
uncompressed file attachments, and I will have a look.

Thanks in advance for your information.
Comment 3 Mike A. Harris 2004-03-23 20:39:35 EST
Closing bug as "WORKSFORME" as per above information.

Note You need to log in before you can comment on or make changes to this bug.