From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5d375e920807030813n49aef88gb26666b70419e159@mail.gmail.com> Date: Thu, 3 Jul 2008 17:13:16 +0200 From: Uriel To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <14ec7b180807030757u32f499ebvb918df63fdaf1c48@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <509071940807030738r4dae6987j57b3db92bf7606bf@mail.gmail.com> <14ec7b180807030757u32f499ebvb918df63fdaf1c48@mail.gmail.com> Subject: Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong Topicbox-Message-UUID: d8fc07f6-ead3-11e9-9d60-3106f5b1d025 This seems to be (given my limited understanding) similar to what acme-sac is doing. Is there any way we could solve the current state of affairs with slightly diverging gui/draw codebases for p9p, drawterm, 9vx, acme-sac and inferno-os? Each seems to have a set of bugs that somewhat overlaps with the other projects, and they have to be rediscovered, and the fixes moved around again and again. That also would mean that new ports, to for example win32, would propagate much more easily (or at least as far as the gui code is concerned). Peace and best wishes uriel On Thu, Jul 3, 2008 at 4:57 PM, andrey mirtchovski wrote: > I think the problem comes from 9vx picking up the main display's > dimensions as the preallocation for "full screen". Drawterm has a fix > for that which loops through all the currently attached displays and > picks up the one with the largest size to decide what the "maximum > dimensions" should be. > > here's the relevant code from drawterm: > > /* figure out which display is the largest and return its bounds so we can > * preallocate drawterm's screen to that > */ > Point > get_largest_screen() > { > CGDirectDisplayID *displaylist; > CGDisplayCount displaycount; > OSErr err; > int i; > Point max = Pt(0, 0); > Point curr; > err = CGGetActiveDisplayList(0, NULL, &displaycount); > if(err != noErr) > sysfatal("can not enumerate active displays"); > > displaylist = (CGDirectDisplayID *)malloc(displaycount * > sizeof(CGDirectDisplayID)); > if(displaylist == NULL) > sysfatal("can not allocate memory for display list"); > > err = CGGetActiveDisplayList(displaycount, displaylist, &displaycount); > if(err != noErr) > sysfatal("can not obtain active display list"); > > for(i = 0; i < displaycount; i++) { > curr.x = CGDisplayPixelsWide(displaylist[i]); > curr.y = CGDisplayPixelsHigh(displaylist[i]); > > if(max.x < curr.x) > max.x = curr.x; > if(max.y < curr.y) > max.y = curr.y; > } > > free(displaylist); > > return max; > > } > you will need to modify _screeninit() in 9vx/osx/screen.c to something like: > > Point max = get_largest_screen(); > osx.fullscreenr = Rect(0, 0, max.size.width, max.size.height); > > this is tentative. i have no second screen to test right now. > > On Thu, Jul 3, 2008 at 8:38 AM, Anthony Sorace wrote: >> I have a 10.5 MacBook with an external display attached. When I start >> 9vx, things look normal. I can resize the window on the main display. >> If I move it to the second display and resize, the window goes from >> "good" to "bad": >> >> http://strand1.com/who/anthony/bug/good.png >> http://strand1.com/who/anthony/bug/bad.png >> >> Resizing the window back to the original geometry makes the window "good" again. >> >> Note that this is "just" a display issue. Things within 9vx continue >> to run just fine, and can update the display (although that becomes >> unreliable, especially in the portion of rio windows to the left of >> where they should be). Dragging my mouse over where the rio window >> border should be causes the cursor to turn into the "resize" cursor, >> and resizing works fine, dragging the still-slanted window around. >> >> This happens independent of what's running within 9vx: I see the same >> thing even with no rio. >> Anthony >> >> > >