Re: [E-devel] E CVS: libs/evas raster

On Sat, 31 May 2008 13:17:42 -0400 Jose Gonzalez <jose_ogp <at> juno.com> babbled:

>    Gustavo wrote:
> > I believe it's up to OS to save/restore all the registers when you
> > change threads. Am I wrong?
> 
>       I have no idea what happens with this, or how using multiple cpu
> cores affects that.

that was my point. it is THREAD SAFE. the os restores registers and cpu state
between context switches between threads/processes. its internal
process/threads state with the mmx/sse/fp state. the fact that pipes
restructured what gets called and how the calls get called and in what stages
they get called that brought it out reliably in certain situations. you will
find MOST of the drawing calls do NOT gaurd themselves on exit with an emms
(evas_cpu_end_opt). the only one actually was the line draw. no others do.
doing an end_opt at every draw call is not cheap - on older cpu's definitely
not. as most of evas's calls use NO floating point (and the polygon stuff
really doesn't need to - i should remove that) there is nigh zero need for what
is a mostly useless call - and so it can go at the end of the pipeline or just
before any of the rare fp calls. again - nothing to do with threads. all to do
with streamlined rendering pipelines.

> >>      There is much too great a difference in the behavior of the
> >> code with vs. without pipes to say for certain that the code-execution
> >> paths are well understood.
> >>     
> >
> > But do you remember my tests where I disabled the other threads, just
> > launching one and still having this behavior?

Re: [E-devel] E CVS: libs/evas raster

   Gustavo wrote:

>>>>      The issue isn't one of safety in the sense of circular
>>>> referencing, it's mmx/fp 'safety', ie. that we know for certain
>>>> that the execution paths aren't being interrupted in such a way
>>>> that although you think you've released mmx registers, and thus
>>>> the next guy is free to use fp ops.. that maybe isn't so.
>>>>         
>>> I believe it's up to OS to save/restore all the registers when you
>>> change threads. Am I wrong?
>>>       
>>      I have no idea what happens with this, or how using multiple cpu
>> cores affects that.
>>     
>>>>      There is much too great a difference in the behavior of the
>>>> code with vs. without pipes to say for certain that the code-execution
>>>> paths are well understood.
>>>>         
>>> But do you remember my tests where I disabled the other threads, just
>>> launching one and still having this behavior?
>>>       
>>      As I understood you, as soon as you disabled pipes the problems
>> disappeared - presumably mmx is being released adequately, and indeed
>> I know of no cases where a problem has being observed (with recent cvs)
>> without pipes or on single-core systems. And when you enable pipes again,
>> the problem came back immediately. That's what I thought you obsrved
>> (among other things).
>>      If that's so, then why is this ocurring.. what is the exact code
>> path that's being executed that causes such a radical change? This needs
>> to be understood far better than what I've seen in any remarks made by

Re: [E-devel] E CVS: libs/evas raster

   Carsten wrote:

> On Sat, 31 May 2008 13:17:42 -0400 Jose Gonzalez <jose_ogp <at> juno.com> babbled:
>
>   
>>    Gustavo wrote:
>>     
>>> I believe it's up to OS to save/restore all the registers when you
>>> change threads. Am I wrong?
>>>       
>>       I have no idea what happens with this, or how using multiple cpu
>> cores affects that.
>>     
>
> that was my point. it is THREAD SAFE. the os restores registers and cpu state
> between context switches between threads/processes. its internal
> process/threads state with the mmx/sse/fp state. the fact that pipes
> restructured what gets called and how the calls get called and in what stages
> they get called that brought it out reliably in certain situations. you will
> find MOST of the drawing calls do NOT gaurd themselves on exit with an emms
> (evas_cpu_end_opt). the only one actually was the line draw. no others do.
> doing an end_opt at every draw call is not cheap - on older cpu's definitely
> not. as most of evas's calls use NO floating point (and the polygon stuff
> really doesn't need to - i should remove that) there is nigh zero need for what
> is a mostly useless call - and so it can go at the end of the pipeline or just
> before any of the rare fp calls. again - nothing to do with threads. all to do
> with streamlined rendering pipelines.
>
>   
>>>>      There is much too great a difference in the behavior of the

Re: [E-devel] touchscreen calibration

Hello,
  Another thought that occurred to me.  Say I decided to dump X and work
directly via the frame buffer (have thought about this before).  Are
these functions touchscreen agnostic?  Or will there be gotchas between
different manufacturers?  Thoughts on what works, what doesn't?  

Thanks,
Jess

On Thu, 2008-05-29 at 20:06 -0400, jess wrote:
> Hi,
>   Thanks for the reply.  I understand that the X server will handle
> communication, but I have noticed next to no support for calibrating the
> devices from the manufacturer for recent kernels.  The only thing I have
> been able to find are several different touchcal source packages which
> are no longer maintained.  These are based on ncurses, take three points
> of reference and provide you with the "MinX|MaxX|MinY|MaxY" option
> values for the microtouch driver (xserver-xorg-microtouch).  I was
> hoping to be able to whip something up with EFL that would do similar
> (to avoid having to stop/calibrate/change xorg/restart X ).
> 
> Let me know if you have any further thoughts.
> 
> Thanks,
> Jess
> 
> 
> On Thu, 2008-05-29 at 20:24 +0200, raoul wrote:
> > Le jeudi 29 mai 2008, jess a écrit :
> > > Hello,

Re: [E-devel] E CVS: libs/evas raster

   I wrote:

