Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Lars

Pages: 1 [2] 3 4 ... 73
Programming / Re: Qt6 Development
« on: January 30, 2023, 12:48:03 pm »
Font scaling should be fixed with - new qos2.dll link is in the testing thread.

I got lucky with browsing github during my lunch break today, and found - searching for references to this led me to a commit which added logicalBaseDPI on other platforms - and voila ;) seems logicalBaseDPI defaulted to 96,96 is not set - which was different to the screen/font dpi of 120,120 - so windows got scaled (which we didn't wnat/need).

I don't get your explanation. From what I can see, QPlatformScreen::logicalDpi is not properly implemented in your github repo. It just returns QPlatfromScreen::logicalBaseDpi and therefore a 1:1 scaling between "logical" and "physical" for x and also y coordinates.
The BWW repo has an implementation for QPlatformScreen::logicalDpi that is more complex and will lead to a different scaling, at least under certain conditions.
Additionally: Looks like you can fumble around with environment var: QT_FONT_DPI to set your logical DPI. Maybe you can try "set QT_FONT_DPI=120" and see if that makes a difference. At least you can experiment with it ...

And I think it seconds what Alex said: QScreen:: is about Windows scaling and QPlatformScreen:: seems to center around font scaling, at least according to the comments in file qplatformscreen.cpp, at least the BWW repo has this:

Code: [Select]
    Reimplement this function in subclass to return the logical horizontal
    and vertical dots per inch metrics of the screen.
    The logical dots per inch metrics are used by QFont to convert point sizes
    to pixel sizes.
    The default implementation uses the screen pixel size and physical size to
    compute the metrics.
    \sa physicalSize
QDpi QPlatformScreen::logicalDpi() const
    QSizeF ps = physicalSize();
    QSize s = geometry().size();

    if (qFuzzyIsNull(ps.width()) || qFuzzyIsNull(ps.height()))
        return QDpi(96, 96);
    return QDpi(25.4 * s.width() / ps.width(),
                25.4 * s.height() / ps.height());

Hardware / Re: USB32 USBMSD problem of re-read diskette
« on: January 24, 2023, 05:30:09 pm »
By now, I don't think it is a timing problem in the driver. It is a problem of not testing for an inserted media long enough for the drive to react. The number of retries is too low and/or the check for inserted media is not done at all places required plus the returned error info ("sense code") is not properly taken into account (the "sense code" will for example tell you if the drive is not ready, does not contain media or if the media has just been swapped and whole bunch of other potential error/status conditions). Then, for a USB floppy drive, you need some special handling regarding the fact media might not be inserted (for a USB memory stick, the "media" is always "inserted"). That is what you observed: to try and access the media when there is no media inserted will lead to that typical "rattling sound" and Windows does the same.

What I did in the past was to install "Wireshark" under Windows which contains an additional "USB capture" feature (USBpcap).
That is what I used to track what commands in what sequence Windows issues against the USB floppy drive (by using it under Windows). I then modified USBMSD.ADD to follow that sequence (as good as that was feasible), including some guesswork about necessary retries.

And regarding that it works on one system while it does not on another system: the USB floppy drive HW has some physical variation even if it is the very same model (but a different physical drive !) and that can lead to one drive needing more retries than another drive (for example). This has to be anticipated and taken into account. You just cannot test against each and every USB floppy drive on planet earth.

Hardware / Re: USB32 USBMSD problem of re-read diskette
« on: January 24, 2023, 08:40:38 am »
I do not have the same USB Floppy Drive as you have but I now did some further tests with the USB floppy drive that I have.
1) I tried it on my notebook with Win 11, Intel CPU, USB 3.x: it will never attach, no matter how often I try.
2) I tried it on my Tower PC with Win 10, AMD CPU, USB 2.x and USB 3.x: it has problems attaching. Initially I attached to a USB 2.x port which did not work. I then tried a USB 3.x port and that helped. I had to plug multiple times but it would finally come alive. Initially, it would report error that "device descriptor cannot be read"
3) I tried it on the very same Tower PC with OS/2 (and USB 2.x only): it also does not always attach but the situation is better than with Win 10. Eventually, after unplugging and replugging, it will come alive.

What I can remember from the USB floppy drive that I have is that on device attach it needs multiple "DRIVE READY" commands to trigger the drive electronics and convince the motor to spin up. That command would need to be repeated until it would no longer return with an error (naturally, you would limit the attempts to some maximum retries).

So, taking the current situation, I would believe that USB floppy drives in general are not very reliable and sometimes need quite a few attempts until they finally come alive. This is likely true on each new media insertion. And it will vary from system to system.

