Linux's snap release doesn't work on Debian Stable

[wiz21b]

Hello,

Just installed the snap package of CLK today. Doesn't run on my current debian stable (buster). The programs starts, displays a a window, the window is not refreshed => I see garbage. The title of the windows is "select a machine..." or another message with "provide roms...", depending on the fact I pass parameters on the command line.

The console reads:

stefan@debian:~/Dropbox/demo2$ clock-signal build/NEW.WOZ
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
QOpenGLWidget: Failed to create context
QOpenGLWidget: Failed to create context
composeAndFlush: makeCurrent() failed
composeAndFlush: makeCurrent() failed
composeAndFlush: makeCurrent() failed

If I run with the --help parameter, it provides a dialog box "unable to open file --help..." and then it allows me to quit.

I have other OpenGL applications that work well...

cheers,

stefan

[TomHarte]

I guess it might be the specific version of OpenGL that I'm trying to instantiate — 3.2 core profile — if it's not some other feature of the context that I'm taking as assumed but should be configuring programmatically.

What's your video hardware?

[wiz21b]

Hi Tom,

Nice FOSDEM talk about buses :-)

Here are my NVIDIA details (comig from glxinfo):

OpenGL renderer string: GeForce GT 730/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 418.152.00
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
...
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 418.152.00
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

hope it helps !

[wiz21b]

Upgraded my nvidia (proprietary) drivers, doesn't fix anything :-(

OpenGL core profile version string: 4.6.0 NVIDIA 418.181.07
OpenGL core profile shading language version string: 4.60 NVIDIA

best regards, stf

[TomHarte]

Ugh. I don't really understand what I'm doing wrong such that Qt fails to get a context but I certainly need to look into this sooner rather than later — it's not exactly like Nvidia cards are a niche product.

Out of interest, have you tried a non-Snap build? Just in case that provides a clue as to whether it's my use of Qt or my packaging as a Snap that's more likely at fault.

[wiz21b]

Hi Tom,

I've successfuly compiled your code (and there ain't no warning, good job :-))

However I'm stuck on what should've been easy : the roms. I think the emulator doesn't see them :-( Look:

stefan@debian:/mnt/data2/CLK-2021-02-02/OSBindings/SDL$ crc32 AppleII/apple2eu-character.rom
816a86f1
stefan@debian:/mnt/data2/CLK-2021-02-02/OSBindings/SDL$ ./clksignal /home/stefan/Dropbox/demo2/build/LOWTECH.WOZ --rompath /mnt/data2/CLK-2021-02-02/OSBindings/SDL
Could not find system ROMs; please install to /usr/local/share/CLK/ or /usr/share/CLK/, or provide a --rompath.
One or more of the following was needed but not found:
AppleII/apple2eu-character.rom (the Apple IIe character ROM; accepted crc32s: 816a86f1)
AppleII/apple2eu.rom (the Apple IIe ROM; accepted crc32s: e12be18d)
DiskII/boot-16.rom (the Disk II 16-sector boot ROM; accepted crc32s: ce7144f6)
DiskII/state-machine-16.rom (the Disk II 16-sector state machine ROM; accepted crc32s: 9796a238, b72a2c70)
stefan@debian:/mnt/data2/CLK-2021-02-02/OSBindings/SDL$

So although the ROM is correctly named and has the good CRC, the emulator complains it can't find it (I've tested only one rom so far 'cos rom hunting takes time :-))

Any idea ?

Stéphane

[TomHarte]

It's going to continue to complain until it can find all of them, as it isn't currently smart enough to know which is missing. No, seriously. I'm embarrassed.

I'm going to commandeer this bug report if I may at least in part to require the following long-standing improvements:

1. conjunctives in the missing ROM list (not relevant here, but e.g. the MSX can start with either of two different ROMs, but isn't smart enough to tell the user that either will do);
2. reduce the error report to only the missing ROMs; and
3. on Qt and macOS, test dragged-and-dropped ROMs against everything the emulator might ever need, not just what it needs right now.

As an aside, every ROM the emulator needs seems to be available from somewhere on archive.org so I'm constantly on the fence about the legality of providing URLs.

(And, as a further aside: ugh, that's poorly worded. "Accepted" is supposed to mean "popularly known", i.e. that's the CRC32 of the files I found that worked. The CRC isn't actually verified by the SDL build at all — though it is used by the Qt and macOS builds to identify ROMs you drag and drop to install, so it's not purely for human information).

[wiz21b]

ok, I'll check that later, maybe today. But don't be too hard on yourself, we're doing this for fun, ain't we ? :-)

[wiz21b]

Finally got it to work. I'm pretty sure that --rompath option doesn't work. In the end I've created /usr/local/share/CLK/AppleII and DiskII as suggested but I had to use sudo to do that => I can't run your program as regular user. Not much of a problem since I'm the only one but that is less than a smooth install :-(

So what works is this : stefan@debian:/mnt/data2/CLK-2021-02-02/OSBindings/SDL$ ./clksignal /home/stefan/Dropbox/demo2/diskcheck_v4.DSK

That is, the SDL bind. The emulator starts, correctly recognize the AppleII, reads the disk OK and run my program up to its mockingboard detection which fails obviously.

The program I run ("diskcheck") does very accurate measurements on the disk behavior. If at some point you implement the mockingboard, it will be nice to run that diskcheck and see how it compares to other emulators :-)

I'm really interested in your CRT emulation as AppleWin is not quite correct there (lots of tearing in the rendering, due, I think, to the fact that the CRT beam may not be correctly modelled). Mame is better on that side...

So I'm waiting for the mockingboard :-)

[wiz21b]

And collecting the ROMs is tough :-( (that's normal since well, I have to have the real one :-)) But maybe you could be more flexible on what you accept ?

[TomHarte]

Clearly I don't pay enough attention; the issue is that CLK has non-idiomatic command-line syntax and needs to be fixed.

--rompath=/mnt/data2/CLK-2021-02-02/OSBindings/SDL should have worked, but my parser fails to apply normal positional logic if there's no =s in there.

So that's the first work item.