Messages

1

Programming / Re: DISKIO - storage device detection logic

« on: January 04, 2025, 11:54:28 pm »

Hey Andi!

Not sure what you're really want to know but DataSeeker uses DosQueryFSAttach() to distinguish between different drive types. I think I copied this from 4os2 code back then but not sure anymore. Anyway http://trac.netlabs.org/dataseeker/browser/trunk/DriveInfo.c contains the code which finds out if the drive is a disk, floppy, network, CD/DVD, or .... Also if removable or not...

Aha...good stuff for sure!

This has helped me a lot in understanding how to correctly call the other DosDevIOCtl category functions and I was in fact able complete the logic for the device mapping function. Alas (see my previous thread update) that's still not enough to tell me whether a simple device # has media mounted on it and could in fact be benchmarked.

FYI - there is a very real chance here I'm missing something obvious, so don't by shy in giving me a quick smack...LOL

2

Programming / Re: DISKIO - storage device detection logic

« on: January 04, 2025, 11:43:58 pm »

Well, that few hours of work took me completely NOWHERE!!! 

OK, that's good to know as I am currently looking at using the media/removable check for each device to identify whether that device should actually be tested. Basically: if the media is 'mounted', we are good, otherwise we need to skip it.
....
Therefore, what your remark tells me is that I should be fine to use that IOCTL_DISK (08h) & DSK_BLOCKREMOVABLE (20h) combo to test for presence of actual media (where a partition object is present) as opposed to just the presence of a storage device that may not in fact have any media currently loaded (thus the problem we are seeing with USB devices) - I think anyways...for now...

Yeah, I completed that function and learned that the DosOpen API won't deal with anything other than either a fully qualified filename, or in the case of a drive it must be a proper drive letter/number.

Soooo...my hope, as slim as it was, that the numbered DEVICE name could in fact be used by DosOpen was incorrect. Given this I lack a way to connect the devices that the INFO_COUNT_PARTITIONABLE_DISKS parameter gives me when calling DosPhysicalDisk to actual volume/partition objects means that I have no way to check whether a USB device currently has media mounted in it and therefore coudl be tested by DISKIO.

