ddca_get_any_vcp_value_using_implicit_type() incorrect order of arguments passed to ddca_get_any_vcp_value_using_explicit_type()

[digitaltrails]

I've been trying to learn a bit about DBUS. I've written a small dbus server that calls libddcutil. I have implemented a detect and was trying to implement GetVcp:

I wasn't having much success with GetVcp until I traced what was happening in libddcutil.

In src/libmain/api_feature_access.c, feature_code and call_type have been swapped.

DDCA_Status
ddca_get_any_vcp_value_using_implicit_type(
       DDCA_Display_Handle         ddca_dh,
       DDCA_Vcp_Feature_Code       feature_code,
       DDCA_Any_Vcp_Value **       valrec_loc)
{
   bool debug = false;
   API_PROLOG(debug, "feature_code = 0x%02x", feature_code);
   assert(valrec_loc);
   free_thread_error_detail();

   DDCA_Vcp_Value_Type call_type;
   DDCA_Status ddcrc = get_value_type(ddca_dh, feature_code, &call_type);
   if (ddcrc == 0) {
      ddcrc = ddca_get_any_vcp_value_using_explicit_type(
                 ddca_dh,
                 call_type,     // <<<-----  Swapped order 
                 feature_code,  // <<<----- 
                 valrec_loc);
   }
   assert( (ddcrc==0 && *valrec_loc) || (ddcrc!=0 && !*valrec_loc) );
   API_EPILOG_WO_RETURN(debug, ddcrc, "");
   return ddcrc;
}

[rockowitz]

@digitaltrails I apologize for having caused you to spend time diagnosing this trivial bug. As you can see, this function was never really tested.

As a practical matter, you can ignore Table type features and use only the simpler ddca_get_non_table_vcp_value() and ddca_set_non_table_vcp_value(). Support for Table type features was implemented based on the DDC/CI spec, before I grasped that there few (as in I've never seen one) monitors that implement the Table type features defined in MCCS 3.0. Monitor makers instead moved on to MCCS 2.2, which provides some of the facilities of 3.0, but in a way that doesn't require Table type.

[digitaltrails]

@digitaltrails I apologize for having caused you to spend time diagnosing this trivial bug. As you can see, this function was never really tested.

As a practical matter, you can ignore Table type features and use only the simpler ddca_get_non_table_vcp_value() and ddca_set_non_table_vcp_value(). Support for Table type features was implemented based on the DDC/CI spec, before I grasped that there few (as in I've never seen one) monitors that implement the Table type features defined in MCCS 3.0. Monitor makers instead moved on to MCCS 2.2, which provides some of the facilities of 3.0, but in a way that doesn't require Table type.

It was a good learning exercise concerning libddcutil. It was heaps easier than trying to figure out the GDBUS library. My C is a bit rusty (I did more than a decade of C coding, but that was mostly prior to 2000). I think I'm on the right track now with both libraries (except for memory allocation in GDBUS). I've got detect/get/set working and can test via D-Feet.

I was wondering about the table features. I'd actually coded get/set with them included, but then I couldn't find an example of a table.

I've no idea where I'm going with this experiment. If you'd like some example C for wrapping DBUS around libddcutil, that could be one possible use. I may continue to the point where I can use dbus from python and experiment with that in vdu_controls, but that might be quite a bit of work.

[rockowitz]

Hi Michael,

I'm very interested in what you're doing. Making libddcutil a service is, I think, a natural next step. Required for that is for libddcutil to handle display connection/disconnection, sleep, etc. At the last minute I pulled the API functions in this regard from release 2.0, largely based on the problems you identified. It's much simpler to add new functions in the future than handle deprecation, etc. I look forward to seeing what you've done, and if you decide to take the server beyond the proof of concept state, I would welcome either contributions to ddcutil or a standalone git project of your own.

As for C, I thought I'd long since left the language behind. But it is the correct language for building a program like ddcutil that has to interact with the operating system so closely. Coming from Java and Scala, it's painfully low level. I too last did serious work in C in the mid-90's. Perhaps the most interesting thing I did was build inter-language interoperability between C and Pascal in a mainframe environment, in order to interact with a server written in Pascal. (Ok, that really dates me.)

I'm also a fan of Python. It's my goto language when there's not a compelling reason to use another. In fact, Guido van Rossum spoke at a Silicon Valley lecture series I chaired in the early 2000's.

[digitaltrails]

I reverted to using the non_table_vcp_value methods, I had originally used them, and they do make for easier coding. I've got methods for detect, get, set, capabilities, and featureMetadata methods working. Plus I implemented some properties, such as SleepMultiplier and Version.

So far the whole thing is very small. The code is one C file and a makefile. I'll email you a tar before I go any further. It's easy to play with the server via the d-feet utility, just search for a SessionBus server with ddcutil in its name. Once we can see how big/complex it gets, we can decide what to do with it (it's so small now, that it would be easy to just fold it into ddcutil as an example).

Next I will examine creating a DBUS structure based on what's returned by ddca_parse_capabilities_string(). That looks to be a reasonable chunk of work and I'm not sure when I will get around to it.

There was quite a lot of porting to UNIX in the 80's/90's. That often involved a change of language. In one instance I got a contract porting a mainframe PL/1 simulation to C (mainly to improve the elapsed time). I used C/yacc/lex to write a PL/1 to C translator to do a lot of the work, it still took a few years though. I quickly transitioned through C++ to Java around the end of the century.

I hardly managed to do any Python coding for work. Around 98 I did write a couple of Linux Journal articles about Python in an attempt to help boost it's profile. So, yeah, I was also an early fan of the language.

[rockowitz]

I look forward to seeing what you've created and playing with it.

I'll leave the personal history to email. But I will mention one experience that solidified my appreciation of Python. During the Dot Com boom, I did consulting work for an online pharmacy. They were using Oracle, and if you've ever worked with it you know that its command line scripting is hideous. But there's a JDBC interface to Oracle, and this was a Java shop. So I created a Jython package that imported the JDBC interface. Voila, a high powered "scripting" interface to Oracle that took about a day to create.