Reply to thread

Message: <blockquote data-quote="cybrmage" data-source="post: 220676" data-attributes="member: 51680">Umm... yeah... actually... never mind 8-}It's hard to ignore when all the logs show that there is a 0x7E after each button press... But I think I've figured out a way around it, and it should also solve the problem you are seeing.... see the latest driver post...The com port logs did not.With that particular driver, yes, they prefix the command with 0x00... But the com logs clearly show that the 0x00 sent before the 0xAF is part of the previous serial write operation. I tend to trust confirmed information (the logs you provided) over unconfirmed information (the linux driver source code)... plus, the temperature reports were working up until the standby issue was resolved...and frustrating!!That is correct... The event handler get executed every time new data arrives on the serial port... That issue has been resolved with a mutex that prevents the second (or third, or fourth, etc) instance from processing data until the first has finished. Once the first has finished, the second will then process any data that has been received after the first event was fired... Ironically, we serialize the serial port 8-}Here is what I think right now - this display driver originally wasn't thought to handle remote codes or any input. It's a plain output driver. Connecting to the VFD when needed, writing contrents to it, then going asleep. If it is like that, then we are just raping the concept a little bit <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin    :D" loading="lazy" data-shortname=":D" /> So now I come up with a completely different idea:Then this driver would be redundant, as MediaPort already has a driver for an IRTrans compatible remote, and the ExternalDisplay plugin has a driver for an IRTrans compatble display.Mushrooms destined for the consumer market (IE: not wild mushrooms) are grown in large, dark underground caverns and fertilized with manure... The are literally "kept in the dark and fed SH**" 8-}Unfortunately, as you mentioned, the autorun entries can be deleted, so they are not a reliable way to get the executable path.That issue has been resolved... You can get the executable path with the System.Diagnostic.Process namespace and the Process.MainModule.Filename proprty. That way, we don't need to search the registry...What??? You want up to date information??? You want to make life easier???  8-}I don't think so either... From the information I found, i suspected that this was the case (but it wasn't explicitly mentioned)... So I decided to leave it the way it is...I actually think that the fan controller is just a fan voltage controller rather than a fan speed controller... (one of the people on another forum mentioned that two different brands of fan ran at different speeds with the same settings)... This means that the 0x00 value will shut the fan off completely (0V), and a value of 0xFF will turn it on at full speed (12V)... but a value of 0x20 (1.5V - 12.5% of full scale) will probably not turn on any fan (except for a very high efficiency low voltage unit). This makes it hard to find a starting point to use as a benchmark for when the fan is actually turned on... The Linux driver uses a base of 0x6E (5.1V - 42% of full scale) as an "on" point.just 0xAF...Regards,CybrMage</blockquote>

Verification