Lars did point out in another thread (circa 2021 => https://www.os2world.com/forum/index.php?topic=2792.0) that I may need to use DosPhysicalDisk, but the problem with that approach is in the fact that the returned device handle can only be used with DosDevIOCtl CATEGORY=09h functions and none of those functions return information about the status of media on the device itself, and I never did figure out what is that "...special "filename" to use [with] DosOpen..." either.

Hmmm...

I tell ya it almost seems like core of DISKIO logic should be re-written to approach this from partition/volume perspective, which would give us visiblity to FS stuff (and thus media presence). That subsequently could be used to determine whether an actual DEVICE (which the partition/volume belong to) should be tested. Right now DIKSIO's logic is the inverse of that.

Maybe I just need to re-focus on handling the exception that arises when an unmounted-media USB device is being benchmarked so that this exception can be correctly handled...LOL?

3

Programming / Re: DISKIO - storage device detection logic

« on: January 04, 2025, 03:51:09 pm »

Hello Lars,

I seem to remember that IOCTL_PHYSICALDISK was for accessing all sectors of a physical disk whereas IOCTL_DISK was for accessimg a drive / a volume (or partition) of a disk.
So that has nothing to do with device type.

OK, that's good to know as I am currently looking at using the media/removable check for each device to identify whether that device should actually be tested. Basically: if the media is 'mounted', we are good, otherwise we need to skip it.

Here is the WIP logic (ignore the obvious missing declarations, etc, this is just general logic with some specific API stuff tossed in as anchors):

Code: [Select]

void device_map (int iDisks, int iCDROMs)
{
   int      iCnt;
   APIRET   rc = NO_ERROR;

   // we have a TOTAL number of HD-type and CDROM-type devices now, so let's
   // take a pass through them all and check to see if they have mounted media
   // in them, if YES, that means we can test, otherwise, we should NOT!
   for (iCnt = 0, iCnt < iDisks, iCnt+)
   {
      // what device am I processing?
      sprintf(szName, "$%d:", iDisk);

      // let's get a handle for this device
      if (DosOpen (szDrv,                                      /* device name */
                   &hfHandle,                     /* address of device handle */
                   &ulAction,              /* address of DosOpen action taken */
                   0,                               /* logical size of device */
                   FILE_NORMAL,                                 /* attributes */
                   FILE_OPEN,              /* action to take if device exists */
                   OPEN_FLAGS_DASD | OPEN_FLAGS_FAIL_ON_ERROR |
                   OPEN_ACCESS_READWRITE | OPEN_SHARE_DENYREADWRITE,  /* mode */
                   0)                           /* device extended attributes */
      {
         // call the DosDevIOCtl API here
         if (DosDevIOCtl (HANDLE (hfDevice),                    /* device handle */
                          IOCTL_DISK,               /* category of request - 08h */
                          DSK_BLOCKREMOVABLE,  /* function being requested - 20h */
                          pParms,                 /* Input/Output parameter list */
                          ulParms,        /* size of Input/Output parameter list */
                          &ulParmLengthInOut,  /* Input: size of parameters list */
                                          /* Output: size of parameters returned */
                          pData,                       /* Input/Output data area */
                          ulData,              /* size of Input/Output data area */
                          &ulDataLengthInOut); /* Input: size of input data area */
                                                /* Output: size of data returned */
         
         // now parse the result and update the global device structure record
         // WIP
      }

      // display the device status information here
      // WIP

   }

} // end of device_map

Subsequently that "global device structure" record would be used by the remainder of the DISKIO logic to check whether the particular device should, or should not be benchmarked.

Therefore, what your remark tells me is that I should be fine to use that IOCTL_DISK (08h) & DSK_BLOCKREMOVABLE (20h) combo to test for presence of actual media (where a partition object is present) as opposed to just the presence of a storage device that may not in fact have any media currently loaded (thus the problem we are seeing with USB devices) - I think anyways...for now...

4

Programming / Re: DISKIO - storage device detection logic

« on: January 03, 2025, 04:58:55 pm »

Alright, a bit of an update.

I spent considerable amount of time over the holidays trying to understand the DISKIO 'device type' detection logic. This is important because the remaining code execution pathway is largely based on what type of a device is being processed.

In short, there are three types recognized, which in turn control the definition of DosDevIOCtrl CATEGORY call.

This section declares two of them:

Code: [Select]

#define PHYSICAL     0x1000   //4096
#define CDROM        0x2000   //8192

Later on a dynamic CATEGORY assignment is made through the following macro:

Code: [Select]

CATEGORY(x)  (((x) & CDROM) ? IOCTL_CDROMDISK : ((x) & PHYSICAL) ? IOCTL_PHYSICALDISK :IOCTL_DISK)

So basically:
if device=CDROM, then CATEGORY = IOCTL_CDROMDISK
if device=PHYSICAL, then CATEGORY = IOCTL_PHYSICALDISK
else CATEGORY = IOCTL_DISK

Indeed, in my debugging I have found the following to be substantitated:

1) HD        - 4099, which means DosDevIOCtl is given CATEGORY = IOCTL_PHYSICALDISK (09h)
2) CDROM - 8195, which means DosDevIOCtl is given CATEGORY = IOCTL_CDROMDISK (80h)
3) USB      - 4099, which means DosDevIOCtl is given CATEGORY = IOCTL_PHYSICALDISK (09h)

...alas, and here is where our problems arises: both HD and USB storage devices are treated like the same category device, that being IOCTL_PHYSICALDISK.

At the moment my stipulation is that the use of "...else CATEGORY = IOCTL_DISK..." was intended to cover stuff like USB based devices...but that's just a guess, and maybe that was even meant to support throughput testing on remote storage devices? (think UNC \\server\mount_point type of stuff)

So to get this under control what I would like to do first is to correctly recognize a USB storage device as such and differentiate it from both the CDROM as well as regular HD.

