The controller is identified as a TPV OpticalTouchScreen.
The Vendor and Product IDs are: 25aa:8882.
Edit - I corrected the title from "Recognize" to "work with", since I believe the driver attempted to work, the driver/hardware needs a specific tweak to prevent going into a uncommunicative state.
Benjamin showed me how to apply the same quirk flag as is applied to the TPV model 8883. And now it works as expected for single touches (I don't use and therefore have not tested multi-touch)
I believe Benjamin will apply the fix into the source code, so eventually this will work automatically. But to get up and running now, do the following:
Append "usbhid.quirks=0x25aa:0x8882:0x8" into your kernel boot string. Most people will need to do this in their boot loader (GRUB or similar). Raspbian users like myself will need to append it in /boot/cmdline.txt
I applied this fix to my Syslinux Append line, digitizer now works. Two finger scroll works in Chromium as well. Arch Linux 4.1.5-1-ARCH
Related
I created a simple RME for TTeeGrid, a descendant perhaps of TGrid in Firemonkey. As shown below, the data are displayed at design time but not at runtime except the headers.
I've been breaking my head over this for weeks already but not luck.
Let me know if you need more details but what you see in the image are all you get.
I just need help to have the data displayed at runtime as shown in the design time.
UPDATE 1
This issue is not the case with TPrototypeBindSource. The data shown in the design time are displayed at runtime. Something is wrong somewhere.
I've never used the TeeGrid before, but the following worked fine
first time for me in Delphi Tokyo:
Download the TeeGrid trial from Steema.Com & install.
Create new multi-device app and place a TeeGrid and a FDMemTable on the form.
Load FDMemTable1 with the file Parts.Fds from the Delphi samples Data directory. Note, I did not then create any FieldDefs as I mentioned in my comment earlier as what I'm describing works without them.
Set the DataSource property of TeeGrid1 to FDMemTable1. TeeGrid1 immediately
creates columns for each of the Parts fields and populates them with data - see
screenshot below. I don't ordinarily include screenshots but in this case thought
I would as what I got was so clearly at odds with what you've reported.
Your TeeGrid etc are obviously more complicated than mine. so the best I can
suggest is that you backtrack to step 2 and see if you can replicate my result
with your data (either at design time or run time). It might be worth loading
your FDMemTable with some data at design time, as my impression is that live bindings
is less grief-prone when the datasource has some data.
Incidentally, fwiw the results of my own attempts to set up live bindings even with a regular TGrid have been rather patchy, until I discovered that instead of messing with the LB components myself, simply starting with a fresh TGrid, right-clicking on it and leaving the Live Bindings Wizard
to do its stuff consistently works fine.
I've struggling a lot with this problem since last week: I am using R presentation (.Rpres file) for the first time and it started alright, meaning that I could build a slide and visualize the result in the Presentation tab in RStudio. However, for reasons I don't understand, after a few hours of working on my presentations the Presentation tab began to show weird symbols for all the french characters in my presentation. The only way so far I could get the presentation back to showing the right characters was by playing with the "Save with encoding..." and "Reopen with encoding..." options in Rstudio.
The problem is that although this has made the french characters in the presentation look good, it is now the text in the source file (.RPres) that looks all weird (e.g. "température" instead of "température").
Here is some more details on my setup, if this can help:
> sessionInfo()
R version 3.2.3 (2015-12-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
locale:
[1] LC_COLLATE=French_Canada.1252 LC_CTYPE=French_Canada.1252 LC_MONETARY=French_Canada.1252
[4] LC_NUMERIC=C LC_TIME=French_Canada.1252
attached base packages:
[1] graphics grDevices datasets stats utils methods base
other attached packages:
[1] readxl_0.1.1 sp_1.2-2 foreign_0.8-66 data.table_1.9.6 dplyr_0.4.3 bit64_0.9-5
[7] bit_1.1-12 RPostgres_0.1 DBI_0.3.1.9008 Rcpp_0.12.3.2
loaded via a namespace (and not attached):
[1] lattice_0.20-33 assertthat_0.1 chron_2.3-47 grid_3.2.3 R6_2.1.2 magrittr_1.5
[7] tools_3.2.3 parallel_3.2.3
I really hope someone will find a solution to this as I like this tool and would like to keep using i in the future. I was thinking of trying the revealjs package as an alternative to fix my problem but I haven't (not sure I won't have the same problem).
Thanks for your help.
This problem might be related to the locale specified for your computer, as explained here: https://superuser.com/questions/655273/r-locale-setting-problems-on-mac-os-x
If the result of system("locale") contains a lot of values "C", then you should try the command
system("defaults write org.R-project.R force.LANG en_US.UTF-8")
After this, you should restart R and use system("locale") to check that the locale has been updated, and hopefully you should now be able to get the correct characters the next time you compile your document.
Note: I know that this strategy has solved a similar problem for users on Linux and OS X, but I don't know if it also works if your OS is Windows.
I'm seeing some very strange behavior with FileMaker 14. I'm using LayoutObjectNames for some required functionality. On the development system it's working fine. It returns the list of named objects on the layout.
I close the file, zip it up and send it to the client, and that required functionality isn't working. He sends the file back and I open it and get a data viewer up. The function returns nothing. I go into layout mode and confirm that there are named objects on the layout.
The first time this happened and I tried recovering the file. In the recovered file it worked, so I assumed some corruption had happened on his end. I told him to trash the file I had given him and work with a new version I supplied. The problem came up again.
This morning he sent me the oldest version that the problem manifested in. I confirmed the problem, tried recovering it again, but this time it didn't fix the problem.
I'm at a loss. It works in the version I send him, doesn't on his system. We're both using FileMaker 14, although I'm using Advanced. My next step will be to work from a served file instead of a local one, but I have never seen this type of behavior in FileMaker. Has anyone seen anything similar? Any ideas on a fix? I'm almost ready to just scrap the file and build it again from scratch since we're not too far into the project.
Thanks, Chuck
There is a known issue with the Get (FileName) function when the file name contains dots (other that the one before the extension). I will amend my answer later with more details and a possible solution (I have to look it up).
Here's a quote from 2008:
This is a known issue. It affects not only the ValueListItems()
function, but any function that requires the file name. The solution
is to include the file extension explicitly in the file name. This
works even if you use Get (FileName) to return the file name
dynamically:
ValueListItems ( Get ( FileName ) & ".fp7" ; "MyValueList" )
Of course, this is not required if you take care not to use period
when naming your files.
http://fmforums.com/forums/topic/60368-fm-bug-with-valuelistitems-function/?do=findComment&comment=285448
Apparently the issue is still with us - I wonder if the solution is still the same (I cannot test this at the moment).
I am working on Solaris 12 and I am trying to get device path like this:
/pci#0,0/pci108e,4856#1f,2:devctl
I could obtain the this path through CLI using prtconf -v. How could I obtain the path through api using C function? I tried serveral functions in libdevinfo, such as di_devfs_path, but it didn't give the same path as the prtconf gives me. Should I use functions like di_node_name, di_instance, di_binding_name to get pieces of information and construct the path by my own. Or there is a function to get the whole device path?
Thanks.
Firstly, unless you're working for Oracle in the Systems division, you're not working on Solaris 12. (If you are working for Oracle, why haven't you asked
Oracle internal mailing lists for help?)
Secondly, the :devctl node is a minor for the device, so you'll need to walk the minor nodes using di_walk_minor() and check di_minor_name() to see if it matches your criteria.
Finally, yes, this should work on Solaris 10 and later.
So we're trying to set up replicated repositories using PlasticSCM, one in the US, and one in Australia and running into a bit of a snag.
The US configuration is Active Directory, the AU configuration is User/Password. This in itself is not a big deal, I've already set up the SID translation table.
The problem is with plasticscm's replicate command itself. This is the command which should replicate from the US to AU, run ON the AU server.
cm replicate br:/main#rep:default#repserver:US:8084 rep:myrep#repserver:AU:9090 --trmode=name --trtable=trans.txt --authdata=ActiveDirectory:192.168.1.3:389:john.doe#factory.com:fPBea2rPsQaagEW3pKNveA==:dc=factory,dc=com
The part I'm stuck at is the authdata part (the above is an EXAMPLE only). How can I generate the obscured password? I think it's the only thing preventing these two repositories from talking to each other.
Ok, I've solved my own problem.
To get that "authdata" string, you need to configure your client to how you need to authenticate.
Then navigate to c:[users directory][username]\Local Settings\Application Data\plastic.
Pick up the client.conf and extract the string from the SecurityConfig element in the XML.
Check the new GUI here. It's a little bit easier.