Bug 77064
| Summary: | window fixed in position | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | jmccann |
| Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | cschalle, hp |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-02-21 18:50:04 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
jmccann
2002-10-31 17:32:56 UTC
This may happen if the system clock goes backward, that's the only case I know of. metacity 2.4.3 fixes the clock issue, you can get a test package at ftp://people.redhat.com/hp/gnomehide/8.0 Thanks for the quick reply! It looks like a time problem. I noticed that when I used Fn-F8 to switch displays the gnome clock would change. For example, if I perform "sudo rdate -s ntp.jhu.edu" between step 2 and step 3 lets say that my clock changes from 8am to 1pm (the correct local time). Then when I change displays in step 5 the gnome clock reads 8am. If I sync the clock again, I am able to move gnome terminal as expected. I installed your new metacity and, unfortunately, it doesn't fix the problem. I even rebooted after installing it. It seems that the inability to move/resize windows is only a symptom of the problem. I think the real problem is that the mouse button is not recognized as being held down. PS. Do you think there is another bug here where shutdown is not correctly setting my bios clock? It's possible that the X server itself gets confused if you play with the time enough. You can use "xev" to look at mouse button events and see what you're getting. I don't have a lot of ideas if it wasn't the time-set-backward bug that I knew about... When it works the event for motion with button 3 down is:
MotionNotify event, serial 20, synthetic NO, window 0x1e00001,
root 0x78, subw 0x0, time 1004178880, (94,146), root:(100,192),
state 0x400, is_hint 0, same_screen YES
When is doesn't work (when the time is wrong) the event with button 3 down is:
MotionNotify event, serial 20, synthetic NO, window 0x1e00001,
root 0x78, subw 0x0, time 1004102453, (162,142), root:(168,188),
state 0x0, is_hint 0, same_screen YES
First, I don't think changing the display from LCD to external should reset the
system time. Second, X shouldn't really care what the time is since the
relationship between the button down event and the motion event is always the same.
Should I submit these as X server bugs? Thanks for your help.
> First, I don't think changing the display from LCD to external should reset the > system time. I would certainly agree with that. ;-) > Second, X shouldn't really care what the time is since the > relationship between the button down event and the motion event is always the > same. The "state" field is mangled in your second example, so it seems X loses track of whether the button is down. This looks like an X server (or hardware/BIOS) problem to me, so moving. *** This bug has been marked as a duplicate of 63509 *** Changed to 'CLOSED' state since 'RESOLVED' has been deprecated. |