So where does that device handle come from (which is then logically AND'ed in that MACRO)? Well, that comes from a call to DosOpen, or DosPhysicalDisk (in which case only the IOCTL_PHYSICALDISK (09h) can execute).

...in turn, this begs the question on my part: should either DosOpen or DosPhysicalDisk not have the ability to properly recognize a USB based storage device as being different than a regular HD, and therefore return a handle which leads me down the path of CATEGORY = IOCTL_DISK???

Seems like there is something missing in this logic and I can't quite put my finger on this.

Once I understand this I think I will be in a better postion to determine which approach is most suited to determine if a USB based storage device actually has mounted media in it, that could in fact be tested.

EDIT => spelling...yikes! *-(

5

Programming / Re: app high-mem capability, how to tell if it's there?

« on: January 01, 2025, 06:07:11 pm »

Hello Dave!

Happy 2025 to you...

Pretty easy. Marking a random DLL to load high, exehdr outputs,

Code: [Select]

...
Automatic data object:          2

 no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 00001320 00000001 00000002 EXECUTABLE, READABLE, 32-bit, HIMEM
0002 00020000 00000740 00000003 00000001 READABLE, WRITEABLE, 32-bit


OK, cool...I am using the 4.01.003 version here already, and indeed that points to the 'flag' that shows me the current state/mark, thank you, great to know this b/c I've been relying on 'highmem -v' up to now.

Alright...so how about the way the EXE/DLL were compiled??? I thought that in order to enable highmem one had to run a special flag during either the compile or link stages??? Would that not be present somewhere?

That is really what I'm after here...b/c having flipped that highmem flag ON/OFF a number of times, how the heck do I know what the DEFAULT setting was?

I suppose that perhaps this question in a sense dovetails into the following:

1) when should something be marked as 'code' highmem enabled
2) when should something be marked as 'data' highmem enabled
3) when should something be marked as 'both' highmem enabled

For now I am under the impression that anything using 16bit stuff must NOT be highmem enabled, for any of the above settings.

So a more specific example: looking at our Lucide PDF viewer, I see the following for lucide1.dll

1) 'code' marked as highmem

Code: [Select]

no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 0005d0f0 00000001 0000005e EXECUTABLE, READABLE, 32-bit, HIMEM
0002 00070000 0001b6f0 0000005f 00000016 READABLE, WRITEABLE, 32-bit
0003 00000000 0000c680 00000075 0000000d READABLE, SHARED, RESOURCE,
                                         DISCARDABLE, 32-bit

2) 'data marked as highmem

Code: [Select]

no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 0005d0f0 00000001 0000005e EXECUTABLE, READABLE, 32-bit
0002 00070000 0001b6f0 0000005f 00000016 READABLE, WRITEABLE, 32-bit, HIMEM
0003 00000000 0000c680 00000075 0000000d READABLE, SHARED, RESOURCE,
                                         DISCARDABLE, 32-bit

3) 'both' marked as highmem

Code: [Select]

no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 0005d0f0 00000001 0000005e EXECUTABLE, READABLE, 32-bit, HIMEM
0002 00070000 0001b6f0 0000005f 00000016 READABLE, WRITEABLE, 32-bit, HIMEM
0003 00000000 0000c680 00000075 0000000d READABLE, SHARED, RESOURCE,
                                         DISCARDABLE, 32-bit

So it is the different object #s that are impacted, this I can see, but just looking at the details and seeing "...32-bit...", is that sufficient enough for me to consider that highmem safe for any of those combinations?

I am using Lucide as an example b/c I've had a nagging issue with this thing freezing during PDF file opening...sort of a soft-lock...I can usually kill the process, but sometimes it's caused my WPS to shut-down...which is really weird. This typically happens when I'm opening a PDF on the NAS, and very rarely, if ever, when opening a local PDF.

Anyways, since the NAS path is complicated (NetDrive: the plugins, samba stuff, etc.) I am trying to work through that whole stream to confirm that all of it is correctly configured...yeah, kind of a needle in a haystack kind of a thing...LOL!

6

Programming / app high-mem capability, how to tell if it's there?

« on: December 31, 2024, 09:27:43 pm »

...basically, when looking at either an EXE or a DLL, how can I tell whether the application was written/compiled with highmem support?

I am aware of 'highmem', and stuff like 'exehdr', but even in the case of 'exehdr' I do not see how to interpret the results (i.e. is there anything in the output I am missing that already shows me that "yup, highmem capable" flag?).

