Active Topics
-
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 2 hrs, 39 mins ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 23 hrs, 27 mins ago - more...
|
2012-09-14
, 06:48
|
|
Community Council |
Posts: 4,920 |
Thanked: 12,867 times |
Joined on May 2012
@ Southerrn Finland
|
#22
|
Not se straightforward as I first thought...
Even as the sources for meegofeedbackd and reactionmaps are available, the backend part which uploads the sample to the device via ioctl is closed source. Bummer.
But, I do have the samples, as I fished them off the kernel, so I do have several options how to proceed;
What would be the best/easiest way to proceed...?
In the last two options I would propably need to recreate vibra_spi as a new module and make sure it is unloaded after use as not to conflict with the original module when it is loaded and initialized in later boot phase.
Or, I could stub out the initialization function in the module so that later init does not cause anything, and just replace the original module...
Thoughts?
Even as the sources for meegofeedbackd and reactionmaps are available, the backend part which uploads the sample to the device via ioctl is closed source. Bummer.
But, I do have the samples, as I fished them off the kernel, so I do have several options how to proceed;
- I could try to fish out what&how the ioctl is used to upload. This is not directly seen in spi_vibra but it goes through the upper SPI layer which makes it a bit obscured.
- I could make my own /proc/ interface to vibra_spi to load the samples. I like proc stuff better than ioctls anyway in my modules as it is way simpler to tweak from userland
- I could hard-code the samples in the driver, there is actually no need to upload that stuff as it never changes
What would be the best/easiest way to proceed...?
In the last two options I would propably need to recreate vibra_spi as a new module and make sure it is unloaded after use as not to conflict with the original module when it is loaded and initialized in later boot phase.
Or, I could stub out the initialization function in the module so that later init does not cause anything, and just replace the original module...
Thoughts?
| The Following User Says Thank You to juiceme For This Useful Post: | ||
 |
