VGA/VESA on the PC port

[da...@boddie.org.uk]

I seem to remember reading somewhere that it should be possible to get wm running on the PC port
of Inferno with a bit of Limbo code. In the meantime I've tried sending commands to the /dev/vgactl
device in an attempt to configure it, without success. Is there an overview somewhere of the work that
needs to be done to enable a framebuffer so that /dev/draw can be created?

[da...@boddie.org.uk]

Just following up on this before I start digging into the os/pc/vga*.c files, is this information for
Plan 9 relevant or useful for understanding how the VGA drivers work under Inferno?

http://plan9.bell-labs.com/wiki/plan9/Video_Drivers_Development/

[Timothy Gaskell]

I'd love to hear what you find out.

I'm not quite as far in as you, though. I haven't (yet) succeeded in getting a bootable floppy out of the binaries I generated with the vitanuova 2015 tarball and instructions at umdrive.memphis.edu or in doing a native compile from your copy of the repository, so all I have is a Linux-hosted environment and a VM set up with the 2007 ISO at https://umdrive.memphis.edu/blstuart/htdocs/inf_native.html

Thanks,
Timothy

[da...@boddie.org.uk]

On Sunday, April 9, 2017 at 12:26:26 AM UTC+2, Timothy Gaskell wrote:

I'd love to hear what you find out.

I'm not quite as far in as you, though. I haven't (yet) succeeded in getting a bootable floppy out of the binaries I generated with the vitanuova 2015 tarball and instructions at umdrive.memphis.edu or in doing a native compile from your copy of the repository, so all I have is a Linux-hosted environment and a VM set up with the 2007 ISO at https://umdrive.memphis.edu/blstuart/htdocs/inf_native.html

It's good to know someone else is still following this. :-)

I like to hope that there's a sequence of strings to send to the vgactl device to set it up. One issue I wonder about is that I'm using qemu to try this out, and I'm unsure as to which, if any, of the supported virtual VGA devices Inferno will work with. If it turns out that it's not compatible with any of them then this is a dead end and I'll need to dig out my old laptop to try it with.

[da...@boddie.org.uk]

Still doing the occasional digging, I found this message from many years ago that mentioned VESA support:

https://marc.info/?l=9fans&m=111558748217689&w=2

I found a file called vgavesa.c in the 3rd Edition but it looks either incomplete or would need some work to
make it compatible with the current Inferno sources.

On another trip through the os/pc directory, I found a comment that says:

  "It would be fair to say that this doesn't work for >8-bit screens."

I wonder if this means I should be trying to limit the colour depth exposed to the virtual machine somehow.

[Joseph Stewart]

