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 ... 38
1
Programming / Re: A clock in WPS - Educational Project
« on: June 04, 2020, 05:35:43 pm »
1) data segment: if you define a global variable or define with "static" keyword. Stack: a lokal variable in a routine is placed on the stack.

2) you have these 2 options: put gModule in the data seg and call the code to query it only once on class initialization (read SOM spec what class init is and when it happens) or call code whenever you need the module handle in which case you can place gModule on the stack.

2
Multimedia / Re: Use of webcam
« on: June 02, 2020, 04:41:55 pm »
Hi Lars,

Hi Wim,

does USBAUDIO.SYS also fail to find the microphone on the C-270 ?

I cannot try because I don't have the C270. But the C270 is also a miscellaneous device so usbaudio.sys will also ignore it.   

Quote
For the C-250 and also for the C-270 I can see AUDIO CONTROL and also one or more AUDIO STREAMING interfaces and that's ok.
But there are also association descriptors. Maybe usbaudio.sys fails to properly find the control and streaming descriptors because it gets confused by the association descriptor.

Certainly, USBAUDIO.SYS should not trap if it finds a "record only" USB audio device. I have a USB microphone (only MIC). Let's see what that does to USBAUDIO.SYS.

I must say that I did a dirty hack to accept the webcam and to find the feature_unit  descriptor. I seem to recall that the traps occur while attempting to record.

Quote
I would say that USBAUDIO.SYS (and USBAUD2.SYS) should support everything that has a AUDIO CONTROL and AUDIO STREAMING interface (descriptor). It has to serve all devices of that class, even if there is more to the device than just audio.

The video part would then be handled by a USBVIDEO.SYS driver but you have decided to go a different route via USBCALLS/USBRESMG which is also ok.
Hi Wim,
in the lsusb report I see a warning "Warning: Descriptor too short" which will break the descriptor chain and that is true for the C-250 and C-270. Maybe THAT is the reason why searching for the audio control and streaming interface descriptors fails because the OS/2 USB client drivers always search the chain by honouring the "bLength" field instead of using known fixed values.

3
Multimedia / Re: Use of webcam
« on: June 02, 2020, 02:00:59 pm »
Hi Wim,

does USBAUDIO.SYS also fail to find the microphone on the C-270 ?
For the C-250 and also for the C-270 I can see AUDIO CONTROL and also one or more AUDIO STREAMING interfaces and that's ok.
But there are also association descriptors. Maybe usbaudio.sys fails to properly find the control and streaming descriptors because it gets confused by the association descriptor.

Certainly, USBAUDIO.SYS should not trap if it finds a "record only" USB audio device. I have a USB microphone (only MIC). Let's see what that does to USBAUDIO.SYS.

I would say that USBAUDIO.SYS (and USBAUD2.SYS) should support everything that has a AUDIO CONTROL and AUDIO STREAMING interface (descriptor). It has to serve all devices of that class, even if there is more to the device than just audio.

The video part would then be handled by a USBVIDEO.SYS driver but you have decided to go a different route via USBCALLS/USBRESMG which is also ok.

4
Multimedia / Re: Use of webcam
« on: June 02, 2020, 11:32:32 am »
Quote
  Interface 2: Alt=0 nEP=0 Class=1(Audio) SubClass=1 Protocol=0 StringIx=0
  Interface 3: Alt=0 nEP=0 Class=1(Audio) SubClass=2 Protocol=0 StringIx=0
  Interface 3: Alt=1 nEP=1 Class=1(Audio) SubClass=2 Protocol=0 StringIx=0
  Interface 3: Alt=2 nEP=1 Class=1(Audio) SubClass=2 Protocol=0 StringIx=0
  Interface 3: Alt=3 nEP=1 Class=1(Audio) SubClass=2 Protocol=0 StringIx=0
  Interface 3: Alt=4 nEP=1 Class=1(Audio) SubClass=2 Protocol=0 StringIx=0

The information on audio is rather meager i.e. even endpoint information is missing.
Fortunately I have lsusb reports from both c250 and c270 webcams and the audio descriptors appear to be identical.
The inbuild microphone may deliver 16-bit mono at 16000/ 24000/32000/48000 Hz.

I have experimented in the past to obtain audio from the c250 webcam and it appears to be possible.
The big question is what to do with the audio data once obtained. Should it go to the default audio device?
The truth is that I am not really an application programmer, so I want this to be as simple as it can be.

I also tried to have usbaudio.sys recognize the c250 microphone but I gave up on that.

Wim, can you send me the lsusb report for the C250 ? I suspect that there is some feature unit for volume/mute on the USB "data out" (microphone) path that needs to be cranked up (or a multiplexer unit set to the correct input or some such). Currently, USBAUDIO.SYS only controls the feature unit for volume/mute on the USB "data in" (speaker) path.

You can even try to write a REXX script to crank up that feature unit. You sure know how to do that once you find the corresponding feature unit in the descriptor info ...

