I have two problems which I would like to solve for the X11 version of GLFW (they are both related to fullscreen functionality):
With pure Xlib (no XF86VidMode), is there a way to determine the physical display size? DisplayWidth/DisplayHeight & WidthOfScreen/HeightOfScreen unfortunately return the virtual size of the display.
With XFree86 it is possible to change the display resolution with CTRL+ALT+[keypad +/-]. Is there a way to prevent this behaviour (block these actions), or at least detect them.
Unfortunately I don’t know the answer to your first question.Regarding the CTRL+ALT+[±] though,since xlib uses VidMode to switch resolution at runtime you can use XF86VidModeLockModeSwitch(or something like that,jesus are these names long) to do so.Just remember to unlock before exiting.I’m going to post on the first one if I find anything.
Edit:regarding the display size.There must be a way to find out since most window managers have a max size toggle for their windows.I doubt they rely on VidMode,besides it doesn’t make sense for xlib ont to expose something like that.Maybe it can be calculated from the calls you used( and others).
[This message has been edited by zen (edited 06-04-2002).]
Yes, you’re correct about XF86VidModeLockModeSwitch. I’m surprised I didn’t see it before, it’s exactly what I need.
About the other question, I still have not found a solution. Even if there are no clear solutions, there usually is some way to solve these things (in my experience). For instance, there is no way to set the viewport without XF86VidModeSetViewPort(), but you can “fool” the display by using XWarpPointer() to position the cursor in the four corners of the viewport that you want. Heck, on the C=64 you could not access memory address $0001, since it was mapped to a control register in the CPU, but people worked around it by using techniques like sprite collision detection…
I’m glad my question got your attention You’re obviously very skilled with the X Window System.
Yes, the C=64 really rocked (and still does, apparently). I’m still amazed by how well balanced the design was - pretty much everything was HW accelerated back then: animated sprites (change animation “frame” by changing a memory pointer, and screen position by setting three bytes), HW collision detection (wouldn’t that be nice in OpenGL? ), three channel sound with automatic envelope generation (and filters etc), HW graphics scrolling (change only one byte to control display pixel offset), character based graphics display (only need to change 40x25=1000 bytes for a complete screen update, where the screen consists of 32000 or 64000 pixels depending on resolution), etc. etc.
[This message has been edited by marcus256 (edited 06-05-2002).]
One such trick I heard about is to get the viewport size for the root window. This should give you the physical screen size if I understood the trick right. Never tested it myself.
Zico, do you have any idea of how that is done? I stumbled upon something called _NET_DESKTOP_VIEWPORT, is that it? (but I think it’s the viewport position, not size)
Pretty clever that.Should work.Btw rob since you seem to know stuff about X,what’s the best way of getting the contents of a window(in 8bpp,16bpp,24bpp whatever) in order to save them to a file?I’ve tried XGetImage with 0x0L for plane_mask and ZPixMap but I get a blank image.May be a packing problem.Sorry for hijacking your thread marcus.
Hello again… I tried your source, but the three versions all gave the same result (I’m using a 1024x768 virtual display on a 800x600 screen to test this). I think you need to get some sort of viewport information (the size of the root window seems to always be the size of the virtual display - which seems logical). I suspect that it is a non-standard thing (perhaps there is a window manager protocol or something similar that can give this sort of information?).
No, I do not know how to do it or even if it is possible. Perhaps could you get the graphic context and check if the clip area is set to the physical screen size?
Other unices than linux is often used on more expensive system with big monitors perhaps is virtual desktops not so common on them anyway?
[qoute]Perhaps could you get the graphic context and check if the clip area is set to the physical screen size?[/qoute]
I suppose you’re refering to the GL context? I think it is set to the window size, which in turn is set to the (virtual) desktop size.
Other unices than linux is often used on more expensive system with big monitors perhaps is virtual desktops not so common on them anyway?
I guess you’re right. Personally I’m not very concerned, but the thing is that when a virtual desktop is used, the fullscreen functionality of GLFW becomes pretty useless (the mouse cursor is hidden and always centered, so it’s impossible to ‘pan’ the view with the mouse). I will release GLFW as it is anyway, but it would be a very nice bonus if I could solve this.
I was thinking about the context for xlib graphics that the root window is using. I have not checked but it seems possible that it is set to the actual screen size.
If you can not get the actual screen size is an alternative to export a fullscreen function that takes width and height as argument. I have not checked your library yet but if it can be mixed with X code could the extra function be good. I assume most unices has X extensions that could be used to get/set the width and height.
One point I don’t understand is why you don’t want to use VidMode(or don’t want ot rely on it anyway).I think everybody who has XFree86 has it.Do you know of any reasons why someone would tell X not to load it?I’m asking because I rely on the fact that it will be there.
PS:As I said in my first post windowmanagers (at leat enlightnenment) seem to know the actual size of the screen.Just take a peek at the code of a simple one in the part that maximizes windows and see how the width,height is calculated.It’s not a very attractive solution I know but it might work
[This message has been edited by zen (edited 06-12-2002).]
#include <GL/glut.h>
then make sure you have
int main(int argc, char **argv){
then just type GlutInit(&argc, argv);
then you need glutGameModeString(“640x480:16@16”);
then use
glutEnterGameMode();
and that should do it
), three channel sound with automatic envelope generation (and filters etc), HW graphics scrolling (change only one byte to control display pixel offset), character based graphics display (only need to change 40x25=1000 bytes for a complete screen update, where the screen consists of 32000 or 64000 pixels depending on resolution), etc. etc.