Yes, I agree that leaving things "as-is" (meaning: the way the software was supplied) is a good recommendation, but if changes were made (we've all marked DLLs to load-high I'm sure) how the heck do I figure out what the intended DEFAULT mode is???

7

Applications / Re: PMInSANE :-P

« on: December 28, 2024, 06:38:17 pm »

Hello Roderick,

..Just a thought why do we not use:
https://www.os2world.com/wiki/index.php/Tame/2
I seem to recall its possible to add scanners to this project ?
Or have I overlooked something ?...

All the best to you in 2025 as well!

To me it's simply a matter of quickness/convenience: Tame/2 is configured and fully functioning here...it's just that too often I simply want to run a quick scan of a page w/o having to fire up the whole "machinery"...lol, so maybe I'm overblowing it a bit, but when all I want is a 600DPI B/W scan b/c I'm going to pipe that through PMView and off to PDFMergeNX...well, so much easier to do this once a REXX custom solution is configured, then to manually repeat the same process in individual applications.

Tame/2 is great for a number of things, such as taking advantage of the ADF feeder on my HP scanner for example, perhaps doing some post-processing for magazine article pages and so on (de-screen), but otherwise it's just 'too big' for about 95% of the stuff I need to do with a scanner.

Subsequently, whether it's Jan-Erik's PMinSANE, or Pete's HPScan, these are much smaller with a sub-set of features you'd find in something like Tame/2 and that's what makes for a quick START=>FINISH workflow.

8

Programming / Re: DISKIO - preferred TIMER to use

« on: December 27, 2024, 07:47:02 pm »

Hello Lars,

You can also use the TIMER$ driver with all its known ill effects (high IRQ load, for example). Question is if that timer will too much interfere with the measurement itself ( decrease I/O performance due to the high IRQ rate of the timer).

Most of this stuff is brand spankin' new to me (as far as actual hands-on code work), however I've done enough reading and doing a few pieces here and there to at least (I hope lol) understand the bigger playing field, point being: my conclusions below may not be spot-on, but I hope at least I'm moving in the right direction.

I looked at the TIMER$ option but concluded, for all the reasons you pointed out above, that this would not be a good option to pursue further given the timing precision needed.

There is an interesting approach highlighted in an EDM/2 article from a few years back: "http://www.edm2.com/index.php?title=High_Resolution_Timing_under_OS/2&oldid=78884" by Timur Tabi that covers this pretty well.

In fact, for me at least it answered (well, almost) the question of "could I pull in the timer information that modern day CPUs already contain, specifically the RDTSC stuff?".

Where I'm a little fuzzy on is whether this API - DevHelp_GetDOSVar, subfunction DHGETDOSV_SYSINFOSEG - can be used in non device driver code???

The example shown in that article is:

Code: [Select]

...
USHORT usrc;                    /* Return Code. */
USHORT TickCount;               /* Number of ticks per call */
void NEAR TimerHandler(void);   /* Callback function */
PGINFOSEG pGlobalInfoSeg;       /* Pointer to Global Info Seg */

usrc = DevHelp_GetDOSVar(DHGETDOSV_SYSINFOSEG, 0, &pGlobalInfoSeg);
...

...but the whole timer topic is waaaaayyyy above my head already! 

9

Programming / Re: DISKIO - preferred TIMER to use

« on: December 27, 2024, 07:19:37 pm »

Hi Dave!

While the Hi-Res timer is supposed to be fixed, as you noted, the fix is in ACPI, so depending on it would remove support for older versions of OS/2 including, IIRC, even early versions of ArcaOS that didn't have the fix.

Hmm, good point, I tend to be a little myopic in my vision of what works, that being the latest set of configurations as far as the main components are concerned.

So a quick look at the ACPI dev toolkit shows me at least two APIs I might be able to use:

1) AcpiTkGetVersion - "Returns the version numbers of various ACPI components including the toolkit API version", so this might be a viable way to look for that 'cut-off' where the hi-res TIMER go fixed?