|
2012-09-20
, 07:00
|
|
Posts: 6,436 |
Thanked: 12,699 times |
Joined on Nov 2011
@ Ängelholm, Sweden
|
#23
|
i think better to produce hardcoded spi and just use it
|
|
2012-09-20
, 15:33
|
|
Community Council |
Posts: 4,920 |
Thanked: 12,867 times |
Joined on May 2012
@ Southerrn Finland
|
#24
|
I have now studied the spi_vibra driver initialization a bit. It seems that the sample upload is done via the following kind of ioctl call.
This bit uploads 612 bytes of sample data to one effect. (Actually I think it is 306 words but that is identical...)
There are 32 effects that need to be uploaded in total.
The sample bytestring is stored in initstring[][] table in this example.
The full code and bytestrings can be gotten from my svn server, same place as before.
However, even as this ioctl produces exactly same results in the driver as the closed-source initialization, I stll cannot make the device vibrate. There is some element I am missing here in the process.
Actually it just occured to me, how is the initialization done in nitdroid? The vibra device works there. Is the initialization sequence there on an open source component?
This bit uploads 612 bytes of sample data to one effect. (Actually I think it is 306 words but that is identical...)
There are 32 effects that need to be uploaded in total.
Code:
int initialize_samples(int fp, int effect)
{
struct ff_effect new;
new.type = FF_PERIODIC;
new.id = -1;
new.direction = 0;
new.u.periodic.waveform = FF_CUSTOM;
new.u.periodic.period = 6;
new.u.periodic.magnitude = 0;
new.u.periodic.offset = 0;
new.u.periodic.phase = 0;
new.u.periodic.envelope.attack_length = 0;
new.u.periodic.envelope.attack_level = 0;
new.u.periodic.envelope.fade_length = 0;
new.u.periodic.envelope.fade_level = 0;
new.u.periodic.custom_len = 306;
new.u.periodic.custom_data = (void *) initstring[effect];
if(ioctl(fp, EVIOCSFF, &new) < 0) {
perror("ioctl");
}
return ret;
}
The full code and bytestrings can be gotten from my svn server, same place as before.
However, even as this ioctl produces exactly same results in the driver as the closed-source initialization, I stll cannot make the device vibrate. There is some element I am missing here in the process.
Actually it just occured to me, how is the initialization done in nitdroid? The vibra device works there. Is the initialization sequence there on an open source component?
| The Following User Says Thank You to juiceme For This Useful Post: | ||
|
|
2012-09-21
, 09:18
|
|
Posts: 6,436 |
Thanked: 12,699 times |
Joined on Nov 2011
@ Ängelholm, Sweden
|
#25
|
i can't remember if nitdroid support vibra.
|
|
2012-09-21
, 17:33
|
|
Community Council |
Posts: 4,920 |
Thanked: 12,867 times |
Joined on May 2012
@ Southerrn Finland
|
#26
|
Originally Posted by coderus
Oh my!
i can't remember if nitdroid support vibra.
That was my mistake, I just had to actually check it tpo belive it, and it is true, I could not get it to vibrate.
I somehow remembered it did work on nitdroid.
| The Following User Says Thank You to juiceme For This Useful Post: | ||
|
|
2012-10-24
, 20:52
|
|
Posts: 52 |
Thanked: 33 times |
Joined on Oct 2011
@ Poland, Tricity
|
#27
|
Originally Posted by juiceme
So did I understood this right - you've managed to "play" some predefined vibration on init? If so I would be interested in source or preferably even a working binary :-). I'd like to change my preinit so that phones vibrates when the system is ready for choosing my system.
OK, I have bee struggling with the vibration device for some time, as it was extremely annoying why I could not make it work.
I did quite a lot of searching, before it hit home that the device actually needs to be initialized with a set of waveform samples before it is usable. I kind of thought it is enough to write a set of input_event structures to it to make it work, but turns out those events only trigger the internal works to play out a pre-loaded sample on the vibrator device.
[...]
BTW. Have you tried a to play few low notes to make a tick sound rather then vibration? Or maybe even play some wav?
|
|
2012-10-25
, 10:10
|
|
Posts: 52 |
Thanked: 33 times |
Joined on Oct 2011
@ Poland, Tricity
|
#28
|
So I made some tests and I found out that I would probably need to initialize PulseAudio somehow to play sounds. Or at least when using `/usr/bin/aplay` I get this error:
But I also noticed that devices in /dev/snd have different rights in preinit and after booted to MeeGo (when booted the group is audio). Do you think it would be wise to change the group and in preinit and try that? Or maybe of more importance - dsp seem to be unavailable and I have no clue how to initialize it.
Oh and BTW - I did try what seemed to be easier to just beep in console. But neither of below work :-(.
In preinit there are also many links missing like vibra -> event4 - which might be more interesting for you, if you still want to vibrate.
This is in preinit stage:
This is after booting:
Maybe there are some internal dependencies to /dev/input/vibra being available? I know this is a long shot, but I've actually seen worse things ;-).
Code:
ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Connection refused
Oh and BTW - I did try what seemed to be easier to just beep in console. But neither of below work :-(.
Code:
echo -ne '\007' echo -ne '\007' > /dev/tty echo -ne '\007' > /dev/console
This is in preinit stage:
Code:
event4 crw------- 1 root root 13, 68
Code:
event4 crw-rw---- 1 root input 13, 68 vibra -> event4 lrwxrwxrwx 1 root root 6
|
|
2012-10-27
, 09:42
|
|
Community Council |
Posts: 4,920 |
Thanked: 12,867 times |
Joined on May 2012
@ Southerrn Finland
|
#29
|
Hi eccenux, thanks for the tip.
Actually I have not tried to play sounds, I was so fixed on the idea of getting the vibration device working I did not think about outputting a clicking sound. That would probably work OK for keypress confirmation too.
As for status update on the vibration device initialization, I have not been actively trying to crack that nut for saome time now, as I have been otherwise enganged.
Anyway, as I state in my posting about four weeks ago, I managed to fish out the initialization sequences out from the closed-source library that does the init by building a debug version of vibration device that logs the given sequences.
Turns out there are 32 different samples that are each 306 words long. However, even as I initialize the device with exactly the same data, still I could not make it vibrate, there is something else that is needed.
You can load the source code for the initialization from my svn repository, https://toosa.swagman.org/svn/sillykbd/TRUNK/ The initialization routine and data is in the file "vibra_test.c"
Please test it, and if you find out what is missing/wrong in the initialization I would really like to hear!
Actually I have not tried to play sounds, I was so fixed on the idea of getting the vibration device working I did not think about outputting a clicking sound. That would probably work OK for keypress confirmation too.
As for status update on the vibration device initialization, I have not been actively trying to crack that nut for saome time now, as I have been otherwise enganged.
Anyway, as I state in my posting about four weeks ago, I managed to fish out the initialization sequences out from the closed-source library that does the init by building a debug version of vibration device that logs the given sequences.
Turns out there are 32 different samples that are each 306 words long. However, even as I initialize the device with exactly the same data, still I could not make it vibrate, there is something else that is needed.
You can load the source code for the initialization from my svn repository, https://toosa.swagman.org/svn/sillykbd/TRUNK/ The initialization routine and data is in the file "vibra_test.c"
Please test it, and if you find out what is missing/wrong in the initialization I would really like to hear!
| The Following User Says Thank You to juiceme For This Useful Post: | ||
|
|
2012-10-29
, 03:05
|
|
Posts: 52 |
Thanked: 33 times |
Joined on Oct 2011
@ Poland, Tricity
|
#30
|
Thanks. I've tried to dig around for sound initialization (alsa/pulse), but eventually gave up. There seem to be to much to it.
I poked vibration a bit but didn't had too much luck. I did found hid-twl4030-vibra module which seem to be used in various places, but just loading it didn't work. Maybe some of my findings will help you:
Anyway for now I gave up on both (sounds and vibrations). I'm going for a different approach and using image feedback. It almost works as I expect but sometimes I need to rub the screen rather then just hold my finger. Don't know why this happens. Maybe you could have a look (attached tar with all files)?
I poked vibration a bit but didn't had too much luck. I did found hid-twl4030-vibra module which seem to be used in various places, but just loading it didn't work. Maybe some of my findings will help you:
- There are some *.ivt files on N9 which seem to be files for vibration. Haven't found a way to "play" them.
- There are some rules for udev that seem to be vibration related in: "/etc/udev/rules.d/92-n770.rules".
- /sbin/immvibed uses vibrations heavily, but have no idea how to use it even when the MeeGo system is fully loaded. If you'll look in the file you'll notice that there seem to be a dependency on "/dev/input/vibra" which is not available in preinit phase.
- Also it seems vibrations where made by Kurre from Nokia. Maybe you could contact him and he would be kind enough to help? :-)
Anyway for now I gave up on both (sounds and vibrations). I'm going for a different approach and using image feedback. It almost works as I expect but sometimes I need to rub the screen rather then just hold my finger. Don't know why this happens. Maybe you could have a look (attached tar with all files)?
I did quite a lot of searching, before it hit home that the device actually needs to be initialized with a set of waveform samples before it is usable. I kind of thought it is enough to write a set of input_event structures to it to make it work, but turns out those events only trigger the internal works to play out a pre-loaded sample on the vibrator device.
There is some user-space utility that initializes the vifrator device with the waveform samples in init phase, and that was the reason I could not tickle it in pre-init phase.
So, I added some debug code to vibra_spi.c, recompiled the module and was actually able to capture the data needed to initialize it. It turns out there are 36 different sample sequences, each 612 bytes long, that need to be fed to the device.
Here is one sample aas seen on kernel log:
meegofeedbackd_0.10.7-5+0m6.tar
meegofeedback-reactionmaps_0.15.1-3+0m8.tar