aboutsummaryrefslogtreecommitdiff
path: root/lib/libvgl
Commit message (Collapse)AuthorAgeFilesLines
* lib/libvgl/main.c: remove an extra semicolonrilysh2024-02-031-1/+1
| | | | | | Signed-off-by: rilysh <nightquick@proton.me> Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/959
* lib: Automated cleanup of cdefs and other formattingWarner Losh2023-11-271-1/+0
| | | | | | | | | | | | | | | | Apply the following automated changes to try to eliminate no-longer-needed sys/cdefs.h includes as well as now-empty blank lines in a row. Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/ Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/ Remove /\n+#if.*\n#endif.*\n+/ Remove /^#if.*\n#endif.*\n/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/ Sponsored by: Netflix
* Remove $FreeBSD$: two-line nroff patternWarner Losh2023-08-161-2/+0
| | | | Remove /^\.\\"\n\.\\"\s*\$FreeBSD\$$\n/
* Remove $FreeBSD$: one-line sh patternWarner Losh2023-08-162-2/+0
| | | | Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
* Remove $FreeBSD$: one-line .c patternWarner Losh2023-08-166-12/+0
| | | | Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
* Remove $FreeBSD$: two-line .h patternWarner Losh2023-08-161-2/+0
| | | | Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
* libvgl: Remove set but unused andmask variable from VGLMouseInit.John Baldwin2023-06-201-4/+1
| | | | Reported by: GCC
* Update Makefile.depend filesSimon J. Gerraty2019-12-111-1/+0
| | | | | | | | | | | | | Update a bunch of Makefile.depend files as a result of adding Makefile.depend.options files Reviewed by: bdrewery MFC after: 1 week Sponsored by: Juniper Networks Differential Revision: https://reviews.freebsd.org/D22494 Notes: svn path=/head/; revision=355617
* Fix copying planar bitmaps when the horizontal start and end are both notBruce Evans2019-05-031-12/+9
| | | | | | | | | | | | | | | | | multiples of 8. Then the misaligned pixels at the end were not copied. Clean up variable misuse related to this bug. The width in bytes was first calculated correctly and used to do complicated reblocking correctly, but it was stored in an unrelated scratch variable and later recalculated with an off-by-1-error, so the last byte (times 4 planes) in the intermediate copy was not copied. This doubly-misaligned case is especially slow. Misalignment complicates the reblocking, and each misaligment requires a read before write, and this read is still not done from the shadow buffer. Notes: svn path=/head/; revision=347054
* Support all reasonable cursor sizes. Reduce the size of the standardBruce Evans2019-04-291-56/+146
| | | | | | | | | | | | | | cursor from 16x16 (with 6 columns unused) to 10x16 and rename it to the "small" cursor. Add a "large" 19x32 cursor and use it for screen widths larger than 800 pixels. Use libvgl's too-small indentation for the large data declarations. MOUSE_IMG_SIZE = 16 is still part of the API. If an application supplies invalid bitmaps for the cursor, then the results may be different from before. Notes: svn path=/head/; revision=346895
* Oops, r346889 broke showing of the mouse cursor after clearing, byBruce Evans2019-04-291-1/+1
| | | | | | | | forgetting to tell the bitmap-copying clearing method to preserve the cursor. Notes: svn path=/head/; revision=346890
* Refactor and simplify hiding the mouse cursor and fix bugs caused byBruce Evans2019-04-294-50/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | complications in the previous methods. r346761 broke showing the mouse cursor after changing its state from off to on (including initially), since showing the cursor uses the state to decide whether to actually show and the state variable was not changed until after null showing. Moving the mouse or copying under the cursor fixed the problem. Fix this and similar problems for the on to off transition by changing the state variable before drawing the cursor. r346641 failed to turn off the mouse cursor on exit from vgl. It hid the cursor only temporarily for clearing. This doesn't change the state variable, so unhiding the cursor after clearing restored the cursor if its state was on. Fix this by changing its state to VGL_MOUSEHIDE using the application API for changing the state. Remove the VGLMouseVisible state variable and the extra states given by it. This was an optimization that was just an obfuscation in at least the previous version. Staticize VGLMouseAction(). Remove VGLMousePointerShow/Hide() except as internals in __VGLMouseMode(). __VGLMouseMouseMode() is the same as the application API VGLMouseMouseMode() except it returns the previous mode which callers need to know to restore it after hiding the cursor. Use the refactoring to make minor improvements in a simpler way than was possible: - in VGLMouseAction(), only hide and and unhide the mouse cursor if the mouse moved - in VGLClear(), only hide and and unhide the mouse cursor if the clearing method would otherwise clear the cursor. Notes: svn path=/head/; revision=346889
* Use __VGLBitmapCopy() directly to show the mouse cursor. The mouseBruce Evans2019-04-261-15/+2
| | | | | | | | | cursor must be merged with the shadow buffer on the way to the screen, and __VGLBitmapCopy() now has an option to do exactly that. This is insignificantly less efficient. Notes: svn path=/head/; revision=346761
* Merge __VGLGetXY() back into VGLGetXY(). They were split to simplifyBruce Evans2019-04-261-16/+10
| | | | | | | | the organization of fixes for the mouse cursor, but after optimizations VGLGetXY() automatically avoids the mouse cursor. Notes: svn path=/head/; revision=346754
* In VGLClear(), check for the overlap of the mouse cursor in the wholeBruce Evans2019-04-261-1/+1
| | | | | | | | | display, not just in the unpanned top left corner. This currently makes no difference since the kernel erroneously doesn't allow moving the cursor completely outside of the unpanned corner. Notes: svn path=/head/; revision=346752
* Remove save/restore of the crtc and gdc registers when showing andBruce Evans2019-04-261-27/+0
| | | | | | | | | | hiding the mouse cursor. The showing and hiding is often done asynchronously in a not very safe signal handler, but the state of these registers and much more is protected from the signal handler in a better way by deferring mouse signals while the state is in use. Notes: svn path=/head/; revision=346747
* Fix the only known remaining (libvgl) bug for 24-bit modes, and enableBruce Evans2019-04-262-6/+20
| | | | | | | | | | | | support for 24-bit modes. The non-segmented case has worked for a long time, but the segmented case could never have worked since 24-bit accesses may cross a window boundary but the window was not changed in the middle of the specialized 24-bit accesses for writing a single pixel. Notes: svn path=/head/; revision=346745
* Restore the line width in VGLEnd(). The line width may be changed byBruce Evans2019-04-261-0/+4
| | | | | | | | | VGLSetVScreenSize(), but is not restored by mode switches to at least standard text mode, so must be restored explicitly. Standard text mode displayed blanks when the line width was doubled. Notes: svn path=/head/; revision=346744
* Fix an off-by-1 error for copying overlapping bitmaps in r346416. ForBruce Evans2019-04-261-1/+1
| | | | | | | | | nonzero height, the first line in the original order was not copied, and for zero height, garbage lines before the first were copied until a crash occurred. Notes: svn path=/head/; revision=346743
* Restore doing nothing for calls to VGLEnd() after the first. I broke thisBruce Evans2019-04-251-0/+1
| | | | | | | | | | | in r346631. VGLEnd() clears some state variables as it restores state, but not all of them, so it still needs to clear a single state variable to indicate that it has completed. Put this clearing back where it was (at the start instead of the end) to avoid moving bugs in the signal handling. Notes: svn path=/head/; revision=346678
* Avoid hiding and unhiding the mouse cursor when copying bitmaps to theBruce Evans2019-04-243-18/+45
| | | | | | | | | | screen. Instead, copy a merged bitmap 1 line at a time. This fixes flashing of the cursor and is faster in all modes (especially in planar modes). Notes: svn path=/head/; revision=346641
* Refactor mouse freezing and fix some minor bugs.Bruce Evans2019-04-244-53/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | VGLMouseFreeze() now only defers mouse signals and leaves it to higher levels to hide and unhide the mouse cursor if necessary. (It is never necessary, but is done to simplify the implementation. It is slow and flashes the cursor. It is still done for copying bitmaps and clearing.) VGLMouseUnFreeze() now only undoes 1 level of freezing. Its old optimization to reduce mouse redrawing is too hard to do with unhiding in higher levels, and its undoing of multiple levels was a historical mistake. VGLMouseOverlap() determines if a region overlaps the (full) mouse region. VGLMouseFreezeXY() is the freezing and a precise overlap check combined for the special case of writing a single pixel. This is the single-pixel case of the old VGLMouseFreeze() with cleanups. Fixes: - check in more cases that the application didn't pass an invalid VIDBUF - check for errors from copying a bitmap to the shadow buffer - freeze the mouse before writing to the shadow buffer in all cases. This was not done for the case of writing a single pixel (there was a race) - don't spell the #defined values for VGLMouseShown as 0, 1 or boolean. Notes: svn path=/head/; revision=346639
* Fix some races and screeen clearing in VGLEnd().Bruce Evans2019-04-241-3/+3
| | | | | | | | | | | | | | | | | | | | | | | The mouse signal SIGUSR2 was not turned off for normal termination and in some other cases. Thus mouse signals arriving after the frame buffer was unmapped always caused fatal traps. The fatal traps occurred about 1 time in 5 if the mouse was wiggled while vgl is ending. The screen switch signal SIGUSR1 was turned off after clearing the flag that it sets. Unlike the mouse signal, this signal is handled synchronously, but VGLEnd() does screen clearing which does the synchronous handling. This race is harder to lose. I think it can get vgl into deadlocked state (waiting in the screen switch handler with SIGUSR1 to leave that state already turned off). Turn off the mouse cursor before clearing the screen in VGLEnd(). Otherwise, clearing is careful to not clear the mouse cursor. Undrawing an active mouse cursor uses a lot of state, so is dangerous for abnormal termination, but so is clearing. Clearing is slow and is usually not needed, since the kernel also does it (not quite right). Notes: svn path=/head/; revision=346631
* Fix mouse cursor coloring in depths > 8 (previously, a hack that onlyBruce Evans2019-04-224-44/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | worked right for white interiors and black borders was used). Advertise this by changing the default colors to a red interior and a white border (the same as the kernel default). Add undocumented env variables for changing these colors. Also change to the larger and better-shaped 16x10 cursor sometimes used in the kernel. The kernel choice is fancier, but libvgl is closer to supporting the larger cursors needed in newer modes. The (n)and-or logic for the cursor doesn't work right for more than 2 colors. The (n)and part only masks out all color bits for the pixel under the cursor when all bits are set in the And mask. With more complicated logic, the non-masked bits could be used to implement translucent cursors, but they actually just gave strange colors (especially in packed and planar modes where the bits are indirect through 1 or 2 palettes so it is hard to predict the final color). They also gave a bug for writing pixels under the cursor. The non-masked bits under the cursor were not combined in this case. Drop support for combining with bits under the cursor by making any nonzero value in the And mask mean all bits set. Convert the Or mask (which is represented as a half-initialized 256-color bitmap) to a fully initialized bitmap with the correct number of colors. The 256-color representation must be as in 3:3:2 direct mode iff the final bitmap has more than 256 colors. The conversion of colors is not very efficient, so convert at initialization time. Notes: svn path=/head/; revision=346580
* Use a shadow buffer and never read from the frame buffer. Remove large slowBruce Evans2019-04-215-314/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | code for reading from the frame buffer. Reading from the frame buffer is usually much slower than writing to the frame buffer. Typically 10 to 100 times slower. It old modes, it takes many more PIOs, and in newer modes with no PIOs writes are often write-combined while reads remain uncached. Reading from the frame buffer is not very common, so this change doesn't give speedups of 10 to 100 times. My main test case is a floodfill() function that reads about as many pixels as it writes. The speedups are typically a factor of 2 to 4. Duplicating writes to the shadow buffer is slower when no reads from the frame buffer are done, but reads are often done for the pixels under the mouse cursor, and doing these reads from the shadow buffer more than compensates for the overhead of writing the shadow buffer in at least the slower modes. Management of the mouse cursor also becomes simpler. The shadow buffer doesn't take any extra memory, except twice as much in old 4-plane modes. A buffer for holding a copy of the frame buffer was allocated up front for use in the screen switching signal handler. This wasn't changed when the handler was made async-signal safe. Use the same buffer the shadow (but make it twice as large in the 4-plane modes), and remove large special code for writing it as well as large special code for reading ut. It used to have a rawer format in the 4-plane modes. Now it has a bitmap format which takes twice as much memory but can be written almost as fast without special code. VIDBUFs that are not the whole frame buffer were never supported, and the change depends on this. Check for invalid VIDBUFs in some places and do nothing. The removed code did something not so good. Notes: svn path=/head/; revision=346488
* Fix missing restoring of the mouse cursor position, the border color and theBruce Evans2019-04-214-0/+38
| | | | | | | blank state after a screen switch. Notes: svn path=/head/; revision=346486
* Make libvgl mostly work without superuser privilege in direct modes byBruce Evans2019-04-203-20/+48
| | | | | | | | | | | | | | | | | | | | | | not doing any unnecessary PIO instructions or refusing to start when the i/o privilege needed for these instructions cannot be acquired. This turns off useless palette management in direct modes. Palette management had no useful effect since the hardware palette is not used in these modes. This transiently acquires i/o privilege if possible as needed to give VGLSetBorder() and VGLBlankDisplay() a chance of working. Neither has much chance of working. I was going to drop support for them in direct modes, but found that VGLBlankDisplay() still works with an old graphics card on a not so old LCD monitor. This has some good side effects: reduce glitches for managing the palette for screen switches, and speed up and reduce async-signal-unsafeness in mouse cursor drawing. Notes: svn path=/head/; revision=346454
* Fix copying of overlapping bitmaps. The cases of copying within theBruce Evans2019-04-191-3/+13
| | | | | | | | | | | | | | | | | | screen bitmap and within a single MEMBUF were broken when first source line is before the first destination line and the sub-bitmaps overlap. The fix just copies horizontal lines in reverse order when the first source line is before the first destination line. This switches directions unnecessarily in some cases, but the switch is about as fast as doing a precise detection of overlaps. When the first lines are the same, there can be undetected overlap in the horizontal direction. The old code already handles this mostly accidentally by using bcopy() for MEMBUFs and by copying through a temporary buffer for the screen bitmap although the latter is sub-optimal in direct modes. Notes: svn path=/head/; revision=346416
* Sigh, r346279 was also a test version with the reduced size doubled (soBruce Evans2019-04-161-1/+1
| | | | | | | | it was actually double the full size in current kernels where the reduction is null, so overran the mmapped() buffer). Notes: svn path=/head/; revision=346280
* Oops, r346278 committed a test version with the change annulled.Bruce Evans2019-04-161-1/+1
| | | | Notes: svn path=/head/; revision=346279
* Quick fix for slow clearing and context switches of large frame buffersBruce Evans2019-04-161-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with old kernels, by breaking the support for large frame buffers in the same way as for current kernels. Large frame buffers may be too large to map into kva, and the kernel (syscons) only uses the first screen page anyway, so r203535, r205557 and 248799 limit the buffer size in VESA modes to the first screen page, apparently without noticing that this breaks applications by using the same limit for user mappings as for kernel mappings. In vgl, this makes the virtual screen the same as the physical screen. However, this is almost a feature since clearing and switching large (usually mostly unused) frame buffers takes too long. E.g., on a 16 year old low-end AGP card it takes about 12 seconds to clear the 128MB frame buffer in old kernels that map it all and also map it with slow attributes (e.g., uncacheable). Older PCI cards are even slower, but usually have less memory. Newer PCIe cards are faster, but may have many GB of memory. Also, vgl malloc()s a shadow buffer with the same size as the frame buffer, so large frame buffers are even more wasteful in applications than in the kernel. Use the same limit in vgl as in newer kernels. Virtual screens and panning still work in non-VESA modes that have more than 1 page. The reduced buffer size in the kernel also breaks mmap() of the last physical page in modes where the reduced size is not a multiple of the physical page size. The same reduction in vgl only reduces the virtual screen size. Notes: svn path=/head/; revision=346278
* Fix a variable name in r346215. Clearing of the right of the screen wasBruce Evans2019-04-161-1/+1
| | | | | | | | broken, except it worked accidentally in most cases where the virtual screen is larger than the physical screen. Notes: svn path=/head/; revision=346276
* For writing and reading single pixels, avoid some pessimizations forBruce Evans2019-04-141-143/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | depths > 8. Add some smaller optimizations for these depths. Use a more generic method for all depths >= 8, although this gives tiny pessimizations for these depths. For clearing the whole frame buffer, avoid the same pessimizations for depths > 8. Add some larger optimizations for these depths. Use an even more generic method for all depths >= 8 to give the optimizations for depths > 8 and a tiny pessimization for depth 8. The main pessimization was that old versions of bcopy() copy 1 byte at a time for all trailing bytes. (i386 still does this. amd64 now pessimizzes large sizes instead of small ones if the CPU supports ERMS. dev/fb gets this wrong by mostly not using the bcopy() family or the technically correct bus space functions but by mostly copying 2 bytes at a time using an unoptimized loop without even volatile declarations to prevent the compiler rewriting it.) The sizes here are 1, 2, 3 or 4 bytes, so depths 9-16 were up to twice as slow as necessary and depths 17-24 were up to 3 times slower than necessary. Fix this (except depths 17-24 are still up to 2 times slower than necessary) by using (builtin) memcpy() instead of bcopy() and reorganizing so that the complier can see the small constant sizes. Reduce special cases while reorganizing although this is slightly slower than adding special cases. The compiler inlining (and even -O2 vs -O0) makes little difference compared with reducing the number of accesses except on modern hardware it gives a small improvement. Clearing was also pessimized mainly by the extra accesses. Fix it quite differently by creating a MEMBUF containing 1 line (in fast memory using a slow method) and copying this. This is only slightly slower than reducing everything to efficient memset()s and bcopy()s, but simpler, especially for the segmented case. This works for planar modes too, but don't use it then since the old method was actually optimal for planar modes (it works by moving the slow i/o instructions out of inner loops), while for direct modes the slow instructions were all in the invisible inner loop in bcopy(). Use htole32() and le32toh() and some type puns instead of unoptimized functions for converting colors. This optimization is mostly in the noise. libvgl is only supported on x86, so it could hard-code the assumption that the byte order is le32, but the old conversion functions didn't hard-code this. Notes: svn path=/head/; revision=346215
* Fix copying of MEMBUFs to MEMBUFs. This case was implemented by usingBruce Evans2019-04-081-28/+2
| | | | | | | | | | | | | | | | | | | the same code as the VIDBUF8 case, so it only worked for depths <= 8. The 2 directions for copying between VIDBUFs and MEMBUFs worked by using a Read/Write organization which makes the destination a VIDBUF so the MEMBUF case was not reached, and the VIDBUF cases have already been fixed. Fix this by removing "optimizations" for the VIDBUF8 case so that the MEMBUF case can fall through to the general (non-segmented) case. The optimizations were to duplicate code for the VIDBUF8 case so as to avoid 2 multiplications by 1 at runtime. This optimization is not useful since the multiplications are not in the inner loop. Remove the same "optimization" for the VIDBUF8S case. It was even less useful there since it duplicated more to do relatively less. Notes: svn path=/head/; revision=346025
* Fix restoring to graphics modes in VGLEnd().Bruce Evans2019-03-291-16/+16
| | | | | | | | | | | | | | | | | | | | | | | Correct restoring was only attempted for mode 258 (800x600x4 P). (This was the only useful graphics mode supported in the kernel until 10-15 years ago, and is still the only one explicitly documented in the man page). The comment says that it is the geometry (subscreen size) that is restored, but it seems to only be necessary to restore the font size, with the geometry only needed since it is set by the same ioctl. The font size was not restored for this mode, but was forced to 16. For other graphics modes, the font size was clobbered to 0. This confuses but doesn't crash the kernel (font size 0 gives null text). This confuses and crashes vidcontrol. The only way to recover was to use vidcontrol to set the mode to any text mode on the way back to the original graphics mode. vidcontrol gets this wrong in the opposite way when backing out of changes after an error. It restores the font size correctly, but forces the geometry to the full screen size. Notes: svn path=/head/; revision=345698
* Fix endless loops for handling SIGBUS and SIGSEGV.Bruce Evans2019-03-291-4/+12
| | | | | | | | | | | | | | | r80270 has the usual wrong fix for unsafe signal handling -- just set a flag and return to let an event loop check the flag and do safe handling. This never works for signals like SIGBUS and SIGSEGV that repeat and works poorly for others unless the application has an event loop designed to support this. For these signals, clean up unsafely as before, except for arranging that nested signals are fatal and forcing a nested signal if the cleanup doesn't cause one. Notes: svn path=/head/; revision=345696
* Fix races in mouse signal handling almost properly using the INTOFF/INTONBruce Evans2019-03-291-19/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | method as in /bin/sh. We still do technically undefined things in the signal handler, but it is safe in practice to access state that is protected by INTOFF/INTON. In a recent commit, I sprinkled VGLMouseFrozen++/-- operations in places that need INTOFF/INTON. This prevented clobbering of pixels under the mouse, but left mouse signals deferred for too long. It is necessary to call the signal handler when the count goes to 0. Old versions did this in the unfreeze function, but didn't block actual signals, so the signal handler raced itself. The sprinkled operations reduced the races, but when then worked to block a race they left signals deferred for too long. Use INTOFF/INTON to fix complete loss of mouse signals while reading the mouse status. Clobbering of the state was prevented by SIG_IGN'ing mouse signals, but that has a high overhead and broke more than it fixed by losing mouse signals completely. sigprocmask() works to block signals without losing them completely, but its overhead is also too high. libvgl's mouse signal handling is often worse than none. Applications can't block waiting for a mouse or keyboard or other event, but have to busy-wait. The SIG_IGN's lost about half of all mouse events while busy-waiting for mouse events. Notes: svn path=/head/; revision=345695
* Fix VGLLine() in depths > 8.Bruce Evans2019-03-281-1/+1
| | | | | | | | | It started truncating its color arg to 8 bits using plot() in r229415. The version in r229415 is also more than 3 times slower in segmented modes, by doing more syscalls to move the window. Notes: svn path=/head/; revision=345643
* Fix VGLGetXY(), VGLSetXY() and VGLClear() for MEMBUFs in depths > 8.Bruce Evans2019-03-281-0/+36
| | | | | | | | This depends on PixelBytes being properly initialized, which it is for all bitmaps constructed by libvgl except mouse cursor bitmaps. Notes: svn path=/head/; revision=345639
* Oops, r345496 got the pointer args backwards for bcopy() in VGLClear forBruce Evans2019-03-281-2/+2
| | | | | | | | | | segmented modes. Also fix some style bugs in the 2 changed lines. libvgl uses a very non-KNF style with 2-column indentation with no tabs except for regressions. Notes: svn path=/head/; revision=345637
* Fix accessing pixels under the mouse cursor:Bruce Evans2019-03-273-24/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reading of single pixels didn't look under the cursor. Copying of 1x1 bitmaps didn't look under the cursor for either reading or writing. Copying of larger bitmaps looked under the cursor for at most the destination. Copying of larger bitmaps looked under a garbage cursor (for the Display bitmap) when the destination is a MEMBUF. The results are not used, so this only wasted time and flickered the cursor. Writing of single pixels looked under a garbage cursor for MEMBUF destinations, as above except this clobbered the current cursor and didn't update the MEMBUF. Writing of single pixels is not implemented yet in depths > 8. Otherwise, writing of single pixels worked. It was the only working case for accessing pixels under the cursor. Clearing of MEMBUFs wasted time freezing the cursor in the Display bitmap. The fixes abuse the top bits in the color arg to the cursor freezing function to control the function. Also clear the top 8 bits so that applications can't clobber the control bits or create 256 aliases for every 24-bit pixel value in depth 32. Races fixed: Showing and hiding the cursor only tried to avoid races with the mouse event signal handler for internal operations. There are still many shorter races from not using volatile or sig_atomic_t for the variable to control this. This variable also controls freezes, and has more complicated states than before. The internal operation of unfreezing the cursor opened a race window by unsetting the signal/freeze variable before showing the cursor. Notes: svn path=/head/; revision=345585
* Fix copying of bitmaps in depths > 8. This fix is complete, except differentBruce Evans2019-03-272-9/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | depths for the source and target are not supported. The bits for higher numbered planes (mostly for red) were either not copied or were copied to lower numbered planes for nearby pixels. Quick fix for creation of mouse cursor bitmaps in all depths. This fix is only complete for the default lightwhite cursor with a black frame. Even the lightwhite and black colors are hard to find. The templates use 0xff for lightwhite, but that means brightblue in the simplest mode (Truecolor depth 24). Other modes are even more complicated -- they are singly or doubly indirect throught palette(s) and changing of the palettes by applications is supported. Details: Replicate the template value for Truecolor modes to fill out the target depth (and more for depths not a multiple of 8). Do this for every drawing of the cursor so that it sort of works for mouse cursor bitmaps set by applications. Use 0xf for lightwhite in most other modes. Only do this for the default cursor so that it doesn't affect mouse cursor bitmaps set by applications. 0xf mostly works because it was originally for CGA lightwhite and is emulated using 1 or 2 indirections on EGA and VGA. 0x3f (EGA white) and 0xff (VGA black) direct palette indexes mostly don't work since backwards compatibility inhibits or prevents them representing lightwhite. But 0x3f (EGA white) must be used for mode 37 (VGA_MODEX) (320x240x8 V) since this mode is closer to EGA than VGA. Notes: svn path=/head/; revision=345568
* Fix another type of buffer overrun for segmented modes. The buffer indexBruce Evans2019-03-251-1/+2
| | | | | | | | | | | | | | | | was not taken modulo the window size in VGLClear(). Segmented modes also need a kernel fix to almost work. The ioctl to set the window origin is broken. These bugs are rarely problems since non-VESA modes only need segmentation to support multiple pages but libvgl doesn't support multiple pages and treats these modes as non-segmented, and VESA modes are usually mapped linearly except on old hardware so they really are non-segmented. Notes: svn path=/head/; revision=345496
* Oops, my previous commit to libvgl was missing the change of VGLSetBorder()Bruce Evans2019-03-242-2/+2
| | | | | | | | | to match the change in its declaration. Change the declaration back to "byte color" since setting of the border color is not supported for more than 256 colors. Notes: svn path=/head/; revision=345486
* Fix the type of the color args for VGLMouseFreeze(), VGLBitmapPutChar(),Bruce Evans2019-03-244-12/+12
| | | | | | | | | | VGLBitmapString() and VGLSetBorder() so as to not truncate to 8 bits. Complete the corresponding fix for VGLGetXY() and VGLPutXY() (parts of the man page were out of date). Notes: svn path=/head/; revision=345484
* Add support for arbitrary font widths. Only multiples of 8 were supported.Bruce Evans2019-03-241-13/+17
| | | | | | | | | | Since the font format is undocumented, it is unclear how non-multiples of 8 should be padded to bytes in the font file. Use the same representation as bdf text format (big- endian, with padding in the lower bits). Notes: svn path=/head/; revision=345483
* Fix reading of pixels in (4 and 8-plane) planar modes.Bruce Evans2019-03-241-7/+2
| | | | | | | | | | | | | | There seems to be no alternative to reading each plane independently using 3 slow i/o's per plane (this delivers 8 nearby pixels, but we don't buffer the results so run 8 times slower than necessary. All the code for this was there, but it was ifdefed out and replaced by simpler code that cannot work in planar modes. The ifdefed out code was correct except it was missing a volatile declaration, so compilers optimized the multiple dummy reads in it to a single read. Notes: svn path=/head/; revision=345481
* Fix buffer overruns in modes with color depth more than 8.Bruce Evans2019-03-244-10/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support for 16-bit and 32-bit Truecolor modes was supposed to be complete in r70991 of main.c and in nearby revisions for other files, but it was broken by the overruns in most cases (all cases were the mouse is enabled, and most cases where bitmaps are used). r70991 also uninintentionally added support for depths 9-15, 17-23 and 25-31. Depth 24 was more obviously broken and its support is ifdefed out. In the other ranges, only depth 15 is common. It was broken by buffer overruns in all cases. bitmap.c: - the static buffer was used even when it was too small (but it was large enough to often work accidentally in depth 16) - the size of the dynamically allocated buffer was too small - the sizing info bitmap->PixelBytes was not inititialzed in the bitmap constructor. It often ended up as 0 for MEMBUFs, so using it in more places gave more null pointer accesses. (It is per-bitmap, but since conversion between bitmaps of different depths is not supported (except from 4 bits by padding to 8), it would work better if it were global.) main.c: - depths were rounded down instead of up to a multiple of 8, so PixelBytes was 1 too small for depths above 8 except 16, 24 and 32. - PixelBytes was not initialized for 4-bit planar modes. It isn't really used for frame buffer accesses in these modes, but needs to be 1 in MEMBUF images. mouse.c: - the mouse cursor buffers were too small. vgl.h: - PixelBytes was not initialized in the static bitmap constructor. It should be initialized to the value for the current mode, but that is impossible in a static constructor. Initialize it to -1 so as to fail if it is used without further initialization. All modes that are supposed to be supported now don't crash in nontrivial tests, and almost work. Missing uses of PixelBytes now give in-bounds wrong pointers instead of overruns. Misconversions of bitmaps give multiple miscolored mouse cursors instead of 1 white one, and similarly for bitmaps copied through a MEMBUF. Notes: svn path=/head/; revision=345478
* Fix libvgl to not always fail to initialize due to its invalid mmap()Bruce Evans2019-03-241-2/+2
| | | | | | | | | | | | args (neither MAP_PRIVATE nor MAP_SHARED). It was broken in r271635 and/or r271724 by stricter checking. The compatibility code in r271724 doesn't work for my old binaries (actually new binaries with old libraries). PR: needed to test the fix for PR 162373 Notes: svn path=/head/; revision=345474
* lib: further adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-267-0/+14
| | | | | | | | | | | | | | | Mainly focus on files that use BSD 2-Clause license, however the tool I was using mis-identified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Notes: svn path=/head/; revision=326219
generated by cgit v1.3 (git 2.53.0) at 2026-05-19 00:20:54 +0000