Hi, see below On 04/01/2014 01:02 PM, 황석연 wrote: > Hi stanislav, > > > > How did you configure jenkins slave machine ?? I didn't do any special configuration at all
> > > > We run jenkins agent at slave with a command "javaws > http://jenkins_master_ip:port/computer/Windows-8-32/slave-agent.jnlp";, > > and then I access "jenkins_master" via web interface and run the test. I just open the browser in slave, got to http://jenkins/computer/test and click "Launch" - that launches the agent. I then start the test. > > > > I tried it again with new "check-gl" you just modified, > > I got "ERROR - Unable to obtain WGL extension string" that is the exact same > result with RDP. It looks like your jenkins agent opens some new session that's not interactive, that's why WGL fails. I think it may be because you've installed jenkins as a service earlier, can you check the service list, does it contains jenkins ? > > > > In real console (not RDP or jenkins slave), a "check-gl" produce > > INFO - Host OpenGL 2.1 - supported > INFO - + GL_VENDOR = NVIDIA Corporation > INFO - + GL_RENDERER = GeForce GT 620/PCIe/SSE2 > INFO - + GL_VERSION = 4.4.0 > INFO - Host OpenGL 3.1 - supported > INFO - + GL_VENDOR = NVIDIA Corporation > INFO - + GL_RENDERER = GeForce GT 620/PCIe/SSE2 > INFO - + GL_VERSION = 4.4.0 > INFO - Host OpenGL 3.2 - supported > INFO - + GL_VENDOR = NVIDIA Corporation > INFO - + GL_RENDERER = GeForce GT 620/PCIe/SSE2 > INFO - + GL_VERSION = 3.2.0 > INFO - Guest OpenGL ES v1_CM - supported > INFO - Guest OpenGL ES 2.0 - supported > INFO - Guest OpenGL ES 3.0 - supported > INFO - Host has hardware GL acceleration! > > > > > > ------- *Original Message* ------- > > *Sender* : Stanislav Vorobiov<[email protected]> Expert > Engineer/SRR-Tizen S/W Group/삼성전자 > > *Date* : 2014-03-28 18:22 (GMT+09:00) > > *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL acceleration. > > > > Hi, > > I've just tried launching jenkins job via JNLP, the job consists of launching > check-gl.exe, here's the output: > > Started by user stas > Building remotely on nvidia (emul) in workspace workspace/test > [test] $ cmd /c call > C:\Users\testuser\AppData\Local\Temp\hudson4187968535345557759.bat > > C:\Users\testuser\AppData\Local\Temp\workspace\test>check-gl.exe > WGL_ARB_render_texture supported! > Render to texture supported, add attributes in array! > GL VENDOR NVIDIA Corporation > GL RENDERER GeForce GT 240/PCIe/SSE2 > GL VERSION 3.3.0 > glFormat: 0x000080E1 glType: 0x00001401 > > C:\Users\testuser\AppData\Local\Temp\workspace\test>exit 0 > Finished: SUCCESS > > It looks like it succeeded, or am I doing something wrong ? > > On 03/28/2014 10:28 AM, SeokYeon Hwang wrote: >> @ stanislav, >> >> >> >> Thank you very much. >> >> You are the best !!! >> >> >> >> >> >> ------- *Original Message* ------- >> >> *Sender* : Stanislav VorobiovExpert Engineer/SRR-Tizen S/W Group/삼성전자 >> >> *Date* : 2014-03-28 14:46 (GMT+09:00) >> >> *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL acceleration. >> >> >> >> Hi, see below >> >> On 03/28/2014 09:25 AM, 황석연 wrote: >>> The legacy "VirtGL" logic is planned to be removed from the next version of >>> Tizen emulator. >>> >>> Is there any possibility that "check-gl" is falsely valued even when YaGL >>> could be enabled because of the differences between check-gl based on >>> "VirtGL" and "YaGL"? >> Don't think so, but anyway, check-gl is part of VirtGL code and if that's >> going to be removed then I guess we need to at least remove VirtGL >> dependencies, >> so ok, I'll update it. >> >>> >>> Also, in regard to GL acceleration enable in remote, I'd like to test why >>> check-gl fails when ran using Jenkins. >>> However, because of my lack of knowledge in this context, I can't decide >>> where to put what log in check-gl. >>> If you can advise me on how to modify check-gl and what information is >>> needed, I'll run check-gl through Jenkins and notify you of the results. >> I see. I think I'll need to see this for myself, I'll install jenkins and >> take a look at that failure, I'll then let you know. >> I'll also update check-gl to be more verbose so that the reason for failure >> is clear. >> >> Thanks. >> >>> >>> >>> >>> Thanks. >>> >>> >>> >>> ------- *Original Message* ------- >>> >>> *Sender* : Stanislav VorobiovExpert Engineer/SRR-Tizen S/W Group/삼성전자 >>> >>> *Date* : 2014-03-25 19:02 (GMT+09:00) >>> >>> *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL acceleration. >>> >>> >>> >>> Hi, >>> >>> And what kind of information "check-gl" should produce exactly ? >>> Technically, we don't have any >>> "extra" OpenGL requirements comparing to VirtGL's, but we can run in >>> several "modes": >>> * legacy - Using host OpenGL 2.1, this limits guest to OpenGL ES v1 and v2 >>> * OpenGL 3.1 - Using OpenGL core contexts, this still limits guest to >>> OpenGL ES v1 and v2 >>> * OpenGL 3.1 + GL_ARB_ES3_compatibility - Same as above, but guest can also >>> run OpenGL ES v3 >>> * OpenGL 3.2 - Same as above, but with guest shader translation >>> Would this information be useful in check-gl ? Also, what are use-cases for >>> check-gl, is it only >>> running from emulator-manager to check if GPU switch should be enabled ? If >>> yes, then no rewriting >>> is required >>> >>> On 03/25/2014 07:36 AM, SeokYeon Hwang wrote: >>>> Hi stanislav, jinhyoung Jo. >>>> >>>> >>>> >>>> Could you rewrite "check-gl" for Windows, Linux and Mac ?? >>>> >>>> Current "check-gl" produce only restrict information and it was made based >>>> on the legacy "VirtGL". >>>> >>>> I think now is a good time to upgrade "check-gl" including kind logs. >>>> >>>> >>>> >>>> What do you think about it ? >>>> >>>> >>>> >>>> ------- *Original Message* ------- >>>> >>>> *Sender* : Stanislav VorobiovExpert Engineer/SRR-Tizen S/W Group/삼성전자 >>>> >>>> *Date* : 2014-03-24 17:35 (GMT+09:00) >>>> >>>> *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL acceleration. >>>> >>>> >>>> >>>> Hi, >>>> >>>> The problem with RDP is not that it's unable to draw stuff, but acquiring >>>> the right device, RDP sessions >>>> use DISPLAY_DEVICE_MIRRORING_DRIVER instead of >>>> DISPLAY_DEVICE_PRIMARY_DEVICE as you mentioned yourself >>>> earlier and you can't have GL or DirectX acceleration with that. That's >>>> why there're things such as RemoteFX - you can try >>>> using that, but I'm not sure that it'll work for OpenGL (it works for >>>> DirectX) and there're some special OS requirements for it. >>>> >>>> But what I don't understand why doesn't jenkins agent work with GL, it >>>> should work. Are there any logs, what >>>> do they say ? Sorry, but I really don't understand what RDP has to do with >>>> all this... >>>> If you want to use RDP for more than jenkins, i.e. remote display then >>>> IMHO it probably won't do, it'll not be able >>>> to utilize host GPU resources >>>> >>>> On 03/24/2014 11:56 AM, SeokYeon Hwang wrote: >>>>> Unfortunately it doesn't work. >>>>> >>>>> We should try to find the way. >>>>> >>>>> >>>>> >>>>> Anyway, is there no way to enable GL acceleration on windows RDP ?? >>>>> >>>>> Even though it could not draw on real display - we can not see that, It's >>>>> OK. >>>>> >>>>> It can be used for remote display or remote auto testing. >>>>> >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> ------- *Original Message* ------- >>>>> >>>>> *Sender* : Stanislav VorobiovExpert Engineer/SRR-Tizen S/W Group/삼성전자 >>>>> >>>>> *Date* : 2014-03-19 16:19 (GMT+09:00) >>>>> >>>>> *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL acceleration. >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I see. Is jenkins agent configured as a windows service ? If yes, m.b. >>>>> this can help: >>>>> >>>>> http://jenkins-ci.361315.n4.nabble.com/DirectX-and-Jenkins-td4525448.html >>>>> >>>>> IMHO this problem is not related to RDP at all, jenkins does not use RDP, >>>>> it simply runs your app >>>>> and can't initialize OpenGL since service may not be allowed to be >>>>> interactive. Does jenkins slave >>>>> service has "allowed interactive" enabled in service properties ? >>>>> >>>>> On 03/19/2014 10:51 AM, SeokYeon Hwang wrote: >>>>>> We already running auto-test exactly same method described that >>>>>> instruction. >>>>>> >>>>>> We can run emulator and can do test, but we can not enable GL >>>>>> acceleration and can not run GL test. >>>>>> >>>>>> Maybe, the jenkins JNLP agent using windows RDP logic. >>>>>> >>>>>> >>>>>> >>>>>> You can test it using "windows remote desktop". >>>>>> >>>>>> 1. In PC (A), Windows, open "cmd" window. >>>>>> >>>>>> 2. Run "[TIZEN_SDK]/tools/emulator/bin/check-gl.exe". It may produce >>>>>> positive results. >>>>>> >>>>>> 3. In PC (B), connect to PC (A) via "mstsc.exe" (Windows Remote Desktop >>>>>> client). >>>>>> >>>>>> 4. You can see already opened "cmd" window that contains positive result >>>>>> of "check-gl.exe". >>>>>> >>>>>> 5. Run "[TIZEN_SDK]/tools/emulator/bin/check-gl.exe". It may produce >>>>>> negative results. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------- *Original Message* ------- >>>>>> >>>>>> *Sender* : Stanislav VorobiovExpert Engineer/SRR-Tizen S/W Group/삼성전자 >>>>>> >>>>>> *Date* : 2014-03-19 14:58 (GMT+09:00) >>>>>> >>>>>> *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL acceleration. >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I didn't use jenkins for quite a while and I don't have it installed to >>>>>> check, but >>>>>> it seems that jenkins can run tests using interactive logon, thus, it >>>>>> can run accelerated apps. >>>>>> >>>>>> Some quick googling shows: >>>>>> >>>>>> http://stackoverflow.com/questions/19441324/how-to-run-gui-tests-on-a-jenkins-windows-slave-without-remote-desktop-connectio >>>>>> >>>>>> On 03/19/2014 06:25 AM, SeokYeon Hwang wrote: >>>>>>> We are running auto-test using "jenkins". >>>>>>> >>>>>>> A "jenkins" master node trigger "tests" in slave nodes with various OS >>>>>>> via JNLP Agent. >>>>>>> >>>>>>> We can use GL acceleration with linux, macos slaves, but we can not use >>>>>>> it with Windows slaves. >>>>>>> >>>>>>> That is our issue currently encountered. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------- *Original Message* ------- >>>>>>> >>>>>>> *Sender* : Stanislav VorobiovExpert Engineer/SRR-Tizen S/W Group/삼성전자 >>>>>>> >>>>>>> *Date* : 2014-03-18 21:36 (GMT+09:00) >>>>>>> >>>>>>> *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL acceleration. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Thanks, but our case is to run the emulator itself remotely, i.e. this >>>>>>> is a little different. >>>>>>> >>>>>>> BTW, TigerVNC indeed works, OpenGL apps and emulator can be launched >>>>>>> remotely but within a single session. >>>>>>> SeokYeon, will that do for auto-tests ? >>>>>>> >>>>>>> On 03/18/2014 04:05 PM, Roman Kubiak wrote: >>>>>>>> x11vnc works well, i tested it with the M0 target and got the tizen >>>>>>>> display from the phone on my desktop. I remember doing the same trick >>>>>>>> @home with XBMC, and i know XBMC uses some sort of hardware >>>>>>>> acceleration technique to run so x11vnc mirrors >>>> that, but >>>>>>>> you'll need to install it inside the emulator, i had to build it >>>>>>>> myself for ARM. >>>>>>>> >>>>>>>> best regards >>>>>>>> On 03/18/2014 12:50 PM, Stanislav Vorobiov wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Is it so important to use RDP, why not try VNC ? IMHO this topic >>>>>>>>> covers it: >>>>>>>>> >>>>>>>>> http://www.opengl.org/discussion_boards/showthread.php/164372-Remote-Desktop >>>>>>>>> >>>>>>>>> On 03/18/2014 01:43 PM, 황석연 wrote: >>>>>>>>>> So using GL acceleration via DISPLAY_DEVICE_PRIMARY_DEVICE within >>>>>>>>>> Windows remoting session is impossible ?? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Or, could you try this ?? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------- *Original Message* ------- >>>>>>>>>> >>>>>>>>>> *Sender* : Stanislav VorobiovExpert Engineer/SRR-Tizen S/W Group/삼성전자 >>>>>>>>>> >>>>>>>>>> *Date* : 2014-03-18 15:47 (GMT+09:00) >>>>>>>>>> >>>>>>>>>> *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL >>>>>>>>>> acceleration. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Oh, you mean you launch QEMU itself from withing remoting session >>>>>>>>>> and GL caps test doesn't pass. Yes this is expected. >>>>>>>>>> >>>>>>>>>> Have you tried doing it on linux ? m.b. AIGLX can help in this case. >>>>>>>>>> >>>>>>>>>> And regarding windows RDP, quick googling revealed that you can't >>>>>>>>>> have 3D acceleration in remote sessions, though it's possible, but >>>>>>>>>> it's really slow >>>>>>>>>> and this is for DirectX only and I'm not sure if it'll work for >>>>>>>>>> OpenGL: >>>>>>>>>> >>>>>>>>>> http://stackoverflow.com/questions/272537/direct3d-over-remote-desktop >>>>>>>>>> >>>>>>>>>> On 03/18/2014 08:03 AM, SeokYeon Hwang wrote: >>>>>>>>>>> I'm not talking about a specific issue. >>>>>>>>>>> >>>>>>>>>>> I'd like to discuss about the possible solutions regarding the >>>>>>>>>>> auto-test issues, and add new functionalities if needed. >>>>>>>>>>> >>>>>>>>>>> Currently, it is possible to use "spice" on Linux host. >>>>>>>>>>> >>>>>>>>>>> However, on Windows host, it is unfeasible to run tests using Spice >>>>>>>>>>> because of the Spice server's inability to support Windows host yet. >>>>>>>>>>> >>>>>>>>>>> So, I suggest running tests using Windows RDP for now. >>>>>>>>>>> >>>>>>>>>>> (I haven't yet found out whether Windows RDP can send screens drawn >>>>>>>>>>> with GL to clients or not. >>>>>>>>>>> >>>>>>>>>>> Even if it can't send the screens, as long as it can be enabled we >>>>>>>>>>> may use it in auto-tests.) >>>>>>>>>>> >>>>>>>>>>> The first issue we encouter is that it cannot pass the GL >>>>>>>>>>> capability test when connected remotely from RDP. >>>>>>>>>>> >>>>>>>>>>> When we run "check-gl.exe" in Tizen SDK, the result becomes false. >>>>>>>>>>> >>>>>>>>>>> It is because of the fact that the display device is >>>>>>>>>>> DISPLAY_DEVICE_MIRRORING_DRIVER. >>>>>>>>>>> >>>>>>>>>>> If we can find a solution to this issue, we can at least solve the >>>>>>>>>>> auto-test issue. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If you have any other suggestions, please feel free to tell me. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------- *Original Message* ------- >>>>>>>>>>> >>>>>>>>>>> *Sender* : Stanislav VorobiovExpert Engineer/SRR-Tizen S/W >>>>>>>>>>> Group/삼성전자 >>>>>>>>>>> >>>>>>>>>>> *Date* : 2014-03-17 17:40 (GMT+09:00) >>>>>>>>>>> >>>>>>>>>>> *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL >>>>>>>>>>> acceleration. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi, SeokYeon >>>>>>>>>>> >>>>>>>>>>> So, if I understand correctly, you've launched the emulator on one >>>>>>>>>>> machine and >>>>>>>>>>> then try to connect to it from different machine using RDP, right ? >>>>>>>>>>> >>>>>>>>>>> So, RDP basically presents QEMU graphic console contents to the >>>>>>>>>>> client, i.e. GL acceleration >>>>>>>>>>> should happen on server as usual, right ? >>>>>>>>>>> >>>>>>>>>>> How can I reproduce this ? What command line should be used to >>>>>>>>>>> launch qemu in server mode so >>>>>>>>>>> RDP clients are able to connect ? >>>>>>>>>>> >>>>>>>>>>> Do I need some special RDP client or can I use standard window's >>>>>>>>>>> RDP for example ? >>>>>>>>>>> >>>>>>>>>>> On 03/17/2014 12:18 PM, SeokYeon Hwang wrote: >>>>>>>>>>>> Yes, the remote approach is likely to be based on "spice", or any >>>>>>>>>>>> other solution with similar features. >>>>>>>>>>>> >>>>>>>>>>>> When considering remote execution, we have to run the emulator >>>>>>>>>>>> from remote, >>>>>>>>>>>> >>>>>>>>>>>> and bring the screen to us using "spice" or a similar solution. >>>>>>>>>>>> >>>>>>>>>>>> But, there's a problem. >>>>>>>>>>>> >>>>>>>>>>>> When we use Windows Remote Desktop to connect and run GL >>>>>>>>>>>> capability tests, the result is "false". >>>>>>>>>>>> >>>>>>>>>>>> Because the device which Remote Desktop uses does not utilize >>>>>>>>>>>> DISPLAY_DEVICE_PRIMARY_DEVICE which supports GL, but rather >>>>>>>>>>>> DISPLAY_DEVICE_MIRRORING_DRIVER. >>>>>>>>>>>> >>>>>>>>>>>> (http://msdn.microsoft.com/en-us/library/windows/desktop/dd183569%28v=vs.85%29.aspx) >>>>>>>>>>>> >>>>>>>>>>>> While different from Windows, Linux is believed to have >>>>>>>>>>>> limitations in GL acceleration as well. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The same thing happens when we run tests using CI tools such as >>>>>>>>>>>> Jenkins, >>>>>>>>>>>> >>>>>>>>>>>> since the Jenkins' master node connects to each of the OS slave >>>>>>>>>>>> nodes and run the tests. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Being not an expert about these issues, I'd like to discuss and >>>>>>>>>>>> find solutions together. >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ------- *Original Message* ------- >>>>>>>>>>>> >>>>>>>>>>>> *Sender* : Stanislav VorobiovExpert Engineer/SRR-Tizen S/W >>>>>>>>>>>> Group/삼성전자 >>>>>>>>>>>> >>>>>>>>>>>> *Date* : 2014-03-14 15:36 (GMT+09:00) >>>>>>>>>>>> >>>>>>>>>>>> *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL >>>>>>>>>>>> acceleration. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi, SeokYeon >>>>>>>>>>>> >>>>>>>>>>>> Could you provide more info on the remote approach being used ? >>>>>>>>>>>> It's based on spice, right ? >>>>>>>>>>>> >>>>>>>>>>>> What does "PRIMARY DISPLAY DEVICE" mean in this context ? >>>>>>>>>>>> >>>>>>>>>>>> What does "emulator remote execution" and "emulator GL auto test >>>>>>>>>>>> on CI tool" mean ? >>>>>>>>>>>> >>>>>>>>>>>> These lines: >>>>>>>>>>>> >>>>>>>>>>>>> It does not need to draw screen on "MONITOR SCREEN" connected to >>>>>>>>>>>>> remote host PC. >>>>>>>>>>>>> >>>>>>>>>>>>> In case of "emulator remote execution", the drawing image can get >>>>>>>>>>>>> another way into my "MONITOR SCREEN". >>>>>>>>>>>> Are also not clear to me. Could you give some overview of this so >>>>>>>>>>>> that we could >>>>>>>>>>>> get a better picture of what's going on. >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> On 03/14/2014 06:12 AM, 황석연 wrote: >>>>>>>>>>>>> Hi, stanislav and other emulator GL acceleration developer. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> When we connect host PC on remote, we can not trun on GL >>>>>>>>>>>>> acceleration. >>>>>>>>>>>>> >>>>>>>>>>>>> Because "remote desktop" did not use PRIMARY DISPLAY DEVICE. >>>>>>>>>>>>> >>>>>>>>>>>>> Is there no method to enable GL acceleration on remote ?? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It is related with "emulator remote execution" and "emulator GL >>>>>>>>>>>>> auto test on CI tool". >>>>>>>>>>>>> >>>>>>>>>>>>> How can we use GL acceleration via remote connection ? >>>>>>>>>>>>> >>>>>>>>>>>>> It does not need to draw screen on "MONITOR SCREEN" connected to >>>>>>>>>>>>> remote host PC. >>>>>>>>>>>>> >>>>>>>>>>>>> In case of "emulator remote execution", the drawing image can get >>>>>>>>>>>>> another way into my "MONITOR SCREEN". >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Dev mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> https://lists.tizen.org/listinfo/dev >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> [email protected] >>>>>>>>> https://lists.tizen.org/listinfo/dev >>>>>>>> >>>>>>>> -- >>>>>>>> -------------- >>>>>>>> Roman Kubiak >>>>>>>> -------------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.tizen.org/listinfo/dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> > > > > > > > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
