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 5 ... 28
Hardware / Re: ArcaOS Hardware Support Discussion
« on: August 04, 2019, 12:11:50 am »
Some info:

1) I think there is no chance that booting from a USB device attached to a plug-in USB card will actually work. I seem to remember that there are some HW limitations that will prevent this from working (some necessary HW signal line not wired via the PCI slot).

2) yes, VIA UHCI host controllers are supported. As far as I understand from ivan, the USB keyboard and trackball work if they are attached to the 2 "USB 2.0 only" USB ports for "normal" operation, that means, way past the boot stage. If the mouse and keyboard support does not work in the booting stage (that is, while you are presented with a fullscreen text mode with the driver signon messages showing etc.) then that either means that the system does not have USB legacy support in the "conventional" BIOS/UEFI CSM layer (that is, disregarding USB support via the UEFI BIOS which does not help OS/2 as OS/2 does not boot up via UEFI) or that the USB support breaks when switching from USB legacy support to native USB support.
What you could try out: back up \os2\boot\config.x and then remove all USB support from this file.
Then, restart the system, hit Alt-F1 and then F2 which will get you to a full screen commandline. Test the USB keyboard, it should work. If not, you are hosed and your system does not support legacy USB (via the "conventional" BIOS / UEFI CSM layer).
Don't forget to reinstate the original \os2\boot\config.x file after the test !


Hardware / Re: ArcaOS Hardware Support Discussion
« on: August 03, 2019, 03:09:03 pm »
I had to borrow a keyboard with a PS/2 plug to get everything up and working again

This is one of the main problems with using USB keyboards. They don't work after the BIOS loses control (sometime early in the boot sequence), and before the driver initializes (right at the end of the boot sequence). At that time, USB keyboards cannot be used to do simple things like hit <enter>. This is not new with new USB drivers, it has always been the case.

No this is not true. The idea is to prevent the HC drivers from resetting the host controllers until finally the system is up and running in order to not prematurely break legacy USB support. It is the job of USBD.SYS to call into the HC drivers to trigger the host controller reset and once this is done to start the enumeration process (as then the HUB HW is able to properly do its work and react to port checking requests etc.). So, the idea is to delay this process until finally the system has booted far enough to no longer need USB legacy support.

I have modified my USB drivers to do just that: USBD.SYS queues the HC driver registration requests with a timer. It additionally checks if the system has already notified (via USBMSD.ADD calling into USBD.SYS) that INT13 boot support for USB MSD is no longer needed. If the timer expires (no more HC drivers asked for registration + the system has signaled it no longer needs INT13 boot support), then USBD.SYS will go ahead and reset the HC controllers.
I can easily boot to a commandline via Alt-F1 and F2 and then use my USB keyboard. There is a short moment where the keyboard will not work from the point in time where the HC drivers have been reset (and legacy USB support ceased) until native USB support has been enabled but you can continue to type and it will eventually continue to work, in practice I have no problem using a USB keyboard from a booted up commandline.
If I additionally run "lvm /rediscoverprm" from that commandline, I can also use attached USB MSD devices.

But of course, the BIOS has to provide legacy USB support. I wonder how long that will still be the case.

The upcoming 10.229 version of my drivers will have the rest of changes I have missed in the past to support the behaviour mentioned above.

Hardware / Re: USBDRV 10.225 - full support for USB audio
« on: August 01, 2019, 05:13:21 am »
Ok, I just realized that I also need to update USBMSD.ADD and USBD.SYS. I will send the modified set as soon as I have tested all the changes.

Hardware / Re: USBDRV 10.225 - full support for USB audio
« on: July 30, 2019, 08:12:19 am »
Just retested with Lars latest USB drivers installed again.

ArcaOS 5.04.  Moved the BASEDEV=USBD.SYS before the other basedev drivers as the way 5.04 does.


Rebooted and the mouse does not work.  Note: the USB mouse did work with the USB drivers installed with ArcaOS 5.04 when using the above ordered config.sys.

Switched BASEDEV=USBD.SYS back to the order done in earlier versions of ArcaOS.


rebooted and the mouse works with Lars drivers.

If you can get me a private email address, I can send you updated USB?HCD.SYS test drivers that no longer rely on a specific config.sys ordering regarding USBD.SYS. You'll never have to touch your config.sys again :-)
It works here, once I know that it works for you I can release a new set of drivers.