If memory serves me, Brian Stuart had this running on some version of VGA (don't know about VESA).

I see breadcrumbs at:

https://www.cs.drexel.edu/~bls96/

Hope this helps.

-joe

[da...@boddie.org.uk]

On Wednesday, July 26, 2017 at 12:50:23 AM UTC+2, Joseph Stewart wrote:

If memory serves me, Brian Stuart had this running on some version of VGA (don't know about VESA).

I see breadcrumbs at:

https://www.cs.drexel.edu/~bls96/

Hope this helps.

Thanks! I actually downloaded the inferno-bls sources from Google Code a while ago during my initial
phase of rescuing Inferno-related content from that service. I hadn't really taken a close look at it, so
thanks for the reminder!

David

[da...@boddie.org.uk]

With the basevga driver in place I've managed to start wm but don't yet have a cursor. Still, this is progress!

According to https://www.cs.drexel.edu/~bls96/infenhance.pdf the cursor should work, so maybe I've just
misconfigured things. I'll look a little closer at it.

[Matheus Garcia]

Any luck having the mouse working? I don't think this is related to the VGA driver. "cat < /dev/pointer" does print stats.

[da...@boddie.org.uk]

Take a look at this thread: https://youtu.be/3NeHil9LJrY

If you run the system image in qemu, you should be able to enable USB mouse support with options like these:

qemu-system-i386 -m 512M -drive file=inferno-pc.img -net user -net nic,model=rtl8139 \

  -usb -device usb-ehci,id=ehci -device usb-mouse

I should probably update the download page to mention this...

[Matheus Garcia]

Never mind. I managed to install and run the driver you linked here. However, the cursor movement is botched. I have the sources for a fork of Inferno, named Purgatorio. This is the only version which I can build kernels successfully. Others, including the official, don't build.

[da...@boddie.org.uk]

Maybe you can bring some of the changes in this branch over to purgatorio?

https://github.com/dboddie/inferno-os/commits/2025-01-usb-mouse/

[Matheus Garcia]

Thanks. Still no dice. I tried importing swcursor.c from 9front. Does build fine, but no cursor is drawn.

[da...@boddie.org.uk]

In the code I added to my 2025-01-usb-mouse branch, I put the software cursor in the vbescreen.c file:

https://github.com/dboddie/inferno-os/blob/2025-01-usb-mouse/os/pc/vbescreen.c

It's not the same as the swcursor.c implementation. I think I borrowed it from the Raspberry Pi port.

In any case, the cursor needs devpointer to be built, and it needs to be enabled in the init file by binding the '#m' device under /dev.

[Matheus Garcia]

I have only partially positive results with the linked implementation. The cursor movement is botching. The cursor loads, and I can move for a few seconds. However, once the window manager is fully loaded, the cursor vanishes.

I made some adjustments to swcursor.c from 9front. I have the same results as with your Raspberry Pi port implementation.

There's something missing or wrong, though don't know what and where.

[Matheus Garcia]

I believe the cursor is only meant for a graphical terminal? That's the case if I omit the start of the window manager from stvga.b. I get a working cursor, though only for a graphical terminal. Something's wrong.

I wonder if this is related to Draw->Context. Perhaps the window manager is overlapping the cursor?

[da...@boddie.org.uk]

Yes, the cursor is for a graphical terminal.

In my most recent attempt to make this work I didn't use the stvga tool at all. I create a framebuffer for a VESA mode and switch to that, then its no longer running in a traditional text mode.

Is your code in a repository somewhere?

[Matheus Garcia]

Yes. Here's the repository.

I tried importing that bootloader code too, but I get a blank screen.

[Matheus Garcia]

Never mind. I believe the issue is related to speed. The cursor does work in the window manager, but is moving too fast. Plus, there isn't bounds to check whether is at the edge of the screen or not.

[Matheus Garcia]

I successfully applied bounds to check whether the cursor is at the edge of the screen or not. This is borrowed from Brian L. Stuart's implementation on vgabase.c. I'm using 9front's implementation on swcursor.c.

𝚟𝚘𝚒𝚍
𝚜𝚠𝚌𝚞𝚛𝚜𝚘𝚛𝚍𝚛𝚊𝚠(𝙿𝚘𝚒𝚗𝚝 𝚙)
{
...
𝚒𝚏(𝚙.𝚡 < 0)
𝚙.𝚡 = 0;
𝚎𝚕𝚜𝚎 𝚒𝚏(𝚙.𝚡 >= 𝚐𝚜𝚌𝚛𝚎𝚎𝚗->𝚛.𝚖𝚊𝚡.𝚡 - 𝟷)
𝚙.𝚡 = 𝚐𝚜𝚌𝚛𝚎𝚎𝚗->𝚛.𝚖𝚊𝚡.𝚡 - 𝟸;
𝚒𝚏(𝚙.𝚢 < 0)
𝚙.𝚢 = 0;
𝚎𝚕𝚜𝚎 𝚒𝚏(𝚙.𝚢 >= 𝚐𝚜𝚌𝚛𝚎𝚎𝚗->𝚛.𝚖𝚊𝚡.𝚢 - 𝟷)
𝚙.𝚢 = 𝚐𝚜𝚌𝚛𝚎𝚎𝚗->𝚛.𝚖𝚊𝚡.𝚢 - 𝟸;
𝚖𝚘𝚞𝚜𝚎𝚝𝚛𝚊𝚌𝚔(0, 𝚙.𝚡, 𝚙.𝚢, 0);
...
}

However, the cursor movement is botching. Odd enough, this only happens when the window manager or a graphical app is loaded. The cursor isn't vanishing, but the movement is broken.

As you can see from the sent recording, I'm presented a graphical terminal, and the cursor is working fine from there.

[Matheus Garcia]

I found out opening /dev/pointer multiple times leads to the movement breakage. Threading bug? Sometimes, I get an error, "attempt to enable cursor multiple times", and the cursor dies. Sometimes, the error doesn't show, but the movement breaks.

[da...@boddie.org.uk]

Is the cursor being positioned using data from a PS/2 interface or from a USB device?
I encountered issues when trying to use data from a PS/2 interface in qemu, but perhaps opening /dev/pointer multiple times is the cause.

[Matheus Garcia]

The cursor does work, even though devpointer isn't binded. I thought the cursor was supposed to work only if devpointer is binded? Only the window manager demands devpointer. Odd.

Looks like this is a threading bug. Calling qlock() from pointeropen() (from devpointer.c) leads to blocking. There's a check for whether the lock is acquired or not, but the code never falls through the block.

Hope to have this figured as soon as possible.

[Matheus Garcia]

I'm not using USB as interface, but PS/2. I believe this is the default if one does not explicitly set.

[da...@boddie.org.uk]

In your repository the pc configuration file has ps2mouse in its link section, and I don't see anything related to USB in any of the sections.

It looks like swcursorinit is called in the vgasoft.c file. I suspect that the swcursor operates almost independently of the pointer device, except that it calls mousetrack to send information to devpointer. It's all more closely coupled and low level than you might have expected.

[Matheus Garcia]

I finally found a fix. I was right pointing a threading problem. The issue lies in i8042intr() (from kbd.c). auxputc() is called without a lock on.

The fix comprises postponing unlocking after auxputc(). However, drag and drop operations are doing terribly.

Interestingly, 9front hasn't touched this code.

[Matheus Garcia]

I don't think that's a quite correct solution. Two threads are in use of auxputc(). No longer a crazy cursor, but a sluggish one.

The sluggishness is quite visible while running Bounce. Might be, in part, related to the Dis virtual machine, since I noticed sluggishness from a hosted environment.

[Matheus Garcia]

Never mind. 9front did touch the code. lock()/unlock() was replaced with ilock()/iunlock(). This effectively remedies the issue as well.