Upstream bugs

Upstream bugs

This page documents upstream bugs.

msys2

texi2dvi

in recent msys2 OSTYPE is something like "MINGW64_NT", which breaks the texi2dvi script. (see bug #1461). reported upstream here.

Gtk3

Pango

Pango >= 1.48.6 breaks font rendering on Windows (see bugs #1499 and #1513). This appears to be triggered by the "Bring back careful glyph position rounding" mentioned in https://github.com/GNOME/pango/blob/master/NEWS

We've currently "fixed" this by having the Windows Gtk3 bindist script download and copy 1.48.5 DLLs as per commit r40416.

The bug has been reported: https://gitlab.gnome.org/GNOME/pango/-/issues/578, but some googling tells us the Pango devs appear to be unable or unwilling to fix this.

The bug was fixed upstream and backported to MSys' Pango 1.48.8-3. The bindist script hack was removed: r40518. Seems we were wrong about the not fixing part, which is nice ;)

cairo_surface_t

An offscreen buffer is allocated and zeroed for each repaint, resulting in a huge performance impact. dqh provided a patch, which sadly did not get accepted :(

see https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1441

GtkComboBox

Some combobox contents appear to have 'empty' entries and sometimes the colors of the items change (upstream Gtk3 bug) (2017-11-08)

GtkFileChooser

sort order

The GtkFileChooser-based dialogs (open/save file etc) sort the drives on Windows in reverse-order. There is no public API or any GSetting that allows controlling this. The Gtk3 devs say they won't implement changing the sort order, but agreed the order should follow what Windows does. See ticket https://gitlab.gnome.org/GNOME/gtk/issues/900. This also happens on Linux: mountable file systems (such as Windows partitions) are list in reverse order by /sda/* and then by volume name, in reverse order.

(This appears to be fixed in Gtk 3.24.x, but FrankenVICE (nightly build system) still uses Gtk 3.22.x, so we need to update FrankenVICE)

Another issue is case-insensitive sorting of dir/filenames (seems to be preferred on Windows), this depends on locale settings, taken from the bug tracker (feature request #429):

This is something VICE cannot control since there is no function or property in Gtk3 to use to set the sort order of files in the file dialogs. It depends on the setting of LC_COLLATE. On my system with LC_COLLATE="en_US.UTF-8 the files are sorted case-insensitive, when I run LC_COLLATE=C x64sc, the files are sorted case-sensitive.

So for running x64sc from a shell you could, for example, use this in ~/.bash_profile:

alias x64sc='LC_COLLATE="en_US.UTF-8" x64sc'

removable Media

The file dialog tries to access all drives, including those that contain removable media. On Windows, this will cause an error dialog to pop up, which the user has to close before he can continue.

VICE Ticket: https://sourceforge.net/p/vice-emu/bugs/1396/ GTK Ticket: https://gitlab.gnome.org/GNOME/gtk/-/issues/418

Gtk3 Fullscreen

When using full screen (Alt+D) on Windows and using the openGL renderer and enabling the main menu bar and the statusbar (Atl+B), menus aren't shown (this includes popup menus triggered via the statusbar), they appear to be hidden behind the openGL canvas (guessing where a menu item is and clicking on it seems to work). According to the Gtk3 devs, this is a known bug, see https://gitlab.gnome.org/GNOME/gtk/issues/1702, so not much we can do about it until a fix lands in upstream GDK.

Going fullscreen and activating the (VTE) monitor does not present the monitor window on top of the emulated machine window. Alt-Tabbing away and back to VICE makes it work on Windows. It works as expected on at least KDE Plasma (KWin) and Gnome 3 (Mutter), so this seems to be a Windows problem. Someone with some actual understanding of the Windows window manager should have a look. An someone should also try this on MacOS, see what happens there.

GDK keyboard handling

related bug: #1200

On Windows GDK doesn't return `KP_Home` when pressing the numpad Home/7 button, but returns a plain `Home` keysym, which results in keymaps for the PET and other machines using a numpad, or similar, not working properly on Windows. This happens for all 'navigation' keys on a keypad. This also affects the enter key on the keypad 'KP_Enter' which is interpreted as normal Enter. The 3rd joystick button on the numpad is by default mapped to KP_Enter so this doesn't work on Windows.

• 2020-03-17, Compyx: I've asked on IRC: got ignored, and posted on the Gnome discourse ([1]) about this: also no response yet.
• 2020-04-27, Compyx: Also posted a bug ([2]) on their tracker a few weeks ago: again, no response and the Gnome discourse thread auto-closed =)
• 2020-12-27, Compyx: It appears at least some work is being done to rewrite the Win32 keyboard handling: ([3])

tried to come up with a workaround by using other members of GdkEventKey - no dice. even "hardware_keycode" is the same for keypad home and regular home - which is plain wrong. Gpz (talk) 00:21, 12 May 2020 (CEST)

• solved - a workaround was provided in [4] which is now implemented in VICE

/*
 * 
 * compile command:
 * 
 * gcc keypress.c -o keypress  `pkg-config --libs --cflags gtk+-3.0`
 * 
 * on windows use -mconsole to see the output on console (using msys2)
 * 
 */

/*
keyval: ff7f keyname: Num_Lock
keyval: ffaf keyname: KP_Divide   
keyval: ffaa keyname: KP_Multiply 
keyval: ffad keyname: KP_Subtract 
keyval: ffab keyname: KP_Add      
keyval: ff8d keyname: KP_Enter    

the "white" keys on the numpad should produce different keycodes depending
on the "numlock" state: (also pressing shift together with one of the keys will
result in "the other" keycode)

numlock on:                             numlock off:

keyval: ffb0 keyname: KP_0              keyval: ff9e keyname: KP_Insert
keyval: ffb1 keyname: KP_1              keyval: ff9c keyname: KP_End
keyval: ffb2 keyname: KP_2              keyval: ff99 keyname: KP_Down
keyval: ffb3 keyname: KP_3              keyval: ff9b keyname: KP_Next
keyval: ffb4 keyname: KP_4              keyval: ff96 keyname: KP_Left
keyval: ffb5 keyname: KP_5              keyval: ff9d keyname: KP_Begin
keyval: ffb6 keyname: KP_6              keyval: ff98 keyname: KP_Right
keyval: ffb7 keyname: KP_7              keyval: ff95 keyname: KP_Home
keyval: ffb8 keyname: KP_8              keyval: ff97 keyname: KP_Up
keyval: ffb9 keyname: KP_9              keyval: ff9a keyname: KP_Page_Up
keyval: ffac keyname: KP_Separator      keyval: ff9f keyname: KP_Delete

on windows the keys with numlock off produce wrong keycodes, eg "Home" instead
of "KP_Home". that makes any combination of shift+ such key undistinguishable from
the regular keys

*/

#include <gtk/gtk.h>
#include <gdk/gdkkeysyms.h>

gboolean on_key_press (GtkWidget *widget, GdkEventKey *event, gpointer user_data)
{
  printf("keyval: %04x keyname: %s\n", event->keyval, gdk_keyval_name(event->keyval));
  fflush(stdout);
  return FALSE; 
} 

int main (int argc, char *argv[])
{
  GtkWidget *window;

  gtk_init (&argc, &argv);

  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);

  g_signal_connect (G_OBJECT (window), "destroy", G_CALLBACK (gtk_main_quit), NULL);
  g_signal_connect (G_OBJECT (window), "key_press_event", G_CALLBACK (on_key_press), NULL);

  gtk_widget_show_all (window);

  gtk_main ();

  return 0;
}

caps-lock

caps-lock event reporting is broken on Windows and macOS apparently.

• in Linux, pressing and releasing the caps lock key generates key press and release events as expected (every time the key is pressed and released). gdk_keymap_get_caps_lock_state() returns true or false depending on the "locked" status (what is indicated by the LED on the keyboard)
• in Windows, pressing and releasing the caps lock key both generates events, but the keyboard symbol is invalid (and the keycode 0xffffff). gdk_keymap_get_caps_lock_state() returns true or false as expected.
• in macOS _enabling_ the "lock" generates a key press event, _disabling_ the lock generates a key release event. gdk_keymap_get_caps_lock_state() always returns false.

SDL

SDL 1 has compatibility issues on various operating systems:

• Window resizing can be intermittent: the window will change its size, but the window-resize event will not be generated and the display will clip or be mislplaced.
• When OpenGL is disabled, most recent versions of macOS will simply display an empty window.

If you see strange misbehavior at the window-manager level in an SDL 1 build, test the SDL 2 build. SDL 2 is well supported on mainstream systems that are 10 or fewer years old, and it is the preferred SDL implementation of VICE under nearly all circumstances.

OpenCBM

Under certain conditions (when using the xum1541 interface/driver, which wants to use libusb-1.0.dll), the opencbm.dll failed to load correctly under windows. We worked around this using an ugly hack, see r43559. Reported to Spiro via mail.