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 ... 58
1
Hardware / Re: Using a LaserJet 2100m on a Print Server
« on: November 30, 2021, 10:40:20 pm »
Why don't you use the SLPR port driver and specify the IP address of the print server (192.168.1.55) and "Printer" (without the quotes) as the  print queue name? That's at least what the DLink config page mandates.
The use of USB should be completely transparent as long as the USB host implementation in the print server works according to standards.

2
Multimedia / Re: How do I change this default behaviour?
« on: November 29, 2021, 07:02:37 pm »
On second thought, it's likely much easier to write a new WPS class that registers for certain file types/extensions and then to override the "open" method (invoked on a double click). And that is what the CWMM classes likely do. Then they just invoke some app with the filename. And the app seems to be configurable via some INI key or config file.

3
Multimedia / Re: How do I change this default behaviour?
« on: November 29, 2021, 05:05:23 pm »
You are mixing up MCD drivers (see "MMPM2.INI") and MMIO procedures (see "MMPMMMIO.INI").

MCD drivers are for actually playing/recording audio/video content, MMIO procedures are for converting file formats (say from ADPCM to PCM) so that they become playable by MCD drivers (which only know a limited number of file formats to play, for audio this is almost exclusively: PCM) or transform to a standard format on record.

I would need to look at what commands an MCD driver needs to support but there must be something like OPEN , LOAD and also PLAY. And I seem to remember that either on OPEN , LOAD or PLAY, the MCI driver gets passed a filename or an "hmmio" which is a handle to an already opened audio/video "file" (where "file" can also mean data in memory). Search for "MCI_OPEN", "MCI_LOAD" and "MCI_PLAY" ...

Then, simply spoken, you'd just start the app with that filename (if it is a real file, otherwise you would need to create a temporary file ...). Then, in order to deal with concurrent calls, you need to deal with device IDs and possibly serializing access to that "MCD device" (maybe that replay app can only play one file at a time ...).

And then, in order to easily support multiple different replay apps, it would likely be a good idea to make that configurable via either some INI file or via some settings page in the "Multimedia Object" or some such. There are a few other functions that are mandatory to support (but won't need to do much for the envisaged use case).

And yes, the entry point of such an MCD driver (DLL) always is "mciDriverEntry".

Have a look at this, I think that's a good explanation of somebody who knows:
http://mireality.co.uk/writing/technology/os2-multimedia-chapter/media-control-interface/

By the way: MCD drivers are added via a CARDINFO.DLL resource DLL. It's some work to write one but it's not extremely difficult (maybe there also exists some script approach but I don't know). An example has been the "Timidity MCD" which essentially wrapped the Timidity SW so that you could play MIDI files with a double click.

4
Multimedia / Re: How do I change this default behaviour?
« on: November 29, 2021, 10:44:13 am »
The MM classes do make an attempt to define some "default" behaviour when you double click a file for the file type/file extension they are responsible for. I have not looked at the MM classes but I'd expect that they just do a MCI_PLAY command on the MM device that is associated with that file type/extension as a default. The CW MM classes might have implemented a smarter approach (looks like it).
Anyway, the "default" MM device for some given file type/file extension is defined through MMPM2.INI. And unfortunately, that "device" has to be an MCI device which essentially boils down to being a DLL with a defined entry point and command support. Certainly not any arbitrary EXE file. It would be possible to "wrap" invocation of an EXE file as a MCI device but this has to be implemented...

5
Hardware / Re: New ArcaOS USB driver.
« on: November 28, 2021, 02:43:58 pm »
Sent to your private email.

6
Hardware / Re: New ArcaOS USB driver.
« on: November 27, 2021, 03:40:49 pm »
I have that test version ready. Bumped up the version number to 14.106 so as to avoid confusion.
Where do you want me to send it to ?

Lars

7
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 27, 2021, 10:36:51 am »
I just tested: libusb uses "Usbquerydeviceinfo" to query the devices. And "lsusb" uses libusb to show the devices list. It will only show non-hub devices (that is: only "end-user" devices).
Unless David has added something. But that of course will never be publicly visible. He'll always roll his own ball.

8
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 27, 2021, 10:19:42 am »
That struct returns the parent hub index a device is attached to as "parentHubIndex". But there is no public way to query the device index of that hub device. (query the device index from the hub index) And therefore you cannot build up the hierarchy.
It would not be awfully difficult to extend the functionality but now we have quite some code out in the field that makes use of USBCALLS. We could add another function that can query the device index for a given hub index. Then an application could of course build up the hierarchy.

EDIT: and sine the struct does not contain the device index but rather the real device address and rmDevHandle, then that new function should better return device address and rmDevHandle.

9
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 27, 2021, 12:09:34 am »
As to controller,hub,device info: I assume you are quoting what the testlog from AN returns.
For debugging purposes, David added an interface to USBD.SYS to completely query all USB devices, including hubs. Since USBD.SYS of course knows about all USB devices, including USB hubs.

But USBCALLS (and USBRESMG) does not have access to that interface.

Anyway, libusb is using USBCALLS to implement its functionality, so that is the proper way to go. Because that is what usbhid obviously uses.

10
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 26, 2021, 01:24:58 pm »
I am currently working on libusb (for various reasons).
I did some updates on what port you will find what device. That'll hopefully solve it. We will see.

Note that our implementation of libusb will NEVER be able to list the whole bus hierarchy (which encompasses root hubs and chained hubs) because USBD.SYS (and therefore USBRESMG.SYS and also USBCALLS.DLL) does not publicly expose hub information.

EDIT: now I see that "libusb_get_port_numbers" tries to resolve the whole bus hierarchy, from the plugged in device upstream up to the root hub port. As I said, that cannot work. Unless we modify USBD.SYS, USBRESMG.SYS and USBCALLS.DLL.

11
Hardware / Re: New ArcaOS USB driver.
« on: November 25, 2021, 10:48:11 pm »
I'll try and knock it together. As time permits.

12
Hardware / Re: New ArcaOS USB driver.
« on: November 25, 2021, 12:59:42 pm »
I can build a test version of OS2DASD.DMD to prove that the error can at least be circumvented in the described way (it's a good question what consequences this error has on system behaviour as it should not occur in the first place).

However, there is the other problem that ArcaNoae will likely not be able to distribute a fixed version of OS2DASD.DMD due to legal reasons.

But maybe you can add this info to your ticket and AN can deduce what they need to do so that this error will never occur.

13
Hardware / Re: New ArcaOS USB driver.
« on: November 25, 2021, 01:19:14 am »
The error happens here in OS2DASD.DMD, in routine "VOID _loadds FAR NotifyDoneIORB (fpIORB)":

...
   if ( ((PRPH)pDMWork->pRequest)->Cmd == PB_REQ_LIST)
      NotifyDoneIORB_RLE(pIORB, (PPB_Read_Write) pDMWork->pRequest, pUnitCB);
   else
   {
      NotifyDoneIORB_RP (pIORB, (PBYTE) pDMWork->pRequest, pUnitCB);
   }
...

It happens because "pDMWork->pRequest" is NULL. This is an error within OS2DASD.DMD because it should itself save a request packet pointer to "pRequest" (it is not the ADD [USBMSD.ADD in this case] calling into OS2DASD.DMD, invoking this routine, that sets this pointer, but rather OS2DASD.DMD itself).

The only fix I see is to update OS2DASD.DMD to check if that pointer has a valid value:

if ((PRPH)pDMWork->pRequest)
{
   if ( ((PRPH)pDMWork->pRequest)->Cmd == PB_REQ_LIST)
      NotifyDoneIORB_RLE(pIORB, (PPB_Read_Write) pDMWork->pRequest, pUnitCB);
   else
   {
      NotifyDoneIORB_RP (pIORB, (PBYTE) pDMWork->pRequest, pUnitCB);
   }
}

One of the gazillion bugs that still linger in OS/2 code ...

Cheers,
Lars

14
Hardware / Re: New ArcaOS USB driver.
« on: November 24, 2021, 03:47:51 pm »
Yes, I saw that 12.10 is out. Ok, let's assume that is the version that Remy is talking about ...

I am just too lazy to update stuff that still does not work reliably. But maybe I'll give it a try in a VM (ArcaOS guest) and see if it solves that problems that I have in a VM.

15
Hardware / Re: New ArcaOS USB driver.
« on: November 24, 2021, 08:52:21 am »
What version is "the new USB driver"?

Pages: [1] 2 3 ... 58