As for Videocards, it seems that our situation is not as bad as it was perceived before. Its not perfect, of course.

- currently i can name at least 3 cards working on my ReactOS PC with native XP drivers: ATI Rage II+, Matrox G100 and Matrox G400. With considerable cerainty i can say that all Matrox models inbetween or bit newer than afforementioned model range will also be working, as they are using same driver package;

- all vesa 2.0 videocards i tested are working correctly with our VESA driver. Only single cases have issues here;

We still have a number of bugs in this area, for your consideration:

- lack of VESA 1.2 support: this locks up older PCI cards, like whole S3 family (up to savage) to VGA driver. Only workaround is to use native XP drivers. It succeeded with S3 Trio 64, but uncovered another bug listed belo;    (bug no.4447)

- if XP video driver is installed (by slipstreaming into bootcd) on installation with VGA driver selected in 1st stage, even though XP driver is loaded, the system will be locked to VGA mode (640x480x4bpp unchangeable). This one is not yet submitted as it needs to be confirmed by other tester first;

- VGA driver, if picked in 1st stage, jumps back to VESA on 3rd stage boot. This can be rigged away by replacing VESA driver with vga driver files, leaving the filenames of the former (bug no.

- Some Windows VGA drivers will cause ASSERT in Videoprt. In many cases this ASSERT may be cont-ed without any visible side-effect, yet it requires more attention (bug no.4354);

- our opengl setup requires only specific opengl setup (bug no. 4574);

- Matrox G400 opengl ICD is not cooperating well with our opengl32.dll (fails when DrvDescribePixelFormat is called from the icd), requires more attention and a way to instert breakpoint within ReactOS to an dll that has not been loaded yet, namely a working debugger like Olly);

I am also preparing to create a support page for I/O controllers, as soon as i get some components for a few entries.