>> ..............
>> ..............
>>
>> the fact that now there was basically nothing between draw calls to guard
>> against fp op safety - as fp ops were not being used mostly, means that it was
>> much more likely u ended up with the cpu in a non emms state before doing fp
>> ops. even so i found it hard to reproduce in a simple test case - i needed the
>> whole gradient dialog in e to bring it out. (i found that edje_test - the old
>> one did it too eventually). my simple "display a white rectangle and a gradient
>> on top only) test app didnt show the bug. the draw pipeline was too simple and
>> had no mmx/sse state change before drawing the gradient - that is why.
>>
>> as such in the old code in some circumstances the cpu was lest in a bad fp
>> state before entering the gradient draw code - but only very rarely.
>>
>> so i repeat - the code as such is threadsafe. mmx/sse state is separate to
>> threads entirely. the only bit of code outside the gradient code that did fp
>> ops was suitably guarded before doing fps ops. it's much cheaper to guard
>> before the much rarer use of fps ops than guard on every exit from possible
>> mmx/sse ops.
>>
>>   
>>     
>       Let me read thru this is more detail.. But basically Carsten,
> there's a problem with the pipes implementation, or they are somehow
> showing a prior problem of - adequately relasing mmx. One can't
> have this willy-nilly, either one can count on things to do what
> they're supposed to do or fix it. You need to pass floats around,

[E-devel] evilized Efreet

Hey,

here is a patch for Efreet, so that it compiles on Windows, using Evil. I 
had to reorganized the header files and i put only the requested ones in 
each source file, because of EAPI nightmare on Windows. It's the cleanest 
way to fix that problem.

It compiles on Windows, but the tests are not all "passed" (some are 
specifically written for a Unix file system). It's just a matter of 
compiling it, for now. My aim being the toolkits, as ewl uses efreet, I'll 
fix only the requested part of efreet so that it will work with ewl.

I've not tested it on Linux, can someone test it on that platform ? If it 
is good, I'll commit the patch

thank you

Vincent

? efreet.diff
? m4/libtool.m4
? m4/ltoptions.m4
? m4/ltsugar.m4
? m4/ltversion.m4
? m4/lt~obsolete.m4
Index: configure.in
===================================================================
RCS file: /cvs/e/e17/libs/efreet/configure.in,v
retrieving revision 1.21

[E-devel] Nightly build log for E17 on 2008-06-01 07:10:54 -0700

Build log for Enlightenment DR 0.17 on 2008-06-01 07:10:54 -0700
Build logs are available at http://download.enlightenment.org/tests/logs

Packages that failed to build:
edvi  http://download.enlightenment.org/tests/logs/edvi.log
enna  http://download.enlightenment.org/tests/logs/enna.log
epdf  http://download.enlightenment.org/tests/logs/epdf.log
evolve  http://download.enlightenment.org/tests/logs/evolve.log
express  http://download.enlightenment.org/tests/logs/express.log

Packages with no supported build system:
entice, esmart_rsvg, exorcist, python-efl, 

Packages skipped:
camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, 
etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, 
ruby-efl, webcam, 

Packages that build OK:
alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, 
edb, e_dbus, edje_editor, edje, edje_viewer, eet, eflame, eflpp, efm_nav, 
efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, 
emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, 
enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, 
epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, 
etk, etk-perl, evas, evfs, ewl, examine, execwatch, exhibit, exml, expedite, 
exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, 
imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, 
net, news, notification, penguins, pesh, photo, rage, rain, screenshot, 
scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, 

Re: [E-devel] E CVS: libs/evas raster

Thank you all for fixing it :)
Now Edjy can work on everyones systems! Yay! :)
Toma

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[E-devel] Tiling module: new URL and merge request

Hi,

I've just now migrated the tiling module from the old server dev.twice-irc.de
to code.stapelberg.de with a working CACert-SSL-certificate and IPv6-support.
You can now find it at https://code.stapelberg.de/git/?p=e17-tiling/.git;a=summary
To change your git-repository, just edit .git/config and replace the old URL
with git://code.stapelberg.de/e17-tiling

Of course, the mirror at staff.get-e.org still exists.

Furthermore, I now consider the module stable. I've been using it for nearly
two months and yesterday I fixed the only bug I've encountered during these two
months (only showed up when using xinerama).

Therefore, I'd be happy to see it in official CVS. I've mailed raster about
this, but he seems to be quite busy. If anyone of you wants to merge, please
apply the included desk.patch to apps/e/src/bin first and then put the module
in e_modules/tiling - thanks!

Best regards,
Michael

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [E-devel] touchscreen calibration

Hello,
  Thanks!  I will definitely look into those utilities!

Jess

On Sun, 2008-06-01 at 14:39 +0200, Michael 'Mickey' Lauer wrote:
> On Friday 30 May 2008 02:06:18 jess wrote:
> >   Thanks for the reply.  I understand that the X server will handle
> > communication, but I have noticed next to no support for calibrating the
> > devices from the manufacturer for recent kernels.
> 
> When we see a new device in OpenEmbedded, we compute a couple of touchscreen 
> calibration constants using ts_calibrate (or xtscal) and try these on 
> different production models. Usually the manufacturing variance is not 
> noticable, so we just ship a package with the precalibrated constants.
> 
> If you don't want to do that, just call xtscal on startup of X, or 
> ts_calibrate, if you want to do it without X.
> 
> A couple of years ago, I have also written a touchscreen calibration program 
> based on evas-fb/ecore-fb. It should sit somewhere in proto/eflpp.
> 
> :M:
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/