2) AcpiTkValidateVersion - "This function is an easy and reliable way for all applications to determine if they are compatible with the installed ACPI", so in a sense knowing what that 'cut-off' ACPI level is (point #1 above) I might be able to use this API to make a quick check whether the target system is at sufficient ACPI level to use the hi-res TIMER

...Another thing is that once you fix diskio, it should be used to update sysbench, which uses diskio for the disk tests, and once again, nice if it works on older versions of OS/2

Absolutely, my goal is to overcome some of the current DISKIO hurdles, get it stable enough (i.e. working for a sufficient large pool of testers & configurations), and then pick this up to retrofit into SysBench.

10

Programming / DISKIO - preferred TIMER to use

« on: December 26, 2024, 11:24:45 pm »

DISKIO uses a TIMER in order to track the duration of various data xfer events.

More specifically, provisions were made in the old code to account for an incorrectly working high-resolution timer on SMP machines.

Subsequently right at the start of DISKIO a call is made to determine which TIMER should be used by examining the CPU core count, and if >1 than we force the use of "standard MS counter":

Original Code

Code: [Select]

// init flHiresTmr flag
// note: DosTmrQueryTime() API not works on OS/2 SMP as designed (thanks scott),
// so on SMP systems we must use other timer - standart MS counter.
void init_timer (void)
{
    int nCPUs = 0;

    if (DosQuerySysInfo (QSV_NUMPROCESSORS,
                         QSV_NUMPROCESSORS,
                         &nCPUs,
                         sizeof(nCPUs)) == NO_ERROR)
    {
        if (nCPUs > 1) flHiresTmr = 0;
    }
}

My udpated code

Code: [Select]

// init flHiresTmr flag
// note: DosTmrQueryTime() API does not work on OS/2 SMP as designed (thanks scott),
// so on SMP systems we must use other timer - standart MS counter.
void init_timer (void)
{
   //int iCPUs = 0; //moved this to a GLOBAL variable in diskio.h, v1.26

   if (DosQuerySysInfo (QSV_NUMPROCESSORS,    /* ordinal of first system variable */
                        QSV_NUMPROCESSORS, /* ordinal of the last system variable */
                        &iCPUs,              /* address of output data buffer */ 
                        sizeof(iCPUs))          /* size of output data buffer */
       == NO_ERROR)
   {
      if (iCPUs > 1)
         flHiresTmr = 1;
   }
         
   #ifdef DEBUG
      printf("\n DEBUG => CPU cores detected is: %d\n", iCPUs);
      printf(" DEBUG => flHiresTmr is: %d\n", flHiresTmr);
   #endif /* DEBUG */

} // end of init_timer

...where I basically ignore that original comment and force flHiresTmr = 1, which also means that throughout DISKIO's execution I will always use the hi-res TIMER, that being through DosTmrQueryTime API.

OK, so when I had initially encountered this I thought to myself: umm, I recall we had some troubles in the past with the hi-res stuff being spotty. Firefox had encountered some of this, heck we even made use of the 'SET NSPR_OS2_NO_HIRES_TIMER=1' flag. But digging into this further, by all accounts today that no longer appears to be the case. My FF install no longer uses this, I have several other apps that use the hi-res TIMER, and I believe some work was done in the ACPI codebase to manage this better, although some opinions remainder for a while as to whether these changes were working or not.

Needless to say, my testing here appears to be showing correct results as the results match what the original DISKO logic was showing.

Here is a more specific example of code (API comments have been added by me, as well as some variable name changes) that relies on previous determination of what TIMER should be used:

Code: [Select]

// use MS counter timer for SMP systems and HiRes Timer for any other
int start_timer (TIMER *tStart)
{
   if (flHiresTmr)
   {
      if (DosTmrQueryTime (tStart) != NO_ERROR)
      {
         printf("Timer error.\n");
         return (-1);
      }
   }
   else
   {
      tStart->ulHi = 0;
      if (DosQuerySysInfo (QSV_MS_COUNT,   /* ordinal of first system variable */
                           QSV_MS_COUNT,/* ordinal of the last system variable */
                           tStart,           /* address of output data buffer */
                           sizeof(tStart))      /* size of output data buffer */
          != NO_ERROR)
      {
         printf("Timer error.\n");
         return (-1);
      }
   }

   return (0);

} // end of start_timer

My question to you all is: should we be still concerned about this?

I feel like simplifying the codebase is a good pursuit and if the hi-res TIMER works (which I understand to be the more precise one given that at the standard frequency the PIT chip runs at (roughly) 1.193182 MHz, so that gives us a microsecond precision as opposed to the ms stuff that DosQuerySysInfo is capable of), we should use it.

11

Applications / Re: PMInSANE :-P

« on: December 26, 2024, 08:58:53 pm »

All versions that actually do something useful output pnm (see PPM in the image) only, so the safe route is to go with what is available and work from there.
I've used the parameter and the versions tested do output files, but when examined the internal file format written is still pnm.
The extension thus deviate from the actual data format it report, open a file with PMView by hand and see if it really is of the file format it pretend to be...

Hmm...that's all very strane to me seeing as the official SANE docs do clearly state that the output file format is completely user selectable given a few standard formats it provides. They all simply work here (as in: hands-on testing with multiple options as almost all of my TIFFs are converted to PDF pages and assembled into multi-page PDF documents), nothing else is needed.

Again, maybe 1.0.27 is different in that aspect, I cannot comment but I've attached a full 'Image Info' PMView screenshot of a CLI created TIFF file and that's no PNM image, that's a genuine TIFF. Heck, scanimage has the capability for you to even feed it a "ICC profile", so you bet it does it.

12

Applications / Re: PMInSANE :-P

« on: December 26, 2024, 08:48:58 pm »

Hello Jan-Erik!

Hmm...not sure what's happened but this verison won't fire up PMView anymore, can I do anyting to troubleshoot this further?

I did delete the App Key from OS2.INI thinking that maybe there was something there confusing it (verison change, etc....just guessing on my part), but that did nothing.

You were quite right.
Added and renumbered the controls, but missed a couple of places that caused it. See attached and updated package.

Yup...that works!!! Thank you...

When attempting to do a CROP the little pop-up measuring fields never pop up here, just a LMB down starts a BLUE line, keeping LMB down and dragging it over and releasing now converts that BLUE line into GREEN and creates a NEW BLUE line to close the CROP box I had created.

I've got to tell ya, that's very counter-inuitive for me, but that's just me being used to a dynamically dragged CROP box. I suspect this may have a lot do to with DrRexx stuff seeing as the CROP fields themselves are missing as well?

Click the button to show the values for crop... (see image with the bubble help).
RMB clear crop area selection btw.

OK, I got it now. So that's actually a 'toggle switch', because I see that selecting it once persists the field pop-up screen and it will continue to show as long as I do not disable it. OK, that works!

While I played with this I noticed a couple of things, although I suspect if you are not seeing this the root cause here must be either the DrRexx library, or the video drivers:

1) first time selecting the crop coordinates pop-up fields actually shows BLANK fields
2) disabling those fields from showing and re-enabling them rigth away now causes them to show, but the bottom right one is displayed missing the field layout...this gets corrected as you move to other sections and re-set the crop coordinates, see attachments that show this

