Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[servers/console] Make it possible to request a console with an inexact mode #138

Open
4 tasks
perlun opened this issue Nov 10, 2018 · 0 comments
Open
4 tasks

Comments

@perlun
Copy link
Contributor

perlun commented Nov 10, 2018

At the moment, when requesting a console, you have to ask for a specific text or graphic resolution (80x50, 640x480 etc.)

We should improve this to handle two other scenarios also:

  1. Ask for "any text mode" or "any graphic mode", by leaving the width and height to zero. The depth can still be set, since the calling program might not be able to handle an arbitrary depth. The console server will give you the best matching mode that the hardware can support.

  2. Ask for "a particular text mode" or "a particular graphic mode", but get another mode instead. Example: ask for 80x25, but get 80x50. Ask for 640x480 but get 1920x1280 instead, and so forth.

    This will be important once we start working on Use framebuffer-based graphics mode instead of EGA text mode #125, since the GRUB/Multiboot bootloader might very well give us different modes for different hardware, and we need to make the code much more flexible and less hardwired here.

This affects a few areas.

  1. [libraries/console] - need to send one message and wait for the reply, indicating what mode was acquired.
  2. [servers/console] - need to fix the reply sending noted above. (right now, we never send anything back to the caller, triggering the IPC_CONSOLE_OPEN message.
  3. [servers/console] - change the code to handle the "width/height == 0" scenario (choose the best mode available)
  4. [servers/console] - change the code to handle the "the exact mode requested was not found, but I have this alternative mode for you" scenario. The t

The first and second one of these are low-hanging fruit and could easily be done right away if anyone wants to volunteer some time on this. The third and forth are probably harder, since they depend on IPC with the vga server (unless we let the console server know about all existing modes using a new IPC message in the video protocol - perhaps not such a bad idea.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant