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 ... 26 27 [28] 29 30 ... 86
406
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: December 11, 2021, 05:45:36 pm »
The interface of the AN USBCALLS and my USBCALLS is exactly the same and therefore the import library is also the very same.
And therefore, if I build usb100.dll, you can run that on any AN system.

407
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: December 11, 2021, 01:14:08 pm »
Anyways, dropping in the new usb100.dll gave
Code: [Select]
12-10-2021  09:59:35  SYS2070  PID 2128  TID 0001  Slot 00a6
H:\TMP\HIDAPI\LIB\HIDTEST.EXE
HIDAPI0->USB100._clock_gettime
127

So I rebuilt hidapi, some wrestling to link to usbcalls (see libcx is also linked in by the pkgconfig script). Things have improved as the PATH error is gone but still unable to open the device.
Code: [Select]
H:\tmp\hidapi\lib>hidtest.exe
hidapi test/example tool. Compiled with hidapi version 0.11.0, runtime version 0.11.0.
Compile-time version matches runtime version of hidapi.

Device Found
  type: 046d c534
  path: 1-3:1.0
  serial_number: (null)
  Manufacturer: Logitech
  Product:      USB Receiver
  Release:      2901
  Interface:    0
  Usage (page): 0x0 (0x0)

Device Found
  type: 046d c534
  path: 1-3:1.1
  serial_number: (null)
  Manufacturer: Logitech
  Product:      USB Receiver
  Release:      2901
  Interface:    1
  Usage (page): 0x0 (0x0)

Device Found
  type: 046d c216
  path: 0-4:1.0
  serial_number: (null)
  Manufacturer: Logitech
  Product:      Logitech Dual Action
  Release:      300
  Interface:    0
  Usage (page): 0x0 (0x0)

unable to open device

Edit: notice the serial number is still null, perhaps the problem, perhaps caused by working around iconv.

"serial number": the "serial number" as well as "Manufacturer" and "Product" are string descriptors, the id of which are given in the device descriptor. But if the string descriptor id is 0, then no string (descriptor) is saved in the device. About all manufacturers bother to set the "Manufacturer" and the "Product" string, but not the "serial number" string (even though it's possible that even Windows is using that to distinguish 2 instances of the very same device).
In short: nothing to worry about.

408
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: December 11, 2021, 01:09:12 pm »
1) as to running configure, I was given this shell script (content of file conf.txt):

export CFLAGS='-Zomf -Wno-attributes'
export CXXFLAGS='-Zomf -Wno-attributes'
export LDFLAGS='-Zhigh-mem -Zomf -lcx'

../git/configure --disable-static \
  --program-prefix= --prefix=/@unixroot/usr --exec-prefix=/@unixroot/usr \
  --bindir=/@unixroot/usr/bin --sbindir=/@unixroot/usr/sbin \
  --sysconfdir=/@unixroot/etc --datadir=/@unixroot/usr/share \
  --includedir=/@unixroot/usr/include --libdir=/@unixroot/usr/lib \
  --libexecdir=/@unixroot/usr/libexec --localstatedir=/@unixroot/var \
  --sharedstatedir=/@unixroot/usr/com --mandir=/@unixroot/usr/share/man \
  --infodir=/@unixroot/usr/share/info

I had to do a "sh conf.txt" in the root of my build directory, after that, I could do a "make" or "make install".

2) as to usbcalls import library: if you install RPM package "usbcalls-devel" from the NETLABS release repo, the import library is in there (in .A as well as in .LIB format)

409
Hardware / Re: New ArcaOS USB driver.
« on: December 11, 2021, 12:34:02 pm »
Hi Lars,

Your driver resolves the trap 000D
Fine.

Regards
Rémy

Thanks for the feedback. as I had written to you, for as long as you use the test driver, keep an eye on your system behaviour. OS2DASD.DMD is a critical system driver.

Lars

410
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: December 11, 2021, 12:29:42 pm »
Thanks, I am still ironing out some bugs, in particular related to iso transfers. Just checked in again.

As to logging: if you specify "SET LIBUSB_DEBUG=4" on the commandline before running your app, then usb100.dll will dump a whole lof of logging info to stderr.

That might give a clue as to what goes wrong, if any.