Alright, so now that I understood how the crop selection works I did a bit more testing trying to understand why the actual crop selection does not match what I select on the screen.

The last attachment shows the result of the following PMinSANE 'scanimage' CLI:

Code: [Select]

Program (actual)    = "G:\USR\BIN\SCANIMAGE.EXE"
Program (specified) = "scanimage"
Parameters = " -p -d hp:libusb:003:001 -l 13 -t 211 -x 205 -y 47 --mode Color --resolution 300  "

I pulled this from Theseus, and so I interpret that to mean:

1) "-l" : top-left X position
2) "-t" : top-left Y position
3) "-x" : width
4) "-y" : height

which in turn translates to (as applicable to the scan page): 13 mm x 211 mm to 218 mm x 258 mm.

As a final sanity-check I took the 'problem' parms and fed scanimage from CLI, the outcome was the same as through PMinSANE, which means: problem is in the HP backend.

For what it's worth the following geometry description is returned by "scanimage -h":

Code: [Select]

Geometry:
  -l 0..215.788mm (in steps of 1.52588e-05) [0]
      Top-left x position of scan area.
  -t 0..296.888mm (in steps of 1.52588e-05) [0]
      Top-left y position of scan area.
  -x 0..215.788mm (in steps of 1.52588e-05) [215.788]
      Width of scan-area.
  -y 0..296.888mm (in steps of 1.52588e-05) [296.888]
      Height of scan-area.

