Bug 80557

Summary: (neomagic) X uses more memory than before, laptops unhappy
Product: [Retired] Red Hat Linux Reporter: lindahl
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED NOTABUG QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-06-01 08:48:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 82781    
Attachments:
Description Flags
XFree86-4 as generated by Anaconda
none
XFree86.0.log none

Description lindahl 2002-12-27 21:53:30 UTC
Description of problem:

The X config with Redhat 8.0 uses more graphics memory than earlier versions.
This results in programs like ogle (dvd player) not being able to run on laptops
unless you crank down the video resolution. The error from X is "BadAlloc".

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

latest ogle: 0.8.5

How reproducible:


Steps to Reproduce:
1. Install latest ogle on your laptop
2. Run ogle, choose "Open Disc"
3. Watch ogle crash
4. Edit /etc/X11/XF86Config-4 to eliminate all display modes but 640x400
5. Run ogle, choose "Open Disc", watch it work

If you look at /var/log/XFree86.0.log you will see that you need 2 mb
of off-screen memory to successfully run ogle. My video chipset is a bit
old (NeoMagic 256, Sony Vaio PCG-F430).
    
Actual results:


Expected results:


Additional info:

Comment 1 Mike A. Harris 2002-12-30 01:47:19 UTC
If you need 2Mb of offscreen memory, that is for an overlay surface.  That
means that you must run in a resolution that is lower that doesn't consume
all video memory.  If there is no free video memory because it is completely
consumed by the 2D framebuffer, pixmap cache, hardware mouse cursors, etc.
and there is not 2Mb free, but 2Mb is required, then of course it is not
going to work as expected.  There should be absolutely no difference between
XFree86 4.2.0 in Red Hat Linux 8.0 and 4.2.0 in 7.3 in this regard.

What video mode and depth did you use in XFree86 before, and what video
mode and depth are you using right now?

Comment 2 lindahl 2003-01-01 08:59:30 UTC
I was using 1024x768x16 then and now. I'm not sure if
I tried it under RH 7.3. I figured out how to reduce the pixmap
cache but not how to reduce the font cache. The ogle guys said that
they use 512k or 1024k; all XFree86 tells me in the logfile is the
starting memory, not how much is left after the pixmap and font caches.

Comment 3 Mike A. Harris 2003-01-04 20:27:29 UTC
font cache has nothing to do with video memory at all, so reducing or even
removing font caching altogether will result in zero change in video memory
usage.

Please attach your /var/log/XFree86.0.log and X config file uncompressed
as individual file attachments using the link below.

Comment 4 lindahl 2003-01-06 01:37:36 UTC
Created attachment 89141 [details]
XFree86-4 as generated by Anaconda

I've added some commented out entries for the config that did let me play DVDs
with ogle.

Comment 5 lindahl 2003-01-06 01:44:07 UTC
Created attachment 89142 [details]
XFree86.0.log

Comment 6 Mike A. Harris 2004-06-01 08:48:22 UTC
The attached config files show that the default configuration does
not leave enough video memory available to permit video playback.
This is normal expected operation on a system with very small amount
of video memory.

In this case, the video driver doesn't have a lot of choice, since
there isn't very much video memory.  It could either limit the max
resolution to a lower res, to ensure there is free memory available
for video playback and other hardware features, in which case you'd
be guaranteed to be able to play video, but you'd be stuck with a
hard coded max resolution.

The other option, is for the driver to permit the user to configure
whichever resolution is desired that the hardware can display, and
then to disable features that are incompatible with the chosen
resolution.  This is what the driver is essentially doing right now,
which is probably the most sensible default, as more users are likely
to want to be able to use higher resolution than will want to
give up high res entirely to guarantee they can always run video
playback.

The benefit of the current driver operation, is that both types of
users can essentially configure the X server to the choice they
prefer.  The downside, is that the video driver and X server can't
guess which of the two possible configurations a given user will
prefer by default.  If it defaults to low res plus video, users who
want working video support by default will perhaps prefer this
setup, however users expect high res to be available by default will
likely consider it a bug.  There's no way to have 2 defaults of
course, and having high res working by default is more likely the
common case.

This type of issue generally isn't a problem in OSs like Windows,
as Windows has the ability to dynamically resize the video framebuffer
on the fly, and to reallocate framebuffer resources as needed without
restarting.  This allows a Windows video playback application to
switch the framebuffer to a lower resolution and recover memory
with which to utilize the video accel engines on a given chipset
while viewing video fullscreen.

In newer releases of XFree86, it does have the capability to
resize the visible framebuffer on-screen, but unfortunately it
does not resize the amount of allocated framebuffer memory
internally yet.  This is a feature which will likely be implemented
in a future release of X.Org X11 (the XFree86 replacement we use
in our current Fedora Core release), however that is likely
a few years off.  Ironically, by the time such feature exists in X,
it is possible nobody will be using hardware with such limitations
anymore.  ;o/

Closing issue as 'NOTABUG' for now, as this is a hardware and
software limitation rather than a bug.