Updated README.md for framebuffer/DRM port. Clarified a comment about the 'common' mouse handling code. Updated PDC_VER_DAY and HISTORY.md.

Author: Bill-Gray

common/mouse.c

@@ -122,6 +122,11 @@ while( the platform has a new mouse event && TRUE == _add_raw_mouse_event( ))
       }
    }
 
+   (Strictly speaking,  the naps are unnecessary.  Without them,  you
+simply go to 100% CPU usage looking for the next mouse event during those
+SP->mouse_wait milliseconds.  With enough clicking,  those cycles would
+start to add up.)
+
    (2) In the above logic,  you can't get double-clicks without also getting
 single-clicks,  and you can't get triple-clicks without getting doubles and
 singles.  This may be changed eventually,  though it seems like an unlikely

curses.h

@@ -44,7 +44,7 @@ Defined by this header:
 #define PDC_VER_CHANGE   2
 #define PDC_VER_YEAR   2025
 #define PDC_VER_MONTH     6
-#define PDC_VER_DAY      19
+#define PDC_VER_DAY      23
 
 #define PDC_STRINGIZE( x) #x
 #define PDC_stringize( x) PDC_STRINGIZE( x)

docs/HISTORY.md

@@ -1,6 +1,33 @@
 Generally speaking,  this history mentions only the more significant
 changes.  See the git log for full details.
 
+Current version - 2025 June 23
+==============================
+
+Minor new features
+------------------
+
+- More fixes a la those in 'upstream' PDCurses to make MANUAL.md more
+  markdown-friendly.  3e528a85d4  ed3103d705
+
+- Framebuffer and DRM ports now have full mouse support.  7ec7b956f0
+
+- Zooming/panning around in 'picsview' no longer flickers.  af4a7c5d72
+
+Bug fixes
+---------
+
+- C23-compliant compilers (and some others) objected to the casting of
+  function pointers returned by GetProcAddress().  ce60aa6608
+
+- If PDC_NCMOUSE is #defined,  the behavior of the mouse routines should
+  copy that of ncurses,  warts and all.  Scroll-up and down are mapped
+  to presses on buttons 4 and 5,  and tilt-scroll events and "real"
+  button 4 and 5 events are ignored.  0de9f723e3
+
+- Minor fixes for Digital Mars and OpenWATCOM compilation of WinCon and
+  WinGUI.  a4c01532e8  6af988940d  6eedea061c
+
 PDCursesMod 4.5.2 - 2025 June 19
 ================================
 

fb/README.md

@@ -6,7 +6,6 @@ This directory contains source code to support PDCursesMod using either the 'tra
 Shortcomings (which should be addressable) are :
 
 - It assumes 8 or 32 bits/pixel.  It should be relatively easy to support other bit depths with suitable changes to the `PDC_transform_line()` function in `pdcdisp.c`,  but I don't currently have a system that supports 15-, 16-, or 24-bits per pixel.   (Fortunately,  such displays appear to be getting rare.  I had to dig out an elderly laptop to test the 8-bit display.)
-- The mouse is not supported.  It looks as if the `uinput` system allows one to access the mouse without needing X;  I need to investigate.  `gpm` may be a better choice.
 - Italic and bold fonts are synthesized from the given font,  but it would be relatively easy to let specific fonts be used for that purpose.
 
 The default font,  borrowed from [DOSVGA](../dosvga),  is fixed at 8x14.  Set the environment variable `PDC_FONT` to point to the name of a PSF1, PSF2,  or VGA font to use that font instead.  (See `psf.c` for comments on these font formats.)  Hit Alt-Minus to toggle between the built-in and the `PDC_FONT`-specified fonts.  Add more fonts with `PDC_FONT2`,  `PDC_FONT3`,  etc;  Alt-Minus will then cycle among all specified fonts and the built-in one.
@@ -26,18 +25,23 @@ In no order :
 - Fallback fonts.
 - Fullwidth characters.  For these,  we may need one font that is,  say,  8 pixels wide (for most characters) and one that is 16 pixels wide for the fullwidth characters.  That may be an extension of the above task of having fallback fonts : "Didn't find the desired glyph in the 'normal' font?  Maybe it's in a fallback font."  Alternatively,  we can make use of the fact that the Unicode-to-glyph table can have the same Unicode value twice.  The first one would point to a 'left' glyph;  the second to a 'right' glyph.  Probably the way I'll go...
 - Programmatic resizing through `resize_term()`,  both before and after calling `initscr()`.
-- User-resizing and moving of windows,  if we can get the mouse to work.
+- User-resizing and moving of windows.
 - Reserve a line at the top wherein the application title and close/full-screen/minimize buttons can go.  The `ripoffline()` function may be useful here.
 
 Building
 --------
 
-Run `make`, `make WIDE=Y`, or `make UTF8=Y`. Add `DLL=Y` to get a shared library (.so) on *nix builds.  On Linux,  add `DRM=Y` to get a DRM version;  otherwise,  you'll get a Linux framebuffer version.  On *BSD,  use `gmake`,  and you get DRM no matter what (as the name implies,  the Linux framebuffer is Linux-only).  Run `make install` (you'll probably need to be root or use `sudo` for this) to install the shared library.
+Run `make`, `make WIDE=Y`, or `make UTF8=Y`. Add `DLL=Y` to get a shared library (.so) on *nix builds.  On Linux,  add `DRM=Y` to get a DRM version;  otherwise,  you'll get a Linux framebuffer version.  On *BSD,  use `gmake`,  and you get DRM no matter what (as the name implies,  the Linux framebuffer is Linux-only).  Add `HAVE_MOUSE=Y` for mouse support (this uses the `evdev` library).  Run `make install` (you'll probably need to be root or use `sudo` for this) to install the shared library.
+
+Permissions
+-----------
+
+Access to either the framebuffer or to DRM requires that a user be in the `video` group.
 
 Caveats
 -------
 
-See above.  This all works nicely and stably,  but it lacks mouse input and support for 15 and (possibly) 16-bit and 24-bit displays.
+See above.  This all works nicely and stably,  but it lacks support for 15 and (possibly) 16-bit and 24-bit displays.
 
 Distribution Status
 -------------------