From: Paul M. <pm...@mv...> - 2001-06-29 21:02:16
|
On Fri, Jun 29, 2001 at 10:33:40PM +0000, Petr Vandrovec wrote: > And after applying your hack we either (a) call some initialization > twice or (b) cannot reorder framebuffers. If you do not know > what I'm talking about, try booting your kernel with >=20 > video=3Dvga16: video=3Dmatrox: >=20 > and then >=20 > video=3Dmatrox: video=3Dvga16: >=20 > and look at completely different behavior (of course if you have > at least matrox alone in the box; you can replace matrox/vga16 with > framebuffer drivers you use). As long as there is no > global kernel service to reorder device scanning (such as my kernel > has for PCI), it is unavoidable to have this hack. With SCSI you can > say that your main disk is /dev/sdq, but with framebuffers it is > really fatal if something wents wrong and you even do not see what > went wrong because of console is now on some videocard without attached > monitor, or on vfb... > =20 This shouldn't really be that big of a deal.. if we use a linked list that devices insert themselves into via register_framebuffer(), it wouldn't be much more difficult to move nodes around the list in the order of which they were passed. For example: video=3Dmatrox: video=3Dvga16: We obviously want the matrox to be initialized _prior_ to the vga16.. the matrox gets inserted at the head of the list and the vga16 after it. The quickest way to do this would be to have two lists.. one list for prioritiz= ed cards, and the primary one where register_framebuffer() appends to. If we had a matrox, a vga16, and a tdfx card and the matrox and tdfx wanted to be initialized first, then the matrox would be removed from the primary list and inserted as the head of the prioritized list, the tdfx would then = be appended to it, and so on and so on. Once we ran out of video=3D options, t= he remainder of the primary list could be appended to the prioritized list, or the prioritized list inserted at the head of the primary list. This might seem kind of hackish, but it should be able to be done fairly cleanly.. and it'd be a better solution then the current hacks, IMO. Regards, --=20 Paul Mundt <pm...@mv...> MontaVista Software, Inc. |