411
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: December 10, 2021, 04:52:19 pm »
By now, I have finished work on libusb (hopefully). I'll ask BWW to create an updated RPM. You might want to try the updated version and see if that helps. Proper support of "libusb_get_port_numbers" is still a problem (what error message did you get when trying out hidapi ?)
Where do I get your version from to build it myself?

It's here:
https://github.com/bitwiseworks/libusb1-os2

but there is still work to do (something's not quite right when you end a process with Ctrl-C). Nonetheless, you might want to try it.


412
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: December 07, 2021, 04:14:17 pm »
By now, I have finished work on libusb (hopefully). I'll ask BWW to create an updated RPM. You might want to try the updated version and see if that helps. Proper support of "libusb_get_port_numbers" is still a problem (what error message did you get when trying out hidapi ?)

413
Comments, Suggestions & Questions / Re: Hobbes (Files) Reoganization
« on: December 06, 2021, 11:57:27 am »
I know that this can be argued forever but I would NOT put "VCompat" under /pub/dos.

"VCompat" is a 32-bit OS/2 VDD (virtual device driver). It CANNOT be loaded by the DOS operating system. The same holds true for "VSound" and "VDMA" (from the same author and in the same directory as "vcompat").

"2GBFix" on the other hand is a DOS TSR (Terminate and Stay Resident) program that can be executed under a real DOS or inside an OS/2 VDM.

What might be reasonable is to have a new subdir "/pub/os2/system/drivers/vdd" to place these kind of drivers.


By the way: the "2GBFix" functionality is included in "VCompat". In short: it's easier and preferrable to use "VCompat" as it also has many additional DOS fixes.

414
Multimedia / Re: How do I change this default behaviour?
« on: December 01, 2021, 04:53:41 pm »
Ok, then try this, assuming we are talking about avi files:

1) create a dummy file "mmtest.avi" on the desktop like so: oo /n MMMPG mmtest.avi "<WP_DESKTOP>"

2) Use the context menu of that file to add "mplayer" to it as an open action. Move "mplayer" up the list to be the topmost/first action (that is: the default action)

3) now, modify the default view: oo mmtest.avi "<WP_DESKTOP>" "CLASSDEFAULTVIEW=4096;" (find out the oo switch to modify an object, I don't have that handy ...)

Maybe that will do the trick. If yes, you can then automate the process (with a REXX script) and do this for all the various file extensions that you want to have mplayer play.


415
Hardware / Re: Using a LaserJet 2100m on a Print Server
« on: December 01, 2021, 04:39:19 pm »
By "old printer", I do not mean "bad printer". It's just that bidirectional communication with a printer was not standard when printers with parallel ports were first built.

416
Multimedia / Re: How do I change this default behaviour?
« on: December 01, 2021, 10:28:50 am »
Yes, the complexity is ridiculous. But if Rich's suggestion means that the "first associated program" will open the file, then you'll also need to associate your desired program and it will have to the "the first".

And in order to do that, I suspect that you need to set up a program object for your desired progam and then, on the association page, to assign by file type and/or file extension the files you want to have handled by this program (the *.AVI files in your case). What I don't know is how to convince the system that this is the "first" program for the files of given file type and/or file extension. I hope that you can specify the usual placeholder parameters in the "command line" entry field to have the program started with additional parameters and the filename.

Since with Rich's suggestion, on a double click, the open action now is "the first associated program" and no longer the default action (which was "Play"), your program should then be called with the filename as the argument instead of the "Play" action invoked (which likely is to invoke the default MM device specified through MMPM2.INI ...).

So I hope at least.

417
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) as "LPD Server" and "Printer" (without the quotes) as the "LPD Printer" ? That's at least what the DLink config page mandates (if you read through the help for "LPD Printer" you will see that it is the LPR Queue Name that you need to enter).
The use of USB should be completely transparent as long as the USB host implementation in the print server works according to standards.

EDIT: the reason why you don't see a "proper" name for your printer might indeed be related to the USB to parallel port adapter and/or also the printer itself. I suspect that you need bidirectional communication functionality to query a "decent" printer name from a printer. If the printer is very old, it might not support that or the USB to parallel port adapter might not support bidirectional communication. Nonetheless I would hope that at least you can print to that printer with the settings given above.

418
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.

419
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.

420
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...

Pages: 1 ... 26 27 [28] 29 30 ... 86