search

aidyw / bosto-2g-linux-kernel-module

GNU General Public License v3.0
7 stars 4 forks source link

Reported max x and y #10

Open stacksmith opened 7 years ago

stacksmith commented 7 years ago

@aidyw, not to beat a dead horse, but I noticed that Monoprice promo materials list the touch tablet resolution at 5080 per inch. I don't know what bosto claims, but I think they are the same...

I think the best way to go about this is to set the max pretty high, like 5080 * 18 (or whatever size in ") for x. Then, using the matrix in xinput, you can fine-tune the values.

Otherwise, you are just dropping data from the tablet (assuming there was that much resolution to start with).

This is not a nag, and you don't have to do anything about it. I just wanted to share.

BTW, I think the development branch may have fixed a bug. With master pressing the eraser down crapped the tablet. Your new branch seems to have solved it somehow.

aidyw commented 7 years ago

Thanks, well I have for some unknown reason decided to push a little harder with the driver, so I have been reading at lot and trying to normalize that output from the driver into the event subsystem. Yesterday I got the resolution set for ABS_X and ABS_Y. This may resolve your issues. Yet still I have not pushed it to the repo as I am awaiting some feedback from Peter Hutterer, the guy who maintains the xinput code base, regarding what is normal. So be patient I will do what I can but we might have a solution. Regarding the output from the hardware. It is a simple bitstream, I never recieve a value any higher than what is coded in the driver. As I explained, if you debug the output from the driver with your tablet, (look at 'bosto_packet') you will see the final word, this is the raw irq stream coming from the usb device. The X & Y are clear. Do the hex conversion and you will have your answer. Best

stacksmith commented 7 years ago

I commend you for the effort, but I am more confused than ever...

stacksmith commented 7 years ago

Actually, there is a <<2 in the derivation of x and y values that completely fucks everything up, as x is a 16-bit quantity and overflows many times. P.S. Removing the shift and setting DBE8 as limit once again works on my system. P.P.S. What's the deal with the low bit of pressure? Is there a hardware dither bit? It seems odd, as there are 11 real bits already - why kill the low bit?

stacksmith commented 7 years ago

Pressure is problematic on my system. Empirically,

if((data[1] & 0xF0) == 0xE0){
                    input_report_key(input_dev, BTN_TOUCH, 1); dev_dbg(&dev->dev, "Bosto TOOL: TOUCH");
                    p =  (data[6] << 3) | (data[7] >> 5) & 0x06) | (data[1] & 0x1);     // Set 2048 Level pressure sensitivity. 
                    p = le16_to_cpup((__le16 *)&p);
                } else ...
ghost commented 7 years ago

I'm currently using the fork that changes max_x and max_y for the Monoprice 22 but the issues I'm having right now are the eraser bug (I see in this issue it has apparently been fixed on the dev branch) and no pressure sensitivity.

I tried to look into debugging it today to figure out why I don't have pressure sensitivity but I don't have the /var/log/kern.log file and using the dynamic_debug/control for PEN_IN didn't seem to report anything for me in my system logs (checked with journalctl and dmesg, maybe I'm looking in the wrong place?)

I'm excited to see you guys are actively working on this! Should I switch back to @aidyw's and use the development branch for now? I'd be happy to help in any way I can but you two seem to be more experienced than I :)

stacksmith commented 7 years ago

@miotatsu - develpment branch is broken right now... I created a repo for now that works with my monoprice 22 here: https://github.com/stacksmith/Monoprice_22_linux_kernel_module

Hopefully we can figure out the issues and merge soon, but at least you have something to work with.