Hardware / Re: USBDRV 10.225 - full support for USB audio
« on: July 30, 2019, 08:10:48 am »
In fact the Linux "guys" had full support from some Intel lady which eventually implemented (or led implementation of) the USB 3 driver for Linux.
Implementing an USB host controller driver is trial and error.

Hardware / Re: USBDRV 10.225 - full support for USB audio
« on: July 29, 2019, 02:54:01 pm »
Currently USBxHCD.SYS HC drivers try to register with USBD.SYS already on INIT. That will only succeed if USBD.SYS loads BEFORE these drivers (if USBD.SYS is first in config.sys). Therefore USBxHCD.SYS will try to register with USBD.SYS also on INIT_COMPLETE if the registration failed on INIT. That covers the case that USBD.SYS loads AFTER these drivers because INIT_COMPLETE will be called once ALL drivers have loaded (gone through INIT).
Obviously, the system does not seem to like it if the HC drivers already register on INIT. I will try and remove the registration already on INIT. Then, the HC drivers will register with USBD.SYS only if ALL drivers (regardless of config.sys ordering) have already loaded which would make the load ordering in config.sys irrelevant.
The code comments implied that all that was relevant if you boot from a USB floppy drive / CD-ROM. I just take it for granted that my drivers would then possibly no longer allow to boot from USB.

Hardware / Re: USBDRV 10.225 - full support for USB audio
« on: July 29, 2019, 09:27:03 am »
sorry, but I don't understand.
If you are using the 12.1 driver stack then you do not use my USB drivers I suppose.
And if you use my USB drivers there is no need to change the config.sys USBD.SYS ordering (but I think you can do so without any negative effect but I will need to try out).
As far as USBAUDIO.SYS and USBAUD2.SYS and potentially USBMSD.ADD goes, there is no need to change anything in config.sys. They are in no way affected by the USBD.SYS ordering in config.sys.

Hardware / Re: USBDRV 10.225 - full support for USB audio
« on: July 28, 2019, 03:10:14 pm »
I now uploaded usbdrv228 to hobbes. It contains all of Wim's changes regarding USBAUDIO and USBAUD2 plus changes to USBWAV.

Programming / Re: SOMOBJ.H syntax errors
« on: July 25, 2019, 08:56:01 am »
Looks like structure "som3InitCtrl" is not recognized which in turn means that some other header file is not included or does not contain this structure definition but it should.
You should do a tree search of all header files and find the file that contains "som3InitCtrl" structure definition. you should then check why it is not included. You should check if the structure definition is bracketed by some define and if yes, why that define is not set or set it manually from the compiler command line.
Beware, there are header files that DO NOT end with the .h extension. For example I seem to remember a header file with an .api file extension.

"som3InitCtrl" is defined in somapi.h which should be included by top-level som.h (which also includes somobj.h) . You should check why this does not happen for you. You might only have one file somobj.h but you might have multiple files som.h. You might also need to run a different version of sc.exe (preferably the one from the OS/2 toollkit).

Setup & Installation / Re: JFS chkdsk problem
« on: July 22, 2019, 11:57:39 am »
I have a good backup so I already recreated the partion and formatted it JFS. However, when copying files back to this new partition the title of the files remain correct but the actual file names are shortened to 8.3. When opening drive P: in details view I can edit the titles but the real name does not get updated correctly if the tilte is longer consists of more then 8 characters. (This procedure works fine on other JFS partitions,.)

Is this a partition on a removable drive (say USB drive or so ?). I have found that this problem happens when the drive is loaded as "non-removable" by the device manager (OS2DASD.DMD). you can tell by the look of the drive icon: if it displayed a fixed hard drive icon, then it means that it is treated as "non-removable" (which usually happens if you have attached the drive already on system start), if it displays a different icon then it is treated as "removable". If it is treated as "non-removable" you will need to eject the drive and then to have it rediscovered by LVM. After that, the problems with restricted filenames is gone and the system will fully support long filenames (as long as the underlying filesystem supports that).

Because I tend to forget to have the medium ejected on system start, I have written a WPS class that will rename the file/folder to its long filename/foldername aka. "title" (which I guess is saved in the files/folders EAs). It works for a single file, a folder including all its content or even on a whole disk by selecting this action from the file/folder/disk context menu:

By the way: this WPS class extension peacefully (I hope ...) coexists with any other WPS class extension (XWorkplace etc.)


