From: James S. <jsi...@in...> - 2004-04-28 19:06:19
|
> > > Your logic is only ever valid once every single fbdev is capable of > > > doing proper mode management & validation. And even then, there isn't > > > a 1:1 relationchip between a mode and an fbcon size. > > > > But we do have the proper data already. Its called modedb. I have two > > So I cannot have a mode that's not in modedb, since it won't survive switching > VTs. Well its a bug in fbdev that we can't alter the modedb. Especially that we have in struct fb_info struct fb_monspecs which has a modedb field. We need to add the functionally to export the drivers modedb to userland and vice versa. > > reasons for why I hate to have a var in struct display. One is that it > > makes fbcon heavier. You now have a extra var in every struct display. > > ... vs. a (non __init) modedb that stays in RAM after bootup. > > Besides the initial mode (modedb, EDID, kernel arg, ...), I'd like to keep mode > databases in userspace where possible. That kind of sucks for modular fbdev drivers. Also with EDID data the driver creates the respected modedb it can work with. Consider the case where we have a fbdev driver all happy. Now we unplug the monitor and plug in a different kind. With the new monitor the old mode doesn't work. How do we handle this? Even if you say you can load the new database from userland before we change monitors we still have to create a database. With EDID we can generate those modes. But its driver side. > > Usually the user has several if not all VCs at the same resolution. That > > means there is alot of duplication of the same data for now reason. If we > > Alternatively, make the vars in struct display pointers to reference counted > data, so initially they all point to the same var. But I don't know if it's > worth the extra effort. Thats a possibity. Of course we still have modedb and it is needed for the above reasons. > But I'm still limited to the modes in modedb. Not if we fix modedb to take userland modes. |