jdi@sparky.UUCP (John Irwin) (11/01/88)
The Release 3 (R2 also) server returns bogus values for the physical screen
width and height of a Sun (in millimeters). The relevant code from the
monochrome initialization routine (it's much the same for a color screen)
looks like:
if (!mfbScreenInit(index, pScreen,
sunFbs[index].fb,
sunFbs[index].info.fb_width,
sunFbs[index].info.fb_height, 90, 90))
...
The 90's are the values for dots-per-inch (horizontal and vertical).
So on a high-res screen (1600x1280) the server says the physical screen
dimensions are much larger than on a normal screen (1152x900), which is
incorrect.
Pulling out my trusty ruler I find that the Sun screen I use is 13.75 inches
in width and 11 inches in height. (About 17 diagonal inches) This trans-
lates to about 82dpi for the normal screen and 115dpi for the high-res
screen. Is 90 supposed to be a compromise? :-)
So we went about looking for a way to query the operating system (or
whatever) to determine how big a physical screen you've got. Guess what?
There doesn't appear to be a way! NeWS 1.1 also doesn't appear to have a way
to get the physical screen dimensions. This is especially amusing given that
NeWS is touted as being "pixel size independent."
Knowing the physical dimensions of the screen is critical to providing
some sort of pixel independence. The new Release 3 fonts are wonderful,
but it's hard to know how to translate a desired point size into an actual
font choice on a Sun. Asking the user to measure his screen when he starts
a client doesn't seem like much of an option. :-)
Anyone know how to solve this problem? (hacks welcome)
-- John Irwin, Franz Inc. jdi%franz.uucp@ucbarpa.berkeley.edujanssen@titan.sw.mcc.com (Bill Janssen) (11/02/88)
This is an on-the-fly mod of a subroutine I keep around for getting
info about sun screens:
#include <sun/fbio.h>
#include <sys/file.h>
#include <sys/ioctl.h>
#include <stdio.h>
#define AND &&
#define OR ||
#define NOT !
/* Get some info about a screen device
Ref: 1. pp. 119-129, SunCore Ref Manual
2. man entry for "fbio(4S)"
3. /usr/include/sun/fbio.h */
screen_info (screen_name, type, height, width, depth, cmsize, size)
char *screen_name;
int *type, *width, *height, *depth, *cmsize, *size;
{
int screen_fd;
int stat;
struct fbtype fb;
screen_fd = open (screen_name, O_RDWR, 0);
if (screen_fd < 0)
{
perror ("screen_info: Open on framebuffer failed");
return 0;
}
stat = ioctl (screen_fd, FBIOGTYPE, &fb);
if (stat < 0)
{
perror ("screen_info: ioctl on framebuffer failed");
close (screen_fd);
return 0;
}
close (screen_fd);
*type = fb.fb_type;
*width = fb.fb_width;
*height = fb.fb_height;
*depth = fb.fb_depth;
*cmsize = fb.fb_cmsize; /* colormap size */
*size = fb.fb_size; /* ?? */
return 1;
}
-- jdi@sparky.UUCP (John Irwin) (11/02/88)
Your message:
This is an on-the-fly mod of a subroutine I keep around for getting
info about sun screens:
...
*type = fb.fb_type;
*width = fb.fb_width;
*height = fb.fb_height;
*depth = fb.fb_depth;
*cmsize = fb.fb_cmsize; /* colormap size */
*size = fb.fb_size; /* ?? */
...
--------
Unfortunately, width and height here refer to the number of *pixels*, not the
physical dimensions in linear inches.
-- Johnguy@auspex.UUCP (Guy Harris) (11/02/88)
>So we went about looking for a way to query the operating system (or >whatever) to determine how big a physical screen you've got. Guess what? >There doesn't appear to be a way! I don't know that the CPU even *knows* how big the physical screen is, so I'm not sure it could answer you even if you could query it. Are there not different monitors available for Suns with different physical sizes but the same resolution? I think the only thing the CPU knows is what kind of frame buffer is attached.
bzs@encore.com (Barry Shein) (11/04/88)
Although I agree there's probably no way for a machine to know what size screen (physically) is attached to it this could be solved by simply adding yet another command-line switch to the X servers, I assume the human could ascertain it (I guess it's not really screen size but dimensions of the useable display area which contains the pixel height/width which is desired, could be an inch or more smaller than the screen size.) Obviously one could make a screen which somehow told the system its dimensions but hey, another nuisance for third-party vendors to play catchup with. It is useful if your goal in life is to make a one-inch line actually be an inch, or a 12-pt type face measure 12 points etc. Now, if one's screen is suddenly hit with one of those shrinking rays from Zryx maybe we need a SIGCRTCH? -Barry Shein, ||Encore||
chris@mimsy.UUCP (Chris Torek) (11/13/88)
In article <4089@encore.UUCP> bzs@encore.com (Barry Shein) writes: >Although I agree there's probably no way for a machine to know what >size screen (physically) is attached to it this could be solved by >simply adding yet another command-line switch to the X servers .... Perhaps there should be standard files (probably in /dev) that contain the physical dimensions of the screens associated with the various frame buffers attached to a workstation. If the hardware is changed, the sysadmin can change the file in /dev at the same time. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris