15 replies to this topic

[terrywen]

Hi guys,
I am building a Win7 Pe image for AIO product. But I am running into the problem of locating a touch screen driver to add to Win7 Pe. The manufacturer never provided a touch screen driver and the touchscreen are automatically set up at the end of standard Windows 7 installation.
My question is, how can I locate this driver so that I can add to the Win7 PE?
Has anyone done something similar before? I am not looking to do anything fancy with the touch screen driver. As long as it allows touch to act like mouse point, that will do it.

Thanks.

[Brito]

Hello,

Have you tried adding up the latest Graphics driver packs onto your build?

They have a Graphics pack called "mobile" that might provide the functionality that you are looking for.

Look at http://driverpacks.n...verpacks/latest

[MedEvil]

Nuno, the question is a bout a default Win7 driver, which is not included in PE. Driverpacks will not include generic MS drivers.

@terrywen
- open in Win7 the devicemanager
- navigate to the device in question
- double click on it
- selct the driver tab on the opening dialog
- click on driver details
- write down all files named there

Check which of the named files do not exist in your PE.
Go look for the missing files in driverstore and always copy the whole driver folder, not just the missing file.

[cdob]

@terrywen
And goto Details section at device manager.
Write Hardware Ids, Compatible Ids, Inf name, Inf section and Matching device Id.

And it's a good idea to name the hardware model including manufacturer if a question relating drivers arise.
If you are lucky, another member use the same hardware and can compare locally.

[wimb]

In Win7 go to WindowsSystem32DriverStoreFileRepository and use Sort date
so that latest added driver folders (your touchscreen driver) is mentioned above in the list.

Copy that driver folder to your building environment and rebuild your 7PE
e.g. drop it in Make_PE3PE3_modWIN7_driversx86

Another approach:
After booting with 7 PE made with Make_PE3 then you can use Drivers from Win7 Host DS icon on Desktop
to add drivers from Win7 host DriverStoreFileRepository

[terrywen]

Nuno/MedEvil/cdob/wimb,
Give you my best regards and thank everyone who take a look at the post.

I have checked the devicemanager in Win7, the driver list below
mshidkmdf.sys
NWVoltron.sys
NWTransLibV.sys
NWWakeFilterV.sys
I download a driver Next Window Voltron from website. Need to clarify that "Next Window Voltron" is the standard driver for the machine, because if return to the Win7 OS platform, the touch screen work perfectly. After Installing the driver "Next Window Voltron" in Win7PE, It doesn't work yet.

Then I checked the inf file from "Next Window Voltron" driver package, and found some info below

;
; Voltron is the function driver BUT
; inbox mshidkmdf shim is the upper filter
;
[NWVoltron.Inst.Win7.NT.HW]
AddReg = NWVoltron_Parameters.Win7.AddReg

[NWVoltron_Parameters.Win7.AddReg]
HKR,,"UpperFilters",0x00010000,"mshidkmdf"

Driver mshidkmdf.sys must be needed, but I couldn't find it anywhere in win7pe. but the same driver can be found in windowssystem32drivers under win7 platform..

So seems that the driver mshidkmdf.sys is the key point.

Considering the driver mshidkmdf.sys is inbox driver, I don't know how to extract it and how to install it to win7pe.

Could somebody help me?

[terrywen]

In addition, there is no any inf file provided to us to install mshidkmdf.sys, so I have no method to install it.

[patsch]

then perhaps just copy the driver to your pe using the additionalfiles script under components. And then you have to add the registry info to your pe

btw one thread is enough, your problem will not be solved faster with more than one thread (http://reboot.pro/16702/#entry152452)

[MedEvil]

The fact that you have now found yet another component missing, the Tablet PC Input Service, suggests that you will need someone, who has a touchscreen device to help you.

If you wanna try nonetheless, try it like this:
- start in Windows 7 regedit
- search in HKLM\System\CurrentControlSet\Services\ for a key named mshidkmdf and export it
- if there is no such key, search for one which contains mshidkmdf.sys and export it
- open the exported .reg file in notepad and change all occurences of CurrentControlSet to WB-Systen\ControlSet001
- save the file
- start WinBuilder and go to Utils\Mount change Mountpoint to %BaseDir%\Mount\%ProjectName%\Target\%TargetDir%
- go to Image Configuration script and check the Install.wim and Boot.wim numbers
- return to the mount script and make sure the same numbers are selected for the wims
- mount both source and target
- open Explorer and go to %BaseDir%\Mount\Win7PE_SE\Source and search for mshidkmdf.sys
- copy it to %BaseDir%\Mount\%ProjectName%\Target\%TargetDir%\Windows\System32\drivers
- open Regedit again and mount under HKLM, %BaseDir%\Mount\%ProjectName%\Target\%TargetDir%\Windows\system32\config\system
with the name WB-System
- import the reg file you've created earlier
- unmount WB-System
- go to the mountscript and click 'unmount all'
- go to Finals\Create ISo script and click 'Create new ISO file'
- test if it works, if so, we can turn it into a script for easier use next time

[terrywen]

patsch,
Thanks for you reminder.

@MedEvil,
It's very kind of you . Follow your instruction, the mshidkmdf.sys Driver is ok now, and I can find the Driver in devicemanager. For a new comer just like me , how brilliant the news is. So I have to give you my regards again.

Now the new problem is how to install "Tablet PC Input Service". I have got a box with touchscreen and the touch screen works find in Win7. Howerer, there are so many files related to "Tablet PC Input Service" in Win7, I have no method to add the service manually. Is there any good method to fix it?

Edited by terrywen, 14 April 2012 - 02:31 PM.

[MedEvil]

Like i said before services are tricky. They have dependencies not just on other files, but also other services and other registry entries.

In general, you would need to get the names of all services the "Tablet PC Input Service" depends on.
Then go to the registry to HKLM\System\CurrentControlSet\Services\ again and export the entries for "Tablet PC Input Service" and all the services it depends on and then prepare the exported .reg files like you did for the driver.

Then you would need to gather all the files that are mantioned in those registry entries.
Now you need a tool to check the dependencies for all those files. (If your installed Win7 is of the same kind 32bit/64bit as the PE, you wanna create. You can use dependency walker for that.)

btw. You can save some work, if you have a search-program handy and let it search first in your PE, for a file that's named as a dependency and only add it manually, if it doesn't exist yet.

Once you have gathered all needed registry entries and files, include them into your PE like with the driver and hope for the best.

If it doesn't work, check first in PE, if the "Tablet PC Input Service" is running.
If not, try to start it again. If it does not start, but also does not complain about something not working, chances are, this service is prohibited by M$ to work in PE.

[crostron76]

Hi All,

 

I am investigating using WinPE for a build environment on some OEM equipment that won't have a keyboard attached.  Did anyone ever get the bottom of the "Tablet PC Input Service" riddle?  Is it possible to get this service up and running in a PE environment or have M$ restricted it?

 

Any info would be greatly appreciated. 

 

Regards,

Chris.

 

[Wonko the Sane]

@crostron76

 

Not to put you tooo down , but there is an issue here.

SURELY it is possible to add the "Tablet PC Input Service" to a Win7PE (NO doubts whatever about that).

 

The issue is the following:

1. anyone familiar enough with 7PE builds has NOT a device making use of "Tablet PC Input Service"
2. anyone having a device making use of  "Tablet PC Input Service" is NOT familiar enough with 7PE builds
3. if by any chance a professional has BOTH familiarity with 7PE building AND has such a device (and managed to get the thingy working), he/she won't tell you (at a probability level of 99.99%

In other words, it is highly UNlikely that such info is already available .

 

BUT, if you are "game" and you will accept to be "remote controlled" in experiments by people familiar with the PE's (and more generically windows device driver innards) like cdob or Medevil (just to name a couple that took part to this thread earlier) I am pretty sure that a solution can be found .

 

Wonko

[crostron76]

Hi Wonko,

 

Thanks for taking the time to reply to me and present the issue as you see it.  Your reasoning as to why a solution has not been presented to the group is quite sound. 

 

I would be game to be remote controlled (time permitting) but as I'm in Australia it's very unlikely I'd get a decent period of overlap with you all.  Also my development environment does not currently have the touch screen connected. 

 

At this stage I am weighing up my options, the answer you gave my was pretty much the answer I was expecting. I most likely will go down the fully automated path which does not require user input or perhaps even use a Windows embedded environment to achive the same.

Anyway, if I make any progress on the Tablet PC Input Service I'll be sure to let the community know what I learn and share my lessons.

 

Chris.

[Wonko the Sane]

Well, the time lag isn't an issue, it won't be "real-time" remote control, and it may take some more time, but we managed to solve problems on different timezones OK in the past.

The show stopper is the availability of the actual device.

 

It is well possible that something like DiPE:

http://reboot.pro/to...oot-not-before/

can automatically import the drivers, but no device=no tests possible.

 

Wonko

[crostron76]

Yep I've been using DiPE for a couple of years now, a fantastic utility that has helped me to no end!!

 

I've been thinking about how we could set something up, but as you said until I get hold of the touch screen hardware there's not much more we can do.

 

Watch this space, I'll be getting my hands on some hardware soon ... once I do we can work out what we might need in a lab environment to allow the group some remote control to "play".