If the console is resized to increase its dimensions, gpm fails to
recognize this, and restricts the mouse to a region of the screen
equal to the previous console mode in size. While this is not a
serious problem on systems with vgacon where the console size should
normally be set only once at boot time, it is quite annoying on
systems with fbcon, since each virtual console can be resized
independently by users, assuming the have access to /dev/fb*.

I am running debian 2.1, with linux 2.2.13. If you need it I can
provide other information, but I assure you, the problem is not
related to any particular kernel or debian version. In fact, the
problem is not even unique to debian. I fixed it manually on my
non-debian machine (which is using fbcon) by making gpm check and
update the console size every time the mouse is moved, but I assume
that's not very efficient, so I doubt my patch is worth sending. Right
now my debian system isn't using fbcon yet so it's not a big deal, but
I am considering working on a vga linear-256 and textmode fbcon driver
sometime, and it'd be nice if I didn't have to hack gpm manually, and
if nobody else had to experience this problem in the future.

If you do find a good solution to this problem, please let the gpm
maintainers know about your fix. Some users of non-debian systems
might appreciate it too. :)

Thanks!

Does anything bad happen if you shrink the screen size below what gpm
thinks it is?
<snip>

Could I get the patch anyways? Just to see how you did it?
I'm not entirely up to date on that chunk of gpm, but I have a few
ideas..

I'd like to start messing with the fbcon stuff, but at the moment am not
in a position to do so, but I'd be interested in hearing what you have in
mind..

Will do..

Zephaniah E. Hull..