So it looks like those parameters should be fine, alas that's just not the outcome I'm seeing.

13

Applications / Re: PMInSANE :-P

« on: December 26, 2024, 02:37:52 am »

...oh, one more thing:

...The backend here can't produce anything else but PNM (PPM) so the library convert the files to above file formats (and BMP that the viewer need)...

1.0.28 sane here and "--format tiff" creates the TIFF stuff, which is consistent with what I see on the SANE man page here => http://www.sane-project.org/man/scanimage.1.html:

Code: [Select]

--format=output-format
              selects how image data is written to standard output or the file
              specified by the --output-file  option.   output-format  can  be
              pnm,  tiff,  png, or jpeg.  If --format is not specified, PNM is
              written by default.

I suspect you have an opportunity here to just use the scanimage out-of-the-box functionality...can't speak for 1.0.27 though...maybe that's the difference you are seeing, as I am not familiar with prior versions???

14

Applications / Re: PMInSANE :-P

« on: December 26, 2024, 02:31:23 am »

Hello Jan-Erik,

Here's and updated version that create output as TIFF, PNG and JPEG, specify "-FMT TIFF", "-FMT PNG" or -FMT JPEG" as parameter to set the output format.
The backend here can't produce anything else but PNM (PPM) so the library convert the files to above file formats (and BMP that the viewer need).

Hmm...not sure what's happened but this verison won't fire up PMView anymore, can I do anyting to troubleshoot this further?

I did delete the App Key from OS2.INI thinking that maybe there was something there confusing it (verison change, etc....just guessing on my part), but that did nothing.

Hi Jan-Erik

The "Crop" problem Dariusz reports could be the result of the differences between an OS/2 screen and every other pc os screen - OS2/2 starts at Bottom Left as 0,0 whereas Windows, linux etc start at TOP Left as 0,0.

Pete

Here crop produce the output I expect, x to the side and y pixels down, but at times sane or the backend fail to recognize the width.
Can't do much unless sane handle the parameters.

When attempting to do a CROP the little pop-up measuring fields never pop up here, just a LMB down starts a BLUE line, keeping LMB down and dragging it over and releasing now converts that BLUE line into GREEN and creates a NEW BLUE line to close the CROP box I had created.

I've got to tell ya, that's very counter-inuitive for me, but that's just me being used to a dynamically dragged CROP box. I suspect this may have a lot do to with DrRexx stuff seeing as the CROP fields themselves are missing as well?

Also, tried the Program Ojbect parameter passing, nothing, and absolutely nothing I did worked.

15

Hardware / Re: Epson L4150 Scanner - USB

« on: December 26, 2024, 01:14:36 am »

Martin,

...I tried removing the rest from dll.conf and with the SET_SANE_WORKAROUND, but I didn't get any results yet...

Hmm...sorry to hear that, and this is about as far as I can take SANE troubleshooting (limit of my capabilities)...looks to me like the scanner end-point simply isn't responding to the epsonds backends' calls:

Code: [Select]

[epsonds]  opened correctly
[epsonds] eds_lock
[epsonds] eds_control: size = 2
[epsonds] eds_send: size = 2
[epsonds] eds_send: FS X
[sanei_usb] sanei_usb_write_bulk: trying to write 2 bytes
[sanei_usb] 000 1C 58                                           .X             
[sanei_usb] sanei_usb_write_bulk: wanted 2 bytes, wrote 2 bytes
[epsonds] eds_recv: size = 1, buf = 0x12f90f
[sanei_usb] sanei_usb_read_bulk: trying to read 1 bytes
[sanei_usb] sanei_usb_read_bulk: read failed (still got 0 bytes): Operation timed out
[epsonds] eds_recv: expected = 1, got = 0, canceling: 0
[epsonds] eds_txrx: rx err, Error during device I/O
[epsonds] eds_control: failed, Error during device I/O
[epsonds]  failed
[epsonds] close_scanner: fd = 0