nanogui: Multiple Screen Support
Subject:
RE: Multiple Screen Support
From:
David Erickson ####@####.####
Date:
30 Oct 2000 18:32:23 -0000
Message-Id: <0104003BF8BED311A20F00508B8B8B2E5E9E94@BIG_MAIL>
Sounds like we have somewhat similar needs. I don't have the global variable
problem because I'm running Linux, but my device supports multiple logical
screens, which I referred to as "surfaces" in a previous post.
The hardware takes each surface, which is just a different region in a
memory map, and blends them together on a single physical screen. I can also
do some cool alpha-blending at the hardware level too. But from MW's
perspective, I need to handle multiple screens.
The problem I mentioned earlier was my need to make custom calls (for the
hardware alpha blending, etc), and the proposed solution was to reopen the
device from the client app and issue the appropriate ioctl()'s. This will
work ONLY if I'm running one copy of Microwindows because the client
couldn't learn from the screen driver which surface it's using. The MW
screen driver would have to be hardcoded to open a specific device (i.e. a
MW-reserved minor number) or make some special call to mark itself as being
MW. It would be great if the client could learn from the screen driver which
surface it was allocated. Basically, I need a single user-defined int
returned from the screen driver.
Make any sense?
In a different direction, would it make any sense to allow one instance of
MW to control multiple screens? Does this complicate things worse? (e.g.
multiple root windows, etc)
I'm interested in your proposal implementation and would love to help as it
seems our needs intersect.
David Erickson
Broadband Interactive Group
Senior Software Engineer
949-885-8200 main
949-885-8301 direct
####@####.####
-----Original Message-----
From: Brent Thompson ####@####.####
Sent: Friday, October 27, 2000 11:16 AM
To: ####@####.#### Greg Haerr
Subject: Multiple Screen Support
In the past, we had touched on the subject of supporting
multiple screen/mouse/keyboard devices with Microwindows. I
am now to the point in my project where I need to come up with
a solution. The main issue is that I am working with VxWorks,
a thread-based operating system with a shared global name-space.
So, as opposed to Linux/Windows/OS-9/QNX/etc where one could
just fork off multiple processes each with their own independent
version of Microwindows running, I need to configure Microwindows
to support multiple screens using the same global name-space.
I've discovered that there are many global variable used by
Microwindows. Some of these are basically constants (eg,
standard palettes, fonts, and mwSYSMETRICS_xxx). Others are
actively used for the processing of window/cursor/clipping
calls. It is these globals that I propose putting either into
the HCD device context structure (for the mwin globals) or
into the PSD screen device structure (for the engine globals).
I am in the process of starting the implementation of this
proposal and will provide additional details after everything
is working. But are there any comments on why this is needed
or variations on accommodating multiple screens?
BAT
--
Brent A. Thompson, Next Level Communications <www.nlc.com>
1776 22nd Street #100, West Des Moines, IA 50266-1444
EMail: ####@####.#### Phone: (515)991-3853
---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####