2Dave Yeo: Yes, I plan to make a command line switch to disable that in the future, but not yet. Just in case someone does not like this. So far, I saw only one reason to not do that. Imagine, you have both "My documents" and "Mydoc~3D" directories in the root directory. Then under DOS, the first one will be abbreviated to the second name, and the second name will be inaccessible. If that's not desired, you'd better avoid creating file names ending at ...~<Number>. But such names are usually not needed. So, it is unlikely if you'd ocassionally create such a file/dir.

I can see another problem as documented in the screenshots that Martin provided:
there is a directory called "VBoxAdditions-os2-x86-5.0.51.r200". This directory name is "shortened" to "VBOXA~29.R20".
Obviously, the translation algorithm misinterprets everything after the last dot as a filename extension even though it is a directory. Additionally, the "extension" r200 is clipped to r20 because for a DOS filename extension only 3 characters are allowed.

I'd say that for a directory name, there should NEVER be an extension (but I am not sure how DOS handles a dot in a directory name). No matter what DOS does it would be much safer to never assume that a directory name has an extension and handle dots in directory names just as an ordinary character.

It's hard to understand what good it does to return "4 Bytes" on a FIL_QUERYEASIZE if the return value is to serve as a measure of how many bytes you need to allocate when you want to actually request an EA.
As I said, you need an FEALIST with at least one entry plus the extra space for the requested EA Name to return the result. even if the EA is empty/does not exist. That is most certainly more than 4 bytes.

And guess what: obviously JFS.IFS returns 0 bytes on a DosFindFirst with FIL_QUERYEASIZE (that's what I read from Gregg's comments). But seemingly it would return 4 bytes on a DosQueryPathInfo with FIL_QUERYEASIZE. In short: the results are not even consistent in itself.

Who is using HPFS (and therefore testing with it) these days ? Nobody.

ok, FS_FINDFIRST / FS_FINDNEXT should therefore also return pfFind->cbList = sizeof(pfFind->cbList) in case of no EAs (!HAS_EAS(pDir->fEAS)) or not activated EAs (!f32Parms.fEAS).

And then, I also wonder if "usGetEASize" returns the correct size. My gut feeling is that you will also need to add 4 on top of what it returns. And I have not yet understood if it really counts the bytes of all the FEA structures (appended by the EA name and the EA data) that it needs to create or only the bytes of the "naked" EA data which, again, would be wrong.

By the way: FS_PATHINFO and FS_FILEINFO do not honour the (!HAS_EAS(pDir->fEAS)) case (that is: the case where no EAs exist).
Unless "usGetEASize" properly handles this case ...

Here is the back and forth discussion regarding FS_FINDFIRST/FS_FINDNEXT:

I just checked the FAT32 source code:

FS_FILEINFO (that should cover API DosGetFileInfo) returns 4 (for FIL_QUERYEASIZE and FIL_QUERYEASIZEL) if there are no EAs.

FS_PATHNFO (that should cover API DosGetPathInfo) returns 4 (for FIL_QUERYEASIZE and FIL_QUERYEASIZEL) if there are no EAs.

FS_FINDFIRST/FS_FINDNEXT (that should cover APIs DosFindFirst/DosFindNext) return 0 (for FIL_QUERYEASIZE and FIL_QUERYEASIZEL) if there are no EAs. This latter one was what Gregg requested as the response for files that do not have EAs.

Read this nonsense about "DosFindFirst" (quoting from the original programmer's documentation):
For Level 2 File Information (ulInfoLevel == FIL_QUERYEASIZE) : On output, pfindbuf contains the FILEFINDBUF4 data structure without the last two fields: cchName and achName. This is used with EAs.

The cbList field contains the size, in bytes, of the file's entire EA set on disk. You can use this field to calculate the maximum size of the buffer needed for Level 3 file information. The size of the buffer required to hold the entire EA set is less than or equal to twice the size of the EA set on disk.

By the way: how does this go together with the fact that if you ask for a specific EA that then, the IFS does have to return an FEA(2) structure, basically returning the EA name that was requested (that is: szName is filled and cbName properly set to the length) but with EMPTY content (that is: cbValue is 0) ?
Returning nothing in this case is definitely WRONG.

That's why in the past I suggested to return a "sensible" size for exactly that FEA(2)LIST structure that would allow to return at least a couple of empty FEA(2) structures but Gregg stated that 0 should be returned.

As I said: a horrible programming interface.

Pages: 1 2 [3] 4 5 ... 28