Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Q quartz-wm
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 12
    • Issues 12
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 2
    • Merge requests 2
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • xorg
  • app
  • quartz-wm
  • Issues
  • #1

Closed
Open
Created May 23, 2019 by Bugzilla Migration User@bugzilla-migration

El Capitan - xterms blow off screen after sleep

Submitted by Randy Bush

Assigned to Jeremy Huddleston Sequoia

Link to original bug (#92653)

Description

old ticket - http://xquartz.macosforge.org/trac/ticket/2180

3" rMBP mid-2014 XQuartz 2.7.8 xterm using --courier-medium-r-normal--12-----*-iso8859-1

multiple desktops (née spaces), each with 12 (4x3) xterms

when it wakes from a snooze, the xterms have scattered, half of them off-screen. i can command-` cycle to the off-screen ones and ^D them, but that's about it.

Changed 9 days ago by jeremyhu@…

Milestone set to 2.8.0
Priority changed from Not Set to Expected
Type changed from crash to usability

Hmm. I suspect that the issue might be that we're getting notified of a state with 0 displays attached as part of the sleep/wake cycle, and that is confusing things.

comment:3 Changed 9 days ago by randy@…

and how might i test that hypothesis? or where can i whack the notification? comment:4 Changed 8 days ago by jeremyhu@…

Take a look at _QuartzRandRUpdateFakeModes in quartzRandR.c

If we get back a list of 0 displays, we just use a fake 800x600 one.

​http://cgit.freedesktop.org/xorg/xserver/tree/hw/xquartz/quartzRandR.c#n516 comment:5 Changed 8 days ago by randy@…

ok, i see that.

if it thinks it is 800x600 would it push xterms well outside those limits?
of course, there is a DISPLAY in the environment

% env | grep DISPLAY
DISPLAY=:0

i am running binary, not source, so can not really gdb or anything useful 

is there a way to set or push the display parms you seek? and note that this was a change from yosemite to el capitan. comment:6 Changed 8 days ago by jeremyhu@…

That DISPLAY envvar is not the one expected, but it is not related to this problem. Please make sure you're not manually setting DISPLAY anywhere.

I'd expect your windows to maybe be rearranged within the 800x600 region and then stay there when you resume.

I suggest you build from source and add logging to that function to triage further. comment:7 Changed 7 days ago by randy@…

more symtomatic data

it affects spawned xterms a la

/usr/X11/bin/xterm -geometry 80x24+1452+680 &

but, if i micro-move that xterm using the title bar, it flashes before settling (as if it moved off the screen and then back). and then it stays stable across sleep etc. so at least i have a way to keep working.

Version: 2.7.9 (xserver-1.17.4)

Assignee
Assign to
Time tracking