RE: how to activate X with famebuffer

Hai Carlo,

I think the framebuffer problem is partially solved.
There is some thing that I to make clear clear about framebuffer.

I think the X was using loaded rivafb on my system from a long time, but problem lies some where in analyzing it.
I was testing it by opening some apps and expecting the rivafb to be invoked, which indeed is not happening?

Perception: X will invoke rivafb when ever I open a new App and when I shift between Apps. But, it is not invoked in such instances. I don’t know why rivafb is not invoked when I open a new app.

It is invoked when I run X server performance tests like "x11perf" in the GUI mode.

Why is it not invoked when a new GUI application is opened?
Is it like X server is capable of doing that( opening GUI apps) without framebuffer?

			 
ACCORDING TO FRAMEBUFFER DEFINITION :-
A framebuffer device is an abstraction for the graphic hardware. It represents the frame buffer of some video hardware, and allows application software to access the graphic hardware through a well−defined interface,
so that the software doesn't need to know anything about the low−level interface stuff 

This is taken from Geert Uytterhoeven's framebuffer.txt in the linux kernel sources.
In the above definition what is an Application? Is it the X server, Applications above it?

Suppose there is a kwrite application, obviously running over X server.
Looking at this angle the flow is as follows:-


	NORMAL Applications ( Kwrite)
	-------------------
		X Server
	-------------------
	Framebuffer Driver
	-------------------
		HARDWARE

Is it Applications like Kwrite should support Framebuffer in order the X server makes use of it. If this is the case, the flow will be as follows:-

	NORMAL Applications (Apps instructs X server - Use fb or don't use) 
   -------------------------
		X Server
   -------------------------
Framebuffer / NON-Framebuffer
		 Driver
   -------------------------
		HARDWARE


IF THIS IS THE ARCHITECTURE, THE X SERVER WILL USE FRAMEBUFFER BASED ON THE APPLICATION THAT IS CALLING IT.

what I am speaking may be a BLUNDER MISTAKE. Regrets, if so. Please correct if mistaken.

Your error message tells you that the "screen" section is
unusable. So, you are supposed to experiment with modifications on
that section until the error message changes - that is, until your
screen section becomes usable. Focus on the immediate block. When your
screen section is OK. either X will work, or you will have a new error
message pointing to new tests and experiments.

Now, I have no problems here.

X must be told at what resolution to work, and all framebuffer drivers
but the simple VESA one can change resolution on the fly, so you can
very well have X in one resolution and text mode in one (or more)
other resolutions.

Yes, the current screen Section has the field of modes defined as follows:-
Modes "800x600"


Regards,
Mukund jampala
�+׭zf��+,��좷�o&P
BT
a
z�ޡ�{����-
٢��h��
����
i�菡�"�!QG�*.�;��鞞�'�)��lʋ���#y�m�����
�^m�-J�'���u����i�b�䞦ݸ�^��m�����޷�iq�'��-�

On Tuesday 28 September 2004 19:27, Mukund JB. wrote:

ACCORDING TO FRAMEBUFFER DEFINITION :-
A framebuffer device is an abstraction for the graphic hardware. It
represents the frame buffer of some video hardware, and allows application
software to access the graphic hardware through a well−defined interface,
so that the software doesn't need to know anything about the low−level
interface stuff

This is taken from Geert Uytterhoeven's framebuffer.txt in the linux kernel
sources. In the above definition what is an Application? Is it the X
server, Applications above it?

'Application' is any process, user or kernel, that directly runs on top of the 
framebuffer. It can be X, or the framebuffer console.  It can be a process 
that totally bypasses X, such as directfb or mplayer -vo fbdev. Any process 
that does not run directly on top of the framebuffer is not considered as 
part of the 'Application' layer, such as kwrite on X on fbdev, or 'mplayer 
-vo directfb' on directfb on fbdev.

But X on fbdev or direcfb on fbdev or mplayer on fbdev are all considered part 
of the 'Application' layer.

Suppose there is a kwrite application, obviously running over X server.
Looking at this angle the flow is as follows:-


	NORMAL Applications ( Kwrite)
	-------------------
		X Server
	-------------------
	Framebuffer Driver
	-------------------
		HARDWARE

Yes, above is how it works.  In this case, Kwrite doesn't know a thing about 
the framebuffer, as it runs on top of X.  Or more properly, something like 
this:

NORMAL Applications such as X, DirectFB, mplayer, etc
-------------------
Framebuffer Driver
-------------------
HARDWARE

The X server is considered as part of 'NORMAL Applications'.

Is it Applications like Kwrite should support Framebuffer in order the X
server makes use of it. If this is the case, the flow will be as follows:-

	NORMAL Applications (Apps instructs X server - Use fb or don't use)
   -------------------------
		X Server
   -------------------------
Framebuffer / NON-Framebuffer
		 Driver
   -------------------------
		HARDWARE

No, the above is not the case.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl