This is vary good.How does mergedfb work internally? I don't know.
- To accomidate mergedfb the number of FBs should be allowed to be 0.
Alternatively to this, maybe the best way to do this would be to specify a double-width mode (eg 2048x768) and an extra "feature" parameter of MERGEDFB or some such -- that might work. However, I can't claim to understand mergedfb (as in, how it's implemented) yet, so this is probably a naive solution.
- Sharing of FBs should be allowed, for heads on the same card.Same deal, except instead of a "feature" of MERGEDFB, the "feature" should be CLONE
- There is no way to ?change?(read as specify) the size of a FB.If you can specify the resolution, you can specify the size of the framebuffer. What else did you have in mind?
- Allocating the second/... FB may be difficult,Hmm... I'd love for you to elaborate here, though I -think- I know what you're getting at.
- Have mem free as well as mem total.
- Returning hardware capabilitys(like in a termcap type way), not just
mem sizes. I.E. zbuffer type(how to know it's size).
The more I think about this, the more sense it makes to have the apps talking to the kernel and requesting things via ioctl(s), the kernel communicating with the userspace to do "mode management", and the kernel communicating back to the app. Having the being the thing communicated with is getting to be a huge mess.
That being said, having kernel calling userspace via whatever method can be ugly. Here's the suggestion I got from hpa (which is roughly what I was thinking of; but he filled in some important bits):
- At startup, a pipe is opened which the mode manager can read from and the kernel can write to
- When the kernel needs to set a mode, it locks the dev, feeds the pipe, and waits a predefined period of time (0.5s?)
- Once the kernel's sure it can set the mode, it feeds the pipe to the mode manager a serialized version of the mode params
- The mode manager sets the mode, then goes back to waiting on the pipe
- The kernel returns from the ioctl 0.5s (or however much time) after it called the mode manager
Bad things about this approach:
- Can't tell if setting the mode succeeded (see below about "fail-over")
- There is an assumption made about how long it will take to set modes -- would probably have to run with realtime priority to ensure setting the mode happened quickly enough (it already runs as root; why not)
Dubious things:
- Have to have mode knowledge gleaned from DDC or whatnot in kernel
- Alternative: Have also do
- There might be problems if the entire device needed to be locked while the mode was being set
- My question: Is this necessary?
Good things:
- Don't have to have the know about MergedFB, clone mode, etc because it's *simply* setting mode timings -- nothing more
- Still moves that important chunk of code out of the kernel
- Keeps locking entirely in kernel (if it is needed)
Here's the call chain for the mode manager (when it starts up):
- Sets up pipe to kernel
- Tries each DRM device, and finds out what's at each one
- Opens a config file, loads in user-specified modelines (necessary?)
- Queries each of them for DDC data or whatnot (using the specific driver) and stores it associated with that device
- Calls an ioctl on each "live" DRM device and informs it of the available modes (simply xres, yres, refresh; nothing more)
- Could fire up a thread to watch for i2c data or whatever
- Waits on the pipe
Here's my current call chain for setting a mode:
- App requests mode from "Extended DRM" via ioctl (same sort of format, except packed into a struct instead of a string)
- "Extended DRM" checks if the requested mode is available
- "Extended DRM" locks the device
- "Extended DRM" checks if there is enough memory to set the specified mode
- If not enough memory, "Extended DRM" returns -ENOMEM or something
- Otherwise, continue
- "Extended DRM" frees previous framebuffer (if applicable), allocates new framebuffer(s) (including Z buffer)
- This could be where the device could be unlocked, all depending
- If the "Extended DRM" ioctl could have a safe way to set registers, it would be true.
- "Extended DRM" cooks up a serialized version of the mode string
- "Extended DRM" feeds pipe to userspace application the serialized mode string
- "Extended DRM" waits 0.5s or whatever timeout is decided upon
- When this is done (if we don't have a safe way to unlock registers and setting modes while other stuff is going on is not safe) the "Extended DRM" unlocks the device
- Mode manager receives serialized mode, parses it (or whatever; could simply shove it into a struct; it's trusted code)
- Mode manager gets "best-match" mode (you want something usable at least if bad things happen; screen corruption's ugly)
- Mode manager sets appropriate registers
- Sets timing registers
- Does _NOT_ set base address registers or anything to do with tiling modes, or anything of that sort
- Is there any reason this restriction cannot be put upon it?
- Mode manager goes back to waiting for mode change requests
This is sorta what I had in mind for modes. The first part is a blatant rip of linux/fb.h:
struct mode {
__u32 xres; /* Actual FB width */
__u32 yres; /* Actual FB height */
__u32 xres_virtual; /* Virtual fb width */
__u32 yres_virtual;/* Virtual fb height */
__u32 xoffset; /* Offset of actual from top-left corner of virtual */
__u32 yoffset;__u32 bpp; /* Bits per pixel */
__u32 refresh; /* Preferred refresh rate (0 for no preference) */
__u32 fb_mode; /* Example: various tiled modes versus linear; defined as integers (LINEAR, TILED4K, etc) */
__u32 feature; /* Numeric feature code (eg MERGEDFB, CLONE) */
};
This is what the mode manager receives:
struct ms_mode {
__u32 xres;
__u32 yres;
__u32 bpp;
__u32 refresh;
};The mode manager then looks this up in its table of modes, and sets the best-match mode.
Now at this point, you'll probably be wondering why there isn't a way to say how many framebuffers you have, why you can't specify a Z buffer, etc -- the reason is because fundamentally, setting a mode has nothing to do with double buffering, triple buffering, and 3D graphics -- it's about bootstrapping a usable mode. After the mode's boostrapped, you can do whatever you want with framebuffers -- if you want more buffers, call another ioctl to request them. At least in my opinion, it is not part of mode setting.
If you have good reasons why it is, I'd love to hear them.
David Bronaugh
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