5
Applications / Re: OS/4 (technical details only)
« on: June 02, 2020, 08:38:34 am »
Do you know what else apart from providing table data ACPI4.BPD offers? If there is an PSD option /MPT to suppress use of ACPI Tables but loading ACPI4.BPD nonetheless,I expect it to offer more. Does it offer shutdown and powersave?
It looks like it at least offers shutdown.

6
Applications / Re: OS/4 (technical details only)
« on: June 01, 2020, 11:14:38 am »
Can anything be done to fix the DMI table?

A little background. ANPM uses the output of dmidecode to hash/encrypt ID/PASS credentials for subscription repos. I was working through an issue where on the OS2 kernel this process was failing. Turned out to be caused by the board maker (MSI) putting/leaving generic identifier string in a specific DMI table field. Alex fixed this, so now that works.

I subsequently booted up using my OS4 config and came to find out that ANPM credentials check on the sub repos failed again. This time I looked through the debug, reviewed the outputs from dmidecode and indeed, the output is broken. In case someone else is attempting to use ANPM on an OS4 configured system they will likely fail as well.

FYI, here is what I'm seeing:

Code: [Select]
[G:\]dmidecode
# dmidecode 3.1
Scanning /dev/mem for entry point.
SMBIOS 2.5 present.
54 structures occupying 1934 bytes.
Table at 0x0009F800.

Invalid entry length (0). DMI table is broken! Stop.

Using OS/4: I don't know if this is the ultimate cure (likely not), but on an eCS system, I just copied DMI.EXE from the \ecs\install\detectei directory to the ANPM program directory and renamed to DMIDECODE.EXE (after backing up the dmidecode.exe file that is located in that dir). That helped to stop ANPM.EXE on blocking when invoking DMIDECODE.EXE.
The DMI.EXE that comes with eCS is version 2.10.  Therefore my buest guess is that DMIDECODE.EXE version 3.1 that comes with ArcaOS is either broken or has changed its output in a form that makes ANPM fail. The DMIDECODE.EXE in the ANPM directory is version 2.12 and that also did not work together with ANPM.
The obvious difference between version  3.1 and older versions is that version 3.1 prints this string:
Quote
Scanning /dev/mem for entry point.
The older versions do not do this.

7
Applications / Re: OS/4 (technical details only)
« on: June 01, 2020, 10:01:00 am »
add. info after rereading the OS/4 kernel info text for OS4APIC.PSD:

In case the MP tables are broken, ACPI4.BPD will interact with OS4APIC.PSD to provide it with the equivalent info from the ACPI tables.

The MP tables as well as the ACPI tables provide OS Software with the information how many cores exist, how many and what type of interrupt controllers exist, etc.
The MP tables however are an outdated way of supplying this information and therefore, they are often broken/incorrect on modern systems. Today, every MOBO producer is strongly encouraged to support ACPI (as well as UEFI, but this is a different topic ...).

Therefore, I am not sure if ACPI4.BPD supports all the other ACPI stuff like power saving and shutdown. You will need to try out. I can say that on my system and with the aforementioned drivers, I can fully power off the system by selecting system shutdown.

8
Applications / Re: OS/4 (technical details only)
« on: June 01, 2020, 09:34:06 am »
OS/4 comes with its own PSD and ACPI support. You need OS4APIC.PSD to support a multi-core/SMP system. However, that PSD only supports APICs instead of the conventional interrupt controller (which is necessary for an SMP system) but it does not support ACPI.
If you really need ACPI support (some systems require this so that they can work at all) you need to get ACPI4.BPD which currently is in an experimental state but I can say that it works on my system.

You will find OS4APIC.PSD (and its .SYM symbol file) in the OS/4 kernel zip. As with any other PSD, it has to go into the \OS2\BOOT directory and needs to added to the (alternate, preferrably) CONFIG.SYS.

ACPI4.BPD is difficult to find, if you give me an email address, I can send it to you. It also has to go into the \OS2\BOOT directory. It will be autoloaded by the OS/4 kernel if it is found, therefore, nothing to add to CONFIG.SYS.


9
Multimedia / Re: Use of webcam
« on: May 26, 2020, 08:03:57 am »
Superb. We now have 2 bright persons to get the error fixed. Now you just need to convince Wim to pass the code over to you.
Sorry, that's enough nonsense for me: breaking an interface that everyone had agreed on and that worked. Period. Enough said.

10
Multimedia / Re: Use of webcam
« on: May 25, 2020, 02:41:57 pm »
One additional note:
Wim can confirm or not but I would believe that uvcview.exe/uvcscope.exe uses USBCALLS/USBRESMG to do its thing.
Therefore,the problem could also be located in those components.
Taken the fact that Rich reported that USB audio works ok with the AN 32-bit stack, I consider these 2 a likely source of the problem.

Yes, uvcview.exe/uvcscope.exe are using USBCALLS/USBRESMG to do their thing. The only difference is that uvcscope.exe has a microscope selection parameter.

I have a Lenovo Thinkpad T540p with two bootable ArcaOS volumes. One has USB 11.17, and runs websee UVCView.exe perfectly. The second has USB 12.05 and  UVCView terminates with an error: [0000FF14] Obtain thread error!

This confirms that the problem is somewhere within the ArcaNoae 12.x USB driver set.