Since I am not a AN customer, maybe you can add that to your problem report.

Another solution would be to buy a new up-to-date USB floppy drive.

Hardware / Re: USB32 USBMSD problem of re-read diskette
« on: January 23, 2023, 05:39:48 pm »
Right now I can only say this:
what you are experiencing is a bug in the media redetermination when one diskette is swapped with another.
When I was working on it, I was seeing that exact problem until I finally got that fixed.

If Lewis claims it works for him with the very same USB floppy drive as yours then either your host controller FW/HW is not the same as that of Lewis or it is a timing issue in USBMSD.ADD (USBMSD.ADD uses a timer interrupt routine to handle command timeouts plus context hooks to offload asynchronous processing to a suitable future point in time. Both, timer interrupt routines and even more so context hooks are influenced by and influence timing. What's more, invocation of context hooks can be delayed by invocation of other context hooks, scheduled by other drivers).

Hardware / Re: USB32 USBMSD problem of re-read diskette
« on: January 23, 2023, 01:45:55 pm »
Hallo Igor, Michael,

this is an excerpt of the readme for USBMSD.ADD in its original IBM version 10.162 which was the base for further development for both drivers, that from AN as well as my driver set:

Code: [Select]
2.7 Known Limitations
2.7.1  Only USB Memory Keys sized 16MB or larger are supported.
2.7.2  IBM 32MB USB Memory Key and Iomega PocketZip USB drive cannot be
       suspended/resumed properly. These devices must be ejected and
       then detached before you start the suspend mode.
2.7.3  Eject must be executed for the USB removable drive prior detaching
       (switching off) it from working system. This is necessary for correct
       drive operation after re-attaching the drive.
2.7.4  Some USB floppy disk drives (i.e. IBM USB Portable Diskette Drive,
       ASM P/N 06P5222, FRU P/N 06P5223) are known to become inaccessible
       if there was no diskette in the drive during boot/attach time.
       To avoid this, a diskette should remain in the drive while the system
       is booting or while the drive is being attached.
2.7.5  Removable device monitoring utility works only under OS/2 Warp 4 
       with Convenience Pack 2 installed and OS/2 Warp Server for e-business 
       with Convenience Pack 2 installed. USB Basic support must be upgaded
       to the latest version before installing the removable device monitoring 

Are you experiencing the effects described in 2.7.4 ?
If yes, I would suspect that AN has rebased their development of USBMSD.ADD on the original DDK source code (apart from adding support for superspeed media which was mentioned somewhere).
Properly handling USB floppy drives need changes to the DDK source code to work properly.

If not, there is another potential for problems if the USB floppy disk drive is the same but the USB host controller HW/FW is different.
As far as I remember from the XHCI spec, a few of the things that Host Controller Driver SW had to implement in SW for UHCI/OHCI/EHCI is now executed totally autonomously by the Host Controller HW/FW. So, if the host controller HW/FW differs, then things might fail even though the USB floppy drive is the very same.

When I attach my USB (1.x) floppy drive under Windows 11, it is never able to detect (left alone use) it. It always plays the "attach sound" and then Windows 11 reports that it could not read descriptor info (which is about the very first thing that needs to be done, before anything else). Since for XHCI, some things are done completely in HW/FW, no SW on planet earth can work around that problem. My Windows 11 notebook has USB 3 only (but I suppose it has some rate matching hub to be able to use USB 1.x and USB 2 devices).

My OS/2 bare metal machine is older, has an AMD CPU and chipset, still has USB 2 (and USB 3) support and will happily accept the USB floppy drive. But I am using USB 2 and not USB 3.

Hardware / Re: USB32 USBMSD problem of re-read diskette
« on: January 22, 2023, 05:34:15 pm »
So you are saying, the AN USBMSD driver does better error checking than my driver and that's why it will not work practically whereas my driver does no error checking and that's why it works ?

That does not seem to make a lot of sense to me ...

By the way: I added a LOT of error checking to the driver. It is not on the same level as it was delivered by IBM as part of their DDK.

To me it rather looks like David is seeing problems where there aren't any.

Programming / Re: Qt6
« on: January 22, 2023, 05:15:33 pm »
Does this Qt6 version of Dooble (rather: the Qt6 libraries) fix the problem that typing a lot of text into an entry field (like this comment field) slows down the typing more and more until finally you cannot type at all ? That`s what happens with my Dooble based on Qt5.

Hi Lars,

I haven't experienced such a behaviour. However I used Dooble-QT5 mostly for visiting the bank pages for Online-Banking (to download documents). So not much text typing.
I just answered Martin and I type this also with Dooble-QT6 and don't see any slow down. But maybe it is to less text to write. Do you have a number of characters / words one should test to see a slow down?

Greetings, Mike

Say after 50 or so characters. When it happens I can barely continue typing and the "back" key will also cease to work.
Initially, I suspected a problem with the USB mouse driver (I am using my driver set) but I have no problem typing in Firefox 45 (which is what I am doing right now).
I have a fully updated set of Qt5 files. I am really out of ideas of where it is going wrong.

General Discussion / Re: ArcaOS on Youtube @MichaelMJD
« on: January 22, 2023, 02:14:03 pm »
ok, so that likely means, the color resolution should be changed to anything else but 256 colors. For example, you should change to 16 colors (lousy) or true color (16 Million colors). Then, according to that article in "PC Mag", that should get rid of that "white text on black background" problem.

If I`d have to guess I would think that there is a problem if colors are selected from a palette instead of being directly coded in RGB.

Programming / Re: Qt6
« on: January 22, 2023, 02:09:47 pm »
Does this Qt6 version of Dooble (rather: the Qt6 libraries) fix the problem that typing a lot of text into an entry field (like this comment field) slows down the typing more and more until finally you cannot type at all ? That`s what happens with my Dooble based on Qt5.

Hardware / Re: USB32 USBMSD problem of re-read diskette
« on: January 22, 2023, 01:59:46 pm »
I think I can tell you what`s wrong: a few years ago, you (Lewis), sent me a Mitsumi USB floppy drive to test.
And that drive did NOT work with the USBMSD.ADD back at the time. Seemingly, there are drives that are more sophisticated, there are even drives that can actually eject a diskette via a command (instead of a mechanical eject), there are drives that have a "diskette change" signal and therefore do not need to be polled for a change but this "cheapo" drive would not do.
After quite some fiddling I found out how to properly interpret the "sense codes" that the USB floppy drive sends back. I then based the media (re)determination on the "proper" sense codes to react upon. Additionally, had to add some logic when and how to reattempt reading from media.
So, as so often with USB, not every USB floppy drive is equal.
That also solved the problem that it is no longer required to have a diskette already inserted when attaching the USB floppy drive to have the diskette propery be detected if you want to access it later on. Plus the desperate attempts of the OS to read from a USB floppy diskette ad infinitum whenever the "Drives" object is opened (and no diskette is inserted in the floppy drive).
Again look at the video: that guy is saying that he tried with 3 different USB floppy drives and none would work.

Hardware / Re: USB32 USBMSD problem of re-read diskette
« on: January 21, 2023, 05:11:05 pm »
As can be seen in this video:

the presenter stated that none of his 3 USB floppy drives would work with ArcaOS (I assume 5.0.x), so that answers the "everything works for us".

I assume that with the "USBMSD driver of the 16-bit version" you mean the USBMSD.ADD from my USB driver set.
Yes, I can tell you that it needed quite a few fixes to redetermine the inserted floppy media. And I know that it works with my updated driver because I have a USB floppy drive to test with.

I am pretty sure that AN never picked up these fixes and they never will.

According to the Windows 11 control panel, I do not even seem to have hyper-v installed ("Windows Hypervisor Platform" is not marked as being installed, also "VM Platform" is not installed, whatever that means). Then I searched in the internet and found a commandline way of disabling it. Still Virtualbox 7 complained in its guest logs that the Windows Hypervisor was still active.

I went back to Virtualbox 6.1.x. Unfortunately, Virtualbox is not a product that necessarily gets better with each version. For me, it`s always trial and error.

I seem to remember that starting with Virtual box 7 under a Windows host, you need to explicitly disable the Windows built-in hypervisor (obviously the Vidtualbox hypervisor implementation and the Windows one get in each other's way). As always, you'll need to find out how to do that and on my system it did not work (the Virtualbox Log still complained that the Windows hypervisor was still active).
Working with more than one core in the guest has never worked for me but I am still using eCS. I don't know if ArcaOS would make a difference. The problem is that multiple cores appear to work ok but after a while, the system(guest) gets confused and hangs eventually. That always happened when I was doing a compile with the old MS 16-bit compiler (run from multiple makefiles).

The Warp3 kernel is a dead end. It does not contain the KEE functionality which means that no current driver will work (including JFS.IFS, as an example as well as the USB stack).

Pages: 1 [2] 3 4 ... 73