This doesn't confirm anything due USBCALLS is specific and must be at same level as other usb drivers.
Changing process or like it works is not a sing of miss function but more like compatibility...
 
What can be done to have uvcscope.exe compatible with new releases ?
(this is something I always have with GUI reequiring me to verify and adapt my "tools" at each update)

Do you have a debug option to trace in/out flow ?

Thanks and Regards
Rémy
 

It worked with 11.17. It worked and still works with my USB driver stack. It fails with 12.05. Therefore, it confirms EVERYTHING. If AN did change the programming interface to USBCALLS/USBRESMG either accidentally or deliberately or if it is a bug accidentally introduced, then it is up to them to fix it.
There are a whole lot of other applications using USBCALLS/USBRESMG. Do you also expect them to be updated ?

11
Multimedia / Re: Use of webcam
« on: May 25, 2020, 11:45:32 am »
One additional note:
Wim can confirm or not but I would believe that uvcview.exe/uvcscope.exe uses USBCALLS/USBRESMG to do its thing.
Therefore,the problem could also be located in those components.
Taken the fact that Rich reported that USB audio works ok with the AN 32-bit stack, I consider these 2 a likely source of the problem.

12
Multimedia / Re: Use of webcam
« on: May 25, 2020, 09:06:06 am »
So we are back to zero. Open a problem report with AN. Something must be wrong ( or different) about isochronous support in the 12.05 USBEHCD.SYS driver.

13
Programming / Re: A clock in WPS - Educational Project
« on: May 24, 2020, 10:23:55 am »
1) do not specify -D__IBMC__ when calling the compiler. That defeats the whole purpose of compiling C++ code as this define is set when the C-compiler is run but not the C++.compiler

2) you are now entering into the dark realms of SOM programming. What you are missing in particular is to include <os2.h> in your code (and defining the proper defines INCL_BASE and INCL_PM) because even the generated code refers to datatypes that are defined in the OS/2 include files.
You could now do this in two ways:
add
#define INCL_BASE
#define INCL_PM
#include <os2.h>
in your c++ source file, even before including "xwpclock.xih". That is easy but is has the negative impact that you have to do that manually and it might get acidentally removed by sc.exe.
or:
you add some "instrumentation" in your .idl file that tells sc.exe to automatically generate these statements into your c++ source file:
        passthru C_xh_before = ""
        "#define INCL_PM"
        "#define INCL_BASE"
        "#include <os2.h>"
        "";
That will place these statements into xwpclock.xh (at the correct place) which is included by xwpclock.xih.
You will have to read the SOM programming documentation to understand what's going on, hint: "xih" is the implementation header which is used by the guy implementing the class, "xh" is the public definition header used by the guy using the class in his own code and the guy implementing the class.

3) in your .rc file you misspelled the . h file you intend to include. Therefore you will get an error on building

4) in your .h file you missed to define DLG_XWPCLOCKTIME and possibly others. The resource compiler gives a bogus warning because it thinks that identifier is a string (where it should be the define for a number)
etc.

5) when you actually want to use resources (like a dialog), you will need to query the module handle of your own DLL because that module handle will need to be passed to OS/2 API functions creating dialogs (like WinLoadDlg etc.) and then to specify the ID of the resource/dialog, like DLG_XWPCLOCKALARM. In order to do that you will need to include the xwpclock-resources.h not only in your .rc file but also in the c++ source file. Again, you can hack that in manually or have it done via the .idl file.

6) There are multiple ways to query your own module handle: you either write a custom _DLL_InitTerm function to get to the handle (which is the most forward way for me, but maybe not to others,see the hwman sample code) or you can use SOM method "somLocateClassFile" plus OS/2 API function "DosGetModuleHandle" to get to the module handle:

HMODULE gModule = NULLHANDLE; /* needs to be placed somewhere into the data segent and NOT on the stack ! */

PSZ ModName=NULL;
somId theId = somIdFromString("XWPClock");
ModName = SOMClassMgr->somLocateClassFile(theId,XWPClock_MajorVersion,XWPClock_MinorVersion); /* you need to include <somcm.xh> */
SOMFree(theId);
DosQueryModuleHandle(ModName,&gModule); /* gModule now contains your module handle */

It should be obvious to you that you will need to fix this piece of code once you change your class name to something else. Maybe you now see why I always go for the custom _DLL_InitTerm function ...


14
Multimedia / Re: Use of webcam
« on: May 23, 2020, 12:43:27 pm »
Remy was using the 32-bit version of USBEHCD.SYS which is the USB 2.0 host controller driver.
And as far as I understood the readme, this version of USBEHCD.SYS does not support isochronous transfer. But the one from the 11.17 stack (16-bit) did.
Or has this now changed for the 32-bit version of USBEHCD.SYS ? If that is the case, then it will indeed be sufficient to just use my version of USBAUDIO.SYS / USBAUD2.SYS together with the AN stack.


15
Multimedia / Re: Use of webcam
« on: May 21, 2020, 10:40:20 pm »
Don't know. I neither work for nor work with ArcaNoae.

Pages: [1] 2 3 ... 38